转载

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

虽然今天一提起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商店服务外部客户。

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

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