今天整理和分享下企业中台规划建设方面的一个解决方案材料。在分享详细的ppt前，还是先分享下在做这个PPT材料前的一些方案构思。

中台规划和微服务架构咨询

对于传统企业架构思想可以看到基于业务驱动IT思路，从端到端流程分析出发进行企业核心的业务流程活动，业务对象识别，然后再规划业务架构，数据架构，应用架构和技术架构，在应用架构中又包括了我们常说的集成架构规划。

传统企业架构规划方法仍然是按照传统遗留大单体应用垂直纵向建设的模式来进行的规划，同时很少考虑到了集中化的云平台建设模式。然后在当前企业的信息化规划建设，平台+应用构建模式已经逐步成为主流。

同时在平台+应用分层构建的模式下，进一步将传统应用大单体拆分为多个独立自治的微服务进行独立建设和管控，而对于平台层则进一步融入云平台建设思路，包括最近1到2年我们谈的最多的面向云原生的解决方案。

这个云原生已经从传统的IaaS云平台过渡到了完整的PaaS云平台和技术服务能力提供。

基于以上分析，可以看到传统企业架构优化点主要体现在

从纵向到横向：架构规划分析需要从纵向过渡到横向分层规划设计
数据库拆分：业务架构和数据架构结合分析，在规划阶段形成数据库拆分
业务和应用架构融合：在剥离了平台后，进一步融合业务和应用架构
基于业务组件规划设计微服务
技术架构规划新增加PaaS和技术中台服务内容

以上即是我们考虑需要进行优化的一些关键点。基于上面的思路，我们可以看到中台规划和建设的方法论可以进一步简化为下图。

从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。

在整个中台建设规划中可以看到业务中台规划简单的重点仍然体现在两方面：

其一是业务中台中的微服务如何拆分
其二就是微服务究竟应该暴露哪些独立的可复用API接口

对于微服务架构规划咨询，我原来在博客上整理过，主要是围绕SOA，微服务，中台提供相应的规划咨询服务。而实际上重点包括了业务规划咨询，核心是中台和微服务模块划分，API接口识别。其次是技术架构规划咨询，核心是整体技术架构设计，微服务开发框架，技术服务等，具体为：

1. 传统企业数字化转型背景
2. 支撑转型的关键技术趋势概述
   2.1 中台概述（中台的概念，展现形式，中台的作用等）
   2.2 微服务概述（微服务产生背景，微服务和SOA关系）
   2.3 DevOps概述（敏捷研发，持续集成和交付，自动化测试等）
   2.4 面向云原生的整体解决方案
3. 中台咨询和规划建设总述
   3.1 中台规划咨询整体方法论（业务建模流程分析，业务中台和数据中台建设，技术中台，实施）
   3.2 业务中台建设方法论
   3.3 数据中台建设方法论
   3.4 技术中台建设（API网关和能力开放平台，技术服务中台，DevOps支撑平台，容器云平台）
   3.5 实施方法论 （实施策略，演进路线，遗留系统迁移等）
   3.6 运维和管控治理方法论
   3.7 技术标准规范体系 （标准规范，开源组件，开发框架等）

微服务和DevOps实施方案思考

在我原来做传统企业微服务架构转型的PPT方案制作的思考，但是里面基本上没有谈到DevOps方面的内容，今天再基于微服务和DevOps实施来谈下整体的解决方案制作思路应该是如何的，在这里我们先整理一个基于当前我们已有的项目进行微服务和DevOps转型的实践案例来整理这个PPT方案。

1.转型前项目现状和问题分析

我们可以拿一个当前实际的单体应用系统来进行这次微服务架构转型的案例整理，因此在介绍后面的解决方案前重点还是要把当前的项目现状和背景讲清楚，把实际在开发和过程管理中的面临的问题讲清楚，有了问题才需要去思考如何解决，这样的解决方案才是和问题和目标匹配的。

单体应用当前现状- 应用功能架构，技术架构，开发框架
研发过程管理现状- 项目任务管理，配置管理，需求管理，测试和缺陷管理，版本发布
当前已经完成实践- 开发框架标准化，持续集成，产品和实施版本分离，共性组件的技术平台化
当前面临主要问题- 前期开发，后期运维，前后方协同，交付效率，系统后期扩展能力方面

2. 整体解决思路

对于整体解决方案，首先我们要对当前现状和问题进行分析，实际上是包括了应用系统架构层面，研发过程管理层面，还有就是持续集成和交付层面。而这三个方面正好是对应了当前主流的几个最佳实践，即分别是微服务架构，Scrum敏捷项目管理和开发，DevOps持续集成和研发运维一体化。

那么要来讲整体解决方案，首先要做的是对三个方法论进行简单介绍，让听众要能够抓住这三个方法论中的本质，也就是我们经常说的最小化概念模型。

微服务架构介绍(基本定义，和传统架构区别，主流微服务开发框架和核心组件）
敏捷方法论介绍(基本定义，原则和价值观，核心过程实践，常见支撑工具等）
DevOps介绍（基本定义，当前成熟度模型，主流的开源工具链）
问题和解决方案对应（我们当前的问题如何映射到三个解决方案上面的）
总体解决方案思路01 (动态构图，覆盖从需求，研发到交付运维的全生命周期视角）
总体解决方案思路02 (静态构图，即整体架构构图，应该能体现出研发管理，DevOps，微服务三块内容）
实施思路 (从解决方案能看出关键就是两步，搭建好平台，一个就是拆解现有单体应用为微服务）

3. 从单体应用到微服务架构

在前面整体解决方案一定要介绍清楚，通过问题分析和整体解决思路，后续的实施就是两件事情，一件就是搭建支撑平台，一个就是将单体应用拆分为微服务。那么第3，4两个部分内容正好是这两件事情的进一步细化讲解，对于单体应用到微服务，本身又拆分为两个独立的思路，其一就是要如何拆分？其二就是拆分后选择微服务开发框架如何进行开发。那么就分开对两件事情进行讲解。

3.1 业务中台构建-对应到微服务架构如何拆分

中台概念介绍（大中台小前台，业务中台和数据中台，中台如何支撑前台）
中台微服务模块划分（理论方法介绍一页，实际最终项目划分结果一页）
中台微服务接口识别（接口识别方法一页，实际当前识别的接口清单和目录库一页）
构建中台能力中心（架构图，构建中台能力服务中心，同时基于API网关对中台能力进行开放）

3.2 微服务模块开发

开发框架选型（介绍基于SringCLoud开发框架进行单个微服务模块的设计开发）
微服务API接口设计（介绍采用标准的Http Rest API接口，并说明接口设计方法，是否接口先行）
开发持续集成 （介绍Jekins使用，自动构建，构建完成后自动发布到容器）
多模块间协同（介绍不同小组开发的模块间如何进行接口协同，包括协同方式等）

4. DevOps支撑平台建设和实践

在第3部分的微服务架构转型和开发中，可以看到我们实际上已经做了一些研发过程改进，持续集成和容器化改造等工作，但是不系统，未集成。而这是我们构建一个完整的DevOps支撑平台的初衷。即希望构建一个支撑平台，能够将研发过程管理，持续集成交付乃至后续的运维管控治理全部协同起来，减少在过程协同中的断点，进一步实现整个过程的自动化，灵活可配置化，进一步实现研发和测试间高效协同协同，实现研发和运维间的高效协同，实现后端产品研发和前方项目交付间的高效协同。

4.1 DevOps支撑平台核心能力

DevOps支撑工具链(先介绍下在整个DevOps支撑过程中涉及到的开源工具支撑链）
DevOps支撑平台整体架构(架构图，覆盖研发管理，微服务，DevOps持续集成和底层容器平台）
研发过程管理(介绍研发过程管理方案，比如采用禅道或者Jira，还是自研实现研发过程管理）
容器化PaaS（需要对Docker+K8s来实现容器化PaaS和资源调度用一页来说明）
微服务或API网关(需要一页来说，采用zuul还是开源的Kong网关定制来作为整体架构中API网关)

4.2 DevOps支撑平台对关键业务场景的支撑

在这些讲解清楚后，不用去逐个详细介绍DevOps平台的功能点，最好以关键业务场景或问题驱动介绍。

持续集成和交付（重点讲解整个流水线设计和自动化编译，构建，打包过程）
研发和测试协同（重点讲解研发管理工具和DevOps平台间的协同）
测试自动化实现（重点讲解下测试自动化如何实现的）
环境迁移和前方发版（重点讲解环境迁移，版本提前，灰度发布等）
研发过程度量（重点讲解研发过程度量，当前做了哪些内容，后续还准备做哪些内容）
后期性能监控（重点讲解后期的性能监控，服务链监控，日志采集和分析）

5. 项目实施完成收益分析

最后一部分重点是对项目实施后的收益或效果进行分析，最好能够有明确的数据来说明。比如整个持续集成周期缩短多少，人为打包部署工作量降低多少，交付效率提升多少，项目管理可视化程度提升多少多个方面进行说明再进行微服务架构实施和DevOps转型后取得的收益情况。