从微服务架构实施看企业数字化转型

摘要：

1. 为什么说企业数字化转型需要进行微服务架构升级

主要描述传统企业IT应用受互联网冲击的大背景，引出传统企业转系需要在架构上向互联网企业学习。

2. 传统企业实施微服务架构的难点是什么：历史包袱太重

从传统企业应用和互联网企业应用的不同特点说起，讲述传统企业架构升级微服务 过程中的一些重点关注的内容、方法和建议。

3. 传统SOA和微服务差别在哪：运行期的快速变更能力不同

讲述SOA与微服务的差异，进而介绍微服务改造的一些关键点。

4. 实施微服务，第一步干什么 : DevOps 

结合上两节，指出实现微服务架构升级和数字化转型，需要建立先进的生产线DevOps来支撑，并说明DevOps平台需要具备的能力和迁移过程说明。

5. 基于DevOps的企业微服务架构"长"什么样子 

简单介绍一下基于DevOps的企业架构以及DevOps平台的架构。

6. 总结

1. 为什么说企业数字化转型

需要进行微服务架构升级

面对互联网的强大活力和竞争态势，传统企业也要变革，也要向市场开放，直接面向用户，增强自身的竞争力，因此IT系统建设向数字化转型的需求也变的非常迫切。

目前企业的传统IT应用主要以服务企业内部用户为主，其特点是需求明确、功能全，覆盖广，大集成，中央控制，非常适合企业稳定和发展阶段，但缺点也非常明显，刚性强，难以快速变化，维护成本高，无法支持快速变革的新业态。

常见的一些对业务应用可靠性要求很高的企业如银行，他们对应用的变更和发布有非常严苛的流程控制，编写投产手册、反复进行投产演练、成立投产临时指挥部、安排各个部门角色的值班与协调工作等，非常复杂，一次投产流程从准备到提交审批再到最终投产完毕会持续三个月左右，整个项目周期中约一半时间都是在投产，这样的投产虽然一定程度上能够提高投产的可靠性，但效率属实很低。这样的情况实实在在的发生在了我们传统企业中IT水平较高的银行中，是非常有代表性的。毋庸置疑，这种状况一定是需要改进的，问题出在哪里以及怎么来解决值得我们思考和研究。

新兴的互联网应用的特点则是主要服务外部客户或合作伙伴，需求变动快，功能简单，独立和分散，分布式进化，一切都从零开始，业务与IT紧密结合，需要快速创新，规模变化大，大范围广泛的尝试，易失败（淘汰），对业务弹性、快速发布要求高。以上这些正是现在火热的微服务架构应用的特点和能力。

成熟的互联网企业的应用从代码提交开始，会运行各种自动测试验证，再到配置、部署也可以做到全自动化，软件投产流程可以在几分钟内自动完成。具备了很强的持续集成和快速交付的能力，一天多次部署，一周多次发布就成了顺利成章的事情。

相比互联网企业，传统企业应用想要做到持续集成和快速交付，在企业的架构方面需要向互联网型应用学习，业务应用架构需逐步向微服务架构应用转型升级，提升整体IT建设的效率与可靠性，才能更有效的加速业务创新。

 

2. 传统企业实施微服务架构的难点

是什么：历史包袱太重

 

传统企业与互联网企业IT系统建设很大的不同点在于互联网企业很多是从零开始，而传统企业则需要在之前大量的IT系统基础之上进行逐步转型和改进，因此传统企业的转型与改造更需要先进的方法论，制定标准的流程与规范，并需要完善的生产线和平台来进行支撑，盲目试错是不行的。企业应用架构转型的决策者们在规划转型的路线和方法时需要从多方位来进行思考，重点应该关注以下几个方面：

1. 需要从关注单个应用的架构改进为支撑整个企业的架构

2. IT应用架构需要从传统架构模式向互联网型应用转变

3. 开发过程和规范需要从只关注开发阶段改进到关注整个应用从设计到运营的全生命周期的关注

从单体巨石型应用架构向微服务架构的转型和升级要兼顾情怀与现实，既要面向未来，又要尊重历史，不走极端。不能推翻重来，更不能原地踏步，而是要逐步将关键应用向微服务架构方向升级和改造。在很长一段时间内，应该是新老架构应用并存，双模运行的状态。不论是单体架构应用还是微服务架构应用，他们的共性是在运维方面，都需要进行配置和部署，因此，我们建议以配置和部署作为切入点，来逐步进行历史应用的改造和升级。以下是一些传统架构升级方面的一些建议：

1. 基础设施虚拟化，基础设施即服务（IaaS）

2. 配置部署自动化，逐步淘汰人工流程，采用自动化的方式替代人工处理

3. 应用分层，抽取公共模块组件作为基础服务

4. 贴近客户的应用或者升级后可能获益最大的应用优先改造

5. 按功能特性进行微服务系统划分和建立功能特性相关的微服务团队

3.传统SOA和微服务差别在哪：

运行期的快速变更能力不同

 

关于应用微服务化改造，我们再来一起探讨一下。前些年都在搞SOA，现在又出来个炙手可热的微服务，这些概念到底有啥关系？

其实这两个概念面向的对象还是有些差异的。SOA讲的是系统间的集成与交互的方式；而微服务则是一种将传统的一个巨石型大系统切分成一个个小系统的架构理论模型。

说到这里，就又要有疑问了，拆分一个大系统，不就是模块化组件化么？

没错微服务本质也就是要做模块化组件化，区别在于原来我们做模块化组件化主要是用以设计开发期用以分工，并行开发用的，打包部署后还是一个大WAR包，运行期还是巨石应用，完全无法做到快速变更和投产上线，然而不具备快速变化能力就无法适应互联网千变万化的形势。

因此微服务化改造，是巨石应用面向互联网转型的必要条件。关于微服务化改造这里梳理了以下一些要点供大家参考：

1. 梳理和抽取基础服务、技术服务、业务服务作为独立的服务下沉，形成稳定可靠的服务中心并作为开发平台中的基础服务提供

2. 前后端分离，将前端展现与后端业务分离，实现前后分离的层次化架构；

3. 按照功能特性拆分子系统，拆分方法论可以参照 《The Art of Scalability》一书中描述的分布式扩展立方体，微服务化拆分对应图中按照Y轴即功能独立性进行拆分，将一个大系统拆分为多个独立的子系统，参见下图：

 

 

4. 选择合适的微服务容器，微服务容器选型对于微服务的快速开发交付非常重要，需要具备轻量、快速等特点。通常微服务容器需要具备秒级的启动速度，提供微服务运行的必备功能如服务发布、注册，服务发现、路由、调用等能力。选择微服务容器还需编译打包部署方面的便利性等。目前通过验证我们推荐选择SpringBoot作为Java类型后端微服务应用的基础容器。

5.统一微服务间的通信方式，我们也做了不同协议和方案的选型与评估，最终选择了基于Http协议的RESTful风格接口作为微服务间的主要通信方式，Http协议具有无状态、安全等特点，RESTful 这种面向资源的API访问方式也与微服务架构非常匹配。

4.实施微服务，第一步干什么 : 

DevOps

企业要进行数字化转型，要将传统应用逐步向微服务架构升级，除了有先进的方法论和标准流程规范之外，还需要有先进的企业级平台生产线来支撑落地实施，这个里说的生产线就是火热的DevOps。我们认为企业数字化转型，实施微服务架构升级需要从DevOps平台建设开始。

那么DevOps是前面说到的自动化配置部署吗？当然不是，前面我们也提到了，自动化配置与部署，只是一个切入点，属于DevOps中的一部分能力。目前通过自动化配置部署替代人工操作，能够解决传统IT面临的一个巨大的痛点和瓶颈，解决了这个瓶颈后，接下来可以有更多的资源和精力投入，进一步完善DevOps生产线，逐步优化整个企业IT架构。

一个完善的DevOps生产线应该具有以下特点：

1. IT资产管理，能够将整个企业的IT系统当做数字化的资产来进行统一管理

2. 全生命周期管理，能够对应用进行生命周期管理提供流程规范与工具支撑

3. 支持新老并存双模运行，能够时支持传统应用和微服务应用并存与协同

4. 持续敏捷迭代，自动化一切

5. 跨部门组织沟通、协作，打破需求、架构、开发、运维、管理等部门墙

6. 统一的概念模型，建立统一的概念模型，提供集成统一且完整的工具链（打通过程、质量、源码、测试、部署、监控、安全等工具链）

7. 完善的系统体系，组织、技术、流程规范等多方面提供理论指导和IT支撑

下面我们来看一下，如何从DevOps开始，逐步将传统应用从单体巨石架构向微服务架构升级，紧接着向云端迁移，建设公有云或者企业私有云，将企业转型为数字化企业，示意图如下：

 

 

参见上图，总体思路就是传统应用需要先从自动化配置部署开始，逐步打造DevOps平台，接下来以DevOps平台为生产线，来对企业应用进行统一的管理和运营，再将传统应用架构改造为微服务型的应用架构，最后则可以更便捷的向云端迁移，实现数字化企业转型，精益运营。

整个迁移过程从技术角度讲，DevOps平台首先要做到的是应用和基础设施解耦，传统应用中的应用部署过程，耦合了太多的下层基础设施，包括各种配置（操作系统、数据库、应用服务器、消息服务器、路由等等）。让每一次的应用部署过程变成一个非常繁杂的过程，需要来回的验证和多方的确认。那么要做到应用与基础设施解耦，需要建立以微服务为中心的统一概念模型，微服务一定要与基础设施环境解耦。执行层面，建设DevOps自动化开发运维平台和微服务化拆分结合较紧密，也可并行实施，逐步完善后，DevOps平台会成为很好的支撑微服务的快速开发交付运维的生产线，屏蔽了底层环境和依赖系统的差异，结合PaaS与IaaS基础设施，最终能够将更方面应用迁移到云端运营。

5.基于DevOps的企业微服务架构

“长”什么样子

 

 

参见上图，传统企业应用架构向数字化互联网型应用架构转型过程中，在很长一段时间周期内，企业的应用架构应该是类似图中的样子，即上文所述的双模运行模式。新系统和已经做好微服务升级的系统采用类似互联网应用架构的模式，传统SOA应用未完成架构升级的系统同时也在运行，一起为企业的业务提供IT能力支撑。传统SOA架构应用可以通过服务总线与新架构应用互通。传统应用由软件资产管理开始，逐步进行微服务化升级，最终由DevOps生产线统一管理，集中监控。

我所在的团队目前正在按照上述思路持续迭代研发DevOps云平台生产线，基于微服务架构抽象出了统一的概念模型，为应用的全生命周期管理、各部门角色协同工作等提供了统一集成的工具链，依托于容器化的基础设施服务CaaS，结合了多年传统企业应用的实践经验总结，目标是为企业应用向微服务和数字化转型提供切实的理论指导和有力的技术支撑。下图为DevOps云平台的逻辑架构图请参考：

 

 

6.总结

本文的主要目的是将传统企业数字化转型中关于微服务改造方面的一些经验分享给大家，这也是站在平台提供者角度对支撑企业应用的经验总结和转型方面探索的一些思路，希望能够对大家有所启发。简单总结一下，就是企业数字化转型是大势所趋，微服务架构升级又是转型的必由之路，而实施微服务架构升级则需要从DevOps开始。

建设DevOps平台同企业数字化转型一样，都是一个持续改进优化的过程，不可能一蹴而就，也不可畏首畏尾裹足不前。不同企业需结合自身情况尽快找到一个切入点推进数字化转型，为走向互联网、面向企业的未来打好每一场战役，让我们遇见未来！