微服务架构与现有系统并存的主要技术

在现实场景中，从零打造一个微服务架构机会很少，更多的是从一个现有系统出发逐步转型到微服务架构。对于那些已经处于架构腐化边缘的现有系统而言，往往正在寻找一种可以替代的架构风格，微服务架构可以是一种潜在的选择。

与构建一个新系统相比，从现有系统向微服务架构转型具有一些显著的特点：

• 业务模型

对于现有系统而言，我们已经具备明确的业务模型。尤其是那些寻找变革的架构，对于业务模型的理解通常很深刻，因为已经经历过了业务建模的阵痛期。这点对微服务架构非常重要，也是转型得以实现的基础。

• 领域模型

业务模型不等于领域模型。从领域建模的角度出发，现有系统中存在的业务边界很可能并不满足界限上下文的定义，也没有使用实体、聚合等手段在某个界限上下文内对业务对象进行建模。在这种场景下，向微服务架构转型将面临挑战，因为系统中基于领域的设计方法需要进行调整。

• 遗留代码

现有系统中存在大量代码，通常这些代码的质量都不高，也普遍存在缺少单元测试、部署复杂等典型问题。微服务架构需要解决这些问题，而解决这些问题的有效方法是引入变化。

正因为现有系统中没有明确的领域模型、也存在很多问题代码，直接通过代码拆分的手段将一个完整的系统分割成多个微服务并不现实。更为现实的做法是通过微服务架构来补充和增强现有系统。在本文中，我们将介绍几种在微服务架构与现有系统并存的情况下优化系统架构的方法，包括应用EAI、应用客户端集成、应用数据复制以及分离服务。

（1）应用EAI

EAI（Enterprise ApplicationIntegration，企业应用集成）是将基于不同平台、使用不同方案建立的异构应用进行集成的一种方法和技术。同时，它也表现为一系列可用于系统集成的架构设计模式。

EAI中的核心组件可以分为两大类，一类是消息路由（Message Routing），一类是消息转换（Message Transformation）。

• 消息路由

消息路由用于将消息传递到某个微服务，我们可以基于消息路由把某些业务请求转发到新的微服务，而不是交由原有系统处理。通过这种方式，我们在开始实施微服务架构的过程中不需要完成整个逻辑，而只需提供部分组件的实现即可。

消息路由需要考虑一次处理单条/多条消息、路由结果面向一个/多个目标、路由是否有状态等问题。围绕上述三个问题所得出的答案，我们加以排列组合可以得到多种路由器的表现形式，一般可以分为有状态路由和无状态路由。其中有状态的路由器指的就是需要根据消息传递的上下文确定路由结果，通常涉及多个消息，具有较高的复杂性。无状态路由中最简单的就是内容路由器（Content-based Router），即通过消息的内容决定路由结果。这里的消息内容包括输入消息的消息头属性值、消息体类型以及各种针对消息体内容的自定义的业务规则，通过内容路由器可以产生一对一的路由效果。显然，通过内容路由器，我们可以实现发送消息到某个特定微服务的效果。

•  消息转换

消息转换器（Transformer）解决服务与服务之间数据如何在异构系统之间进行适配的问题。现有系统与微服务之间经常需要异构系统之间的交互和集成，通过转换器可以消除异构系统之间由于数据格式所导致的依赖。最基本的转换思路就是通过一种自定义转换机制进行两种数据结构之间的映射，但有些场景下我们也需要实现基本数据结构转换，并对输入的数据结构进行内容的扩充和过滤。

内容扩充器（Content Enricher）就是往消息中扩充新的数据，扩充的数据来源可以来自计算、外部环境和第三方其他系统，扩充的对象可以是消息的消息头也可以是消息体，所以内容扩充器一般可以分成消息头扩充器（Header Enricher）和消息体扩充器（Payload Enricher）。内容过滤器（Content Filter）是内容扩充器的对称操作，内容过滤的目的是去除消息中的某一部分而不是在消息传递过程中过滤掉该消息。

下图展示了一个简单场景，消息路由器接收请求并把消息转发到某个微服务或现有系统。在这个场景中，我们可能已经使用《微服务拆分的维度和策略》中介绍的绞杀者模式对系统中的部分功能进行了微服务改造，同时保留了部分原有功能。当业务请求到达系统，可以通过业务请求的属性进行服务路由，分别转向已改造完成的微服务以及尚待改造的现有系统

（2）应用客户端集成

相比通过各种企业应用集成模式来实现微服务架构与现有系统之间的协作，客户端集成的方式简单而有效。我们在《微服务架构中服务集成的主要技术》节中已经深入讨论过客户端集成的各项技术，以BackEnd For FrontEnd服务器为例，我们可以通过该服务器做一层转发操作，将系统的一部分请求转发到微服务，而另一部请求则仍然流向现有系统。下图展示了这种方式的基本结构。

客户端集成虽然简单，但如何合理划分客户端入口是一项挑战。如果现有系统的各个客户端入口规划比较合理，能够简单通过入口划分就能界定业务边界，客户端集成是一项很好的请求转发机制。当我们把部分业务通过微服务进行实现之后，新的请求就可以完全脱离现有系统转而由新的微服务处理。但在很多现有系统中，客户端入口并不是非常独立，可以针对那些边界比较清楚的入口采用客户端集成方式，其余入口则结合前面的EAI方式进行综合处理。

（3） 应用数据分离

随着引入微服务之后部分业务功能的解耦，系统中已经存在一些微服务能够独立提供业务功能。这个时候我们就可以逐渐考虑开展数据分离工作。通过从现有系统中剥离部分业务相关的数据，尽量构建独立而隔离的微服务业务系统，这同样也是从数据层面对现有系统进行“绞杀”的一种有效方式。数据分离的效果如下图所示。

数据分离对于一部分业务是可以直接应用的，但对业务逻辑较为复杂的现有系统而言，数据分离需要花费很大代价所以在向微服务架构转型的过渡阶段，数据复制也是需要采用的一种策略。在上图中，我们可以在现有系统和微服务之间采用离线批量策略开展数据同步，如果数据同步实时性要求较高，那就只能采用服务接口的方式集成。关于数据复制，我们也在《微服务架构中服务集成的主要技术》中做了详细讨论。

（4） 应用服务分离

这里服务分离的含义在于我们是否要启动一个新的服务还是继续沿用已经存在的老服务。关于这个问题有一些原则可以参考。

• 数据和流程

首先比较明确的一点思路还是来自数据，当我们引入新的数据模型以及相应的数据处理流程时，一般都需要启用一个新的服务。

• 同步和异步

当系统中同时存在同步和异步处理流程，并且需要把这两种处理方式混合起来时，我们需要考虑是否应该引入新的服务以简化这种处理流程。

• 服务切面

在一个现存服务中，当我们发现其具有不同的切面（Aspect）时，例如某些通用机制不断在业务代码中重复出现或者说某个功能有多个不同的实现场景时，我们可以从切面的角度出发分析是否需要将这些切面抽取出来形成新服务。

更多内容可以关注我的公众号：程序员向架构师转型。