上一讲里，我们介绍了两大类型的系统升级重构方案，还介绍了如何进行重构版本的上线，以及如何平滑地完成新老版本切换的方案。在本讲里，将会具体介绍如何判断系统发展到什么阶段需要重构，以及如何实施重构。 系统稳定性的重构升级 简单、通用的微服务架构如下图 1 所示，它包含一个应用服务和一个数据库作为存储。
发布于 2025-12-25
专栏的前 21 讲，从读、写以及扣减的角度介绍了三种特点各异的微服务的构建技巧，最后从微服务的共性问题出发，介绍了这些共性问题的应对技巧。 在实际工作中，你就可以参考本专栏介绍的技巧构建新的微服务，架构一个具备“三高”能力的后台服务。同时，也可以利用所学的技巧对已有的微服务进行系统升级重构，从而解决
发布于 2025-12-25
前三讲基于“防备上游、做好自己、怀疑下游”的准则，讲解了如何通过系统设计、部署，以及代码编写的方式来构建一个更加高可用的后台系统。 基于上述三个准则提出的方案可以预防部分问题，但百密一疏，即使我们做了很多防护措施，仍无法保证绝对安全，避免问题发生。此时作为系统的负责人，你需要在第一时间，也就是用户感
发布于 2025-12-25
在后台架构中，压测非常常见，也是必须的工作。它能够帮我们发现微服务架构中的性能瓶颈，以及知道构建的微服务能承载的流量极限值。 但实际情况是，很多压测并不能发现瓶颈点和微服务所能承载的真实流量极限值。一方面是因为压测时使用的是人为构造的压测参数；另一方面有些时候压测场景是经过修改的，和实际的线上场景存
发布于 2025-12-25
在前三个模块里，我将微服务根据目的性划分为三大类：读、写与扣减类，并针对每一大类涉及的各项技术问题讲解了应对方案。其实，每一类微服务除了本身业务特点涉及的技术问题外，在纯技术维度也有很多共性问题，比如 SDK 如何设计、服务如何部署等。 本模块将针对上述微服务中的共性技术问题进行深入讲解，首先咱们先
发布于 2025-12-25
在上一讲里，介绍了构建一个稳健的微服务的具体法则：防备上游、做好自己、怀疑下游， 并介绍了为什么要防备上游，以及一些防备上游的具体手段。 在本讲里，咱们一起来学习，做好微服务自身的设计和代码编写的常见手段。 微服务 CPU 被打满如何排查 在讲解具体有哪些手段可以用来构建一个更加稳固的微服务前，咱们
发布于 2025-12-25
在前两讲里，分别从微服务的对外接口、消息消费以及微服务自身的相关编码规范上阐述了“防备上游、做好自己”这两个准则如何落地。 在本讲里，将会讲解为什么要“怀疑下游”，以及有哪些手段可以落地此条准则。此外，还会介绍在进行微服务拆分后，调用外部依赖会产生的分布式事务、消息发送等问题的应对方案。 为什么要怀
发布于 2025-12-25
在本讲里，将会对扣减中涉及的两个公共话题进行讨论，分别是异步任务的设计和扣减中的返还的设计。 在“第 14 讲”和“第 9 讲”里，均使用了异步任务（Worker）来做无状态存储到正式业务库的数据同步。但关于具体如何设计异步任务来保证高可用，以及如何设计任务的执行来保障执行的速度，避免产生任务积压，
发布于 2025-12-25
从“第 12 讲”到“第 14 讲”，我们介绍了可以应对百万并发扣减请求，以及同时能够保障高性能的架构方案。此外，上述的架构方案还具备水平扩展能力，即当流量增加后，可以通过扩容底层存储和应用服务器来应对。 但面对百万并发的极端场景，比如大量用户在同一时间内抢购同一商品，前几讲介绍的几种方案就不能有效
发布于 2025-12-25
在上两讲里分别介绍了使用数据库和纯缓存实现的扣减方案。在需求层面上，上述两者都能实现业务需求。但均存在一些缺陷： 数据库方案的性能较差； 纯缓存方案虽不会导致超卖，但因缓存不具备事务特性，极端情况下会存在缓存里的数据无法回滚，导致出现少卖的情况。且因“第 13 讲”是异步写库，也可能发生异步写库失败
发布于 2025-12-25
