在前面我做过传统企业微服务架构转型的PPT方案制作的思考，但是里面基本上没有谈到DevOps方面的内容，今天再基于微服务和DevOps实施来谈下整体的解决方案制作思路应该是如何的。虽然前面讲过多篇关于云原生的文章，但是可以看到对于传统企业IT架构转型来说，实际上重点仍然在于微服务和DevOps两个关键各方面。
对于微服务和DevOps都是相当技术化的内容，因此要把整个方案本身的核心理论，包括方案实施后带来的收益和价值讲清楚并不容易。整体的售前方案目录思考如下：
1. 传统IT架构现状和目标分析
2. 整体解决方案
3. 从单体应用到微服务
4. 微服务设计开发
5. DevOps支撑平台建设
6. 详细的实施方案
7. 收益和价值分析
我们可以拿一个当前实际的单体应用系统来进行这次微服务架构转型的案例整理，因此在介绍后面的解决方案前重点还是要把当前的项目现状和背景讲清楚，把实际在开发和过程管理中的面临的问题讲清楚，有了问题才需要去思考如何解决，这样的解决方案才是和问题和目标匹配的。
单体应用当前现状- 应用功能架构，技术架构，开发框架研发管理现状- 项目任务管理，配置管理，需求管理，测试和缺陷管理，版本发布已经完成实践- 开发框架标准化，持续集成，产品和实施版本分离，共性组件的平台化当前面临主要问题- 前期开发，后期运维，前后方协同，交付效率，系统后期扩展
对于当前现状分析必须从研发过程管理，软件交付敏捷性和效率，软件变更和后续运维，软件本身的高可靠性和可扩展性几个方面来展开说明。
其核心原因就是，我们后面实践的微服务架构化拆分，DevOps，敏捷研发管理，包括容器云部署和资源动态管理等正好是为了解决这些实际问题的。
对于整体解决方案，首先我们要对当前现状和问题进行分析，实际上是包括了应用系统架构层面，研发过程管理层面，还有就是持续集成和交付层面。
而这三个方面正好是对应了当前主流的几个最佳实践，即分别是微服务架构，Scrum敏捷项目管理和开发，DevOps持续集成和研发运维一体化。
那么要来讲整体解决方案，首先要做的是对三个方法论进行简单介绍，让听众要能够抓住这三个方法论中的本质，也就是我们经常说的最小化概念模型。
微服务架构介绍(基本定义，和传统架构区别，主流微服务开发框架和核心组件）敏捷方法论介绍(基本定义，原则和价值观，核心过程实践，常见支撑工具等）DevOps介绍（基本定义，当前成熟度模型，主流的开源工具链）云原生介绍（基础概念，核心管理要素，核心技术要素）
以上四个方面的基本概念还是有必要。可以看到对于微服务，敏捷方法论和DevOps本身也是云原生解决方案的重要内容。在这些基础概念介绍清楚后，重点是要说明下，从我们传统的SOA架构思想到微服务，到云原生的一个架构演进过程。
即DevOps是衔接微服务和容器云关键桥梁，实现整个集成和容器部署过程自动化，微服务模块彻底业务化，不再含具体共性技术能力提供。
在演进到第三阶段后可以看到两个重点
其一是上层的微服务模块如何拆分，以确保高度自治和松耦合其二是如何搭建一个面向云原生技术中台，提供技术能力支撑
问题和解决方案对应
这点实际上相当重要，即我们最终给出的解决方案如何和前面提到的目标和问题映射的。即你给出的解决方案中提到的各个关键技术能力如何解决具体的问题，是1对1解决，还是多对1解决，这些都应该能够阐述清楚。如下图：
你最终形成的解决方案必须是一个完整的整体，能够覆盖具体的问题域。那么整个解决方案的沟通实际上我们仍然可以从静态架构沟通和动态架构两个方面来思考。
静态架构
即整体架构构图，应该能体现出研发管理，DevOps，微服务三块内容。比如我前面给出的我们的技术中台架构图，里面覆盖了微服务，DevOps，容器云，敏捷研发管理等关键内容。
动态架构
对于动态架构，则是覆盖从需求，研发到交付运维的全生命周期视角。由于DevOps本身就是研发运维一体化的管控过程，因此进行动态构图还是很有必要。
实施思路
从解决方案能看出关键就是两步，搭建好平台，一个就是拆解现有单体应用为微服务。因此你后续的展开需要包括两个方面的内容，一个就是技术平台的搭建，一个就是微服务如何拆分，如何设计开放，如何和DevOps配合进行持续集成和交付。这些都必须说清楚。
在前面整体解决方案一定要介绍清楚，通过问题分析和整体解决思路，后续的实施就是两件事情，一件就是搭建支撑平台，一个就是将单体应用拆分为微服务。那么第3，4两个部分内容正好是这两件事情的进一步细化讲解。
对于单体应用到微服务，本身又拆分为两个独立的思路。
其一就是要如何拆分？其二就是拆分后选择微服务开发框架如何进行开发。
业务中台构建-对应到微服务架构如何拆分
中台概念介绍（大中台小前台，业务中台和数据中台，中台如何支撑前台）中台规划方法论(给出一个中台规划的整体思路和方法论介绍）中台微服务模块划分（理论和方法介绍，实际最终项目划分结果）中台微服务接口识别（接口识别方法，实际当前识别的接口清单和目录库一页）构建中台能力中心（架构图，构建中台能力服务中心，同时基于API网关对中台能力开放）‘
可以看到，要把上面这些内容讲清楚并不容易，在我原来的方案材料里面将中台规划和微服务架构规划两个内容是揉合在一起的。实际上两者可拆分。
即传统架构转型为微服务架构，并不一定就要特意构建中台。而对于中台构建也是同样的道理，共享下沉的能力是否进行了微服务拆分也非必要条件。
对于中台规划重点是如何找到共性业务能力，其次才是如何进行能力拆分进一步解耦。而对于微服务架构规划重点是传统遗留系统如何拆分和解耦，其次才是是否可以复用。因此两者的先后顺序有明显的差异。
这个也是我们在进行微服务架构和DevOps售前的时候需要考虑的问题。
原因是啥？
原因就是现在中台炒得太火，很多没有理解清楚中台得也在推中台架构和方案，因此反而中台有种烂大街的感觉。其次就是富贵论坛更多的是业务概念，需要业务战略和组织配合，当我们去推一个技术平台解决方案的时候，你想去推动业务变革本身不现实。
简单来说就是如果你是一个专门做中台规划咨询的厂家，那么推中台没有问题。但是如果你是一个推云原生技术方案的厂家，那么推中台思想反而是负分。
对于微服务模块的设计和开发，实际上包括了比较多的内容，对于这块实际需要讲解几个关键内容，就是一个完整的微服务开发框架的整合。
微服务开发框架选择和整合
在前面我就讲过，这里有多种选型，可以是SpingCloud框架，也可以是当前公有云平台开源的类似ServiceComb，Tars等微服务开发框架。
而实际上在前面的文章里面我已经谈到，我们当前给出的微服务开发框架是基于SpringCLoud进行整合后的一个开发框架，具体即：
具体微服务开发仍然基于SpingBoot， Feign和Ribbon来完成。服务注册中心采用阿里开源的Nacos注册和配置中心限流熔断采用阿里的Sentinel限流熔断对于服务链监控采用Skywalking来实现服务链监控对于API网格采用开源的Kong网关
也就是我前面讲过的尽量减少对整个SpingCLoud框架的依赖，方便后续具备一定的移植性和扩展性。其次我们也没有采用Mesher服务网格化的方案，仍然采用传统的API网关配合限流熔断等来实现基础的微服务治理能力。
但是ServiceMesh服务网关模式下的微服务治理一定是一个重要趋势。
基于微服务框架的低代码开发平台
低代码开发平台是整个方案的另外一个重点。即当前我们已经实现基于微服务架构的低代码开发平台，实现常见的流程可配置，权限可配置，数据模型可自定义，界面设计可配置等关键内容。而对于另外一个规则可配置我们不做，很多年前我就研究过规则引擎，对于规则这块要做到完全可配置本身不现实。
整个低代码平台的核心目标就是实现常见功能的日常维护，自定义查询，自定义报表等功能。而对于复杂功能则进行代码生成或暴露相应的接口实现类，你自己可以灵活去扩展相关的代码和业务规则。最终生成的代码页完全符合SpingCLoud框架体系，对开发人员完全透明。
也就是我们的低代码开发平台要做到对开发完全可见可视，脱离低代码开发平台你的应用也随处可以运行，可修改和维护。
微服务API接口设计和集成
这块实际上需要讲解两个方面的内容。
其一就是微服务下的Http Rest API接口究竟应该如何设计，具体的设计方法是如何的？是否也遵从接口契约设计先行的思路进行。接口本身的规范如何保证，接口变更如何处理？
其二就是最终的API接口如何管理，即还需要详细讲解API网关的内容，包括网关的功能架构，技术架构，网关关于服务注册接入，限流，安全，日志等各种关键能力介绍。
在前面第3部分的微服务架构转型和开发中，可以看到我们实际上已经做了一些研发过程改进，持续集成和容器化改造等工作，但是不系统，未集成。而这是我们构建一个完整的DevOps支撑平台的初衷。
即希望构建一个支撑平台，能够将研发过程管理，持续集成交付乃至后续的运维管控治理全部协同起来，减少在过程协同中的断点，进一步实现整个过程的自动化，灵活可配置化，进一步实现研发和测试间高效协同协同，实现研发和运维间的高效协同，实现后端产品研发和前方项目交付间的高效协同。
DevOps支撑平台核心能力
DevOps支撑工具链(整个DevOps支撑过程中涉及到的开源工具支撑链）DevOps支撑平台整体架构(架构图，覆盖研发，微服务，DevOps持续集成和容器平台）研发过程管理(介绍研发过程管理方案，比如采用禅道实现研发过程管理）容器化PaaS（需要对Docker+K8s来实现容器化PaaS和资源调度用一页来说明）
DevOps支撑平台对关键业务场景的支撑
在这些讲解清楚后，不用去逐个详细介绍DevOps平台的功能点，最好以关键业务场景或问题驱动介绍。即基于业务场景将DevOps平台提供的核心功能全部讲解清楚。
持续集成和交付（重点讲解整个流水线设计和自动化编译，构建，打包过程）研发和测试协同（重点讲解研发管理工具和DevOps平台间的协同）测试自动化实现（重点讲解下测试自动化如何实现的）环境迁移和前方发版（重点讲解环境迁移，版本提前，灰度发布等）研发过程度量（重点讲解研发过程度量，当前做了哪些内容，后续还准备做哪些内容）后期性能监控（重点讲解后期的性能监控，服务链监控，日志采集和分析）
DevOps下的集成和协同
这块实际上需要单独来讲下，即DevOps研发运维一体化下几个关键的协同点。这个实际上在我前面的文章有过介绍，其中包括了如下：
其一是敏捷研发管理和DevOps的过程协同
在DevOps实践中，一定要解决好的就是开发和测试的协同，开发测试和工程运维的协同。因此对于研发项目过程管理工具，DevOps支撑工具本身要紧密集成才能够更好的支持整个协同过程。
虽然敏捷方法论强调面对面的沟通，但是在整个持续交付过程中要减少各种无谓的沟通，通过工具进行自动化协同。类似测试不清楚开发的功能是否完成了，是否可以测试了，是否部署到SIT环境了，Bug是否修改好可以重新验证了等等问题，都应该在工具层面进行解决。
开发和测试协同：重点解决版本多次编译构建持续集成和测试验证过程协同开发和运维协同：重点解决测试完成版本发布后，工程运维进行版本提取和部署的协同
其二是DevOps持续集成和容器云平台协同
即整个DevOps的持续集成和持续部署如何和底层的容器云平台进行协同。一个DevOps支撑平台离不开和容器化PaaS平台的集成，即最终的编译构建完成的内容形成镜像并放到镜像仓库，后续部署，环境迁移，资源扩展基于镜像仓库进行快速的拷贝和复制。对于Docker容器一般会和K8S结合来实现资源的动态调度，集群管理能力。
环境迁移是基于镜像进行环境拷贝和迁移，而不再需要重新构建和打包，这也是我们原来在谈持续集成技术的时候一直强调的一点。只有这样才能够保证测试通过的包就是最终部署到生产环境的包。
其三是DevOps持续集成过程和API网关协同
如果整体架构中，所有的微服务模块都不需要和外面的业务系统打交道，那么你可能并不需要使用微服务网关，但是如果存在整个架构朝外部提供API接口服务能力，包括你的APP端也需要理解为外部。那么就一定涉及到微服务网关的使用。
微服务模块中的接口方法不是所有的都需要注册到微服务网关上面，要梳理清楚，究竟哪些接口方法要注册到微服务网关上面。而这块注册操作我们希望是完全自动化注册并运行。
即微服务模块部署-》k8s发布可访问的API地址-》微服务网关封装后暴露最终的API服务地址
而这个API服务地址是可以给外部系统或前端APP使用的一个地址。对于其它应用的开发我们可以使用该地址。如果说到DevOps支撑平台，那么在集成微服务网关能力后，最基本的就是要有服务注册和管理能力。
最后一部分重点是对项目实施后的收益或效果进行分析，最好能够有明确的数据来说明。
比如整个持续集成周期缩短多少，人为打包部署工作量降低多少，交付效率提升多少，项目管理可视化程度提升多少多个方面进行说明再进行微服务架构实施和DevOps转型后取得的收益情况。对于DevOps支撑平台实施收益和价值，今天再从业务和管理层容易理解的视角来进行下阐述。
企业研发管理过程的标准化和规范化
在DevOps实施过程中，协助企业进行研发管理过程的规范化和流程化，不论是传统的研发过程管理模式，还是敏捷开发思路，都需要对研发过程进行标准化和流程化，再进一步自动化。
这里面涉及到最基本的开发框架，开发规范，配置管理，变更和缺陷管理，测试管理，版本发布等诸多关键过程域，而这些在我们进行DevOps支撑平台实施的时候会协助企业进行这方面的优化和改进。
企业研发资产的可视化
在DevOps里面我们会强调研发和运维一体化，研发和质量管理一体化，这些都没有问题。但是DevOps有一个关键就是本身是完全包括覆盖了传统的持续交付和持续集成最佳实践的。即整个研发生命周期过程应该进一步的可视化，同时通过微服务架构设计和模块拆分，进一步的实现短周期迭代开发。
迭代开发最终交付的用户可以使用的功能，而不是中间的半成品。但是如果半成品的输出过程不可视，如何确保最终的功能输出没有问题？
不论是甲方企业，还是软件企业本身，都需要对研发过程可视化，即对研发过程的关键中间节点做到完全可控，可视，而这里面最重要的就是做到中间输出结果本身的可验证。注意在整个DevOps流水线作业中，增加的代码入库和静态检查，构建，自动化的单元测试等都是确保这些中间件节点可视，确实研发检入的代码是完整并可以编译通过的。
对于原来的关于微服务，DevOps等各个方案，虽然前期也进行过整合。但是经过分析和重新思考。具体的优化和改进点主要包括了如下几个方面。
其一是咨询规划和技术平台两个大部分必须分离和松耦合，以适应不同的售前场景。即如果客户本身只需要一个标准化的技术中台，那么你完全没有必要去讲解中台规划咨询方法论。
其二是我们PPT内容的呈现逻辑有些需要调整。比如对于微服务架构框架的整合方案，原来写的思路是给出我们具体选型的分析思考过程，而真正应该的思路还是开门见山的方式给出最终的解决方案，再来说明最终解决方案的优势。
其三是技术类解决方案本身相当理论和技术化，很容易陷入到技术原理和技术实现细节中。因此在很多关键技术点和技术优势呈现的时候，仍然需要考虑结合具体的业务场景和实践来进行讲解。即你完全可以讲我们遇到问题是如何做的，而不是你有什么功能去解决什么问题。
