美团面试：微服务如何拆分？原则是什么？

小咪咪 2024-02-18 13:32 38阅读 0赞

### 尼恩说在前面 ###

在40岁老架构师 尼恩的**读者交流群**(50+)中，最近有小伙伴拿到了一线互联网企业如美团、字节、如阿里、滴滴、极兔、有赞、希音、百度、网易的面试资格，遇到很多很重要的面试题：

> 微服务如何拆分？
> 
> 微服务拆分的规范和原则是什么？
> 
> 谈谈你的DDD落地经验？
> 
> 谈谈你对DDD的理解？

最近有小伙伴在美团，又遇到了相关的面试题。小伙伴懵了， 当然，**面试也就挂了**。

这里尼恩给大家做一下系统化、体系化的 DDD、微服务拆分的 梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，**让面试官爱到 “不能自已、口水直流”**。

也一并把这个题目以及参考答案，收入咱们的 《[尼恩Java面试宝典PDF][Java_PDF]》V128版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取

除了本文，尼恩输出了一个 《从0到1，带大家精通DDD》系列，帮助大家彻底掌握DDD，链接地址是：

《[阿里DDD大佬：从0到1，带大家精通DDD][DDD_0_1_DDD]》

《[阿里大佬：DDD 落地两大步骤，以及Repository核心模式][DDD _Repository]》

《[阿里大佬：DDD 领域层，该如何设计？][DDD]》

《[极兔面试：微服务爆炸，如何解决？Uber 是怎么解决2200个微服务爆炸的？][Uber _2200]》

《[阿里大佬：DDD中Interface层、Application层的设计规范][DDD_Interface_Application]》

《[字节面试：请说一下DDD的流程，用电商系统为场景][DDD 1]》

《[DDD如何落地：去哪儿的DDD架构实操之路][DDD_DDD]》

《[DDD落地：从腾讯视频DDD重构之路，看DDD极大价值][DDD_DDD_DDD]》

《[DDD落地：从美团抽奖平台，看DDD在大厂如何落地？][DDD_DDD 1]》

大家可以先看前面的文章，再来看本篇，效果更佳。

另外，尼恩会结合一个工业级的DDD实操项目，在第34章视频《DDD的顶奢面经》中，给大家彻底介绍一下DDD的实操、COLA 框架、DDD的面试题。

#### 文章目录 ####

*   *  尼恩说在前面
     *  微服务设计的规范和原则
     *   *  1.准备好微服务治理基础设施
         *  2.单一责任原则（SRP）
         *  3.松耦合原则
         *  4.领域驱动原则，不数据驱动原则，也不是界面驱动原则
         *  5.架构分层职责明确，严守调用规范，规避 “微服务小泥球”
         *  6.进行全方位的监控、记录
         *  7.通过CI/CD实现devops （开发运维一体化），提升工程效能
         *  8.基于业务需求变化频率进行微服务拆分
         *  9.基于吞吐量进行微服务拆分
         *  10.基于技术异构因素进行微服务拆分
     *  参考文献
     *  未完待续，尼恩说在最后
     *  尼恩技术圣经系列PDF

### 微服务设计的规范和原则 ###

单体架构往往以烟筒式方式发展，往往存在两个主要问题：**中心化**和**高耦合**。

所谓中心化，就是数据集中存储在单个数据库中，业务系统集中部署在单台服务器上，通过集群部署方式提供服务能力，然而中心化的问题，也就是单点问题。

所谓高耦合，主要是指其中一个功能模块升级，其它的模块都得一起升级。模块依赖度高的本质是架构腐烂。因为本来架构可能就没有设计好，但是，在实际场景中，随着快速迭代开发，研发换了一波又一波，产品走了一茬又一茬，难免系统架构腐化严重。

如何解决单体架构的问题呢？ 方案很多，主要有： SOA、微服务架构。

SOA（Service-Oriented Architecture，**面向服务的架构**）是一种高层级的架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。SOA 集成了独立部署和维护的服务，并允许它们相互通信和协同工作，以构建一个跨不同系统的软件应用。

微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。

如何 做单体架构 到微服务架构的升级呢？

#### 1.准备好微服务治理基础设施 ####

微服务首先需要有微服务基础设施，没有微服务基础设施，实践微服务就是一场灾难。

![ed5e435ed230448da26b897c9515c18f.png][]

> **注意：请点击图像以查看清晰的视图！**

#### 2.单一责任原则（SRP） ####

SRP是微服务架构重要的原则。

每个微服务都应该负责一个单一的业务，并确保做好这个业务，这个业务粒度的大小取决于你对业务和架构综合考虑。

SRP能够确保微服务职责单一性、功能完整性拆分， 这样，就便于维护、测试和部署。

![20a9780b1aef498696bf512b5318c360.png][]

> **注意：请点击图像以查看清晰的视图！**

#### 3.松耦合原则 ####

什么事松耦合：松耦合是指每个微服务都应该是独立的，并通过API与其他服务进行通信。

松耦合的优势：可以降低 级联故障 的风险，也可以提高服务可扩展性，提高微服务的可复用性。

尽量做彻底解耦，包含数据库层的解耦：

*  数据库层的解耦，就是避免一个微服务与其他微服务共享数据库，因为这可能会导致数据不一致，并且会使故障排查变得非常困难。
 *  每个微服务也都应该只管理自己的数据，每个微服务都有自己的数据库来存储数据，以确保可扩展性和可靠性。

在设计微服务时，应该专注于创建小型、松散耦合和高度内聚的服务。

![3a99e20865a5496fb898327221cb3cbb.png][]

> **注意：请点击图像以查看清晰的视图！**

#### 4.领域驱动原则，不数据驱动原则，也不是界面驱动原则 ####

DDD是一种软件设计方法，它专注于特定业务领域的软件设计。

微服务架构、微服务设计非常适合采用DDD，为啥呢？

因为每个服务都可以设计为特定业务领域的具体实现。

![f00f5e4083ad4e4482c3d64500ea8e38.png][]

> **注意：请点击图像以查看清晰的视图！**

领域驱动设计，首先应建立领域模型，确定领域限界上下文，然后才进行微服务拆分，

如果是 数据驱动原则/界面驱动原则 ，那么，是一上来就定义数据库表结构，就去调整领域逻辑代码。

领域模型和领域服务应具有高度通用性、稳定性，通过接口层和应用层屏蔽外部变化对业务逻辑的影响，保证核心业务功能的稳定性。

基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分。

#### 5.架构分层职责明确，严守调用规范，规避 “微服务小泥球” ####

老的单体架构， 常常被成为大泥球。

**“大泥球”单体，主要的问题**：

*  **代码腐化**：业务代码经过长时间的迭代，有很多重复代码。比如一个功能可能有 3,4 种实现。
 *  **业务逻辑交织**：业务应用经过长时间发展，功能变多，业务功能里的逻辑代码可能相互引用，交织不清。
 *  **代码复杂**：功能多，业务逻辑复杂，只有少数员工能理解。这也是代码腐化一种。
 *  **维护性变差**：修改 bug 或增加新功能时，牵一发而动全身。一个 bug 没修好可能导致整个软件不可用。
 *  **扩展性变差**：增加新功能时，牵一发而动全身。
 *  **编译发布变长**：软件代码量大，编译时长变长，导致发布时长也变长。

化解“大泥球”单体的措施，是微服务架构。微服务架构最基本的一个点：分而治之，由大化小。

*  **松耦合**：划分为一个一个小的微服务，代码之间逻辑交织降低。
 *  **独立部署**：每个划分的微服务都是一个独立的项目，可以独立部署。
 *  **编译发布改善**：划分为独立的小项目，编译时长变短，发布时长相应变短。
 *  **故障隔离**：由于划分为一个一个微服务，故障仅发生在独立的微服内。
 *  **可扩展性**：每个服务可以独立横向扩展，也可以从应用程序中提出独立功能变成服务，扩展变强。
 *  **职责单一团队**：每个小的微服务都由一个小型的高度专注的团队负责。
 *  **技术异构**：每个团队可以选择适合该业务的技术。

微服务架构目的就是把一个大单体划分为各种微服务，松耦合，独立自治。

微服务架构把一个大泥球，变成了很多个小而美的颗粒。

每个小颗粒职责单一，边界明确，可以通过简单组装完成大的功能，自然就比之前的大泥球好处理得多

但是，迭代过程中，出现了一种奇怪现象，微服务内部没有进行内部的模块划分，代码耦合严重，调用关系混乱，就像一个小泥球。

在腾讯视频的DDD重构案例中，在老的微服务架构中，存在分层不明确，下层服务过于理解业务逻辑，存在下层调用上层的问题，出现了代码耦合严重，调用关系混乱的 “微服务小泥球”。

具体请参考《[DDD落地：从腾讯视频DDD重构之路，看DDD极大价值][DDD_DDD_DDD]》

在腾讯视频的DDD重构的过程中，明确架构分层，降低模块间不必要的耦合；

严格遵守分层架构原则，上层服务可调用下层服务，下层服务不涉及业务逻辑。如上下层服务需交互，可通过逻辑解耦方式实现，如消息队列或中转。

如果规避 “微服务小泥球”？ 各层职能定位清晰，只能上层调用下层，也就是说只能从外层调用内层服务，下层服务通过封装、组合或编排对上层暴露，服务粒度由细到粗。

微服中，各层职能定位清晰：

*  基础层为各层提供资源服务
 *  领域层负责领域业务逻辑的实现
 *  应用层负责服务的编排和组合
 *  接口层对外进行服务暴露

![320929ba435b4499bc23d1d6d2be76d5.png][]

> **注意：请点击图像以查看清晰的视图！**

#### 6.进行全方位的监控、记录 ####

监控和日志记录对于微服务架构的安全、维护和调优都至关重要。

在拥有数百个微服务的项目中开发的主要困难之一是调试非常困难，因为服务分散、日志分散，很难找到失败的原因。

因此，每个服务都应该有日志记录和监控措施，以跟踪其性能并检测错误。

![b704d2e519f24617989b464331f3b1af.png][]

> **注意：请点击图像以查看清晰的视图！**

#### 7.通过CI/CD实现devops （开发运维一体化），提升工程效能 ####

CI/CD是一种软件开发运维过程实践，打通开发和运维环节，实现应用程序的构建、测试和部署自动化。

任何微服务都应该是可持续部署的，实现微服务的快速高效部署，缩短了微服务上线时间。

![490fd6ffe04241b18b30c16282e8d5a7.png][]

> **注意：请点击图像以查看清晰的视图！**

总之，采用微服务架构开发有许多优势，但要确保为微服务系统成功实施就需要遵循一些设计原则。

包括但不限于上面介绍的几个基础原则，在此基础上还需要有与所在领域或者行业的做定制化优化实践。

#### 8.基于业务需求变化频率进行微服务拆分 ####

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。

分离变和不变， 是 设计领域遵守的一条 核心的原则。

识别变动频繁的业务需求和领域模型，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离。

经常性变动必然会导致代码的频繁修改和版本发布，分离变和不变，可以有效降低频繁变动业务对稳态业务的影响。

#### 9.基于吞吐量进行微服务拆分 ####

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。

识别领域模型中性能压力较大、高吞吐量的功能，并且进行解耦，解除独立的微服务。

两个好处：

*  避免高吞吐服务，拖累整个系统的性能， 由于局部的性能拖累整体性能。
 *  解耦之后，可以对高吞吐量服务定制个性化的 扩容缩容策略、熔断保护策略、限流策略。

#### 10.基于技术异构因素进行微服务拆分 ####

这是一条扩展原则，是一条针对特定场景的的微服务拆分原则。

领域模型中有些功能虽然在同一个业务域内，但在技术实现时可能会存在较大的差异，也就是说领域模型内部不同的功能存在技术异构的问题。

比如，在尼恩的go+java 双语言云原生架构实操中， 有的可能用go，有的则是 Java，当然，还有的微服务用大数据架构。

所以，对于这些存在技术异构的功能，可以考虑按照技术边界进行拆分。

### 参考文献 ###

https://www.51cto.com/article/769421.html

https://blog.csdn.net/inaoen/article/details/121107764

https://www.jianshu.com/p/1c16195e9a1b

### 未完待续，尼恩说在最后 ###

微服务拆分、DDD 面试题，是非常常见的面试题。

大家面试的时候， 可以参考以上的内容去组织答案，如果大家能做到对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

另外在面试之前，建议大家系统化的刷一波 5000页《[尼恩Java面试宝典PDF][Java_PDF]》，并且在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

最终，**让面试官爱到 “不能自已、口水直流”**。offer， 也就来了。

当然，如果面试过程中，**项目low，简历low，表达low**，也可以找尼恩进行简历再造、项目再造，

再造之后，很容易获得面试官的青睐。

然后，依靠降维攻击， 实现快速 升级，快速上岸。

解锁：一个进大厂的捷——降维打击

### 尼恩技术圣经系列PDF ###

*  《[NIO圣经：一次穿透NIO、Selector、Epoll底层原理][NIO_NIO_Selector_Epoll]》
 *  《[Docker圣经：大白话说Docker底层原理，6W字实现Docker自由][Docker_Docker_6W_Docker]》
 *  《[K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由][K8S_K8S_14W_K8S]》
 *  《[SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由][SpringCloud Alibaba _10_SpringCloud]》
 *  《[大数据HBase学习圣经：一本书实现HBase学习自由][HBase_HBase]》
 *  《[大数据Flink学习圣经：一本书实现大数据Flink自由][Flink_Flink]》
 *  《[响应式圣经：10W字，实现Spring响应式编程自由][10W_Spring]》
 *  《[Go学习圣经：Go语言实现高并发CRUD业务开发][Go_Go_CRUD]》

……完整版尼恩技术圣经PDF集群，请找尼恩领取

> 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓

[Java_PDF]: https://blog.csdn.net/crazymakercircle/article/details/132927258
[DDD_0_1_DDD]: https://blog.csdn.net/crazymakercircle/article/details/134128426
[DDD _Repository]: https://blog.csdn.net/crazymakercircle/article/details/134128879
[DDD]: https://blog.csdn.net/crazymakercircle/article/details/134221190
[Uber _2200]: https://blog.csdn.net/crazymakercircle/article/details/134341888
[DDD_Interface_Application]: https://blog.csdn.net/crazymakercircle/article/details/134351936
[DDD 1]: https://blog.csdn.net/crazymakercircle/article/details/134365111
[DDD_DDD]: https://blog.csdn.net/crazymakercircle/article/details/134398390
[DDD_DDD_DDD]: https://blog.csdn.net/crazymakercircle/article/details/134450280
[DDD_DDD 1]: https://blog.csdn.net/crazymakercircle/article/details/134494149
[ed5e435ed230448da26b897c9515c18f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/a0c9284178e84774a9e80c87a73df344.png
[20a9780b1aef498696bf512b5318c360.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/f1faf64c1cfc478ead6e27f76cccf9c6.png
[3a99e20865a5496fb898327221cb3cbb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/66b0a9f6723746cd86725bc640a94a65.png
[f00f5e4083ad4e4482c3d64500ea8e38.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/9e68418b0e9340cf8384214dfe549b26.png
[320929ba435b4499bc23d1d6d2be76d5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/d8122658f8a944ff910b79c9d5a3e977.png
[b704d2e519f24617989b464331f3b1af.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/6fe82eb18d5c41ea96f538e419a28823.png
[490fd6ffe04241b18b30c16282e8d5a7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/0011db619f2a4ed8a1cdb07360a03090.png
[NIO_NIO_Selector_Epoll]: https://blog.csdn.net/crazymakercircle/article/details/133186797
[Docker_Docker_6W_Docker]: https://blog.csdn.net/crazymakercircle/article/details/129482349
[K8S_K8S_14W_K8S]: https://blog.csdn.net/crazymakercircle/article/details/130073643
[SpringCloud Alibaba _10_SpringCloud]: https://blog.csdn.net/crazymakercircle/article/details/129559428
[HBase_HBase]: https://blog.csdn.net/crazymakercircle/article/details/132589856
[Flink_Flink]: https://blog.csdn.net/crazymakercircle/article/details/132347440
[10W_Spring]: https://blog.csdn.net/crazymakercircle/article/details/129022714
[Go_Go_CRUD]: https://blog.csdn.net/crazymakercircle/article/details/131383065