3. 挎斗模式
传统企业中存在大量的遗留系统，要对这些遗留系统全部进行微服务化改造的成本会很高，并不现实，而且有些遗留系统甚至是无法完全改造的。对于这些系统，我们的选择并不一定是将其进行微服务化改造，而是将其接入到微服务环境中，与其他服务共同协作来实现业务需求。
- 然而将各种形态各异的遗留系统接入到微服务环境中并不容易，存在以下常见问题：
- 需要对原有代码进行一定修改，但遗留系统有时本身已经难于修改，而且如果原系统是由多种语言构成的，就要为每种语言考虑解决方案。
接入代码如果是和原系统运行在同一进程中，就意味着没有很好的隔离，可能会因为接入代码的一点小问题造成原系统无法工作。那么是否存在低成本的方法，将遗留系统接入到微服务环境中呢？一种方法是使用挎斗模式，如图6-4所示。“挎斗”一词来源于带挎斗的摩托车。
图6-4 挎斗模式
如图6-4所示，具体到遗留系统接入场景下，挎斗模式就是将接入功能代码集中在一起，作为一个独立的进程或服务，为不同语言的遗留系统提供一个同构的接入接口。在部署结构上，挎斗服务与原遗留系统紧密相关，原遗留系统在哪里它就在哪里。对于原遗留系统应用程序的每个实例，旁边都部署和托管了一个挎斗实例。挎斗是支持与原应用一起部署的进程或服务。
使用挎斗模式的好处有以下几个：
- 挎斗服务是独立运行的进程或服务，与原遗留系统的实现语言无关，不需要为每种语言各开发一种挎斗。
- 由于是非侵入式的接入方法，通常不需要改写原遗留系统的代码，可以实现零修改成本的接入。
- 挎斗服务与原遗留系统相邻部署，可以访问与原系统相同的资源，有时可以拿来作为监控服务的接入代理。
- 虽然增加了一些通信成本，但是由于挎斗与原系统相邻部署，增加的通信成本往往很少，延迟很低。
在使用挎斗模式时，也需要注意以下问题：
- 注意与原系统相邻部署，降低通信时延。
- 注意进程间采用与语言无关的通信机制，如REST。
- 考虑使用容器化的部署方式，比如将跨斗服务和遗留系统部署在同一个Pod中。
- 考虑放入挎斗的功能，是作为单独的服务或是传统的守护进程运行方式。
ServiceMesh就是采用了挎斗模式的思路，在每个服务近端部署一个代理，帮助遗留系统接入ServiceMesh，享受服务治理带来的好处。
三、遗留系统改造场景
在进行具体的改造前，可能会遇到如下的挑战：
- 新旧系统可能需要不同的数据源，或具有不同的数据库结构，怎样解决数据之间的同步和依赖问题呢？
- 单体应用下的旧系统需要拆分为多个服务时，怎样实现安全的渐进式拆分？
下面根据遗留系统改造过程中的常见场景，来一一解答这些问题。遗留系统的常见改造场景，如图6-5所示。
图6-5遗留系统的常见改造场景
如图6-5所示，对于某个具体改造需求，可以分为以下两种不同的场景。
- 实现新业务：需要在系统中增加新业务，与现有业务相对独立。根据新业务与现有业务之间.
- 否存在数据依赖关系，又可分为两种子场景，即与现有业务数据独立或者与现有业务数据依赖。
- 对现有业务微服务化：需要将系统的现有业务改造为微服务架构，比如对现有业务的拆分和服务化工作。
改造场景1：实现新业务时与现有业务数据独立
图6-6改造场景1：业务数据独立
由于和遗留系统的数据之间无耦合，新服务的技术栈、工具选型就比较灵活，充分利用到微服务技术的异构性。
改造场景2：实现新业务时与现有业务数据依赖
新业务与现有业务有数据依赖时，根据数据持有者不同，有两种处理方案。
- 方案A：遗留系统持有数据，新业务访问共享数据。
- 方案B：新业务服务持有数据，通过数据同步解决数据依赖问题。
方案A：遗留系统持有数据，新业务访问共享数据
适用场景：允许新业务访问遗留系统的共享数据，或者数据库分离成本较高。
实现方案：在允许新业务服务直接访问遗留系统的数据库的情况下，最简单的一种实现方案是新业务服务直接连接遗留系统数据库获得数据，如图6-7所示。
这种方案的实施成本相对较低，与原有数据源进行集成即可，但缺点也在于此，由于直接使用了数据库作为集成方式，新业务服务仍与原遗留系统数据存在直接耦合，原数据库的变动会直接影响到新业务服务的实现，而且对于新旧业务的数据访问权限与控制也需要纳入考虑范围内。针对这些问题，也可以考虑另外一种方案，即新业务服务通过遗留系统所提供的API来获得数据，如图6-8所示。
适用场景：新业务与现有业务数据独立，不存在依赖。
实现方案：新业务可以通过单独的服务和数据库来实现。在消费者请求和底层系统之间引入一个绞杀者门面服务，该服务负责将请求按照业务不同路由到遗留系统和新业务服务上即可，如图6-6所示。
