企业传统应用架构向微服务架构转型的一种流程设计

刘帅华， 王天青

(1. 上海道客网络科技有限公司， 上海 200233； 2. 星环信息科技(上海)股份有限公司， 上海 200233)

0 引言

在互联网化转型过程中，传统企业的销售模式转为直接服务最终消费者。这对企业创新的速度，服务的连续性、扩展性和移动为中心的用户体验提出了很高的要求。相应地，也对企业IT架构，以及软件交付的速度及质量提出了新的要求。云原生[1]技术栈正好符合企业架构转型的需求，但是经研究数十个项目的经验表明，企业转型过程中，具体的架构技术，DevOps研发流程和工具链往往并不是首当其冲的问题，最大挑战往往是这些传统企业缺乏对整个转型流程的正确认识[2]。

传统的应用架构，不管是单体架构还是SOA架构，在满足这样的需求方面往往已经力不从心了。微服务架构[3]的提出恰当其时。简单来说，微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式管理，服务可用不同的语言开发，使用不同的数据存储技术。

然后，这种转型并不容易，在转型的过程中，很多企业往往只了解了微服务架构本身或者微服务开发框架本身，但是对于如何落地微服务架构，包括从需求分析、系统设计、代码框架、研发流程与平台和应用运行平台等多个方面如何循序渐进并相互配合的推进缺少系统化的认识，导致了转型失败或者低效。

(1) 业务人员对IT和研发不甚了解，表达需求的时候使用了很多口语化的表达，而不是系统性和结构化的表述需求。但是，任何一个微服务架构都是对业务架构的映射，因此开发者需要一套方法梳理需求，将其中的业务逻辑、流程和约束以形式化的方式进行描述，从而便于开发人员理解和实现需求。

(2) 服务的划分往往凭着架构师或者开发人员的经验，没有一套成熟的方法论。因此，需要一套方法论将单体应用进行拆分为一组合理的微服务，以便满足业务部门对应用架构的需求。

(3) 基础架构往往只是使用了虚拟化技术，对应用的编排、调度、监控和日志等支持相对较弱，同时很多操作都是手工完成。因此，需要一套敏捷的基础架构系统，用来支撑微服务系统由于它的复杂性带来的编排、监控和日志等新的挑战。

(4) 交付流程自动化程度低，往往只实现了持续集成。因此，需要一套从需求分析、编码、测试、部署到运维的一套方法论和工具链来加快从代码到生产的交付速度和信心指数。

1 架构设计的流程与方法

企业传统应用架构向微服务架构转型是一个系统工程，因此需要使用一套清晰完善的、具有普适性的流程指导帮助转型。针对企业传统应用架构向微服务架构转型遇到的挑战，经过多个项目的实践和总结，总结出了一套转型流程，能够很好地解决转型过程中遇到的问题，如图1所示。

图1 转型流程

由图1可知，前5部分为应用架构的转型，后5部分是使用容器技术和DevOps自动化流程来标准化交付物和交付流程，以及满足微服务架构带来的自动化运维需求。每一步的具体研究如下。

(1) 传统应用架构的调研，了解企业目前的业务结构，系统架构及各类运营指标。

(2) 业务架构梳理：可以使用用户故事地图[4]，将需要完成的功能按照时间维度进行排序和管理，同时编写产品需求文档，将重要的业务流程，逻辑和约束进行描述。

(3) 领域设计：使用领域驱动设计[5]的方法论和原则，识别上下文和领域，定义领域模型、实体对象和值对象等。

(4) 系统设计：主要针对系统性的需求[6]，即非功能性需求来进行设计。例如，为了达到系统高可用，对于服务经过研究需要采用Master-Slave或者Cluster的方式；为了达到高伸缩性，需要使用负载均衡和服务注册与发现。

(5) 微服务开发框架引入：业界已经整理出了微服务架构的一些核心模式[7]，同时例如Spring Cloud[8]这样的微服务开发框架已经将微服务的一些核心模式以组件的方式提供支持，包括配置中心、服务注册与发现、熔断器和分布式追踪等，因此可以将这样的开发框架引入，加快微服务应用的开发。

(6) 微服务基础设施构建：除了微服务业务和通用服务之外，配置中心、服务注册与发现和熔断器等微服务基础组件需要按需要进行构建，核心是根据应用需求设置部署模式和配置参数。

(7) DevOps自动化流程构建：微服务架构带来的复杂性，导致用人工部署/管理的成本极高，因此经过研究需要将需求分析的工具、任务分配的工具、代码管理的工具、持续集成的工具、测试的工具、部署的工具和运维的工具，按照既定的流程整合在一起，并实现自动化，从而加快交付的速度及质量。

(8) 应用容器化：容器[9]技术最大的好处是标准化，它将程序及其依赖的环境以镜像的方式标准化，从而确保它在任何支持容器的操作系统上运行的行为是一样的。同时它标准化了运维的工作，简化了运维的复杂程度。

(9) 容器管理平台集成：当运行的容器数量大大增加并且跨多台主机的时候，容器管理平台[10]就显得非常重要。它提供了容器编排、调度、监控和日志管理等管理平台必备的功能。

(10) 微服务运维设施构建：微服务架构中服务是第一公民，而容器世界中容器是第一公民，因此一些有交集的功能，如应用的服务注册与发现和容器的服务注册与发现需要很好地集成在一起，以免出现不匹配的情况。

2 转型实践

传统三层架构图如图2所示。

图2 传统三层架构图

应用该流程设计，以上述车企为例，转型前它的架构是一个典型的三层架构，遇到了如下问题。

(a) 系统耦合性高

① 做任何改动花费太高；

② 功能，一挂全挂；

③ 模块与模块之间功能有重叠，设计不合理，存在数据不一致的问题。

(b) 故障定位难

① 发生异常时，对于影响范围无法做出清晰的判断；

② 用户请求在系统内部的执行流程无法有效跟踪。

(c) 故障恢复复杂

当发生异常时，会终止链接，要靠人工恢复，非常慢，而2017年，该App需要支撑的业务目标却有如下几点。

① 用户数：2017年底目标120万，挑战150万；

② 迭代速度：一月一迭代，全年完成49个大功能；

③ 可用性：满足99.9%核心业务可用性；

④ 性能：单一请求响应不超过3秒。

因此按照上述转型流程对它进行转型，如下。

① 对已有需求和2019年的新需求进行梳理。

② 重新构建用户故事地图。

③ 根据业务梳理的结果进行领域设计，划分领域并定义微服务。

④ 根据可用性和性能需求，对系统进行设计，包括缓存机制，负载均衡机制等。

⑤ 将原有Spring MVC项目改造为Spring Cloud项目。

⑥ 引入配置中心，服务注册与发现，熔断器等微服务基础服务。

⑦ 使用以Jenkins为核心持续交付平台，将相关的工具整合进来，并增加自动化测试的比例。

⑧ 引入Docker，构建基础镜像并构建应用的镜像。

⑨ 引入K8S，一种容器管理平台，提供了应用编排，性能监控，日志管理，负载均衡，自动伸缩功能等能力。

⑩ K8S能够和Spring Cloud Discovery集成，正确完成应用的服务注册与发现功能。

按照这个基本思路，拆分后包含10个业务服务，3个基础服务，7个微服务基础服务。目前注册人数达到60万，两周一个迭代，已经完成上线30个功能。

3 总结

传统企业的应用架构向微服务架构转型的过程中，面临着各种困难，各种先进的技术，流行DevOps研发流程和强大工具链，并不是转型成功的特效药。作为经验汇集，经过研究提出了一个转型的流程包括：分解需求，使用领域驱动的设计方法，按照特定的非功能性需求进行设计，并引入微服务开发框架，DevOps平台，容器平台等技术，加快业务开发，提升自动化交付的水平，从而加快软件交付的质量与速度等步骤。这一套流程具有一定的普适性，它是对现有技术，方法，流程和工具的一个有机组合，对转型实践具有很好的指导作用。