背景
从过去几个月, 我的工作精力主要集中在企业级发布平台的建设上. 同时也聚焦在容器云 PaaS 层建设。
在当下云原生时代, 发布平台通常起到一个联结 PaaS 和 IaaS 的作用. 通过在 PaaS 层抽象，将 IaaS 层基建细节屏蔽，同时通过 api 和各个服务平台(CI/CD 服务, 监控告警服务, 网关服务, 工单系统, 服务治理系统等) 交互, 在云平台提供了一个统一的快捷入口，从逻辑上进行汇聚，便于开发者进行一站式应用发布、服务生命周期管理、服务治理、服务运维等操作.
这也是发布平台的职能，在一个完整的 PaaS 云平台体系中，其能力应是集成的，而非离散的－－系统需要提供很好的集成能力，让系统得到收敛，避免系统被割裂成一个一个的执行单元，那么用户常常会为此痛苦不堪；同时平台也是场景化的，而非基于功能需求的－－场景能够串联工具的能力，跨越短平快的需求，让平台的各个工具能够串联的运转，其数据能力能在多个子系统间流动起来。
那么什么是 PaaS 平台?
PaaS 是在 IaaS 层之上的基础平台，一个典型的特征是拥有 App 概念，一切围绕 App 开发的生命周期展开，也会对 App 的架构做一定的约束. 由于直接对接业务侧应用甚至应用架构, 且 PaaS 平台通常是业务方最直接所见的基础平台. 对 PaaS 平台的建设要求就有所提高，通常需要在建设通用性能力的基础上，提供一定的贴切公司使用场景的定制化能力。
故通常云平台也在承接着各个业务线开发者提来的各式各样的需求. 起到对业务部门垂直支撑的作用.
一个常见的云平台生态支撑场景如下图所示
云原生时代发布平台思考
随着近年来云原生概念和云原生架构设计的流行，越来越多的开发团队开始使用 DevOps 模式进行系统开发，并把大型系统拆解成一个个微小的服务模块，以便系统能更好地进行容器化部署。
基于 DevOps、微服务、容器化等云原生的能力，可以帮助业务团队快速、持续、可靠和规模化地交付系统，同时也使得系统的复杂度成倍提升，由此带来了前所未有的运维挑战，比如：
- 模块之间的调用从进程内的函数调用变为容器进程间的调用，而网络总是不可靠的。
- 微服务拆分多样, 难以从全局视角观测各个微服务健康信息。
- 服务的调用路径变长，使得流量的走向变得不可控，故障排查的难度增大。
- 引入 Kubernetes、Docker、Service Mesh 等云原生系统，基础设施层对业务开发团队来说变得更加黑盒。
无论是微服务拆分, 容器化, 云原生化等, 都对服务的发布过程带来巨大挑战. 如何做到无感地支持容器/k8s发布, 同时提供云原生时代的可观察性可以说的云原生时代发布平台的主要目标。
而从前司的平台建设经验来看, 我们在平台建设初中期也遇到了以下问题
如发布过程中的金丝雀/预发布环境/持续测试支持, 属于对于服务自身发布过程的稳定性建设, 帮助业务更搞笑稳定的进行版本发布.
发布后的应用观测中也涉及到日志查询, 容器 debug 能力, 实时诊断能力等支持.
基于以上遇到的问题，大致抽象了以下几个长线来探讨发布平台建设
- 服务发布稳定性
- 发布系统可扩展性
- 服务可观察性
- 发布系统易用性
根于上述4条长线, 列出了我个人理解的云原生时代的发布平台建设全景图