王健+李冬睿

摘 要 文章针对目前单一模式系统开发周期周期长、开发成本高等困难，将原有系统往微服务架构上迁移提出了几种解决方案，结合具体场景，讲述了各个环节的实现机制。

关键词 微服务 单一模式 迁移转化技术

中图分类号：TP271.4 文献标识码：A DOI：10.16400/j.cnki.kjdkx.2016.09.021

Abstract Aiming at the current development cycle of single mode system of long period， high cost of development difficulties， the original system to the micro service architecture on migration of several solutions are proposed， combined with the specific scene， describes the realization mechanism of each link.

Key words micro service； single mode； migration and transformation technology

1 Web系统架构情况概述和分析

目前web系统架构具有如下几个特征：（1）以快速上线，快速迭代方式发布单一系统为主要模式。单一系统开发易于调试，只需要简单运行此应用；易于部署，只需要把打包应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝无状态服务就可以轻松实现应用的横行扩展。对于中小型web系统开发周期快，运维门槛低。（2）随着需求变更，系统逐渐演变的越来越复制。最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。另外，如果代码难于理解，就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。（3）传统开发模式无成本和效率优势，制约企业发展。目前单一架构应用也使得采用新架构和语言非常困难。应用无法扩展，可靠性很低，最终，敏捷开发和快速部署变得无法完成。

2 微服务架构处理复杂事务

2.1 微服务架构优势

微服务架构将服务拆分，分别采用相对独立的服务对各方面进行管理，彼此之间使用统一的接口来进行交流，架构变得复杂，优势也很明显（如图1）。

（1）解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变。这个应用被分解为多个可管理的分支或服务，每一个服务都有良好定义的边界，以远程过程调用（RPC）驱动或信息驱动的API的形式；微服务架构模式单一模块代码库，实际很难实现。因此，独立的服务开发速度明显更快，而且更易理解和维护。

（2）让每个服务能够独立开发，开发者能够自由选择可行的技术，让服务来决定API约定。当然，大多数组织会通过限制技术选择来避免完全的失控。然而，这种自由意味着开发者们不用被迫使用从项目开始就存在的陈旧技术，他们可以选择使用当下的技术编写一个新的服务。另外，由于这些服务本身相对比较小，用新的技术来重写旧的服务也更可行一些。

（3）每个微服务都能独立配置，开发者不必协调对于本地服务配置上的变化，这种变化一旦测试完成就被配置了。举个例子，UI团队可以执行A|B测试后立刻对UI的变化执行迭代。微服务架构模式使不断地配置成为可能。

（4）让每个服务都可以独立调整，你可以给每个服务配置正好满足容量和可用性限制的实例数。另外，你也可以使用最适合服务的资源需求的硬件。举例说明，你可以在EC2计算优化的实例上配置CPU加强的图片处理服务，另外给EC2存储优化的实例配置内存中的数据库服务。

2.2 实践从单一模式系统重构到微服务架构系统

为了未来系统的扩展性，对原有庞大的单一模式系统进行微服务重构，既让人兴奋，又充满挑战，下文将提到几种重构方案。这里需要强调下按照微服务架构，重写全部系统代码，对任何已经在线上运行的中大型web系统来说，都是不可行的，变更风险太大，系统测试不完善会直接导致，系统挡掉，无法对外提供服务。

2.2.1 停止在单一模式的系统上开发新业务

首先停止让问题更糟。不要继续通过向单一应用程序添加代码的方式来实现新功能。采用某种方式来将新功能实现为独立的服务。这可能并不容易。你可能会编写凌乱的，复杂的胶水代码来向单块应用程序集成服务。但这是打散单块程序的第一步。

这种方案有2个新增模块“request router”和“glue code”（如图2）：

Request Router

前端的请求路由层，用于处理（HTTP）请求，将符合新规则的请求发送给新增的服务，老的请求发给原有系统。

GlueCode

在程序设计中，为了让新服务可以使用老系统的功能和数据设计编写的，将不同部分的不兼容的代码“粘合在一起”。在编写代码过程中，粘合代码为了让存在的库或程序间进行交互。这里有3种访问老系统方案：

（1）给单一系统添加远程调用API

可以使用REST HTTP API

或者跨语言调用框架 Thrift RPC；

（2）直接访问单一系统数据库；

（3）访问复制的同步的单一系统数据库，并保持同步。

利用以往的开发经验，可以新建一个可伸缩的微服务，控制住单一系统的复杂度。

2.2.2抽离web层与业务逻辑层

表现层与业务逻辑层分离。单一模式系统内的架构中，调整本地调用方法，更改为远程调用方法。

典型Web应用通常由至少三个不同类型的部分组成（如图3）：

表示层——处理HTTP请求并实现（REST）API或基于HTML的网页UI的组件。在一个有复杂的用户界面的应用中，表达层常常有大量的代码段。

业务逻辑层——是应用的核心组件，实现业务规则。

数据访问层——访问基础设施组件的组件，比如数据库和消息代理。

抽离展现层的优点：

（1）接口预先定义，开发视野提升，需求驱动。

（2）开发和设计工作分离。

（3）利于更快定位性能瓶颈。

3 总结

单一模式是构建企业级应用程序常用的模式。对于小的应用程序它很适用：开发，测试和部署小型的单块程序相对简单。但是，对于大型的复杂的应用程序，单一模式会阻碍开发和部署。如果你经常长期的锁定你的初始技术选择，则会使得持续交付变得困难。对于大型的应用程序，更适合适用微服务架构，其将应用程序分解为一组服务。

微服务架构有很多优点。例如，单个服务更容易理解，可以独立于其它服务来开发和部署。也更容易使用新的语言和技术，因为你可以一次只对一个服务尝试新技术。微服务架构也有一些显著的缺点。特别是对那些更复杂，拥有更多变化部分的应用程序。你需要高级别的自动化，来高效地使用微服务。你也需要在开发微服务时处理一些复杂的分布式数据管理问题。尽管有这些缺点，微服务架构还是更适用于大型的复杂的应用程序，因为可以快速演化。

参考文献

[1] 韦伯.帕拉斯泰迪斯.鲁滨逊.REST实战：中文版超媒体和系统架构.中国：东南大学出版社，2011.

[2] MICROSERVICES From Design to Deployment by Chris Richardson with Floyd Smith.

[3] Building Micorservices by Sam Newman Copyright 2015 Published by OReilly Media.