微服务划分的姿式

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

　　有人说微幅不难，难的是服务的划分，虽然我持保留意见。可是从侧面也反应了划分具备必定的困难。这里的矛盾在于粒度。若是粒度太大了，分和不分彷佛都差很少；若是粒度过小了，聚合、发布、调用链、调试等都是坑。

　　如下谈到的拆分是前人经验的总结，我罗列了三种行家的拆分姿式，每一个的的经验和视野不一样，各有偏颇，我在这里更多的是谈共鸣和感觉，但愿对你有所启发。

1、拆分姿式

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在个人理解应该是一个基准线，不一样的时间段会有上下波动，可是相对稳定。