传统企业IT架构和微服务转型-从需求问题到实施策略

在前面头条文章中我分享过钟华老师的《企业IT架构转型之道》这本书的读书笔记，这本书基于阿里的中台战略，服务中心，SOA服务治理给出了相对多的最佳实践，也给了传统企业转型很多有借鉴意义的思考，但是对于传统企业IT架构转型还是有许多问题值得思考。

因此今天对传统企业IT架构转型，传统架构微服务化方面再做下总结整理。

传统企业IT架构转型概述

企业IT架构为什么要转型

传统企业内部信息化部门的核心目标仍然是基于业务驱动IT的思路，通过IT规划和应用的建设更好的支撑企业业务流程，IT本身的价值都体现在IT系统建设对业务核心价值链的绩效提升和增值上面，而不是体现在各种先进技术的应用，技术只是工具手段，最终业务能力提升才是最终目的。

企业信息化推进可以理解为三个阶段。

第一阶段是基础应用建设解决基本的业务和流程协同自动化，提升基本的效率；第二阶段是提供管理层的管理能力，实现基本的业务全流程协同和管控；第三阶段则是到了决策层的辅助决策和商业智能能力。

虽然我们一直在强调业务推动IT，但是了第二和第三阶段，你会发现往往强势的IT部门会反推业务进行优化和变革，这也是在传统企业经常会碰到的现场。

企业IT架构为什么要调整？核心原因仍然是在业务敏捷性和IT成本投入上。

首先是企业业务高速发展，IT系统的建设和能力无法匹配，这里面包括了业务功能，接口，性能，安全的匹配；也包括了对于有新的业务开展如何快速地迭代和版本升级后的变更匹配。在业务系统不能提供快速，准确，高性能和高易用的功能时候，往往IT就成为业务发展的瓶颈，业务人员也花大量时间在系统响应等待，数据协同等待，变更功能需求开发等待，数据核对等大量事务上面。对于如何更加敏捷地响应业务这个问题，我们就需要去考虑哪些是通过IT架构调整能够更好的解决的。

我们常说的SOA参考架构的思想，实际和制造企业的敏捷和柔性生产思路完全一致，即面对前端需求的变更，我们如何做到整个IT应用的柔性和快速响应能力。

其次就是信息化部门经常遇到的IT系统管控困难和大量成本重复投入问题。企业在发展过程中IT系统越建设越多，很多相同的业务系统还3到5年就换一次，反复建设和重复投入，各种服务器，存储硬件资源也大量购买而利用率低下。对于外包给供应商开发的业务系统后续自己无法运维管理，只能依托和受制于厂家，系统间的交付和接口也越来越复杂，很难真正看得上整个信息化建设后的全局应用架构视图，以及IT对业务当前的支撑情况，包括差距分析等。

而这些问题最终都体现在能否通过IT架构的调整和统一规划，来尽可能减少IT建设和运维期的重复投入，同时能够将已经建设完成的企业应用真正变化为企业能够自主掌控的IT资产。

企业IT架构优化的目标

当我们和传统企业交流的时候，一定要避免两个方面的问题。一个是企业直接就提出需要参考互联网企业做法，要做企业内部私有云，要参考工业4.0的做法建设大数据平台和ESB平台等，或者还有直接就提出要实施容器化技术和微服务架构；还有一种情况就是我们在没有了解企业当前业务和IT的现状和问题的情况就直接先入为主的方式给客户推广某种主流技术和产品，这些都是双方应该避免的做法。

IT架构优化的目标一定是为了解决前面说的两个问题。

第一个问题：业务敏捷性和响应能力的提升上面，要解决这个问题就必须要考虑IT架构如何更好的基于SOA参考架构进行分层，真正将共性业务和技术能力下沉，变成服务中心和能力中心，同时各个中心暴露可以高度复用的能力接口，那么上层业务在新增或变革的时候，我们就很容易基于已有能力进行组合和编排。

你要做到这样，正是SOA核心思想，即首先要找到可复用的业务组件，同时将业务组件能力通过服务化的接口暴露出来，通过这个做法也正是阿里说的中台战略和各中心建设的核心思路。

第二个问题：如何节约成本，我们在考虑应用层组件和服务复用的时候本身已经节约了成本，但是到了IT建设阶段还可以考虑的就是资源层如何规划提升利用率（IaaS平台），平台共性能力如何集中建设并复用，避免重复建设（PaaS平台），后续功能如何灵活扩展而不是全部要新建系统（微服务架构和组件化），如何更加自动化地监控和管理整个业务环境(IT管控治理，DevOps，运维自动化等），当这些问题都思考清楚后，在如何降低成本上面的目标和思路也就清楚了。

IT架构和微服务转型-关键需求分析

微服务架构这个概念出来已经很长一段时间，从最开始在互联网企业的广泛应用，到现在越来越多的企业开始关注和希望尝试使用微服务架构并实施云原生整体解决方案。

对于企业从传统IT架构到微服务架构的转型，绝对不是盲目地跟风互联网企业，而是企业的业务规范，企业的信息化水平和IT成熟度发展到一定阶段后的比如诉求，那么这些关键的诉求究竟有哪些？

从系统规划建设期到IT管控治理和运维期

首先可以看到当企业的信息化和IT系统建设发展到一定阶段后，自然会从IT系统的规划和建设期发展到后期的IT系统管控治理和运维期。到了后期不会再有大量的新系统规划建设，而更多的都是为了业务流程优化进行的IT系统需求变更，优化和功能改造。那么关键的问题就变成了如何快速地响应业务需求变化并发布系统，同时如何又以最小的代价和影响来发布系统？

传统的IT架构模式可以看到很难解决这个问题，每次需求或功能变更的发布周期相当长，同时由于是一个大单体应用全部发布，往往增加了一个新功能反而导致多个老功能出问题。这些都是我们经常遇到的问题，其核心的原因就是原来我们管理的业务系统本身的颗粒度太大了，其次就是从需求到开发到测试到发布整个过程如何自动化衔接。第一点涉及到微服务架构，第二点涉及到容器云PaaS平台和DevOps过程支撑方面的内容。

在微服务架构下，我们管理的单位从原来的大单体应用变化为了细粒度的微服务模块，自然在变更和发布的时候影响单位也相应变小到各个业务模块粒度。这将有效的解决子在后期运维变更功能发布的影响。

业务组织和IT系统紧耦合到解耦需求

其次，在传统IT系统规划和建设中，在企业架构规划设计中，我们经常谈业务和流程驱动IT，强调端到端流程的贯通。但是系统规划设计和实现的过程中，最普遍的现象就是不是业务驱动IT，而是业务部门驱动IT，导致我们的IT系统和业务部门是紧耦合的。举例来说，一个企业只有供应链部，那么建设的系统就是供应链系统；但是如果一个企业有采购部，有物流部，那么建设完成的系统就是采购系统和物流系统。

在这种情况下，带来的最大问题就是企业的业务组织架构一调整，往往带来IT系统巨大的调整工作量，在我原来的企业也经常遇到IT系统经常配合业务组织架构调整的事情。这类工作已经不是简单的HR系统组织结构调整，还包括了本身的业务系统中业务功能点的调整，已有的业务数据的调整，这些都需要进行动态切换和割接。

当企业建设的业务系统越多，和业务部门关系绑定得越紧密，这种调整带来的复杂度和工作量也就越大。而真正的解决思路就是要将业务组织和部门和业务系统解耦。

如何解耦？

仍然是从业务流程驱动的角度去考虑和拆分具体的业务单元，这些业务单元形成独立的业务组件（微服务架构中的微服务模块），由于这些业务组件粒度已经足够细，因此更加容易灵活的组装或组合去满足实际业务部门的日常业务需求。

举例来说：如果是大的供应链部门，就配置供应商管理，物料管理，采购订单，招投标，库存管理，物流配送管理等多个微服务模块。如果是拆分为采购部门和物流部门，那么采购部门配置供应商管理，物料管理，采购订单，招投标管理，物流部门配置库存管理，物流配送管理等微服务模块。

在规划和拆分微服务模块的时候更多是业务和流程角度出发，只要划分得足够合理，就能够最小化的减小业务组织架构调整对IT系统本身造成的影响。

从单打独斗信息孤岛到共享思路下的平台战略

企业信息化发展到一定阶段，自己都会意识到按照传统的一个个孤立的业务系统建设模式越来越行不通，这不仅仅是业务系统很多功能重复建设的问题，同时还导致了业务系统中数据不一致性，集成困难，后续的运维和变更处理困难等一系列问题。即典型的钱花得更多，但是系统却越来越复杂和难用。

而解决这个问题的的关键就是平台战略，对于平台战略本身又有两个重要的核心，即不是简单的遗留系统能力直接服务化共享，而是首先要集中，其次才是共享。集中化是云的思路，而共享才是SOA的思路，两个关键点都解决了才是云计算+SOA的关键思路融合。

为啥要把这个问题在微服务架构里面谈，因为平台+应用构建模式本身也是微服务架构实施的一个基础条件，微服务模块更多都应该是独立承担某个业务域的业务组件模块，而不应该包括类似流程引擎，系统管理等共性底层组件，否则微服务模块又变成很重的单体应用，没有了任何价值。

要做好微服务架构，我们就必须做好底层基础共性平台的建设，只是微服务架构里面会谈为共性的技术服务能力提供，都是一个道理，就是共性的东西或能力要下沉，然后再以标准的服务接口方式暴露或共享出来给上层的业务系统使用。

资源池的有效利用和资源动态调度

这是微服务架构结合PaaS容器化技术和动态调度技术后带来的一个新的亮点，即可以真正实现按照业务需求和业务并发量动态的申请和分配资源，以满足业务并发访问的需求。在整个过程中不需要人为去干预，而只需要设置好相应的调度规则和资源动态扩展规则即可。

对于这个点实际当前并不是很强企业的诉求，只是后续成熟度发展到一定阶段后带来的亮点功能，真正解决了IT系统的灵活资源分配，扩展和动态调度问题。

问题解决和关键收益

前面谈了传统企业IT架构转型的一些关键述求，那么在实施了微服务架构转型后可以解决的关键问题或带来的收益有哪些？

下面具体谈下这方面的内容。

首先是进一步节约IT基础设施建设投入，容器比虚拟机更加轻量化，同时结合Kurbernetes后可以实现自动化的资源调度，可以最大限度的提升资源的利用率。要明白，没有真正实现PaaS层能力的企业云平台，往往仅仅是简单的实现了从物理机到虚拟机的使用转变，而并没真正解决资源利用率大幅提升的问题。要解决资源利用率的大幅提升就必须实现应用托管和资源动态调度，而是要非人为干预全部自动化完成。

彻底贯彻平台+应用，以及业务部门和IT系统解耦的思想，以后企业扩展的都不再是业务系统，而是业务组件或模块，同时逐渐不再有业务系统的概念，只有业务组件模块的概念。业务部门不会和IT系统严格一一对应，而是通过业务组件的组合和组装方式来快速搭建业务部门需要的功能。这是IT系统能够更加灵活或柔性地适应企业业务流程，企业组织架构变化的关键一步。

进一步加强企业作为甲方的时候，对业务系统开发厂商的管控能力，即从粗粒度的业务系统管控到更加细粒度的微服务模块。同时结合DevOps可以使整个从需求，开发，测试，上线的整个过程全部透明化，而不是作为开发商的黑盒。正是由于整个过程的全程可视和自动化，甲方企业才可能后续真正做到业务系统的接维。

转型后可以进一步提升敏捷响应业务变化的能力，你会看到从业务部门提出业务需求或变更，到最终功能发布的上线时间会大大缩短。这种缩短的原因体现在整个流程中能够自动化的工作，全部自动化掉了，包括打包，自动化的单元测试，环境迁移和部署等；其次变更发布影响的范围减小，从影响一个业务系统变化到往往只需要影响一个微服务模块，大大减少了变更发布的测试验证工作量。最后，理想状态下很多平台层的能力和技术服务都全部实现，而实现业务组件的开发只需要关注业务本身，而不需要再去考虑任何技术层的共性能力，这本身也可大大提示业务组件和模块的开发效率。

在整个微服务基础框架+技术服务组件建设完成后，实际上单个业务微服务模块开发本身反而更加容易，在这种情况下微服务模块的开发人员并不需要完整的了解详细的完整业务流程细节。而只需要按业务需求开发业务功能和实现业务逻辑，消费微服务API接口，并按要求提供和暴露共享接口即可。对于微服务模块的集成和组装可以由专门的技术架构人员来完成。

进一步提升企业对IT资产的管理水平，企业管理的不再是简单的最终状态的部署包，而是实现从最开始的需求到源代码文件的全流程管理和检查。

当企业所有应用都按照标准的微服务架构，开发工具和环境进行开发后，同时严格实施DevOps后，可以看到企业的运维就完全实现统一管控和运维。包括运维管理流程，运维工具，运维监控和预警等，安全管理等都可以进行统一。同时在这种运维能力统一并自动化后，IT运维人员效率提升，需要的IT运维人员数量也大幅减少。

厚平台+薄应用的概念，真正实现了前端应用和后端服务的解耦和分离，服务可以更加灵活的组合和组装来构建前端应用。同时可以支撑移动APP，BS网页，Pad等多种前端应用类型。也可以更加灵活的支撑不同的前端业务应用使用相同可共享的业务服务或技术服务能力。

从传统偏重的ESB服务总线集成模式转变到轻量的去中心化的微服务网关集成模式，真正实现整个架构搭建中无中心化节点（也就是无关键瓶颈节点），从而实现整个架构极强的资源动态水平弹性扩展能力。另外从传统的代码编译和部署包交付模式转变为基于Docker容器的镜像交付模式，极大的提升了部署和环境迁移的效率，同时提升了整个业务系统的弹性可伸缩性。

建设和实施难点分析

下面重点谈下微服务架构在实施过程中的难点，特别是在已有IT架构已经基本成型的情况下转型到微服务架构的实施难点。

首先是数据库的拆分，如果数据库没有拆分而仅仅是应用组件拆分不能称为完整意义上的微服务架构，传统单体应用转变为微服务架构后，从页面前端到逻辑层到数据库都应该完全独立的一套，可以独立进行需求，设计，开发，部署和后续的运维管理。因此要转为微服务架构，首先数据库要拆分，微服务模块在拆分的时候一定要考虑对应数据库拆分的合理性和自治性。

数据库拆分后，原来简单的底层数据库关联查询，变化为需要通过领域服务层进行服务组合才能够完成。原来数据库层很容易控制的数据库事务，转变为了由于进行WS接口交互带来的分布式事务问题。这个我们在谈组件化和微服务架构的时候多次谈到，是微服务架构实施的一个关键难点。

其次，基础平台层和技术服务能力的建设是转型中第二个难点，这些能力有可能在传统架构建设模式下已经独立建设，如何将这些共性能力抽象出来并下沉到平台层共性建设，并再将能力以WS接口方式开放出去供上层微服务模块使用，是微服务架构转型中必须首先考虑实施的内容。

要实施这点，就会造成原有业务模块的较大改造，特别是对于原有各业务系统中的技术组件本身差异就大的情况下，这种统一往往更加困难，势必对已有的业务系统造成较大的影响。这也是很早我们在谈企业微服务架构实施策略中谈到的尽量是逐步迁移，老系统或平台也逐步消亡的渐进模式实施。

第三是新技术的引入，微服务架构思想的引入。对于微服务架构，前面已经强调过多次不仅仅是单纯的微服务开发框架的引入，更加重点的是和容器化技术，和DevOps实践的结合，进一步对组件化架构和领域建模思想的实践，同时可能还涉及到EDA事件驱动架构方面的内容。在业务层面还涉及到如何去更好的划分微服务模块，这个粒度究竟如何把控，对于划分完成的微服务模块如何去识别和定义微服务接口，确保接口本身的复用性和粗粒度特性。

因此不是使用了WS接口就是SOA，也绝对不是简单的使用了Rest接口，使用了Spring Cloud等微服务框架就是微服务架构。更加重要的是组件化和服务化，持续集成和DevOps等思想的最终实践和落地。只有这些思想真正落地，才能够解决我在上篇文章中谈到的关键诉求所描述的问题。

第四是企业本身的软件过程和IT管控治理能力的成熟度。如果一个企业原来就实施了组件化开发，或者原来就使用了一些开源了SOA总线或服务网关产品，已经实践过了持续集成方法论，或者已经建立了自己的类似流程引擎，4A等基础技术平台，那么实施微服务架构相对就很容易。反之，如果一个企业在传统IT架构下都没有形成标准的开发过程，开发框架，技术组件积累，标准软件生命周期，编码规范和接口使用标准等，那么要实施微服务架构就相对难。

其次对于微服务架构下，我们管理的最小单位将从原来的一个大的单体应用变化为多个更加细粒度的微服务模块，原来单体应用内部的接口和集成可能属于混乱状态，但是在黑盒内部没有暴露出来，但是事实微服务架构后这些都会被完全暴露出来需要去管控。我们需要管理的微服务模块数量，接口数量等都会成倍的增加，没有一定的IT管控和治理流程的积累，要做好这些管控也是相当困难的事情。

最后谈下运维监控能力差距，由于要管理的模块数和接口服务数都成倍的增加，对管控和运维的能力要求都相应提升，如果还按照传统的人工去运维的方式肯定行不通。这里面一方面就是要实现自动化的监控和运维能力，模块和接口服务的性能分析和及时预警能力；其次就是要实施DevOps，真正将从需求开始，到设计，开发，测试，部署的全过程实现流水线式作业。

可以看到，对当前传统企业和传统IT架构建设和实施过程中，运维和后续管控的能力差距还很大，这就很容易发送上了微服务架构，后续服务很好的管控和运维的情况，人员疲于奔命的应付各类故障和问题，那么这样不是节约了运维和管理工作量，反而是使整个运维管控流程复杂化了。

实施实施准备和实施策略

前面已经谈到过，微服务架构不是简单的微服务开发框架的使用，更不是简单的Restful接口的使用，而是大量的SOA，持续集成，组件化和服务化，云平台和容器，DevOps等思想的融合应用。因此在考虑转型到微服务架构的时候可以首先进行相应的准备，而这些准备基本都是可以独立完成并实施的。

在实施前具体需要考虑到多个方面的技术储备和管理储备。

对于技术储备包括了微服务架构，微服务开发框架和开源组件，DevOps持续集成交付工具链，容器云PaaS平台，领域分析和建模，API网关和事件引擎，前后端分离和前端开发框架，微服务治理框架。类似消息，缓存，日志，4A，流程引擎等各种技术组件和技术服务能力准备等。

对于管理和过程初步重点是Scrum敏捷研发方法论，DevOps研发运维一体化过程实践方法，传统的软件工程和软件生命周期管理，标准的过程规范和标准体系，测试和质量管控体系，IT治理和IT运维管控体系，需求端到端管理，安全管理等方面的内容。

当然这里面个人理解最重要的还是SOA和云平台的架构思想的深入理解，包括当前的数字中台，平台+应用，前后端分离等很多都来源于以上两个核心思想。

企业IT架构转型的实施策略

企业IT架构转型一定要明确清楚相关的业务驱动力和业务需求，同时在转型实施过程中还需要有企业当前本身的IT治理水平相匹配，而不是盲目跟风各种互联网先进技术。企业在信息化发展到一定阶段后，往往随着业务的高速发展，IT建设已经无法满足和快速响应业务需求，这个实施转型驱动力是最大的。

但是在IT架构转型过程中，不是对原有IT架构的完全否定和推翻重来，而是应该考虑如何在转型过程中对业务的影响最小，已经如何尽可能的复用已有的IT资产，这是IT架构实施过程中重要的实施策略。

对于传统企业IT架构转型，其最终要达到的目标仍然是我前面大量的SOA和云计算思想在企业内部的应用，企业私有云PaaS平台建设，平台+应用的构建模式，微服务架构+DevOps的全程贯通等。整体来说实施策略可以分为如下几个大的步骤：

横向统一：基础和共性能力下沉

对于业务系统中的共性能力下沉是SOA参考架构和私有云平台中平台+应用的核心构建策略思想。对于传统企业内部横向统一就包括了几个核心内容，第一个就是底层基础平台的建设，包括了4A平台，公共流程平台，基础主数据平台等，而对于上层则包括了统一的用户门户，统一认证和单点登录等。

因为这些内容都是偏技术平台的内容，因此这些共性能力的提取对已有的业务系统相对影响最小，同时在统一平台化建设后，在后续新规划的业务系统中就完全可以复用。

如果是大型集中化项目，技术平台就不是仅供一个项目使用，而是需要为多个项目提供服务，类似我们前面很多文章都谈到的平台+应用模式，企业私有云PaaS平台建设。在为多个业务子系统提供平台层能力支撑的时候，那么一个关键就是这个平台不会再内嵌在业务系统里面，而是应该独立进行建设和部署，并将平台层的能力通过接口的方式开放出来供上层应用使用。在这种模式下平台层的建设一般会包括如下内容：

1. 独立的门户集成能力，提供门户，统一身份认证，单点登录能力。2. 提供4A能力，特别是统一用户和统一授权，该能力可以集成在门户中统一提供。3. 提供公共的流程平台和流程引擎能力，对流程建模，执行，监控数据全部集中在流程平台中管理。4. 提供一些关键的技术服务能力（其中包括消息，缓存，日志，安全，文件处理等）5. 整体的UI/UE标准规范制定，开发框架规范和技术制定。

其中1到3基本是一个最简单的公共支撑平台必须提供的，而对于4一开始可以先不提供，由各个业务系统自己去提供和解决。由于上述内容已经抽象到公共平台进行统一提供，因此对于上层的业务子系统开发就更加简单，具体包括的内容为：

1. 提供最基本的核心系统管理模块能力(用户，角色，授权，组织，菜单，数据字典等）2. 公共技术组件模块(提供一些类似公共函数，缓存处理，日志封装，异常封装，安全等基础能力)3. 使用统一平台和整体应用架构制定的UI规范和开发框架进行开发

这也是我们常说的厚平台+轻应用的模式，即能够复用和共性的内容尽量下沉到平台统一提供，上层的业务应用开发只需要关注业务流程和业务逻辑实现，而不再需要关心技术的内容。更详细的内容介绍可以参考我去年出版的私有云PaaS平台建设一书，可以网上书店搜索《SOA与大数据实战：企业私有云平台规划和建设》，里面对这部分内容有详细的介绍和说明。

纵向统一：软件工程和研发管理

对于纵向统一包括软件工程和研发过程管理两个方面的内容。对于软件工程本身包括了开发框架，技术框架，主流技术，服务接口标准，单业务系统架构选型，分层模式等常见的软件工程域的相关内容。

对于研发管理则包括了标准的技术标准规范，UI/UE规范，开发规范，测试规范的统一。包括了业务系统在交维后的ITIL标准规范流程等方面的统一，安全管理标准规范的统一等。同时也包括了Scrum敏捷研发方法论，CI/CD持续集成和当前DevOps实践方面内容。

内部统一：业务能力组件化和模块化

在上面两点统一后可以看到，剩下的就是业务系统的各个业务模块了，那么要做的事情就是如何让业务系统内部的各个模块进一步的组件化和服务化，逐渐变化到我们常说的微服务架构，并且对于传统业务系统的概念逐渐消亡，更多的就是基于平台上建设了不同的多个微服务模块，微模块模块可以朝上层灵活组合各类应用。

对于微服务架构的实施，我前面已经专门有文章讲到过，企业IT能力成熟度如果没有达到一定阶段，实施微服务架构往往是增加了整个IT开发和后续管控的复杂度，因此对于微服务架构的实施核心建议策略也是需要从单独新的的业务功能模块逐步开始，或者从已有的共性基础能力剥离开始，而不是完全推翻原有业务系统。