周大壮的博客

简单来说，是因为这些业务在技术实现上存在共性，比如技术点或者架构模式。在本讲我将和你一起探寻问题背后的原因，并向你提供一个分析业务架构共性的标准。学完本讲，希望你在面对层出不穷的新业务、新模式时，能够洞穿出背后的架构本质，套用通用架构模式，轻松应对各项技术指标，真正做到大道归宗。

在本讲，我向你介绍了为什么要做服务架构的拆分以及哪些情况可以暂不进行拆分。我们再来复习一下系统拆分的几个主要原因。当需求不断叠加导致并行开发和上线时，通过拆分可以减少相互影响。当维护一个覆盖范围比较广的业务系统，从而导致研发人员业务专业度不够高时，通过拆分可以适当聚焦，提升专业度。当一个系统范围较广同时线上 Bug 不断时，就需要适当拆分，逐个击破。在落地进行拆分时，有几个重要准则需要你牢牢记住。拆分是按维度逐层进行，从顶层逐步向下。在顶层按业务及业务流程进行垂直拆分，而不是按技术或其他。

在本讲里，我们介绍了读服务在实现时应该满足的技术功能性要求，由此确定了读服务实现时应该满足的目标——应该遵守两个基本原则：架构尽量不要分层、代码尽可能简单。在此原则之上，我们提供了一个在实战中常见的架构方案，指出了此方案存在的四点不足，并提供了相对应的应对方案。在理解了上述的方案后，现在我给你留一道思考题。你所负责过的或者你公司里的读服务架构和本讲的架构有差异吗？对于上述的几个问题，你是如何应对的？欢迎在留言区留下你的想法，我们一起讨论。

在这一讲里，介绍了一种能够解决毛刺和更新实时性问题的全量缓存的完整架构方案。此方案提供的性能和高可用的能力，基本上可以满足各大互联网的业务场景里对于读服务的性能和容灾指标的要求。即使是近些年越来越热闹、流量瞬间爆发非常大的电商大促活动，只要对方案稍加改造，也能够轻松应对。但上述方案也带来了另外的问题，即成本的消耗。从上述的文字中，相信你也会有这样的感受——任何新的架构和应对方案都不是完美的，架构是解决问题的方案，也是取舍的艺术。这也是本讲所传达的另一个核心思想。

因缓存中同一个订单的基本信息和商品是存储在一起的，更新时需要把缓存中的数据读取至同步程序并替换掉此次变更的内容（如某一个发生变更的商品信息），再回写至缓存中即可。还是以上述修改微博为例，在“Binlog 订阅及转发模块”转发 Binlog 数据前，会按业务规则判断转发的 Binlog 数据是否在并发后仍需要串行消费，比如上面提到的同一条微博的多次修改就需要串行消费，而多条微博间的修改则可以并行消费，它不存在并发问题。基于上述格式的数据同步的实现代码会非常简单，但缺点是，上述格式产生的数据量较大。

除了需要应对热点缓存，另外一个重点就是如何发现热点缓存。对于发现热点有两个方式，一种是被动发现，另外一种是主动发现。被动发现是借助前置缓存有容量上限实现的。在被动发现的方案里，读服务接受到的所有请求都会默认从前置缓存中获取数据，如不存在，则从缓存服务器进行加载。因为前置缓存的容量淘汰策略是 LRU，如果数据是热点，它的访问次数一定非常高，因此它一定会在前置缓存中。借助前置缓存的容量上限和淘汰策略，即实现了热点发现。

本讲介绍了读业务在系统重构及日常需求开发时，均存在的测试回归耗时长和可能存在漏测的问题。根据读业务无状态及可重复执行的特点，针对上述问题我们构建了一套基于业务日志的自动化回归平台，主要包含三大子模块，分别是日志采集、数据回放及差异对比。希望你学习完本讲内容之后，对比你所在的团队，思考是否存在测试回归耗时长及漏测导致线上问题的场景。如果有的话，可以考虑尝试采用此方案及其变种，来提升你所在团队的效率。最后，留一道思考题给你。本讲介绍的方案是基于读回放场景，请你思考写回放和读回放有什么区别？

不断进行分库分表一定能解决容量问题，但“杀敌一千，自损八百”的事情少做为宜。使用分库分表会将代码和架构的复杂度变高，带来资源成本上升等问题。另外，在使用系统时，用户（不管是客户还是管理员）的查询体验也存在一定的降级。在使用分库分表前，你需要确定这是否是最优选择，是否能通过其他更简单的手段处理无效数据清理？架构是通过最小代价解决问题，而不是技术工具的比拼。最后，我再给你留一道讨论题，你知道的分库分表的问题还有哪些或者上述问题你还有哪些解决方案？欢迎留言，我们一起在留言区讨论。

本讲基于无状态存储打造了一个可以随时切库的高可用写服务。虽然当某一台无状态存储出现故障时，其中遗留的数据会出现短时的同步延迟，但此方案可以将出问题的无状态存储立刻移除，保障了写入的 7*24 高可用。对于一些对写入有极致要求的场景，比如在电商的大促零点时刻，每一秒钟都会产生上百万、千万的下单金额。可以进行适当地体验降级，比如让用户晚几秒看到历史订单列表，但一定要保障在此时刻用户可以下单并看到此订单的结果，以及对应的收件信息（如收货地址、电话、收货人）。对于上述场景，此方案也可以很好地应对。

本讲介绍了在完成一个写请求时，除了保障存储高可用之外，对于外部依赖，如何保障高可用，以及在出现故障时的可选降级措施。当你在实现一个高可用写服务时，可以参考依赖并行、显式的设置超时和重试来保障性能和可用性。本讲介绍的内容不仅适用于写接口，对于读接口和扣减接口依然适用。只是大部分场景里，写接口的外部依赖较多且写接口担负一个公司的营收重任（外卖下单、购买电影票等），故将此讲内容放到此模块内。最后，留一道讨论题给你，你使用过的降级方式和具体业务场景有哪些，欢迎写在留言区，我们一起讨论学习。

本模块的前几讲里围绕着分库分表，以及外部依赖治理的话题进行了讨论，通过上述方案来提升写业务的高可用和高性能。但分库分表以及无状态存储也带来了另外一个问题，即数据按路由规则分散后，如何满足无路由字段的多维度富查询？

看到这个标题很多人可能会有疑惑，扣减类业务不就是指秒杀吗，为什么要取这么抽象的名字呢？但其实秒杀只是扣减类业务中的一个有代表性、具备一定技术复杂度的场景，它并不能代表扣减类业务的全部场景。我将在“第 16 讲”中详细讲解秒杀相关的内容。除了秒杀之外，常见的扣减类业务有：购买一个或多商品时扣减的库存商家针对用户设置的某个或几个商品最多购买次数支付订单时扣减的金额...上述业务场景有几个共性点：购买的或设置需要扣减的数量一次可以是一个或多个；数量是共享的，每个用户都可以扣减某一个数据的数量。

在上一讲中的纯数据库方案无法完全满足量级要求时，本讲介绍了纯缓存的扣减方案。着重讲解了为什么纯缓存可以满足扣减的功能需求，对于分析的过程希望你能够理解并应用，而不是关注最终提出的方案。作为一名优秀的开发人员，你要知道架构图是一个最终态，是静止的，它并不能 100% 直接应用到你所面对的场景，而分析思路却是可以复制和模仿的。其次，本讲也分析了纯缓存方案存在的一些异常场景。在实战中，正常流程是简单的，而异常流程的思考与处理十分的复杂与烦琐，同时也最能体现技术性，请你务必注意与加强。

在本讲里，我们介绍了通过缓存和数据库结合的方式，实现了一个更加可靠的扣减方案。相比纯缓存方案，即使使用了无状态的分库存储，它的性能也会有一定的损耗。但此方案的好处在于数据更精准、更可靠。对于类似额度扣减、实物库存扣减等场景，此方案均适用。而对于一些虚拟的次数限制，同时业务上能够容忍在一定概率下数据不准确的场景，也可以选择纯缓存的扣减方案。此外，“顺序追加写要比随机修改的性能好”这个技巧，其实在很多场景里都有应用，是一个值得你深入学习和理解的技能。比如数据库的 Redo log、Undo log；

在本讲里，讲解了几种扣减方案里都会涉及的任务执行和扣减返还这两个公共话题，不管你的业务场景采用了哪种扣减方案，你都可以参考上述的返还和任务执行方案。最后，我再给你留两道思考题，一道题是需要你动手操作的，另一道题则是需要你深入思考的。动手题：上述提供的分布式 Worker 扩容两台机器后，etcd 或 ZK 里的哈希列表值，以及后续任务执行的区间是如何变化的，你可以试着梳理下。思考题，取消订单后，除了要返还商品的库存数量，还需要做哪些内容的返还呢？再见。

本讲在本模块前几讲的基础上，介绍了四种限流拦截策略，以及除了限流之外，可以实现水平扩展架构升级的方案。除了上述方案外，还可以在部署架构、系统隔离、前端静态资源前置等方面进行升级改造来应对热点扣减。最后，留一道观察题，你在秒杀抢购商品时，是否遇到过提示你已经无货，后续稍等几秒又抢到的场景呢？可以参考本讲的内容，思考下背后的原因。再见。

在本讲里，梳理了如何设计对外 SDK 里的接口的原则，以及如何设计和它架构上相类似的消息消费的原则。在实际工作中，你可以通过这些原则，构建一个更加高可用和兼具兼容性的系统。你应该还记得，在本讲的开头我直接给出了对外接口的设计准则：防备上游。通过本讲介绍的 SDK 的几个落地的细节手段便可以看出原因，它们都是对上游调用方进行鉴权、限流、入参前置校验与拦截，这些都属于防备外部调用的具体手段。因此，防备上游是对外接口设计的基本准则。最后，留一道思考题。你们团队在微服务对外接口里还有那些准则？

本讲介绍了设计不规范的微服务会产生的典型线上问题：机器 CPU 被打满的详细处理过程。后续遇到此类线上问题时，你可以参考上述过程进行处理。然后通过部署和代码两个层面讲解了可以规避服务器宕机的一些设计和编码技巧。后续你在设计和开发中，可以进行参考使用。上述介绍的应用部署和代码编写的原则，都是为了防止微服务出现故障的手段。这些手段，换种说法就是做好自己，防止出现问题。除了上述介绍的一些原则，你们团队有哪些设计和编码规范呢？欢迎留言，我们一起讨论。再见。

本讲介绍了采用微服务架构后，不可避免的分布式事务的解决方案，同时介绍了微服务常见的依赖：数据库、消息中间件的基本治理原则。后续你可以将本讲学习到的内容应用到你所负责的微服务的依赖治理中去。最后，我再给你留一道讨论题，你所负责的微服务对于它的依赖的使用，有哪些基本原则？欢迎留言区留言，咱们一起讨论。再见。

监控是指对被监控体的运行状态数据进行持续地审查，并设置运行状态数据不符合要求的阈值，对不符合阈值的运行状态主动报警的一种方式。被监控体的运行状态数据通常以如下图 1 中 XY 轴的格式进行展示。图 1：XY 轴格式的运行状态数据图上图 1 的 X 轴表示时间，由固定的间隔组成，此间隔可以是秒级或分钟级。Y 轴表示在该时间间隔里的运行状态数据的汇聚，它可以是间隔数据的累加、平均值、最大值等方式。下面将对几种常见的被监控体，以及它们的运行状态数据、阈值设置等相关内容进行一一介绍。

在这一讲里，讲解了如何构建高保真的压测环境。同时，针对写服务，详细介绍了如何通过优化升级来解决“写服务有状态”这一问题。此外，压测过程中的数据和压测结果不只是用来记录，还可以用于分析，寻找可以优化的瓶颈点。其次，需要根据压测极限值，设置微服务的限流阈值，防止流量超过压测极限值，进而将机器打挂，导致服务完全不可用。最后，再给你留一道讨论题，你当前所在团队的压测是如何开展的？欢迎留言区留言，我们一起讨论。

本讲介绍了系统升级重构的两种常见的类型。并分别介绍了这两种类型在升级重构后，如何实施让用户尽可能少感知的切换方案。同时，在包含存储的系统升级重构切换方案里，借鉴了很多本专栏前面介绍过的技术方案，比如基于Binlog的数据同步、基于流量回放的自动化回归方案等。由此可以看出，很多技术方案之间都是相互依赖的、相互连通的，甚至是成体系的。所以建议你在学习本专栏各讲的内容时，尝试寻找知识之间的联系，完善自己的知识体系，这样才能将专栏里的知识融会贯通，真正应用到实际的业务场景里。

罗马不是一日建成的，系统建设也是一样，它是随着业务的发展不断演化而来的。当业务体量较小且没有类似像 QQ 和微信的多个前台应用时，没有必要在建设初期就采用平台化或中台化的建设方案。因为它们的建设人力成本和消耗的机器资源也更高。一个系统在建设时，假如预期未来的三到五年的用户量并不会增长太大，可以先采用烟囱式的架构，快速地满足业务需求。当发展到一定体量后，再发起从烟囱式到平台化及中台化演化即可。毕竟能够发展到百万、千万用户体量的系统是少数，所有的系统都提前建设会存在较大可能的成本浪费。