微盟开发平台设计与实现_TakinTalks稳定性技术交流平台

一、设计背景

此前微盟存在多个应用开发平台，包括应用开发、容器资源管理平台和微前端平台等，多个平台长期割裂、规范不统一、研发使用成本高、底层管理和运维成本高。为了统一微盟研发规范，提供一站式的应用开发全生命周期管理能力，所以落地了微盟开发平台的设计与实现。

二、整体架构设计

微盟开发平台是基于微盟统一开发平台框架而建设，以应用为核心构建开发者生态能力，平台各模块解耦，生态能力共同建设。微盟开发平台整体架构图如下图所示：

微盟开发平台通过统一业务网关对外提供 API 接口，在网关层进行统一鉴权、审计和限流，进入业务网关后内部以微服务方式分别实现开发平台的 CI/CD、容器管理和应用管理等功能模块，依赖基础服务和三方组件，以集控1托N模型纳管公司内所有的 K8s 集群，基于 Tekton 实现流水线复杂的任务编排。

三、核心模块设计

3.1 CI模型设计

3.1.1 流水线运行模型

目前微盟开发平台流水线中共包含了代码构建、容器部署、代码扫描、镜像打包、自定义扩展等十几种任务，任务之间可以进行串并行的编排，多个任务可以组成一个阶段，多个阶段组成一条流水线，阶段内任务并行执行，阶段之间串行执行，如下图所示：

微盟开发平台流水线任务支持灵活的编排能力，且资源用完即销，且流水线构建资源可以快速扩容以增加流水线并发执行能力，在构建低峰期构建资源还可以用于扩充集群资源，充分利用流水线构建资源。

3.1.2 流水线设计

（1）队列缓存：所有提交的流水线任务，都会先进入到对应的流水线等待队列中，并不会直接调度资源进行执行，而是会实时根据当前构建资源使用率和并发执行限制进行判断是否将等待任务调度到执行队列中执行，保证稳定性和效率的前提下充分利用构建资源。

（2）触发模式：支持手动触发、定时触发和代码更新自动触发三种模式。

（3）监控告警指标：并发运行数量和等待运行数量指标打点，实现相关监控大盘和告警。

（4）结果触达：运行结果实时触达通知到相关研发。

3.2 CD模型设计

3.2.1 CD模型

（1）队列缓存：所有发布通过平台提交后，都会进入到对应环境的发布等待队列中排队等候，而不是直接生效的到 K8s 集群，有相关定时任务会实时处理等待队列中的任务，根据当前集群资源水位、集群运行情况以及当前并发运行部署的任务数量等条件综合判断是否可以将等待任务进行实际生效部署。以缓存队列设计来避免高流量的并发部署冲击，同时避免过多应用同时部署对集群稳定性造成影响，既保证了发布的稳定性和也兼顾了发布效率。

（2）资源变更全局锁：应用+环境+集群粒度全局资源锁，保证生产部署操作的原子性和稳定性。

（3）环境隔离：部署任务根据环境不同分别进入到不同的缓冲队列中去执行，各个环境之间任务隔离，互不影响。

（4）监控告警指标：不同维度的并发部署数量和等待部署数量指标打点，实现相关监控大盘和告警。

3.2.2 CD容器资源操作逻辑

（1）发布入口：分两大类，分别是基准发布入口和全链路灰度发布入口。

（2）部署类型：分为流水线部署、手动部署、灰度部署和灰度转正四种类型，流水线部署是指通过流水线构建完成自动触发部署，手动部署则是用户手动选择镜像版本进行基准的部署，灰度部署是指发布到灰度环境中的部署，灰度转正是指将灰度环境中的版本转正发布到基准环境中。

（3）部署逻辑：流水线部署和手动部署操作逻辑基本一致，都是进行相关部署预检后，再对集群资源进行镜像版本的替换，并实时检测变更后的资源状态；灰度部署则是分两种逻辑，如果是首次进行灰度环境的部署，则会先复制基准环境的资源再进行镜像版本的替换，如果是非首次部署灰度环境，则只需进行镜像版本的替换；灰度转正则是先进行基准环境的镜像版本替换，再清理灰度环境的资源。

3.3 容器管理设计

3.3.1 COS架构

微盟开发平台由 COS 提供云原生容器编排能力，COS 整体架构如上图所示。COS 提供的云原生容器编排能力有：

（1）多集群管理能力

（2）多集群资源分发能力

（3）增强型资源查询能力

（4）多版本兼容能力

具体实现原理图如下：

基于上述 COS 的容器编排能力，微盟开发平台实现了对 K8s 集群的可插拔式纳管能力。即新增一个 K8s 集群到微盟开发平台纳管或者减少一个微盟开发平台当前纳管的集群，只需要修改集群的相关元数据配置信息即可。

3.3.2 COS多集群管理能力

COS 集控层纳管了集群的相关元数据信息，而集群元数据信息则是由每个 K8s 集群自动上报注册获得。微盟开发平台对 K8s 集群的纳管模型为1托N模型，即一套微盟开发平台同时纳管多个 K8s 集群。

3.4 生态纳管模型

3.4.1 生态纳管设计

第一版的微盟开发平台只具备容器应用的生命周期管理能力，而公司内除了容器应用外还具有 iPaaS 应用、微前端应用、移动端 APP 应用等，所以为了能够体系化标准化的纳管这些生态应用，基于微盟开发平台的现有基础能力抽象出应用生态纳管模型，具体如下图：

将开发平台能力分为基础能力和扩展能力两部分，基础能力是指生态入驻到开发平台后天然具备的一些基本能力，比如应用管理、项目管理、统一鉴权、审计日志等。而每个生态应用类型可能还会具备生态特有的一些扩展能力，一样可以定制化的入驻到开发平台上，比如容器应有的容器管理能力和集群管理能力等就属于生态应用自定义扩展能力。

3.4.2 生态纳管实践

拿微前端应用生态入驻微盟开发平台来进行举例，整个入驻过程具体包含以下几步：

（1）确认操作入口：研发侧入口和运营侧入口均需要具备。

（2）确认基础能力：需要具备应用管理、项目管理、统一鉴权、审计日志和 CI/CD 这五大核心能力。

（3）确认扩展能力：扩展能力需要具备两块，分别是服务委托配置和路由管理能力。

（4）按照确认的基础能力和扩展能力进行，生态应用在入驻前需要进行基础能力的规范改造和扩展能力的定制化调整。

（5）完成上述四步之后，即完成了微前端应用生态入驻微盟开发平台，在开发平台上架该生态应用后，即可提供研发使用。

四、总结

（1）统一微盟开发平台：