下载掌阅APP，畅读海量书库
立即打开
1.3 服务拆分与集成 |
|
本节将在服务建模的基础上，简要分析服务拆分的策略和手段，同时给出了对拆分之后的服务进行集成的各种实现方法和技术体系。
在微服务架构中，我们认为服务是业务能力的代表，需要围绕业务进行组织。服务拆分的关键在于正确理解业务，识别单体内部的业务领域及其边界，并按边界进行拆分。所以，微服务的拆分模式本质上是基于不同的业务进行拆分。
服务拆分存在两大维度，即业务与数据。业务体现在各种功能代码中，通过确定业务的边界，并使用领域与界限上下文、领域事件等技术手段可以实现拆分。而数据的拆分则体现在如何将集中式的中心化数据转变为各个微服务所拥有的独立数据，这部分工作同样十分具有挑战性。
关于业务和数据谁应该先拆分的问题，可以是先数据库后业务代码，也可以是先业务代码后数据库。在拆分中遇到的最大挑战可能是数据层的拆分，因为在数据库中，可能存在各种跨表连接查询、跨库连接查询，以及不同业务模块的代码与数据耦合得非常紧密的场景，这会导致服务的拆分变得困难。因此，在拆分步骤上推荐数据库先行。数据模型能否彻底分开，很大程度上决定了微服务的边界功能是否彻底划清。
根据系统自身的特点和运行状态，服务拆分的方法通常分为绞杀者与修缮者两种模式。绞杀者模式（Strangler Pattern）指的是在现有系统外围将新功能用新的方式构建为新的服务的策略，通过将新功能做成微服务方式，而不是直接修改原有系统，逐步地实现对老系统的替换。采用这种策略，随着时间的推移，新的服务就会逐渐“绞杀”老的系统。对于那些规模很大而又难以对现有架构进行修改的遗留系统，推荐采用绞杀者模式。而修缮者模式就像修房或修路一样，将老旧待修缮的部分进行隔离，并用新的方式对其进行单独修复。修复的同时，需保证与其他部分仍能协同功能。从这种思路出发，修缮者模式更多地表现为一种重构技术，具体实现可以参考Martine Fowler的Branch By Abstraction重构方法。
数据对于微服务架构而言同样可以认为是一种依赖关系，因为任何业务都需要使用某个数据容器作为持久化的机制或者数据处理的媒介，这里的数据容器不仅仅是指关系型数据库，而是泛指包括消息队列、搜索引擎索引以及各种Nosql在内的数据媒介。微服务架构中存在一种说法，即我们需要将微服务用到的所有资源全部嵌入该服务中，从而确保微服务的独立性。
服务之间势必需要集成，而这种集成关系远比简单的API调用要复杂。对于微服务架构而言，我们的思路是尽量采用标准化的数据结构并降低系统集成的耦合度。微服务架构中服务之间的集成模式可以分为以下4大类，同时还可引入其他一些手段来促使服务与服务之间的有效集成。
接口集成是服务之间集成的常见手段，通常是基于业务逻辑的需要进行集成。RPC、REST、消息传递和服务总线都可以归为这种集成方式。
RPC（Remote Process Call，远程过程调用）架构是服务之间进行集成的最基本方式。在RPC架构实现思路上，远程服务提供者以某种形式提供服务调用的相关信息，远程代理对象通过动态代理拦截机制生成远程服务的本地代理，让远程调用在使用上就如同本地调用一样。而网络通信应该与具体协议无关，通过序列化和反序列化方式对网络传输数据进行有效传输。
REST（Representational State Transfer）从技术上讲也可以认为是RPC架构的一种具体表现形式，因为RPC架构中最基本的网络通信、序列化/反序列化、传输协议和服务调用等组件都能在REST中有所体现。但REST代表的并不是一种技术，也不是一种标准和规范，而是一种设计风格。要理解RESTful架构，最好的方法就是去理解它的全称Representational State Transfer，这个词组直译过来就是“表现层状态转移”，其实它省略了主语，“表现层”其实指的是“资源”的“表现层”。所以，通俗来讲REST就是指资源在网络中以某种表现形式进行状态转移。
消息传递（Messaging）机制能够降低技术、空间和时间耦合。消息传递机制在消息发送方和消息接收方之间添加了存储转发（Store and Forward）功能。存储转发是计算机网络领域使用最为广泛的技术之一，其基本思想是先将数据缓存起来，再根据目的地址将该数据发送出去。显然，有了存储转发机制之后，消息发送方与消息接收方之间并不需要相互认识，也不需要同时在线，更加不需要采用同样的实现技术。紧耦合的单阶段方法调用就转变成松耦合的两阶段过程，技术、空间和时间上的约束通过中间层得到显著缓解，这个中间层就是消息传递系统（Messaging System）。
企业服务总线（Enterprise Service Bus，ESB）本质上是一种系统集成组件，用于解决分布式环境下的异步协作问题，可以看作是对消息传递系统的扩展和延伸。ESB提供了一批核心组件，包括路由器、转换器和端点。路由器（Router）在一个位置上维护消息目标地址并基于消息本身或上下文进行路由；转换器（Transformer）用于异构系统之间进行数据适配，数据结构、类型、表现形式、传输方式都是潜在的需要转换的对象；端点（Endpoint）封装了应用系统与服务总线系统的交互。
数据集成同样可以用于微服务之间的交互，共享数据库（Shared Database）是一种选择，还可以通过数据复制（Data Replication）的方式实现数据集成。
在微服务架构中，我们追求数据的独立性。但对于一些遗留系统而言，我们无法重新打造数据体系，数据复制就成为一种折中的集成方法。所谓数据复制，就是在不同的数据容器中保存同一份业务数据。这里的同一份业务数据的概念不在于数据内容的完全一致性，而是在于这些数据背后的业务逻辑的一致性。
由于微服务是一个能够独立运行的整体，有些微服务会包含一些UI界面，这就意味着微服务之间也可以通过UI界面进行集成。站在某一个微服务的角度讲，调用它的服务就是该服务的客户端。关于客户端与微服务之间的集成可以分为以下3种方式，即直接集成、使用FrontEnd服务器和使用API网关。
直接集成的方式比较简单，就是客户端通过微服务提供的访问入口直接对微服务进行集成。这种方式适合于微服务数量不是太多的场景。如果采用直接集成的方式，服务按照业务模块进行边界划分和命名是一项最佳实践。
FrontEnd服务器有时候也可以认为是一种Portal（门户）机制，即把客户端所需要的CSS、JavaScript等公共资源统一放在FrontEnd服务器，然后每个微服务包含自身特有的HTML等客户端代码片段以及业务逻辑，通过集成FrontEnd服务器上的公共资源完成独立服务的运行。
当微服务数量较多且客户端集成场景比较复杂时，通常就需要单独抽取一层作为客户端访问的统一入口，这一层在微服务架构里有个专门的叫法称之为API网关（Gateway）。API网关的主要作用是对后端的各个微服务进行整合，从而为不同的客户端提供定制化的内容。API网关是微服务架构的基础组件，下一节还会再次介绍。
这里把外部集成单独剥离出来的原因在于现实中很多服务之间的集成需求来自外部服务的依赖和整合，在集成方式上也可以综合采用接口集成、数据集成和客户端集成。