大家好，我是陈总~我们知道微服务是一个没有确切定义和界限的概念，就像设计原则一样，是一个抽象的概念。定义不清就谈划分，也是一种谈资，需要具体问题具体分析。所以本文所说的划分不是绝对标准，仅供参考。有人说微服务不难，难的是服务的划分。虽然我有所保留，但也从侧面反映了划分的难度。这里的矛盾在于粒度。粒度太大，分不分好像都一样；粒度太小，聚合、发布、调用链、调试等都是坑。下面说的拆分是对以往经验的总结。我列举了三种高手的劈叉姿势。每个人都有不同的经历和愿景，每个人都有自己的偏见。我这里说的更多的是共鸣和感受。我希望受到你的启发。Java工程师推荐技术指南：https://github.com/chenjiabing666/JavaFamily拆分姿势姿势一：新浪微博微服务专家胡忠想从纵向和横向维度进行拆分，简单粗暴1.纵向拆分从业务维度拆分。该标准根据业务关联程度确定。关系密切的业务适合拆分成微服务，功能相对独立的业务适合拆分成微服务。2.水平拆分从公共和独立的功能维度拆分。该标准基于是否有多个其他服务的公共调用，依赖的资源是独立的，不与其他服务耦合。垂直以业务为本，关系是铁的；水平功能是独立的。我想拆分这么简单，你有信心拆分吗？你敢拆吗？所以我们继续对比其他专家的言论。立场二：综合来看，阿里的合作伙伴会在某些维度上与上述重合1.服务拆分要符合业务需求，充分考虑业务的独立性和专业性，避免定义服务由团队造成“土匪”抢地盘，影响团队信任。这个维度和上面类似，但是强调业务和团队成员的独立性，是对上面的一个很好的补充。2、拆分后的维护成本低于拆分前。这里的维护成本包括：人力、物力、时间。这里的成本是大多数中小型团队必须考虑的一个重要环节。如果投资和收益不成正比，或者超出领导者的预算或市场窗口，那么先进的技术就是绊脚石。不要沉迷于技术。绝不能允许所谓的工程师思维。关注公众号：码猿技术专栏，回复关键词：1111获取阿里内部Java性能优化手册！拆分不仅仅是调整架构，还要调整和优化组织架构，确保拆分后的服务由相对独立的团队维护。怎么理解这句话？传统的团队划分是按照产品部门、前端、后端进行横向划分。微服务之后，团队可能就是吃一个披萨的人数。产品、前端、后端分类为服务，以服务为中心分配人数。拆分最有价值的结果是提高了系统的可扩展性。将具有不同扩展性需求的业务拆分出来，分别部署，降低成本，提高效率。比如全文搜索服务。这有点类似于上面按功能独立的拆分，功能独立其实是面向可扩展性的。3、考虑软件发布的频率，比如将20%的频繁变化的部分分离出来，将80%的不经常变化的部分分开部署和管理。说白了，就是按照8/2原则拆分。这种拆分的好处是显而易见的。它可以最大限度地减少发布后遗症，例如用户体验和服务之间的相互干扰。关注公众号：码猿技术专栏，回复关键词：1111获取阿里内部Java性能优化手册！但是这里有一个问题。如果20%的服务属于不同的业务级别呢？所以这里的拆分应该是有优先级的。当拆分相互冲突时，应优先考虑权重较高的拆分。立场三：资深技术专家李云华在他的架构书中给出的拆分1、以业务逻辑为基础，根据职责范围识别系统中的业务，将相同的职责划分为单独的服务.这种业务优先级的方法在前面两个姿势中都出现过，可见是最基本也是最重要的划分方法（没有之一）。2、以稳定性为基础，对系统中的业务模块按稳定性进行排序。稳定的和不经常修改的分成一件；不稳定的和经常修改的分成一个独立的服务。比如日志服务和监控服务是比较稳定的服务，可以归为一类。这和上面说的2/8原则很像，80%的业务是稳定的。此时你会发现，服务的划分真的没有绝对的标准，合理才是标准。3.基于可靠性同样，将系统中的业务模块按照可靠性进行排序。将可靠性要求较高的核心模块归为一组，将可靠性要求较低的非核心模块归为一组。这种巧妙的拆分，可以很好地避免一只老鼠掉一锅粥的单一劣势。同时，未来的高可用方案也可以节省机器或带宽的成本。4、在同上高性能的基础上，根据性能需求对系统中的业务模块进行优先级排序。将性能要求高的模块分离成一个服务，将性能要求低的模块放在一起。例如全文搜索、商品查询与分类、秒杀等都是高性能的核心模块。姿势盘点：以上不同的劈叉姿势各有优缺点，都是大同小异。业务逻辑是第一位的。业务模块的稳定性和可靠性、功能的独立性、可扩展性有类似的看法。强调拆分应该是多选，而不是单选。具体情况具体分析，可以自由灵活安排组合。推荐给Java工程师的技术指南：https://github.com/chenjiabing666/JavaFamily，star支持！说句题外话，如果把上面的划分角度背下来带到现场，可能还会遇到矛盾或纠纷。业务冲突如果按业务来划分，按照粒度的大小可能有以下两种：第一种分为商品、交易、用户三种服务；第二类分为商品、订单、支付、物流、买家、卖家6个服务。3VS6，我该怎么办？如果您的团队只有9人，那么分成3份是合理的，如果有18人，那么6份是合理的。这里介绍团队成员协助拆分。可以看出拆分的姿势不是单选，而是多选。这时候就必须考虑团队成员的数量。当拆分遇到争议时，我们一般会加上一个拆分条件。虽然不是充分必要条件，但至少我们的回答会更接近真相。除了生意上的纠纷，其他部门也会有争议。比如一个独立的服务需要多少人员？推荐给Java工程师的技术指南：https://github.com/chenjiabing666/JavaFamily，star支持！三剑客（人员编制）上面说的人员编制数量，这里为什么是9个和18个？（这里的团队配置参考了李云华学长提到的三剑客的观点。）还有一个问题，为什么要给一个服务分配三个人（当然成员主要是后端人员）？假设只有一个人，请假或生病是不行的。一个点就会出问题，这是不合理的。假设有2个人，好不容易有了一个备份，但是去掉一个之后，剩下的一个压力还是很大的，这是不合理的。假设有3个人，去掉一个，还剩下2个人。而数字3是一个稳定而神奇的数字，用起来事半功倍。尤其是涉及到技术讨论的时候，3个人比较体贴。如果有2个人，他们可能会各持己见，有自己的偏见和盲点。那么这3个数量稳定吗？假设你边开飞机边做换引擎的重写工作，那么前期3个人可能都捉襟见肘了。但是在服务结束的时候，你可能1就够了。所以3应该是我理解的baseline。不同时间段会有波动，但相对稳定。
