面对“恐龙级”老旧系统，怎样用微服务实现敏捷交付？

作者介绍
刘华（Kenneth），就职于世界500强银行。负责基金外包业务软件开发与交付。敏捷、精益、DevOps领域专家。著有《猎豹行动 硝烟中的敏捷转型之旅》一书。

虽然今天一提起IT，很多人首先想到的是互联网。其实，银行是IT技术的首批重度用户之一，也因此，银行有大量的遗留系统，有些“恐龙级”系统甚至有超过30年的历史。所以，银行系统给人的刻板印象总是老旧、臃肿、用户体验差。

一、遗留系统的问题

遗留系统经历了很多代人在上面“添砖加瓦”，其代码早已经是一团乱麻。维护难，变更成本高。

1、强监管导致开发求稳

银行是一个强监管、不允许出错的行业，长期以来，其系统设计、开发节奏的原则就是求稳，快速应变一向不是传统银行系统要考虑的事情，这些特性也深深根植在遗留系统中。

但是面对快速变化的市场环境和业务需求，特别是互联网金融的冲击，近年来，银行也要探讨如何更敏捷地交付和实现DevOps。这些遗留系统显然不能适应新时代的要求。

2、难以一次性替代遗留系统

然而，要一次性替代遗留系统又谈何容易呢？由于系统已经深深根植在银行的生态中，每个系统和周边系统都有千丝万缕的关系，剪不断理还乱。

3、数据迁移缓慢

数据迁移也是一件头疼的事情。我们其中一块业务要把原来的系统替换掉，光是数据迁移就花了两年的时间，而这个项目我们原本的计划的时间是一年，也就是说，它实际延期了整整一倍的时间，成本也大大超出预算。这种现象几乎发生在所有银行系统的升级、替代项目中。因此遗留系统的替代成本很高，也蕴藏着巨大的风险。

4、员工成就感不高

对于员工来说，外面的世界都在谈论微服务、互联网，甚至是人工智能、区块链等新技术，而长期维护这些系统的IT工程师完全没有机会接触到这些新技术，他们很容易感觉到自己与外面的世界完全脱节，工作成就感不高，对公司来说，也不利于人才培养和团队稳定。

5、系统间交互重度依赖落地文件

除了以上问题，我们的系统间交互重度依赖落地文件。每一个落地文件除了要满足对方的数据要求外，还要完全匹配格式的要求，这就导致每当需要一个新的接口文件时，都可能需要进行定制化开发，成本高，周期长。特别是要和其他外部客户进行数据对接时，这样的定制化开发导致我们接入新客户的周期变长，影响了业务开展的时间，错失市场机会。

在我们的一个项目中，我们的系统需要和20多家台湾的托管银行进行数据对接，其实大家所需要的数据都差不多，但是因为没有统一的文件格式，我们不得不为每一家托管银行开发落地文件接口。因此，我们的业务也在推动客户通过API和我们交互数据。API的好处是，我们只需要满足对方所需要的数据，如何“消费”数据完全由对方自己处理，实现了解耦。

二、解决方案

在这个契机下，我们产生了通过在遗留核心系统外围搭建自主研发的API微服务系统的思路：

一方面可以加快接入新客户的进程；

另一方面可以逐步降低对遗留系统的依赖，并借此机会让我们的IT工程师接触和掌握最新的微服务技术和框架。

由于是全新系统，我们采纳了最新Spring Cloud全家桶和Spring Boot框架：

Spring Cloud提供了微服务网关所需要的所有组件，如路由、服务注册、熔断、配置中心等。

Spring Boot具有“开箱即用”的特性和大量强大的Starter组件，大大加快了开发微服务应用的速度。

同时，我们也利用其它最新的开源框架如ELK做分布式日志跟踪、Grafana做服务监控、Zipkin可视化请求访问链路等，实现了系统的现代化。
我们采纳微服务架构是为了实现DevOps，而在API开发过程中，我们采用了大量DevOps工具栈实现持续交付。

基于Spring Cloud Contract的契约测试解耦上下游开发——通过契约，我们作为API提供者与API消费者在开发前就约定了对接口的期望，这样双方不必等对方都完成了开发才能进行集成测试，而是可以围绕契约按照自己的步伐进行开发和测试；

通过FitNesse实现验收条件驱动开发——与业务人员在需求阶段把具体的验收条件确定下来，并通过FitNesse的文档固化下来，然后编写相应的测试代码把验收测试自动化，成为持续集成的一部分。实现了交付的闭环；

通过Ansible实现自动化部署和基础设施即代码，实现快速部署。

由于数据全部来自遗留系统的数据库，而遗留系统的数据结构也非常复杂，比如获取基金信息，背后可能需要整合几十个数据表。

我们通过设计领域模型对系统能提供的数据进行了抽象，形成领域模型，并以此划分微服务应用的边界，使每个微服务应用可以提供一个独立的领域数据，确保服务的隔离性。

按照目前的设计，我们将提供基金、投资者、销售机构、交易数据等的领域数据，并整合到银行的API商店服务外部客户。

通过微服务架构，整个系统的伸缩性也得到了保证，当某些服务需要更多资源时，如交易数据服务，其数据量大，请求频繁，我们可以根据流量，通过部署多个交易数据微服务应用来进行横向容量扩展。

我们也在研究系统上云的可行性，云部署将为我们提供更好的弹性和一步到位的容器化解决方案，降低运维的难度并提高可靠性。

三、从想法到现实

我们有了思路和想法，但是要使它得到认可并变成现实需要经历一个反复沟通的过程。我们的架构设计需要得到架构委员会的评审和认可，在可行性、灾备、技术栈上都要考虑周全。

继而我们也请了一些不了解我们业务和系统的外部专家来进行评审，我们要说服这些“外人”明白我们想做什么、怎么做以及为什么要做，这样也能让这些专家提出一些我们未考虑到的点。

然后我们要和其他要做API的部门开展API工作坊，确保大家在网关、技术栈、安全机制上有统一的规范，将来实现更好的融合。

而最最重要的是，我们目前还是基于项目立项的，没有单独为产品立项的机制，所以要把这个产品做出来，还需要寻找一个合适的项目，通过项目实施把它实现出来。经历了半年的历程，我们的想法已经成为目前某个重要项目的实施过程。

四、总结

大量遗留系统是银行普遍的痛点，我们通过在遗留系统外围搭建自主研发的微服务系统来逐步降低对遗留系统的依赖。

系统间交互重度依赖落地文件，我们通过用API取代落地文件来解耦上下游的开发依赖。

通过这些手段，我们将加快接入新客户的进程，也会提升自身的敏捷性，创造更多让员工接触、掌握最新技术的机会，实现银行系统的现代化，更好地适应快速变化的市场环境和业务需求。

以上是我关于银行遗留系统痛点的分享，后续我将着重解析基金服务API微服务系统的构建过程与技术实现，欢迎大家持续关注，有想要了解的内容也可留言告诉我。