深入微服务核心：从架构设计到规模化

腾讯云开发者

墨衍会员 · AI 创作全网分发码龄10年

关注

原创 2025-04-23 08:46:06 933 阅读 AI 写同款· GEO 优化 ›

👉目录

1 微服务

2 演化式架构师

3 如何建模服务

4 集成

5 分解单块系统

6 康威定律和系统设计

7 规模化微服务

8 总结

《Building Microservices》这本书是吃透微服务的大部头，本文基于全书内容，系统性地阐述了微服务架构的设计原则、实施策略与挑战，从微服务的核心概念出发，延伸到架构设计、服务拆分、集成技术及规模化实践，为开发者提供了构建稳健微服务体系的指导框架。

关注腾讯云开发者，一手技术干货提前解锁👇

01

微服务

什么是微服务？

微服务就是一些协同工作的小而自治的服务。我们在一个单体系统中，通常会采用一些抽象层或者模块来保证代码的内聚性，直白点就是，把因相同原因产生变化的一类东西聚合在一块儿。

什么时候需要考虑微服务？

当我们的代码库异常庞大，以致于可能会出现“牵一发动全身”的情况，那么根据业务的边界来确定服务的边界，服务专注于某个业务边界之内，那么应该就能很好的解决这个问题了。例如，一个大型的商城系统，通常会划分用户，订单，支付等微服务。

微服务需要满足自治性

微服务应该可以彼此间进行独立修改，某个微服务的部署不应该引起该服务的消费方的变动。

微服务的好处

技术异构性

假如一个庞大的业务，不同的模块所需要的存储不一样，适合的语言也不同，那么微服务可以很好的屏蔽技术细节，打破技术栈所带来的壁垒。而且当你需要引进某些新技术的时候，使用微服务也可以降低系统风险，即便出现问题也很好处理。

弹性

单体应用如果出现异常，整个服务可能都无法使用，但是假如拆分成微服务，并且进行多机部署，那么就能降低系统完全不可用的风险，同时也可以采用功能降级来保证核心功能不受影响。

扩展

单体应用中，如果某个模块出现性能问题，我们必须对整个服务进行扩展，但是拆分成微服务，则可以对某个服务进行扩展，把那些性能要求低的服务，部署到相对较差的硬件上，这样可以充分利用资源来提供系统的性能。

简化部署

单体应用如果需要发布，会影响整个系统，微服务架构中，只需要对某个服务独立发布部署，即时出现问题，也只会影响这一个服务，可以快速回滚。

与组织结构相匹配

微服务架构可以很好地实现小团队+小代码库这种模式，提高团队生产力。

可组合性

微服务架构中，已有的功能可以重用，甚至通过组合几个微服务，就可以为某个应用程序提供完整的后台支撑。

对可替代性的优化

单体应用中，某些模块可能已经淘汰了，但是删除他们可能会带来不可预估的问题，但是微服务架构中，某些小模块可以轻松地进行移除或者重写。

小结

业界也存在共享库、模块这些分解技术，但是可能会导致它成为系统的耦合点；同时我们也要记住，没有银弹，不可能存在一条通用的准则。使用微服务甚至要面对单体应用没有的部署、测试和监控等一些列复杂的工作，还要处理分布式事务，CAP 相关的问题。

02

演化式架构师

模糊的定位

架构师的一个重要职责是，保证团队有共同的技术愿景，能够保证项目的交付质量。但是我们这个行业很年轻，以至于有时候我们自己都不清楚自己要干什么，人们把程序员叫做XX开发工程师，但是和传统行业相比，比如建筑师，假如我们的工程也根据一些图表和文档进行设计，那么可能会忽略一些基础性的因素，实现起来将会非常困难。不同于建筑行业必须遵循自然规律，物理规则，软件需要足够灵活，能够根据用户的需求不断演化。

城市规划师

相对于“架构师”，“城市规划师”可能更加贴合这个角色，城市规划师的职责是优化城镇的布局，进行合适的分区，使其更易于现有的居民生活，同时也会考虑一切未来的因素，与我们架构师的职责如出一辙。

分区

城市规划师要对城镇进行合理分区，那么架构师这边的区域概念对应的是什么？就是服务边界。架构师要多关注服务间的交互，而忽略服务内的细节，如果每个服务对外暴露的协议五花八门，那么对于消费者来说是个噩梦。虽然说不用关心每个服务内部的具体实现，但是假如一个团队，10种技术栈，我相信会增加管理成本和招聘难度。另外，架构师最好和团队共同 Coding，才能指导并且了解你的团队。

原则性的方法

制定战略性目标-业务部门的愿景。
制定设计原则-最好不要超过10个。
实践-对原则的落地。
结合-原则要与实践相结合。

标准

监控-所有服务使用同样的方式上报健康状态和其他监控数据，最好标准化。
接口-对外暴露接口的类型最好固定那几种，HTTP/REST或者RPC。
架构安全性-所有服务都要能够应对下游的错误请求，避免系统逐渐脆弱。

代码治理

达成共识，大家才能做好事情。所以，提供范例和服务代码模板是比较有效的两种方式。有比较好的代码范例，供人们模仿，即使错了，也不会错得很离谱。模板也可以提高开发速度，提升服务质量。但是要注意不要落入DRY（Don't Repeat Yourself）的陷阱，因为过度依赖共享可能会导致系统过耦合。

技术债务

每个团队都可能由于排期等因素欠下技术债务，架构师需要提供一些温和的指导，让团队决定如何偿还，最好是列一个表格，定期回顾。

例外管理

原则有时候可能会被打破，但是不代表它不正确，可能它会演化成一个新的原则，架构师要有严谨但包容的心态，如果对开发人员的限制过多，可能微服务架构并不适合。

集中治理和领导

架构师需要了解新的技术，并且知道如何取舍，通常领导一个小组，整个小组都负责治理，并且能够得到高层的支持。架构师一个人的想法有时候可能会比较片面，通常小组比个人更聪明。

建设团队

帮助战友共同进步，使其能够独立负责某个服务，并且能够得到充分的锻炼。

小结

演化式架构师应该承担的责任：

愿景-确保团队有共同的技术员警，能够满足客户和组织的需求。
同理心-理解你所做的决定对客户和同事带来的影响。
合作-尽量多和同事进行沟通，从而更好的对愿景进行定义、修改和执行。
适应性-确保在你的客户和组织需要的时候调整技术愿景。
自治性-在标准化和团队自治之间寻找一个正确的平衡点。
治理-确保系统按照技术愿景的要求实现。

03

如何建模服务

什么样的服务是好服务

松耦合

修改一个服务而不需要修改另一个服务

高内聚

相关行为聚集在一起形成独立服务

限界上下文

每个限界上下文包含两个部份，一部分需要和外部通信，一部分则不需要。就像细胞膜一样，细胞之所以会存在是因为细胞膜定义了什么在细胞内，什么在细胞外，并且决定了什么东西可以通过细胞膜。在不同的限界上下文之间，存在共享模型，屏蔽了内部实现细节。

如果服务的边界和领域的限界上下文能保持一致，并且微服务可以很好地表示这些限界上下文，那么就走出了高内聚低耦合的微服务架构的第一步。当然，微服务不宜过早拆分，将大型单体拆成微服务比较容易，但是直接使用微服务架构会比较困难。

业务功能

不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能出发，不应该成为基于CRUD的，贫血的服务。要思考这个上下文是做什么用的，然后考虑它需要什么样的数据。

逐步划分上下文

当考虑微服务的边界时，应该先考虑比较大的、粗粒度的，然后发现合适的缝隙之后，再进一步划分，就像劈柴一样，要先劈出来两条大缝隙，然后再逐步分解成比较细木片。

修改系统的目的是满足业务需求，基于业务的划分，在客户提需求的时候，就会更倾向于对一个服务的改动；按照技术接缝进行划分可能会导致洋葱式架构，服务被分成很多层，改动起来可能会很痛苦，所以一般来说这种方式不是首选方式。

04

集成

理想的集成技术

集成可能是微服务相关技术中最重要的一个，理想的集成技术要能够做到以下几点：

避免破坏性修改：在对一个微服务的响应中添加了一个字段，不应该影响消费方。
API要保证技术无关性：不应该选择那种对微服务的具体实现有限制的集成方式。
使服务易于消费方使用：如果消费方使用我们的微服务比登天还难，那么设计得再好也没用。
隐藏内部细节：微服务应该屏蔽内部实现细节，否则可能会提高和消费方耦合的风险。

共享数据库

这是业界常见的集成方式，它简单且快捷，但是他的问题很多。外部系统能看到内部细节，消费与特定的技术绑定，对逻辑修改可能要同时修改相关的系统，这样做的话，可以说和松耦合高内聚毫不相干了，它会给开发人员带来无穷无尽的痛苦。

同步与异步

服务之间到底是使用同步还是异步进行通信？同步=阻塞，调用方会阻塞自己直到整个操作完成，异步的话，调用方则不需要等待，甚至都不关心这个操作有没有成功。

同步可以知道事情执行到底成功与否，异步对于运行时间较长的任务比较有效。那么异步通信如何知道执行结果呢？可以采用注册回调的方式，服务端调用完成后，可以调用改回调来进行通知。

也可以基于事件进行协作，客户端发起的不是请求，而是一个事件，所有的订阅者可以收到这个事件，并决定是否需要处理。这种方式的耦合性很低。

编排与协同

使用编排的方式，我们会把某个服务当成中心大脑来指导并驱动整个流程。

使用协同的方式，仅会告知系统中的每个部分各自的职责，至于具体的实现，由他们自己决定。

使用编排的方式，可能会导致某个服务成为整个流程的中心枢纽，其他服务沦为贫血的、基于 CURD 的服务，但使用协同的方式，则需要额外对整个流程做跨服务的监控，以保证其正常运行。所以我们可以根据不同的场景，进行选择，或者混用。

RPC

远程过程调用，允许你调用一个方法，但事实上整个方法的结果是由某个远程服务产生的。RPC 帮程序员生成桩代码，从而能够快速使用，理论上，只调用方法，忽略细节确实是给程序员带来极大的便利。

但是要注意远程调用和本地调用其实是有区别的，因为网络并不可靠！

REST

表述性状态转移，它是一种风格，举个例子，我要对某个资源进行增删，我会使用 CreateCustomer和DeleteCustomer，但是使用 REST 风格就会变成：

POST : www.test.com/customerDELETE : www.test.com/customer

是不是要简洁很多？

为避免把存储数据暴露给消费者，我们可以先设计外部接口，等稳定后，再实现微服务内部的数据持久化。

但是，使用 REST 就无法帮助你生成桩代码，而且性能上可能遇到问题，对于低延迟场景来说，使用 HTTP 可能不是一个很好的主意。

基于事件的异步协作

主要关注两件事：微服务发布事件机制和消费者接受事件机制。

我们可以使用像RabbitMQ这样的消息代理来解决，但是这么做系统虽然有较好的弹性和可伸缩性，但是也会增加开发流程的复复杂度，但是一旦做好了，它会成为实现一个松耦合系统的重要手段。

还有一个原则：中间件一定要足够简洁，不要掺杂业务逻辑。

事件驱动的系统虽然看起来有较好的弹性和可伸缩性，但是开发难度高，带来的一些一致性问题比较复杂，而且对程序员的要求也很高，要进行思维上的转换，这有时候真的很困难。当我们要追踪某个问题的时候，我们一定要要引入监控机制，并且对时间有关联 ID，方便我们追踪这种跨服务的请求。

DRY

在微服务架构中，如果一味追求 DRY 是很危险的，比如很多微服务使用了同一个共享库。

所以，建议微服务内不要违反 DRY，微服务间可以适当违背 DRY。

按引用访问

如果我们确定了一个领域实体，那么任何和该领域相关的改动，都应该由这个领域完成。

比如我有一个客户服务，任何对客户的改动，都应该调用客户服务来完成改动，即客户服务是客户信息唯一可靠的来源。

举一个例子，如果我要发一封邮件，邮件里面有用户的姓名，地址，订单信息等，但是请求邮件服务是异步的，但是在这个时间差中，用户信息可能发生改变，如何解决？我们可以仅把客户资源和订单资源的 URI，等真正要发送的时候，再去查询最新的信息即可。

版本管理

减小破坏性修改影响的最好办法是尽量不要这样修改。
要尽早发现破坏性修改。
使用语义化管理版本，见文知意。
新老接口可以共存，来保证灰度或者随时回退。
同时存在新老服务（建议不要这样做，成本很高）。

小结

无论如何都要避免数据库集成，在 RPC 和 REST 之间做取舍，协同优先于编排，避免破坏性修改。

05

分解单块系统

我们上面讨论了什么是好的服务，一些规范和建议，以及系统如何向好的方向进行演化，那么一个大型的单体应用应该如何拆分成微服务呢？

关键是接缝，这部分代码进行修改不会影响系统的其他部分，这些被识别出来的接缝就会成为服务的边界。

前面讨论过的限界上下文就是一个很好的接缝，它定义的就是组织内高内聚，低耦合的边界，很多代码会使用包或者命名空间来定义这个概念，例如：golang的package。

好，现在假如我们有一个巨大的单体服务，它是一个在线音乐系统。我们把它划分为以下几个上下文：

产品目录。
财务。
仓库。
推荐。

从哪个部分入手？

最好考虑一下那部分抽离出去的效益最大，而不是为了抽离而抽离。

我们考虑以下几个因素：

改变速度：某个功能抽离且可以自治，可以加快后期的开发速度
团队结构：根据团队结构来抽离，比如存在异地协作，可以拆分出去。
安全：某部分业务是做数据安全，抽离出去可以对所有服务做监控、数据保护等。
技术：推荐系统出了一种新的算法，独立部署后，能提高我们系统的速度。

在我们分析系统为什么会有各种杂乱的依赖的时候，通常来说数据库大概率是源头。

找到源头后，我们抽象出一个独立的存储层，把数据库相关操作聚类到一起。

几个例子

打破外键关系

我们要生成一份财务报表，8月份销售《青藏高原》2000份，获利10000元。就需要从产品表和账单表获取数据，甚至存在外键关联，所以最好是产品服务暴露API给财务服务，而不是直接访问数据库，这个API会成为微服务化的第一步。

有时候让系统的一部分变慢会带来更大的好处，而且这个慢事实上也能控制在一定范围。

打破的前提是知道系统期望的行为是什么，想清楚再做决定！

共享静态资源

把城市编号放到数据库，各个服务共享，那么就形成了数据库集中，这显然不是我们想要的。

应该怎么做？

每个服务一个库。
这部分资源放到各自的服务代码中。
这部分资源行程一个单独的服务（太极端了）。

建议采用第二种，但是以配置文件的形式，各个服务自己保存一份，并支持热更新。

共享数据

仓库服务和财务服务都需要用户记录，他们都会向客户记录写数据和读数据，形成了数据共享，那么我们可以把客户的概念抽象出来，形成服务，对外暴露API。

共享表

我们的产品目录服务和仓库服务都会用到产品的信息，他们共享一张表，这个时候，可以把这个表分离成两个表，产品目录项表和库存表。

实施分离

事实上，先分离数据库结构，暂时不对服务进行分离会更好一些，我们可以随时回退，不影响消费者，一旦稳定下来，在考虑对整个应用程序进行分离。

事务

事务的好处是，可以使一系列操作要么全部执行，要么全都不执行。

那么微服务架构中如何实现？

再试一次-通过日志或者放入队列，之后再次尝试。
终止整个操作-通过补偿事务来抵消之前的操作，如删除某行记录，失败怎么办？可以重试或者给个界面操作，也可以自动化解决。
分布式事务-借助其他工具，如事务管理器，常见的算法是两阶段提交（本文不做介绍）。

我们到底应该怎么做？

这些方案都会带来复杂性，而且分布式事务很容易出错，且不易扩展。我们是否可以讲各种操作放到本地事务，然后依赖最终一致性方案解决？我认为可以，而且不要仅仅从技术上去解决，因为可能它真的不好解决，我们可以从业务上解决，设立一个间态，例如这类问题订单统一归类为“处理中的异常工单”？然后通过其他方式进行管理和修复？

数据导出

当我们要导出数据或者生成报表，可以通过提供API，定时同步数据库，使用事件订阅等等，但是千万不要暴露数据库！

小结

我们要理解，服务一定会越来越大，但是我们需要在拆分太过昂贵这件事发生之前，意识到我们需要拆分，这非常关键。

06

康威定律和系统设计

康威定律说的是，任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

Amazon 认为，小团队比大团队的工作更有效，于是产生了著名的“两个披萨团队”，即没有一个团队应该大到两个披萨不够吃。

07

规模化微服务

微服务形成一定规模后，系统变得异常复杂，我们应该怎么办？

首先故障一定会有，而且无处不在，我们要允许错误发生，控制在一定范围，当一个系统变得不是很可用的时候，要有安全降级方案，保证核心功能。

要从架构设计原则上，保证一个服务不会导致整个系统崩溃。

规模化微服务这种分布式架构下，我们要准备好应对系统故障的方案：

超时-跨进程调用要设置超时时间来保护下游。
断路器-当下游资源请求失败或超时达到一定数量，断路器打开后续不再请求下游。
舱壁-为每个下游服务设置一个连接池，形成舱壁，保证不会互相影响。
隔离-服务之间依赖越低越安全。
幂等- 允许重复调用，且每次调用造成的相同，不必担心多次调用会有不利的影响。
扩展：
1. 强大的硬件可以提升系统性能。
2. 拆分服务提高负载。
3. 把服务进行分散部署。
4. 做好负载均衡，避免单点故障。
5. 基于worker的模式，按需分配数量。
6. 系统架构完全无法应对当前负载，考虑重新设计。
扩展数据库：
1. 使用副本数据库，并且可以在必要的时候切换为主数据库。
2. 读取扩展：很多服务已读取为主，可以选择读副本。
3. 写操作扩展：使用分片机制，如对某个关键字取hash，写入不同实例。
缓存。
自动伸缩：根据负载主动扩缩容。
CAP定理：一致性、可用性、分区容忍性不可能同时满足，我们最多只能保证其中的两个。
服务发现：告诉人们微服务在哪里。