云原生中的标准化

云原生带来的一个比较大的收益就是标准化。提升比较明显的包括基础环境与版本标准化、发布部署标准化、分支管理标准化、环境标准化、网格标准化。

1、基础环境与版本标准化

在运维管理过程中，很容易出现操作系统、中间件多版本并存的情况，我们经常会在已有的版本上修修补补，打各种各样的补丁。不同的版本会导致不同的环境差异，不同的环境差异就会引发各种线上问题。云原生引入了不可变基础设施的理念，对老的版本或环境不会侵入，新的环境都会通过标准的 Dockerfile、YAML 文件来统一描述，基本避免了因为版本不标准而引发的线上问题。

2、发布部署标准化

标准的 CI/CD 平台，本身就是对公司持续交付的平台化实现，平台中的标准流水线、工具、卡点就是发布部署规范的产品化体现。比如新需求上线就是要创建新的特性分支，因为老的分支都被删掉或隐藏了，开发完成后必须合并，由测试人员授权才能进入集成。代码的合并权限已被收回，合并代码的事只能交给平台来做，只能先从测试环境到预发环境再到生产环境，不能越级直接上线。

类似的流程把发布和部署做得非常标准，每个团队的发布规则都是一样的，再也不会出现不同团队发布和部署方式不一致的问题。

3、分支管理标准化

之前的架构下，每个团队有一套独立的分支管理标准，有的是 Git flow，有的是基于测试分支开发，有的是基于主干分支开发，因分支使用混乱导致的生产环境故障率长期处于高位。而云原生模式下标准的 Aone Flow 代码分支流程，基本上使由分支产生的故障率降到了 0，研发人员再也不用担心分支管理的问题。

4、环境标准化

在旧的持续部署流程中，环境众多，包括开发环境、测试环境、准生产环境、预发环境、生产环境，甚至在哪个环境进行测试，不同的团队都有不同的标准。CI/CD 平台规范了三大环境的流水线关系，测试运维人员再也不用争吵应该用哪套环境来进行测试。同时，同样的代码在测试环境无 Bug，而生产环境有 Bug 的问题再也没有了。

5、网格标准化

在旧的架构模式下，不同团队的超时机制、限流机制、熔断机制参差不齐，甚至大部分团队是没有这些质量保证机制的。同时，之前基础架构团队给出的一些中间件接入标准大部分是有侵入的 SDK 形式，研发人员多多少少都有接入时的抵触情绪，服务网格的出现，使研发人员接入标准化插件的动作变得极其轻量且统一。