阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/jackyfei/p/10856427.html 「张飞洪」欢迎转载，保留摘要，谢谢！

• 一、拆分姿势
  • 1.姿势一：
  • 2.姿势二：
  • 3.姿势三：
  • 4.姿势盘点：
• 二.题外话
  • 1.业务矛盾：
  • 2.三个火枪手(人员配置)

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

我们知道微服务是一种理念，没有确切的定义和边界，好比设计原则，是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话，具体问题需要具体分析，所以这篇文章谈到的划分也不是绝对标准，仅供参考。

有人说微幅不难，难的是服务的划分，虽然我持保留意见。但是从侧面也反应了划分具有一定的困难。这里的矛盾在于粒度。如果粒度太大了，分和不分似乎都差不多；如果粒度太小了，聚合、发布、调用链、调试等都是坑。

以下谈到的拆分是前人经验的总结，我罗列了三种行家的拆分姿势，每个的的经验和视野不同，各有偏颇，我在这里更多的是谈共鸣和感受，希望对你有所启发。

一、拆分姿势

1.姿势一：

新浪微博微服务专家胡忠想从纵横两个维度来划分，简单粗暴：

1.1 纵向拆分

从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

1.2 横向拆分

从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

纵向以业务为基准，关系铁的在一起；横向功能独立的在一起。我想如果拆分这么简单，你有底气拆，敢拆吗？所以我们又继续比对一下其他专家的言论。

2.姿势二：

阿里的小伙伴从综合的维度来看，部分维度和上面会有重合。

2.1 服务拆分要迎合业务的需要

充分考虑业务独立性和专业性，避免以团队来定义服务边界，从而出现“土匪”抢地盘，影响团队信任。

这个维度和上面的类似，但是强调的是业务和团队成员的各自独立性，对上面是一种很好的补充。

2.2 拆分后的维护成本要低于拆分前

这里的维护成本包括：人力、物力、时间。

这里的成本对大部分中小团队来说都是必须要考虑的重要环节，如果投入和收益不能成正比，或者超出领导的预算或者市场窗口，那么先进的技术就是绊脚石，千万不要迷恋技术，所谓工程师思维千万要不得。

2.3 拆分不仅仅是架构的调整，组织结构上也要做响应的适应性优化

确保拆分后的服务由相对独立的团队负责维护。

这句话怎么理解呢？传统的团队划分是按照产品部、前端、后端横向划分，微服务化以后的团队可能就会是吃一张披萨饼的人数，产品、前端、后端被归类到服务里面，以服务为中心来分配人数。

2.4 拆分最有价值的结果是提高了系统的可扩展性

把具有不同扩展性要求的服务拆分出来，分别进行部署，降低成本，提高效率。比如全文搜索服务。

这点和上面的按功能独立性来拆分有点类似，功能独立其实就是面向可扩展性。

2.5 考虑软件发布频率

比如把20%经常变动的部分进行抽离，80%不经常变动的单独部署和管理。说白了就是按照8/2原则进行拆分。这个拆分的好处很明显，可以尽可能的减少发布产生的后遗症，比如用户体验、服务相互干扰等。

但是这里有一个问题，假如20%的服务分属于不同的业务层面，那该怎么办？所以这里的拆分应该有个优先级，在拆分相互冲突的时候应该要优先考虑权重比较高的那个。

3.姿势三：

资深技术专家李运华在他的架构书中给出的拆分：

3.1 基于业务逻辑

将系统中的业务按照职责范围进行识别，职责相同的划分为一个单独的服务。这种业务优先的方式在前面两种姿势当中都出现过，可见是最基本，最重要的划分方式（没有之一）。

3.2 基于稳定性

将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块；将不稳定的，经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务，可以归到一起。这个很类似上面提到的2/8原则，80%的业务是稳定的。

至此你会发现服务的拆分真的没有绝对的标准，只有合理才是标准。

3.3 基于可靠性

同样，将系统中的业务模块按照可靠性进行排序。对可靠性要求比较高的核心模块归在一起，对可靠性要求不高的非核心模块归在一块。

这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端，同时将来要做高可用方案也能很好的节省机器或带宽的成本。

3.4 基于高性能

同上，将系统中的业务模块按照对性能的要求进行优先级排序。把对性能要求较高的模块独立成一个服务，对性能要求不高的放在一起。比如全文搜索，商品查询和分类，秒杀就属于高性能的核心模块。

4.姿势盘点：

以上不同拆分姿势各有千秋，异曲同工！

• 对业务逻辑均不约而同的放在第一位。

• 对业务模块的稳定性和可靠性，对功能的独立性、可扩展性都有相似的看法

• 强调拆分应该是多选，而不是单选。具体情况具体分析，可以自由灵活排列组合。

二.题外话

如果你把上面的划分角度背下来了拿去现场套，可能还会遇到矛盾或争议。

1.业务矛盾：

假如我们按照业务来划分，根据粒度大小，可能存在以下两种：

• 第一种分为商品、交易、用户3个服务；
• 第二种分为商品、订单、支付、物流、买家、卖家6个服务。

**3 VS 6，**这该怎么办？

如果你的团队只有9个人，那么分成3个是合理的，如果有18个人，那么6个服务是合理的。这里引入团队成员进行协助拆分。

可见拆分的姿势不是单选，而是多选的。这个时候必须要考虑团队成员数量。

在拆分遇到争议的时候，一般情况下我们增加一项拆分条件，虽然不是充要条件，但至少我们的答案会更加接近真理。

除了业务可能存在争议，其他的划分也会有争议，比如一个独立的服务到底需要多少人员的配置？

2.三个火枪手(人员配置)

上面提到的人员数量配置，这里为什么是9和18呢？(这里的团队配置参考李云华前辈提到的三个火枪手的观点)

换一种问法，为什么说是三个人分配一个服务（当然，成员主要是后端人员）？

• 假设是1个人，请个假、生个病都不行。一个人会遇到单点的问题，所以不合理。
• 假设是2个人，终于有备份了，但是抽离一个后，剩下1个压力还是很大，不合理。
• 假设是3个人，抽离一个还有2个在。而且数字3是个稳定而神奇数字，用得好事半功倍。特别是遇到技术讨论，3个人相对周全，如果是2个可能会各持己见，带有自我的偏见和盲区。

那么这个3是不是就是稳定的数量呢？

假设你做的是边开飞机边换引擎的重写工作，那么前期3个人都可能捉襟见肘。但是到了服务后期，你可能1个就够了。

所以3在我的理解应该是一个基准线，不同的时间段会有上下波动，但是相对稳定。