（分享）微服务+DevOps支撑平台

Posted 2021-04-16 远见先行

       重点还是谈下远行云台规划和系统实现方面的思考，对于远行云台的建设目标就是提供平台层支撑能力，包括微服务框架，容器平台，DevOps支撑平台，4A+BPM等。你也可以理解远行云台就是企业内部私有云的PaaS平台，只是这个PaaS平台更加敏捷和轻量化，比如在资源托管和调度上转变为了轻量的Docker容器技术，同时资源调度采用k8s来实现；对于开发框架上引入了微服务框架实现彻底的组件化，对于传统PaaS平台谈到的开发态+运行态+运维态，现在通过DevOps思想实现了完整的整合，这就是当前云台带来的变化。

       为了更好的支撑这种变化，我们要做的就是实现一个基于微服务架构+容器技术的DevOps支撑平台，通过该支撑平台来实现上面所有内容的一个支撑，以实现进一步的自动化，可视化，实现对整个平台的更好的管控和治理能力。要知道，一个平台能否用好，支撑平台的规划和建设相当重要。

       在建设这个支撑平台的时候，我们首先实现的仍然是容器+DevOps过程的一个集成。而对于DevOps里面最重要的仍然是如何实现整个流水线作业和自动化的管控能力。一个简单的流水线至少也要包括从开发，构建，部署，测试等几个关键动作，同时需要将这些动作串联起来形成一个完整的整体。

       我们可以来看下我们开发一个最简单的业务系统，先不考虑微服务架构和组件化，那么这个支撑平台究竟应该提供什么样的能力。

       1.建立相应的开发项目，进行项目基础数据的定义，包括业务系统名称，团队成员，版本规划等。
       2.配置好你的源代码管理库，比如本地的SVN或公网的GitLab，GitHub等都可以。
       3.独自建立你的开发和编译任务，构建和打包任务（镜像制作），部署任务，测试任务等。
       4.编排作业流水线，将独立的任务串联为一个完整的流水线作业，可自动执行，也可以手动执行。
       5.开发每天check in自测通过的内容，流水线运行，完成整个应用的部署和发布。
       6.测试人员在测试环境对业务系统进行完整的测试，并反馈Bug和跟踪问题的解决。
       7.开发和测试人员都可以通过平台提供的各种看板监控到当前环境的部署情况，资源的运行状态信息。

       当然在整个实现过程中可能远比这个复杂，一个业务系统本身可以分解为多个Jar包，那么我们实际在编译和构建的时候就需要支持能干编译构建不同的Jar包文件。同时在镜像制作的时候也要支持既可以每个Jar包都是独立的镜像文件，也可以支持全部放在一个镜像里面。在部署的时候需要能够支持各类环境变量的灵活配置和自定义。

       通过以上过程本身可以看到整个过程自动化后，开发人员应该只需要关心自己代码编译和自测OK，同时按时Check in自己的代码即可。其它内容都不要去关心，而测试人员也很简单，只需要对流水线成功运行发布的版本进行测试和反馈问题即可。也就是说当前支撑平台不再是简单的通过容器化资源池来解决资源的利用率问题，而更加重要的是实现整个开发过程的自动化和可视化管控问题，真正提升开发，测试包括后续的运维效率。

       在建设DevOps支撑平台的时候，结合互联网的应用实践，必须还具备如下能力：

1. 环境的迁移能力（即可以将Dev环境测试通过内容迁移到SIT环境，把SIT测试通过内容迁移到UAT环境）
2. 灰度发布能力（能够支持不同的灰度发布测试，按黑白名单，按区域，按用户群等）
3. 自动化测试能力（对于自动化部署完成的内容，应该能够进行完整的自动化单元测试和冒烟测试）
4. 中间件运行日志的采集和监控能力（日志采集和处理，日志的查询和全文检索）

       要知道，在实现容器化PaaS后，我们整个系统对应的物理资源和逻辑资源都可能是不固定和动态分配的，正是由于这个原因，我们对整个资源池的管控也必须通过支撑平台来完成。

       对于整个支撑平台对微服务架构的支持，不是简单的引入SpringCloud等微服务框架就能够解决的问题，而是涉及到微服务框架下的开发如何更好的和DevOps整个过程衔接起来。其中包括了微服务API的注册，微服务网关，服务链监控等诸多内容，将在后续进一步展开说明。