对云原生整体解决方案的进一步复盘

　　在前面的头条文章中，我给出过完整的云原生解决方案和整体架构思考。最近开始重新整理产品规划，对当前做的一些内容和准备做的一些内容做下进一步的思考和总结。
　　云原生当前虽然越来越受到传统企业的重视，但是由于很多企业本身信息化建设水平相对滞后，因此当前云原生涉及到的微服务，容器，DevOps等管理和技术实践更多也集中在金融，电信，能源，互联网等企业偏多。云原生解决方案概述
　　在前面我给出过一个完整的云原生整体解决方案架构如下：
　　云原生的重点就是微服务，DevOps和容器化PaaS。而我们提供的解决方案实际上完全包括以上三方面的内容，同时是提供一个从规划咨询到架构设计，到平台搭建和实施，到后期管控治理，监控运维的一个完整解决方案。
　　我一直在考虑整个产品线和团队的优势究竟在哪里? 其一就是从咨询到实施的端到端解决能力，其二就是对于微服务和DevOps我们都有成熟的项目案例和实践，唯一缺少的就是两者同时在一个大项目的融合实践。
　　我们可以看下上面这张图，基本把当我我们提供的能力做了一个完整的说明。
　　微服务架构咨询
　　注意微服务架构咨询实际上是一个较为笼统的能力，要注意到这个能力实际上是对于我经常谈到的企业架构规划的一个轻量敏捷化变形，在这个过程中增加了中台和微服务相关的设计思考，同时对传统企业架构里面的数据架构，集成架构和技术架构进行更新，对业务架构和应用架构的建模思路进行合并等。
　　即微服务架构咨询是以微服务和云原生为技术基础，以业务驱动IT的企业架构规划方法论为理论指导，帮助企业构建高度灵活敏捷，高可用的业务中台和技术中台体系，实现企业的数字化转型和产业互联。
　　其核心是需要完成几个关键事情，具体如下：能够识别业务中台构建过程中的各个微服务模块能够通过数据架构规划和分析，对微服务模块对应的数据库也进行拆分通过业务交互和前台应用需求协同，通过数据库本身的能力同时分析和识别API服务能力
　　简单来说就是中台应该包括哪些微服务，每个微服务对应的数据库是什么样的，应该包括哪些owner的数据库表，同时这个微服务模块应该对外暴露哪些API接口服务。这些都搞清楚，那么我们整个业务中台关键的内容也就搞清楚。这个是不论你用什么开发框架，技术架构都必须搞清楚的问题。
　　其次，微服务架构咨询需要给出我们的微服务开发框架，技术架构选型，同时对微服务开发框架里面的个别关键子组件进行选型和整合，类似我们经常说的API网关，限流熔断，服务链监控，消息中间件等。
　　再次，给出微服务架构整体相关的标准规范体系，其中既包括了架构标准规范，也包括了咨询规范，开发规范，实施规范，运维规范等。整个微服务架构设计和开发实施需要遵循标准的规范体系进行。
　　微服务开发框架和运行环境，技术中台服务提供
　　这个是偏建设和实施阶段的内容，既我们可以给企业提供一套完整的微服务开发框架和开发标准规范流程。可能大家会觉得之间采用SpringCloud微服务开发框架体系即可。但是实际上整个微服务开发框架和技术组件绝对不是单个开源软件就解决的，往往涉及到多个开源组件的集成和整合。
　　其次，在提供微服务开发框架时候，我们整合我们的技术中台服务能力。技术中台服务既包括了传统企业信息化经常谈到的流程引擎服务，4A技术服务，也包括了类似消息，缓存，分布式存储，数据库，文件，通知等各类技术服务能力。
　　技术服务本身和业务无关，同时具备高复用可共享性，因此更加适合下沉统一建设再暴露API接口服务能力。
　　DevOps过程支撑平台
　　对于DevOps过程支撑是面向云原生整体解决方案里面的一个关键内容，我们整体的平台本身也是基于DevOps能力成熟度标准来构建。包括了类似研发过程管理，持续集成，持续交付，数据管理，测试管理，度量分析等各个大的模块。在这个平台中集成了大量的开源组件工具链，实现了整个软件开发项目从代码管理到检入，到自动化编译构建，打包，部署，发布，环境迁移的完整流水线作业能力。
　　容器化PaaS平台
　　DevOps过程支撑平台本身底层基于容器化PaaS平台，我们本身提供容器化PaaS平台的完整能力，核心还是基于Docker+k8s的整体容器部署，编排和动态调度方案。但是整个DevOps过程支撑平台也可以实现和当前公有云容器化PaaS平台的无缝集成能力。
　　通过微服务架构+DevOps过程支撑+容器化PaaS平台，基本就可以实现一个传统应用完整的面向云原生的构建，迁移和后期自动化运维治理能力。
　　云服务总线- 遗留系统的接口适配和集成
　　对于遗留系统的接口适配和集成，仍然需要传统的ESB服务总线产品来完成。而对于我们自主研发的ESB服务总线产品，当前已经完全支撑对Http Rest接口服务的全生命周期管理能力，也可以理解为完全覆盖了当前主流的API网关产品的标准能力。
　　也就是说我们的云服务总线完全整合了ESB服务总线和API网关两方面的关键能力。对云原生方案进一步复盘思考
　　下面谈下当前基于整体解决方案的复盘思考。
　　架构规划和咨询
　　对于架构规划咨询实际包括多个方面的内容，即数字化转型规划咨询，传统企业IT架构转型规划，企业传统IT架构迁移上云规划，PaaS云平台规划，微服务架构规划和治理，DevOps最佳实践规划咨询等。
　　在今年5月，我重新整理了完整的企业数字化转型和云原生架构规划咨询整体方案材料，里面即是围绕整体数字化转型方法论展开，包括了数字化转型规划，云原生平台建设，能力中心建设，能力开放，微服务规划和识别，DevOps过程支撑能力提升等方面的内容。
　　从数字化转型到云原生-架构规划整体方法论整理
　　当前能够做好数字化转型和云原生架构规划的不多，当前看到的主要也是类似传统的类似IBM，埃森哲，ThoughtWorks等大的咨询公司，或类似国内阿里云，华为云在做类似的事情。实际我们更加偏向于类似阿里云这类公司的规划咨询，其很重要的一个特点就是规划后的落地实施能力，同时其本身规划经验也大部分来源于实践。
　　就远行科技来讲，同样规划咨询能力来源于大集团项目的规划经验，实际PaaS平台建设项目的长年实践总结。规划咨询不是目标，最终协助企业转型和平台建设落地，包括后续的知识转移才是目标。
　　低代码开发平台
　　在我前面头条文章中谈过多篇低代码开发平台的文章。最近对低代码开发平台进行复盘重新明确了后续产品规划和研发的重点。
　　第一个重点就是先形成了一个面向特定类型应用的快速开发定制平台，比如只针对财务领域的管理应用进行上层能力的扩展开发。这有点类似BaaS+FaaS的无服务器架构的组合思路。即在无法保证BaaS能力能够完全通过低代码开发自动生成时候，首先要确保前端开发能够完全可以低代码和可配置化。
　　低代码开发平台需要解决的核心问题-服务编排和规则引擎
　　第二个重点就是我在前面一篇文章谈到的低代码开发有一个关键能力就是微服务API的服务组装和编排能力，这个本身是可以作为一个独立小产品进行规划和研发的。在这块前期我们预研了Node-Red开源的组件化编排产品，虽然该产品更多的是应用在物联网服务编排领域，但是经过分析，完全可以引入到微服务API的组装和编排上面。
　　微服务开发框架
　　原有的实现是基于 SpingCloud微服务框架进行定制和扩展。当前有两个重点，其一是引入ServiceMesh来实现微服务治理和管控能力，Mesh去中心化的管控思路是整体云原生架构发展的一个关键趋势。
　　其二就是前面我一篇文章谈到的微软Dapr微服务框架的一些启发。即一个好的开发框架，除了需要微服务间横向的接口集成和管控能力外。也需要纵向的全贯通能力，即底层从传统的资源层到服务层API接口服务，而上层有能够提供API能力开放的北向接口。
　　微软开源Dapr微服务框架-云原生应用和微服务发展主流趋势
　　当一个微服务开发框架能够完全提供以上两点时候，那么剩余的内容就仅仅是业务功能和逻辑的开发，同时开发完成的微服务组件模块能够天然具备和其它微服务API接口集成的能力，又具备适配多种外围云资源，云服务的多环境适配能力。
　　也就是说你会看到你开发完成的微服务能够一键快速地交付到类似阿里云或华为云，你不需要面对虚拟机资源，而是面对的各种技术服务能力。其次，当你不满意阿里云的服务的时候，你也可以一键迁移到华为云，底层框架已经完全帮你做好各种适配。
　　API网关和能力开放
　　虽然ESB服务总线能够更好地适应传统IT架构里面的各种复杂接口适配，协议转换等。那么随着企业IT本身的微服务化改造，ESB总线集成方式会逐步淡出。
　　取而代之的是基于API网关的服务集成和能力开放。
　　但是企业IT架构转型本身也有一个过程，存在新系统和老架构共存的情况，因此我在前面文章也谈到ESB+API网关的两层架构集成模式会存在相当长一段时间。
　　对于API网关本身足够轻量，传统ESB总线具备的适配，协议转换，数据映射等各种能力往往都不具备。但是我们可以考虑在API网关引擎的基础上来开发各种插件来提供这种适配能力。
　　在上半年我们先做的就是数据库适配插件，并形成一个API快速开发平台，简单来说就是通过DB数据库表，你可以快速的发布CRUD等各类Http API接口服务能力。但是对于SOAP和Rest接口转换，数据映射，消息集成，动态路由等能力仍然需要开发定制插件来支持。
　　这也是后续准备进一步分析和研究的关键地方。
　　DevOps过程支撑平台
　　DevOps平台当前更多的叫法是研发效能平台，即提升整体研发效能和集成交付效率。DevOps本身是大量的开源工具链的集成和组合，核心仍然是CI/CD持续集成和持续交付过程。围绕持续集成交付又扩展了敏捷研发和自动化测试等关键过程支撑。
　　对于DevOps平台研发当前重点仍然是扩展整体平台的高可用性，高性能和高可靠性。其次就是我前面提到的多云适配和多云交付能力。
　　围绕整个敏捷方法论，如何实现敏捷研发项目管理，开发和集成过程，测试过程，部署和交付过程的高效一体化协同仍然是提升整个平台核心竞争力的关键。
　　云原生一个重点就是从资源层到服务层的完整抽象，对于开发人员来说不应该再去接触资源层的内容，而是订购和消费各种技术和业务服务能力。
　　运维监控
　　在运维监控层面重点考虑两个事情，其一是分布式大规模部署的集群日志的实时采集，日志的全文检索和分析能力。其二是混沌过程。
　　对于混沌工程是提升整个云原生架构下可观测性的一个关键手段，特别是面对大规模的分布式集群应用下，更加需要通过混沌过程来进行整改环境高可用性的验证工作。
　　分布式架构下混沌工程-提升云原生应用的稳定性和可观测性
　　运维监控方面虽然AIOps智能化运维提得相当多，但是当前实际很难达到这个水平，当前要做的重点仍然是基于各种预定规则的自动化运维，能够做好这步已经可以解决大部分问题。而要做到这点本身同样需要从资源层抽象到服务层，从服务层抽象到应用层。即从传统的资源监控到服务链路监控，再到上层的应用监控。