微服务架构转型-方案制作02(7.4)

如果要做一个给传统企业讲解的企业微服务架构转型的方案，那么这个方案应该做？对于传统企业转型微服务架构，包括涉及到工作内容和范围，技术的关键点，实施方法等在前面博客多篇文章中都进行了详细的阐述，那么要做一个面向企业宣讲的技术方案材料，初步考虑整体搭建思路应该为：

传统企业IT架构的问题

系统是建设的最小单位，那么这里的业务系统实际就是我们说的单体应用，讲问题实际上更多是讲传统单体应用存在的问题有哪些？如果从整体生命周期来看，实际上是可以从规划选型期，开发建设期，运维期几个方面来谈。本身里面又包括了软件工程，项目管理，过程支撑三个维度的内容。

规划选型期更多选择是厂商比较产品化的产品，你很难去定一套技术架构，开发标准和规范体系，这也是后续导致整体IT架构里面多语言，多数据库，多开发框架，多接口类型的一个主要原因。

对于开发建设期，实际上最主要的问题还是整个业务系统里面各个模块间紧耦合，无法拆分，其次就是大量共性的内容重复建设的问题。这里可以画图描述，如何把各个业务系统共性内容统一掉，并下沉到平台统一建设，构建平台+应用，应用层通过微服务模块构建思路来完全松耦合。

在开发建设期，实际上还需要谈一个重要问题，就是传统建设模式下响应变化的能力弱，都是业务需求和功能，前端和后台逻辑完全绑定死的。而实际上引入SOA思路和微服务架构化后，应用构建逻辑发生了变换，即核心的SOA思路，即先搭建中台（技术中台+业务中台），然后暴露中台关键能力和服务，再由这些服务来组装上层的关键前端业务和流程。

对于标准规范体系，实际上仍然是包括三个方面的内容，项目管理类，软件工程类，过程支撑类，再加上后续运维期的的话还包括IT治理和服务治理类。本身这些规范如何和敏捷方法论，DevOps和持续集成等融合。规范作用一个是使过程标准化，模板化，其次是加强甲方对整个项目的管控力度。

微服务架构概述

方案里面还是需要对微服务架构做一个简单的介绍，即解释清楚什么是单体应用，什么是微服务架构，微服务架构的核心是什么？其次解释清楚微服务架构和SOA的关系。

对于微服务架构进一步解释清楚判断的标准是什么？

同时要说明清楚，要实现一个完整的微服务架构，需要满足哪些判断准则，同时在微服务架构里面有哪些关键的核心组件，这些组件是起什么作用？具体选用的标准是什么？在这里可以讲解下SpringCloud框架以及框架中的各个开源组件，并把每个组件本身的作用讲清楚。但是最后一定要强调到，不是采用SpringCLoud框架就是微服务架构，SpringCLoud框架只是微服务架构里面的开发框架部分内容。

微服务架构业界通用的一个定义是如何的？

微服务架构的判断标准和准则，可以表格化来说明。

微服务架构实现中最基础要具备的能力(开发框架，注册中心，负载均衡，服务网关，流控+熔断，安全）

微服务架构化和传统企业业务系统间SOA集成的差别在哪里？实际上我们看到最主要的就是SOA集成思路深入到了业务系统的内部，业务系统本身的各个组件变化为微服务模块，共性组件变化为采用平台层能力，微服务模块间通过Rest接口服务集成。

如果单业务系统还是一个厂商来做，实际上单业务系统本身就是一个SpingCLoud框架体系，通过服务网关发布接口服务能力，同时将接口服务进一步注册到跨系统的轻量SOA服务总线上面来。即实际上的接口服务集成可以理解为两层的集成，内部仍然可以走注册中心点对点集成，有需要发布到外的通过微服务网关通过二次注册将能力发布出来。

一个企业应该如何实施微服务架构？实际上在前面一篇文章里面已经谈到，应该包括了咨询和规划，开发和构建，管控和治理三个方面的内容。后续的介绍可以围绕这三个方面的内容展开。

注意：这里应该有一个完整的阶段模式的流程图来说明，一个完整的微服务架构规划建设和实施过程是如何的，即包括了前期的规划阶段，开发建设阶段，后续的运维治理阶段。要体现每个阶段究竟是完成什么关键工作，每个阶段是如何衔接的。

这张图实际上相当关键，即后续你要展开描述的内容都应该在这张图上有体现。

微服务架构-咨询和规划

咨询规划做什么事情？首先应该是调研清楚当前企业的IT架构是如何的？当前的架构下存在什么问题？然后是给出企业本身的微服务架构转型思路，具体的微服务架构演进路线。

在演进路线规划完成后，在第一阶段，比如对一个老的应用系统进行迁移或者一个全新的业务系统进行微服务架构开发，那么我们就需要基于这个实际的需求来分析如何进行微服务架构的实施？里面的关键点仍然是如何划分不同的微服务模块？如何定义清楚微服务模块间的接口关系？如何拆分好不同的数据库？这些顶层设计工作都必须在前期做完。

对于咨询规划阶段，重点应该包括如下几个方面的关键内容

1. 微服务模块如何拆分，其中包括了业务模块的拆分，包括业务模块对应数据库拆分

2. 在拆分过程中，微服务接口API如何识别和定义，微服务模块间的接口集成关系是如何的？

3. 平台层能力如何识别，共性能力如何下沉，包括了技术中台+业务中台。

4. 基于微服务架构模式下整体应用架构，技术架构，集成架构，数据架构的规划是如何的？

5. 基于微服务架构下的开发标准，规范体系

6. 基于微服务架构下的项目管理，过程管理，运维治理规范体系。

微服务架构-开发和构建

开发和构建实际上最好的方法是，我们只进行类似4A，流程引擎，MDM主数据等平台层微服务模块的开发，而对于业务类微服务模块只是划分清楚模块，定义好接口，而实际的开发则转给企业内部开发人员或其他开发商进行。而我们需要做的就是整体的项目群管理，后期的多个微服务模块间的集成。

即我们拆分好微服务模块和数据库，定义了一套标准规范体系和技术开发框架，然后找了不同的开发商来进行多个微服务模块的开发，我们最终要保证开发完成的内容能够完整的集成起来，并满足端到端业务流程的需要。同时我们会实施一套过程支撑工具来实现对DevOps过程的可视化支撑，通过过程支撑工具可以实现对整个应用开发的完全自动化，可视化管理能力。

这里重点实际上是基于规划阶段讲解的总体思路和内容，来演示清楚如果一个厂商单独构建一个微服务模块整个开发建设的过程是如何的？我们大的原则就是厂商内部可以走独立的SpingCLoud框架体系，但是厂商和厂商间接口服务集成，走外部的SOA服务总线来实现治理和管控。在这里的一个前提是厂商进行微服务模块的开发时候，前面的整体架构设计工作应该已经完成，即模块和数据库已经划分好，接口也已经定义好。

这个过程就是微服务架构模式下的实施过程，即厂商如何进行开发，接入如何发布和注册，如何消费接口，如何进行开发，如何提交部署和发布等一系列问题。这个和我们原来讲的私有云PaaS平台思路是相当类似的。

首先从大思路和流程上讲清楚如何做？其次还得讲清楚两个层面的内容，比如选用了SpringCLoud框架来实现微服务模块，那么基于SpringCLoud框架如何来做开发，开发完成的接口服务如何提交注册，如何消费外部接口，如何和其它微服务模块集成和联调。如果启用了容器化部署和DevOps，如何和这些支撑平台更好的集成等，这些都需要进一步描述清楚。

以上都描述清楚后，接着讲微服务架构+容器化+DevOps结合的最佳实践，同时来介绍整个融合的过程和DevOps支撑平台和工具集。即通过这个支撑平台和工具集，如何更好的实现了敏捷和自动化，如何更好的支撑整个微服务模块开发和集成的过程？

微服务架构-管控和治理

整体微服务架构最终上线后，马上面临的问题就是运维管控问题。在运维管控上面需要考虑的内容就是微服务架构整体体系如何监控和运维？这个监控运维即包括了资源层面的，也包括了服务和服务链监控等APM层的内容；其次还需要考虑在整个架构体系下，变更如何处理？版本如何发布？

这些基础的指导仍然是类似ITIL标准的方法论，但是在微服务架构和支撑平台实施后，类似问题管理，变更管理，运维监控，版本发布等流程都需要配合微服务架构进行相应的调整和定制。比如在实施了DevOps和容器化部署后，对于整个部署过程都是自动化进行的，和原来的手工部署就寻找较大的差异。

1. 整个建设期软件开发过程的管理和管控

2. 运维期功能和接口服务变更的管理和管控

3. 涉及到ITIL相关的内容，特别是问题管理，变更，日常运维，配置管理等

4. 平台的运维监控能力，性能分析，服务链监控

企业实施微服务架构存在的风险点和准入

光说好的地方还是不行，对于企业是否实施微服务架构，微服务架构本身存在哪些问题也需要一并进行介绍。实际上讲风险点，更多的应该是讲企业要实施微服务架构应该进行的前期准备工作，包括了已有的IT积累，人员积累，企业本身的IT项目管理成熟度和规范化等，这些内容都必须要强调到。

举个简单的例子，原来是6个业务系统，微服务架构化后变成了60个微服务模块的管理和监控，如果后续的运维监控能力跟不上，对于后续的运维和变更管理反而是灾难。