解析服务拆分的实现策略

在现实中，任何软件系统的发展都是从简单到复杂、从集中到分散的过程。而从架构设计角度讲，一个应用程序本身的职责应该清晰明确。一旦功能与职责之间的边界不够清晰导致系统的维护成本不可控，那么就到了需要对系统进行拆分的时候了。当下，微服务架构已经是业界主流的软件系统设计方法，而微服务架构本质上就是解决了如何对服务进行拆分以及集成的问题。

在今天的内容中，我们将集中讨论服务拆分的维度和相关策略。而在下一讲中，我们将聚焦服务的集成过程。

服务拆分的系统方法

服务拆分是有方法的。我们第一个要明确的问题是：服务应该按照什么维度进行拆分？让我们先从AKF扩展立方体开始说起。

AKF扩展立方体是业界关于如何开展系统拆分的一种原则，通过这个原则，系统就可以实现高度的扩展性。我们看到在AKF扩展立方体的X轴上，开发人员可以使用负载均衡等技术来实现水平复制；而在Z轴上，我们则可以使用类似数据分区的方式实现系统扩展性。我们这里需要重点关注的是Y轴，它提示我们针对单体系统，我们应该基于业务体系按服务功能进行拆分。这就回答了我们前面抛出来的问题。

上图展示了针对“商品下单”这一业务体系按照“订单”、“商品”以及“会员”等业务功能进行拆分的结果。

一旦我们完成了服务的拆分，原本的单块系统就演变成了多个独立的服务。那么，这些服务之间应该保持怎么样的依赖关系呢？这是我们关于服务拆分要讨论的第二个问题。

服务之间依赖在不可避免的，但是过多的依赖势必会增加系统复杂性和降低代码维护性，从而成为团队开发的阻碍。在微服务架构中，我们通常从故障容忍度的角度来分析服务之间的依赖关系，包括弱依赖与强依赖两大类。

在上图中，如果服务B无法正常提供功能，则依赖它的服务A的整个业务流程无法正常执行下去，那么即为强依赖关系，也就是说，强依赖关系是服务正常运转的基本单元。而弱依赖则没有这样的限制，对于服务C所提供的诸如消息发送等服务，如果该服务无法正常提供功能，核心业务流程同样可以正常运行。

我们对依赖关系进行进一步分析。通过对强依赖和弱依赖对应的服务调用进行区分，我们可以得到可靠调用和非可靠调用。可靠调用必须通过系统级的方式进行保障，使得关键服务能够运行；而对非可靠调用，则可以简单容忍失败或丢失行为，使得整体系统的复杂度降低。这种设计理念为我们实现服务降级提供了基础。

通常，我们可以对上图中的服务C设置开关，其目的是在极端资源瓶颈出现的时候，使得业务系统能够丢弃一些诸如服务C的弱依赖服务从而保全更关键的强依赖服务B。

关于服务拆分的第三个问题关于数据。在进行服务拆分过程中，我们往往会发现数据和服务本身是耦合在一起的，可以说业务的拆分势必涉及到数据的拆分。数据拆分的目标就是把数据从集中式的管理转变为分散式的管理，常见的场景涉及到数据的跨表查询、跨库查询和存储过程等的技术耦合。

通常，业务和数据是需要同时进行拆分的。但在真正实施过程中，我们发现还是应该采用一定的前后顺序来分别对两者进行拆分。这种前后顺序取决于具体的业务场景和系统复杂度。但作为一般策略，我推荐你先进行数据层面的拆分。如果我们能事先将数据模型梳理清楚，并明确数据的边界，那么业务代码的迁移工作就会顺利很多。事实上，各个微服务边界能够清晰划分，在很大程度上取决于数据模型在设计上的清晰度。

面向遗留系统的服务拆分架构模式

在介绍完服务拆分的系统方法之后，我们接下来要讨论的是具体的工程实践。在现实中，服务拆分的实施过程因场景而已，但面向遗留系统的拆分场景非常具有典型性。面向遗留系统的服务拆分就是一个从老系统中拆分成新服务，然后用新服务替换老系统的过程。

在上图中，遗留系统中的所有业务模块最终都将给拆分后的新服务所替代。那么，如何做到这一点呢？业界存在一些主流的架构模式，今天我们介绍其中两种非常常用的架构模式，即绞杀者模式与修缮者模式。

绞杀者模式

我们先来看绞杀者模式。所谓绞杀，可以理解是一种比喻，通过压制和摧残使不能存在或发展。在微服务架构的实施过程中，通过这种绞杀过程，我们就可以把一部分业务功能拆分成新服务，然后最终完成新服务与老功能之间的替换。我们来看它的具体实施过程。

在初始阶段，我们只有一个遗留系统。然后我们将新功能逐步以微服务的方式进行开发。这个过程势必会涉及到一部分对老系统的改造过程，这样部分遗留系统的代码就会被迁移到新服务中。

接下来，新服务的功能不断得到演进，遗留系统中的代码也越来越多被拆分到新服务中。

最终，随着时间的推移，新服务的代码迭代的同时就会慢慢具备了原有遗留系统的所有业务功能，从而实现对原有系统的绞杀。

显然，对于那些遗留代码复杂度很高、难以通过进行代码改造的方式进行直接重构的系统而言，绞杀者模式非常适合。

修缮者模式

介绍完绞杀者模式，我们再来看修缮者模式，该模式采用了另一个不同的实现策略，面向的场景也有所不同。从本质上讲，修缮者模式区别绞杀者模式的核心点在于它是一种重构技术。在实施这一模式时，我们还需要对原有的遗留系统进行一定程度的改造，而不是像绞杀者模式一样完全进行替换。

在实施过程中，修缮者模式需要实现一个抽象层，然后基于这个抽象层来改造原有系统。

上图中，抽象层的提取可以使用很多面向对象的设计模式。通过这一步，遗留系统实现了这个抽象层。有了这个抽象层，我们就可以基于它提供另一种更加合理的实现方案。

上图中，我们开发了一个新服务，该服务同样实现了这个抽象层。这样，原有遗留系统中可以抽象出来的业务功能就可以被新服务所替换了，从而起到修缮作用。这种修缮的过程可以持续进行，直到遗留系统中的所有代码全部完成抽象和替换。

在实施微服务架构的过程中，我们应该按照业务功能进行服务的拆分，而业务功能往往与数据相关，所以业务+数据构成了服务拆分的主要工作。同时，从单块系统到微服务架构意味着服务之间的依赖关系变得复杂。在今天的内容中，我们对这些换题做了讨论，并专门针对遗留系统的服务拆分需求，梳理了业界主流的两种拆分模式。