步骤1：通过遗留系统API提供数据
通过如上所述的方式，极大地减少了对原门户平台的修改，同时通过在新服务上实现相关逻辑，不仅提升了交付效率，而且该服务能够独立部署上线。
步骤2：通过遗留系统数据源提供数据
接下来，研发团队接到的特性需求如下：
- 支持房产发布者的信息展示。
- 支持地理兴趣点（POI）信息显示。
但是这两部分的数据在原门户平台的基础搜索API中并未包含，在面临人手有限和交付时间紧的挑战下，如果要在门户平台中新增接口，变更成本会比较高，可能无法按时交付。
面对这些挑战，团队决定尽量避免对原有遗留系统的直接修改，改为在AppService微服务中实现新业务逻辑，做了如下修改：
- 直接访问遗留系统数据源：由于原门户平台的基础搜索API提供的数据不足，便让AppServic
- 通过直接访问遗留系统数据源的方式，获得所需的房源、发布者、地理兴趣点等数据信息。
- 构建基础搜索模块：在AppService中构建基础搜索模板（EngineAPI），实现与原门户平台的基础搜索API同样的功能，提供数据给上层API。
- 构建业务层API：在AppService中构建业务层API，新增两组API，分别是提供地理兴趣点数据的POIAPI和房产发布者信息的PubAPI。
- 独立地理位置服务：将之前相对独立的LocAPI，拆分出来作为独立的地理位置服务LocService。
改造后的系统架构图，如图6-15所示。通过这步改造，将基础搜索数据的查询功能重构到了AppService微服务内，减少了对原门户平台相关功能的修改。
步骤3：拆分基础搜索服务，替换数据源
产品的需求持续演进，接下来，团队需要为桌面端用户新增支持多边形的地理位置搜索功能。但在现有架构下，FASTSearch搜索引擎并不支持这个功能，这就意味着需要替换原有的搜索引擎，需要对原门户平台的代码做大量的修改。
如何有效地实现这个特性呢？具体操作方法如下：
1．将基础搜索API拆分出来作为独立服务EngineService，这样以后关于搜索相关的逻辑，都可以放在EngineService中实现了。
2. 在EngineService中实现基于多边形的搜索。
3. 对原门户平台的搜索机制重构，让其使用EngineService获取相关数据（之前是使用FASTSDK）。基于这种方式，门户平台和AppService与底层搜索引擎隔离开来，可以方便地替换底层数据源。
该方案的实现，如图6-16所示。
步骤4：构建移动端专属的后端服务
团队在预期时间内很快地完成了前面的各项需求，随着业务发展迅猛，接下来需要在手机端和平板端增强用户体验。然而，目前手机端、平板端的实现逻辑较落伍，均是基于JSP的模板方式实现。如果要直接修改，成本高。
考虑到在屏幕尺寸、性能和显示限制等方面，移动设备与桌面浏览器的能力存在显著差异。因此，移动应用对后端的需求与桌面UI是不一致的。
如果仍然使用原有的门户平台逻辑，则需要同时为这两种客户端提供数据，这极大地增加了维护的成本。于是，团队借鉴了BFF模式，将手机端和平板端网站的特定后台需求，拆分为一个独立的后台服务SPA-Web，作为后端实现。为前端提供数据。然后基于最新的前端技术，采用轻量级、更有效的单页面方式实现前端，如图6-17所示。
步骤4：构建移动端专属的后端服务
通过为移动端创建一个专属的后端服务，可以为移动端的用户进行专门的优化，量身打造最佳体验。同时，由于微服务架构下的这个新服务足够的小而简单，就更容易进行修改、部署和上线了，也更容易在性能和行为方面进行精心的优化。
步骤5：基于数据继续划分微服务
随着团队的微服务化实践越来越成熟，整个系统的架构趋向于朝更细的粒度演进。
系统典型的业务场景分为待售房源（Buy）、已售房源（Sold）、待租房源（Rent）等。所以，团队基于这些业务继续划分单独的搜索API以及独立的数据存储机制，每种数据由独立的ElasticSearch 集群存储，并利用前后端分离的机制实现前后端的解耦。
解耦后的系统，如图6-18所示。
对于系统中使用的服务支撑组件，如服务注册发现机制、集中化配置信息等机制，其实现和在之前的章节中阐述的差不多，这里就不展开赘述了。
3. 改造结果
可以看到，经过上面一系列步骤后，原有的门户平台已逐渐迁移为微服务的系统，原有的大约300万行的代码也只剩下了大约50万行，继续提供着业务价值。团队对遗留系统的修改和变更成本已经大大减少，总体交付周期也大大缩短，技术的升级带来性能、可维护性的提升，充分享受到了微服务架构小而美的好处。
小结
本章介绍了遗留系统的特点、改造策略和场景，并结合一个实战案例进行了讲解。目的是帮助读者从以下方面掌握对遗留系统的微服务改造方法：
- 遗留系统是“需要被替代的系统”，往往存在类似的特征，如难于修改、学习和维护成本高、缺乏质量保障等。
- 通过直接重写并一次性替换遗留系统解决微服务改造问题是不现实的，可能会导致上线困难、影响面不可控、学习成本高等问题的产生。
- 对于遗留系统的改造过程，应当采取逐步替换而非一次性替换的策略。通常采用“演进式改造流程”和“绞杀者模式”来保证整个改造过程可控，并实现平滑过渡。
另外，对于遗留系统的改造需求，本章将其细分为三种场景，如新业务数据独立、新业务数据依赖以及现有业务服务化。通过对这些场景的分析，能有效地指导读者进行微服务的演进。
本文节选自《微服务架构与实践（第2版）》一书，王磊等著，电子工业出版社出版。点击阅读原文，可直接购买此书。
