如何改造传统应用为云应用?

随着云计算的深入发展，越来越多的应用是以一种云原生的方式被开发的。例如，在新的PaaS平台上开发的应用，我们通常也称之为第三平台应用或云原生应用（CNA=Cloud Native Application）。

而业界普遍遇到的一个棘手的问题是还有相当大数量的传统的应用（即第二平台应用或Monolithic Application）如何去维护？例如新的CNA在云数据中心中，而传统应用通常跑在原有的数据中心中，它们对开发、测试与维护的要求不尽相同，自然也会带来不同的挑战。

如何把传统应用改造为新型云生应用是我们在本篇中着重关注的。

有一种流行的提法叫作Lift-n-Shift（提起后平移），指的是把传统数据中心中的企业级应用原封不动打包（例如封装在VM或容器中）后向云数据中心（如公有云AWS）迁移，并直接运行于其上。这听起来不像是很复杂的一件事情，但事实上能这样简单且成功操作的应用并不多见。多数的第二平台的企业级应用都要比想象中复杂。在对其进行云化改造的过程中，需要考量的因素很多，因各种定制化而造成的限制也很多，例如：硬件、操作系统、中间件、存储、网络等。

在本案例中，我们会按照一个三步走的方案来改造第二平台的传统应用为第三平台云生应用：

（1）把第二平台应用封装后运行在PaaS之上；

（2）整理、选定应用组件并改造为微服务；

（3）通过工具链接这些微服务后整体运行于PaaS平台之上。

从方法学角度看，如何能实现以上的每一步呢？

笔者在Pivotal的同事们给出了以下的敏捷实现方法：

（1）每一次变动都是小的、渐进的（Small and Incremental Changes）；

（2）确保每次变动之后的测试是充分的，被更改后的产品是能正常工作的。

我们选择一款在GitHub上面叫作SpringTrader的基于Java语言环境编写的开源股票交易软件来为大家演示如何将其从传统的B/S（浏览器/服务器，如下图所示）架构迁移并成功运行在PaaS平台Cloud Foundry之上，然后把SpringTrader中的主要组件以微服务的方式重构。

把SpringTrader这样的典型Java（企业级）应用向PaaS（如Cloud Foundry）迁移通常会先后遇到如下一些问题。

（1）编译环境问题，例如JDK升级。

（2）部署脚本更新。

（3）是否需要对库栈（Library Stack）做大幅度调整：依照之前我们提过的小步幅调整原则，应当尽量避免对库的依赖性做大规模调整。

图：SpringTrader Web GUI

能成功运行在PaaS之后，我们的下一步就是如何把架构调整为MSA。如下图所示，SpringTrader采用的是典型分层逻辑架构，它通过数据库层提供的模拟的股票信息服务，因此我们在改造过程中第一步就是看如何可以把真实的股票市场信息以MSA的方式接入到SpringTrader架构中。

图：SpringTrader的初始逻辑架构

为SpringTrader提供基于MSA架构的股票信息服务，我们需要四个步骤来完成：

（1）在源码中找到现有Quote部分的实现。

（2）找到现有代码中的实现的QuoteService接口。

（3）通过代理模式（Proxy Pattern）来实现QuoteService接口。

（4）调用新的QuoteService服务。

在这里，股票信息源来自于Yahoo! Finance，QuoteService通过标准的RESTful JSON API来调用Yahoo! Finance API，并通过SpringTrader的BusinessService模块向展示模块提供数据。改动之后的SpringTrader架构如下图所示。

图：连接了Yahoo! Finance之后的SpringTrader逻辑架构

在把更多的服务改造为MSA或添加额外的微服务之前，我们还需要考虑至少三个问题：

（1）当远程服务连接失败时如何处理？

（2）如何自动地定位与管理（松散连接的）服务？

（3）调用外部服务时，如何处理返回的异构的JSON格式信息？

解决以上三个问题的关键如下：

（1）服务发现（Service Discovery）：通过Netflix开源的Eureka服务来实现服务的注册与自动发现。在SpringTrader中，我们提供了多个股票市场信息源，它们的注册管理与自动发现都可以通过Eureka的帮助来实现。 （2）回退机制（Fallbacks）：回退机制在企业级应用中的作用就是确保服务始终在线，当首要股票信息服务掉线时，可以自动切换到备用服务。在SpringTrader中我们采用了Netflix开源的Hystrix，一个基于circuit-breaker（断路器）模式设计理念开发的延迟和容错库（Latency and Fault-Tolerance Library）。 （3）JSON调和：好在开源社区已经有类似的解决方案，以Netflix开源的Java-to-HTTP客户端绑定Feign提供了GsonDecoder解码器，可以把JSON信息翻译为域对象（Domain Objects）。这样，在解码器当中可以处理各种异构的JSON信息，而不至于需要去改变SpringTrader的API。

实现了以上改变之后，SpringTrader的架构如下图所示：

图：添加了Service Discovery/Fallback的SpringTrader

像SpringTrader这种典型的交易服务软件中除了Quotes（股票信息）服务可以被改造为微服务架构，其他的还有：

（1）账户服务（Accounts）；

（2）订单管理服务（Orders）。

在上图中展示了最终的SpringTrader的架构。

在整个SpringTrader从Monolithic到MSA的改造过程中，有如下一些数据供我们思考：最初的Java代码大约7,000行全部为Monolithic设计，而最终新增的MSA代码少于2,000行，剩余的Monolithic代码大约6,000行，这其中有相当的代码是为了实现弥合（Remedial）与测试（Test-related）功能。在改造SpringTrader的过程中，因为Java与Spring开发环境的规模庞大，依赖关系复杂，我们使用了构建自动化（build automation）软件Gradle，把整个SpringTrader的模块间的依赖关系整理与管理起来，总计有173个依赖关系（data module dependencies）!