如何合理的拆分微服务

本文来说下如何合理的拆分微服务

---

概述

微服务在最近几年大行其道，很多公司的研发人员都在考虑微服务架构，同时，随着 Docker 容器技术和自动化运维等相关技术发展，微服务变得更容易管理，这给了微服务架构良好的发展机会。

在做微服务的路上，拆分服务是个很热的话题。我们应该按照什么原则将现有的业务进行拆分？是否拆分得越细就越好？接下来一起谈谈服务拆分的策略和坚持的原则。

---

拆分目的是什么

在介绍如何拆分之前，我们需要了解下拆分的目的是什么，这样才不会在后续的拆分过程中忘了最初的目的。

拆分的本质是为了将复杂的问题简单化，那么我们在单体架构阶段遇到了哪些复杂性问题呢？首先来回想下当初为什么选用了单体架构，在电商项目刚启动的时候，我们只希望能尽快地将项目搭建起来，方便将产品更早的投放市场进行快速验证。在开发初期，这种架构确实给开发和运维带来了很大的便捷，主要体现在：

• 开发简单直接，代码和项目集中式管理。
• 排查问题时只需要排查这个应用就可以了，更有针对性。
• 只需要维护一个工程，节省维护系统运行的人力成本。

但是随着功能越来越多，开发团队的规模越来越大，单体架构的缺陷慢慢体现出来，主要有以下几个方面。

在技术层面，数据库的连接数成为应用服务器扩容的瓶颈，因为连接 MySQL 的客户端数量是有限制的。

除此之外，单体架构增加了研发的成本抑制了研发效率的提升。比如公司的垂直电商系统团队会被按业务线拆分为不同的组。当如此多的小团队共同维护一套代码和一个系统时，在配合的过程中就会出现问题。不同的团队之间沟通少，假如一个团队需要一个发送短信的功能，那么有的研发同学会认为最快的方式不是询问其他团队是否有现成的，而是自己写一套，但是这种想法是不合适的，会造成功能服务的重复开发。

由于代码部署在一起，每个人都向同一个代码库提交代码，代码冲突无法避免；同时功能之间耦合严重，可能你只是更改了很小的逻辑却导致其它功能不可用，从而在测试时需要对整体功能回归，延长了交付时间。模块之间互相依赖，一个小团队中的成员犯了一个错误，就可能会影响到其它团队维护的服务，对于整体系统稳定性影响很大。

最后，单体架构对于系统的运维也会有很大的影响。想象一下，在项目初期你的代码可能只有几千行，构建一次只需要一分钟，那么你可以很敏捷灵活地频繁上线变更修复问题。但是当你的系统扩充到几十万行甚至上百万行代码的时候，一次构建的过程包括编译、单元测试、打包和上传到正式环境，花费的时间可能达到十几分钟，并且任何小的修改，都需要构建整个项目，上线变更的过程非常不灵活。

而这些问题都可以通过微服务化拆分来解决。

---

拆分时应该坚守哪些指导原则

---

服务拆分的几种方法

纵向拆分

纵向拆分（基于业务逻辑拆分）

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

以社交App为例，你可以认为首页信息流是一个服务，评论是一个服务，消息通知是一个服务，个人主页也是一个服务。

---

横向拆分

横向拆分

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

继续以前面提到的社交App举例，无论是首页信息流、评论、消息箱还是个人主页，都需要显示用户的昵称。假如用户的昵称功能有产品需求的变更，你需要上线几乎所有的服务，这个成本就有点高了。显而易见，如果我把用户的昵称功能单独部署成一个独立的服务，那么有什么变更我只需要上线这个服务即可，其他服务不受影响，开发和上线成本就大大降低了。

---

基于可扩展拆分

基于可扩展拆分

将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中，例如将“日志服务”和“升级服务”放在同一个子系统中；不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量。

这样拆分主要是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响了已有的成熟功能导致线上问题。

---

基于可靠性拆分

将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。

这样拆分可以带来以下好处

避免非核心的业务故障影响核心业务

例如，日志上报一般都属于非核心服务，但是在某些场景下可能有大量的日志上报，如果系统没有拆分，那么日志上报可能导致核心服务故障；拆分后即使日志上报有问题，也不会影响核心服务。

核心服务高可用方案可以更简单

核心服务的功能逻辑更加简单，存储的数据可能更少，用到的组件也会更少，设计高可用方案大部分情况下要比不拆分简单很多。

能够降低高可用成本

将核心服务拆分出来后，核心服务占用的机器、带宽等资源比不拆分要少很多。因此，只针对核心服务做高可用方案，机器、带宽等成本比不拆分要节省较多。

基于性能拆分

基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。

---

以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合，例如可以基于可靠性拆分出服务 A，基于性能拆分出服务 B，基于可扩展拆分出 C/D/F 三个服务，加上原有的服务 X，最后总共拆分出 6 个服务（A/B/C/D/F/X）。

---

服务都拆了为什么还要合并

古希腊哲学家赫拉克利特曾经说过：“人不能两次踏进同一条河流。”随着时间的流逝，任何事物的状态都会发生变化。线上系统同样如此，即使一个系统在不同时刻的状况也绝不会一模一样。现在拆分出来的服务粒度也许合适，但谁能保证这个粒度能够一直正确呢。

服务都拆了为什么还要合，就是要不断适应新的业务发展阶段，笔者这里做个类比看大家是否清晰，拆相当于我们开发代码，合相当于重构代码，为什么要重构呢，相信你肯定知道。微服务的合也是一样的道理，随着我们对应用程序领域的了解越来越深，它们可能会随着时间的推移而变化。例如，你可能会发现由于过多的进程间通信而导致特定的分解效率低下，导致你必须把一些服务组合在一起。

同时因为人员和服务数量的不匹配，导致的维护成本增加，也是导致服务合并的一个重要原因。例如，今年疫情的影响导致很多企业开始大量裁员，人员流失但是服务的数量确没有变，造成服务数量和人员的不平衡，一个开发同学同时要维护至少 5 个服务的开发，效率大幅下降。

那么如果微服务数量过多和资源不匹配，则可以考虑合并多个微服务到服务包，部署到一台服务器，这样可以节省服务运行时的基础资源消耗也降低了维护成本。需要注意的是，虽然服务包是运行在一个进程中，但是服务包内的服务依然要满足微服务定义，以便在未来某一天要重新拆开的时候可以很快就分离。服务合并到服务包示意图如下：

---

拆分过程中要注意的风险

不打无准备之仗，开发团队是否具备足够的经验，能否驾驭微服务的技术栈，可能是第一个需要考虑的点。这里并不是要求团队必须具备完善的经验才能启动服务拆分，如果团队中有这方面的专家固然是最好的。如果没有，那可能就需要事先进行充分的技术论证和预演，至少不打无准备之仗。避免哪个简单就先拆哪个，哪个新业务要上了，先起一个服务再说。否则可能在一些分布式常见的问题上会踩坑，比如服务器资源不够、运维困难、服务之间调用混乱、调用重试、超时机制、分布式事务等等。

不断纠正，我们需要承认我们的认知是有限的，只能基于目前的业务状态和有限的对未来的预测来制定出一个相对合适的拆分方案，而不是所谓的最优方案，任何方案都只能保证在当下提供了相对合适的粒度和划分原则，要时刻做好在未来的末一个时刻会变得不和时宜、需要再次调整的准备。因此随着业务的演进，需要我们重新审视服务的划分是否合理，如服务拆的太细，导致人员效率反而下降，故障的概率也大大增加，则需要重新划分好领域边界。

要做行动派，而不是理论派，在具体怎么拆分上，也不要太纠结于是否合适，不动手怎么知道合不合适呢？如果拆了之后发现真的不合适，在重新调整就好了。你可能会说，重新调整成本比较高。但实际上这个问题的本质是有没有针对服务化架构搭建起一套完成的能力体系，比如服务治理平台、数据迁移工具、数据双写等等，如果有的话，重新调整的成本是不会太高的。

---

本文小结

本文介绍了微服务拆分相关的概念与知识，微服务的拆分是一个比较复杂的话题，需要在掌握服务治理的基础之上不断的去进行实践。