首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

服务设计要解决的问题

前几天和同事聊天,同事说:   “业务的服务(相对于我们基础架构这边的底层技术)在技术上就需要解决三个问题:分布式、通信和存储。”   ...我回忆之前做业务的时光,觉得确实,再加上一个“服务治理”就差不多了。想想“服务设计要解决的问题”这个话题可以把之前静儿写的很多文章做一个归纳概括。今天做一个总结。 ?...分布式 通常要解决的问题是分布式事务的一致性问题。 刚性事务和柔性事务   刚性事务:严格遵循ACID原则(原子性、一致性、隔离性、持久性)的事务。基本上指的是本地数据库事务。...服务可用性(availability):所有的操作在一定时间内都能得到响应。     分区容错性(partition-tolerance):在网络分区环境下,被分割的节点仍然能对外提供服务。...其中本地资源管理器往往由数据库实现,比如Oracle、DB2都实现了XA接口。MySQL对XA的支持不是很好。而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

38811

缓存设计问题

概述 缓存设计需要关注的点 关注指标: KV大小 读写峰值 命中率 缓存空间大小 置换策略 穿透加载时间 分类 本地缓存 远程缓存 应用模式 Cache Aside Read/Write Through...常见的缓存问题 缓存雪崩 很多使用场景,查询的缓存数据都是由定时任务取刷新,然后缓存查不到从 DB 查了在更新缓存。...就会直接打到 DB 上, 这个时候 DB 很可能被打垮,即使马上重启也会被新的流量打垮。 这种同一时间大量缓存的失效,导致请求直接打到 DB 上的情况, 就是缓存雪崩。...针对这种情况可以: 异步设置热点key过期时间, 提前续上 缓存失效的时候, 加上一个全局的锁再去load db, 避免所有线程都打到db上 hot key 问题 对于某些 key 有非常大的访问量,...在另一篇博客有详细的介绍: MySQL与缓存一致性问题

33110
您找到你想要的搜索结果了吗?
是的
没有找到

过度设计问题

这是学习笔记的第 2069 篇文章 前几天碰到了一个严重的硬件问题导致服务受到影响,我在总结思考的时候,脑袋里冒出了一个观点:过度设计。...问题的背景是这样的,有一套数据仓库的集群,使用了Greenplum技术,里面有不少的segment节点,在最开始设计的时候,因为服务器资源有限,所以在每个服务器上部署了大量的segment节点,假设有200...个segment,如果是10台服务器,那么每台服务器上面就有20个segment,通过这种MPP的设计,可以把计算资源(这里是pg)优势整合起来,同时充分利用硬件资源。...,而在批量计算的过程中一旦因为资源的过度使用而导致集群节点再次出现问题,那么这种问题就是连锁式的,排除这种极端情况,一个服务器上部署了过多的节点,要恢复起来本身也是一件痛苦的事情。...,而过度倾斜就会是上面的这种情况,这种情况下是基于性能的视角来设计的,但是没有充分考虑数据的可用性和可恢复性,所以第三层的设计应该是基于故障的设计方案,我们在设计之初就应该明确服务器是不可靠的,资源是不能完全可靠的

43830

如何避免微服务设计中的耦合问题

如何避免微服务设计中的耦合问题 译自:How to Avoid Coupling in Microservices Design Distributed monolith (分布一体式)是一个幽默的词,...如果忽略了微服务设计实践,不仅会无法克服一体式带来的缺点,也会导致出现新的、复杂的问题或恶化已存在的问题。...一个数据库,一个日志存储位置,一个监控系统,更简单的问题定位,以及端到端测试等等。除非你有充分的理由去使用微服务,否则最好采用同样的理念。 本文将主要关注微服务设计中的松耦合的重要性。...我将给出一些简单的、可以避免耦合和导致分布一体式架构设计的例子。 微服务中的松耦合? 两个系统中,如果修改任意一方的设计、实现或行为不会对另一方造成影响,则称两个服务是松耦合的。...更好的方式是将下游服务容器化,并加载到相同的微服务实例中,以此来避免网络连接问题。 共享过多的领域数据 领域驱动设计(DDD)是将一体式服务拆分为微服务的推荐技术。

1.6K10

过度设计说的根本不是设计问题

很多人说"过度设计(overdesign)"的时候,说的根本不是设计问题,而是“需求蔓延(requirements creep)”。 比如,搜索引擎搜“过度设计”,第一页出来的这个文章: ?...A-业务建模——定位需要改进的目标组织(人群或机构)以及该组织接下来最需要改进的问题。 B-需求——描述为了改进组织的问题,所引入的信息系统必须具有的表现。...---- 即使是看起来真的是说“内部”的设计的,其实有可能还是需求问题,比如,网络上摘的一篇名为《软件开发-什么是过度设计》的文章里举的例子: ?...以上文章以为所说问题是“设计”,其实问题是,考虑了不存在的需求,跟设计过度不过度没什么关系。...更糟糕的是,“过度设计”还成为拒绝思考的遮羞布——我害怕自己“过度设计”,所以干脆就不学习设计了,这样就避免了陷入“过度设计”的陷阱。

72310

系统设计典型问题的思考

系统设计方面的问题问题是非常考验经验和思维过程的,而且和常见的算法问题、语言基础问题不同,涉及的面很广,还没有比较一致的判别标准。但无论如何,还是可以归纳一些常见的思路和典型问题的线索。...缓存设计,分层的数据流动?如何识别热门? 删除微博功能的设计。 2、怎样设计一个短网址映射系统(tiny url 系统) 思考读写模型,明显是读优先级高于写的服务,但是通常不需要修改。...由于属于 web 服务,考虑判定 URL 合法性,考虑怎样控制请求流量和应对恶意访问。 3、怎样设计一个实时聊天系统?...这个问题的特点是客户端和服务端已经天然地分开了,核心问题之一是把服务端和客户端的交互梳理清楚。如果是 BS 结构的,怎样使得从服务端到客户端的消息推送成为可能?...还有一些系统设计典型和经典问题,想到的先列在下面,等后续有时间总结了再补充到上面去: 搜索引擎设计(包括网页爬虫) 邮件系统设计(例如 GMail) 无论如何,对于这些问题的解决,反复思考是非常有趣的。

49120

Mobile Web中URL设计问题

这也说明国内很多IT人员都会在CSDN发表博客,记录解决问题过程或者想法。因为之前在学校主要学习是.NET技术,所以自己的博文基本都是在博客园上。 CSDN博客有桌面版和移动版,2个版本。...这里不知道是最初设计问题,还是程序的问题,我们可以看到path=/,这个值,有可能这是returnurl之类的。具体问题,需要csdn的技术人员说明了。...一般网站的移动版url都会在前面多加“m”开头,表明是移动网页,所以我就去掉m,把url改成了http://blog.csdn.net/blog/jinzheng069/8783370,网站给出了一个500服务器内部错误...从设计的角度来说,我们现在对比一下这2个地址: 移动版 http://m.blog.csdn.net/blog/jinzheng069/8783370 桌面版 http://blog.csdn.net/...当然也有可能是早起设计上的问题,如果吐槽的不对,还请指出。

749100

基于 MongoDB 解决微服务设计中的原子写入问题

借由这些能力,我们很容易在单进程应用中解决原子性方面的问题。但是,微服务架构让应用程序处理并发原子性问题变得更加复杂,这是由分布式系统的复杂性所决定的。...图-影院订座页面 如果使用 MongoDB 来设计影院的场次订座功能,应该如何实现呢?..."201": "N", "202": "Y:user05", ... } } 这里我们大胆使用了一种"预分配"的方式来设计该文档,一个场次的主要信息包括: id:场次的ID...借助这一点,我们也可以巧妙的解决许多并发性的问题。...作者:唐卓章 华为技术专家,多年互联网研发/架设经验,关注NOSQL 中间件高可用及弹性扩展,在分布式系统架构性能优化方面有丰富的实践经验,目前从事物联网平台研发工作,致力于打造大容量高可用的物联网服务

1.2K10

redis缓存设计以及经典问题分析

增强可扩展性 3 缓存代价 系统复杂性提高 存储和部署成本变高 数据一致性问题 4 缓存的三种模式 4.1 Cache Aside 旁路缓存 写操作:更新 DB 之后,直接将 key 从缓存中删除;...缺点: 1、如果删除缓存失败,可能会有问题; 解决方法:失败增加监控 2、如果同时有比较高的QPS访问刚插入或者更新的数据,可能会打垮DB; 解决方法:使用多线程异步执行查询,防止这种问题。...4.2 Read/Write Through 核心思想:读写缓存和 DB 的操作,都有一个中间的数据服务代理。...;方法2: 服务端 限流 事前预防:使用主从节点 构建Redis 缓存高可靠集群 5.2 击穿 概念:1、是发生在某个热点数据失效的场景下,大量请求直接访问 DBDB 压力骤增,业务响应延迟。...读取部分数据删除; hash类型,用Hscan,读取部分数据删除 2、拆分 string类型,拆分成多个key 集合或者hash类型,拆分成多个list或者hash 5.5 热key 概念: 所谓热key问题就是

47410

留心那些潜在的系统设计问题

这种情况发生的时候,请千万不要放过它,很多次,在系统上线以后,最初的问题或者潜在的问题最终暴露出来,而这样的问题很多在系统设计阶段都是有端倪的。...看起来确实可以实现需求,可是,这样的设计有什么问题? 这样的设计当时居然没有受到系统设计评审的人的质疑,我实在觉得奇怪。...例子 5:单点故障问题 单点故障问题也是很常见的会导致服务失去的问题,出了问题所有人都知道原因,但是有时候就是很难在系统设计阶段识别出来。...例子 7:服务器掉电以后的快恢复 再说一个问题,这个问题是从一个技术分享中流传开来的。...初看这样的设计真不错,但是很容易忽视的一点是,这样的数据是建立在足够长时间,以及足够多统计数据的基础之上的,但是在单个时间段内,缓存命中率可以低到难以承受的地步,导致底层的数据服务直接被冲垮。

31210

手机盾设计相关安全问题

我们的安全设计必须围绕着这两部分来进行。我们今天来着重聊聊这两个步骤。 1,证书如何从CA中心安全地下载到SE中? 这里流程会与IFAA有所不同。...也就是说SE中的公钥事先并未上传到服务器中。所以银行APP首先会从SE中申请公钥,并上传到服务器。在这个过程中,有3个问题需要探讨。 APP与银行服务器之间的安全信任机制问题。...银行APP与服务器之间的安全问题,目前可以通过多因子协助手段进行辅助安全保证,比如短信验证码,比如人脸识别。...APP与TA之间的安全信任机制问题。 同时还有恶意APP对TA的访问通道的占用风险。...TA与SE之间的信任机制问题。 本质上这两种之间的信任是TEE和SE之间的信任关系。TA已经有签名机制,只有合法的TA才能在TEE中运行。

91570

GeneralUpdate解决设计中异常传递问题

设计组件的时候也会遇到不少问题,经常会在半夜想到一个解决办法爬起来将这个办法或者是设计记录下来或者直接实现。...这里将很久之前设计思路写出来向大家讨教、分享,在设计和实现的过程遇到的问题以及是如何解决的。...这个时候可能会想到,不断向外层传递异常信息的时候会有这些问题。如果集中将异常管理起来,点对点抛到最外层不就可以解决问题了吗?...确实,这样做简单明了但是光有解决思路不能落实成解决方案那么也只是产生了新的问题罢了。 那么我们简单分析一下设计的解决方案要满足什么样的条件: 点对点传递异常,不会因为各种其他因素影响。 能集中管理。...软件工程中流传着一句话,大部分软件问题通过增加一层就能解决,如果一层解决不了那就两层。

11920

DFX设计中的常见问题

相比于传统设计,DFX设计较为复杂,无论是从设计本身(RTL代码的层次化、约束)的角度看还是工具的使用角度看,都是如此。因此,在综合后,一定要执行设计规则检查,如下图所示。...这样能尽早发现设计可能存在的问题。这里并不需要对所有规则都做检查,只需要检查DFX相关的规则即可。这样可以节省时间。 可以对同一RP下不同的RM添加不同的约束吗?...这个问题的本质是RM是否可以用BD创建。答案是肯定的。只是这时需要将BD设计转换为BDC(Block Design Container),勾选下图中的红色方框所示内容即表明该模块是一个RM。...除了上述几个问题之外,我们还需要从以下角度来看待DFX设计。 DFX设计本质上是FPGA内嵌入了FPGA,也就是说RP可视为一个内嵌的FPGA,那么这个RP的可用逻辑资源、布线资源和IO也就固定了。...因此,同样的设计,使用DFX和不使用DFX可能会有不同的时序结果。层次化设计在DFX设计中也非常重要,将直接影响合动态区和静态区的分割。

46320

几个系统设计问题的解决思路

曾经写过一些系统设计方面的思考(比如这个和这个),但是最近准备面试,又接触了更多系统设计方面的问题。这里我想简单记录一些典型系统设计问题的思路。...通过学习常见的系统,在心中形成一些问题解决的套路,以在思考和分析新问题的时候提供一些既定思路。很抱歉时间关系写得很简略,主要是提示一些思路和方向。...,user id 作为 range key,email id 作为 primary key,邮件的时间列索引化,以便查询某人最近的邮件 读写分离,收取邮件和发送邮件的服务分开 设计图片上传和访问系统...处理在用户上传图片后,CDN 数据还没有最新数据的情况(数据不一致的问题设计图像转换服务 典型异步系统的设计: 一个分布式 queue 存放异步任务, 另一个 key-value storage...设计 Tiny URL 服务 schema 的设计,需要解决两个问题:short URL -> long URL(最多被使用)和 long URL -> short URL short URL 的生成

38920

开发者必备——API设计问题

API的选择问题丝毫不亚于跨端框架Flutter和RN的激烈斗争。...本篇文章主要探讨前两种API设计的优缺点以供读者进行技术决策的参考。...getUserById 由于接口的个性化需求,添加新功能时,API中可能会引入其他的动词或介词如By,With,create等等,这也是RESTFul征讨RPC的主要原因 一是嫌它丑 二是认为它不够通用(在服务端更新了之后...,客户端也需要阅读文档,适应服务端) 3.1 常用实践 面向接口编程 在参数传递过程中使用接口而不是实现类,使程序更加灵活可扩展 例如使用Map而不是HashMap,TreeMap,使用List而不是...参考文章 浅谈如何设计API restful与rpc风格 REST与RESTFul API最佳实践 API 设计最佳实践的思考 RESTful API 最佳实践

52220
领券