微服务如何拆分

服务拆分是微服务改造的第一步，也是最为关键的一步，拆分是否合理，决定了整个微服务化过程的成败，因此，需要有科学的拆分原则和拆分方法，保证拆分过程有序进行。

1、拆分原则

微服务拆分前，需要确定拆分的基本原则，微服务拆分的一个非常重要原则是无状态，无状态服务方便扩展和运维，所以无状态设计需要贯穿到微服务架构设计的全局层面进行思考。

服务拆分粒度并不是越细越好，需要结合当前团队的人员情况而定，比如当前团队只有 5 个人，如果拆分后的微服务个数超过 50，和人员的数量严重不匹配，不仅不会带来效率的提升，反而会导致效率的下降，建议拆分后每个人维护的微服务不要超过 3 个，并且每个微服务都有相应的备用负责人，规避可能的突发风险；针对多团队异地开发的情况，最好拆分后每个子团队负责的微服务相对独立，尽量减少异地团队的直接沟通成本。

微服务拆分时经常会遇到一些问题，比如是否需要拆分、拆分粒度的问题等，一般原则是遇到痛点问题时才进行拆分，非拆分不可时才启动微服务拆分，不要为了拆分而拆分。对于拆分方案拿捏不准的场景，尽量先不进行拆分，等想清楚了再定，避免拆分不合理，带来大量返工。

拆分后的微服务组织上层次不要过深，一个请求的处理过程中经过的微服务个数不要超过 5 个，链路太深会导致定位和追查问题特别麻烦，同时也会带来一定的性能损耗。对于拆分后的子服务来说，尽量避免相互依赖的场景，子服务调用时相互依赖会导致升级和维护时特别麻烦，增加很多不必要的运维成本。

2、拆分方法

微服务拆分的总体思想是根据高耦合、低内聚的原则识别出各个微服务的边界。具体拆分思路和业务形态紧密相关，没有绝对的标准。

• 以数据为维度进行拆分

按照数据拆分，是微服务拆分中最常见的一种方式，没有特殊考虑时一般根据领域实体数据进行拆分，拆分出来的服务负责处理给定的数据/资源的所有操作。以电商系统为例，大体可分为订单系统、用户系统、库存系统等。以订单系统为例，订单系统就负责订单核心数据的维护、订单数据的增删查改，确立了主要实体数据后可以根据数据的查询、修改等确定服务的接口，如订单的各种查询接口以及订单状态更新接口。根据数据维度把系统可以拆分出若干个子服务，但这些数据之间会有不少关联关系。

• 按照使用场景拆分服务

这种拆分方式也比较常见，如顺风车的所有后端查询操作之前都在一个单体服务里面，有固定路线/临时路线查询顺路订单，有根据路线查询附近订单，还有查询跨城订单，以及后续的需求乘客查询附近司机，乘客查询顺路司机等。之前这些在线查询接口都在一个单体服务中，多个 RD 会同时负责和修改这个服务的代码，开发效率低下，测试、上线都会相互影响，维护起来比较困难，后来把这些查询按照功能都拆分为不同的子服务，每个 RD 单独负责，大大提高了开发、测试以及运维效率。

• 重要和非重要的拆分

将核心逻辑和非核心逻辑拆分为不同的微服务，然后采用不同的高可用处理方案，比如核心服务尽量做到机房、集群等多维度的冗余和隔离；非核心服务则可以适当降低可用性标准，出现问题时只要能够及时降级和熔断即可。

• 变和不变的拆分

按照变更频次对服务进行拆分，尽量将变化聚集到少部分微服务上面，系统的绝大多数服务变更很少，可以减少变更对整个系统的冲击和影响。