何子波-蚂蚁集团配置即代码的规模化实践之路.pdf

《何子波-蚂蚁集团配置即代码的规模化实践之路.pdf》由会员分享，可在线阅读，更多相关《何子波-蚂蚁集团配置即代码的规模化实践之路.pdf（30页珍藏版）》请在三个皮匠报告上搜索。

1、演讲人：何子波目 录01浅谈配置管理02配置即代码03蚂蚁落地实践04总结与展望浅谈配置管理传统的配置管理 Kubernetes YAML Strikes分布式配置中心 配置格式五花八门，YAML、配置领域专用语言(DSL)、通用编程语言(GPL)各种配置工具层出不穷，热闹非凡，Helm、Kustomize 仍然最流行配置即代码Borg接入三件套：BCL/borgcfg/WebConsoleProdspec and Annealing运维平台功能透明度不足，大量黑盒代码逻辑运维平台高度定制化灵活性不足，无法满足应用个性化运维需求资源瓶颈，无法复用和发挥 SRE 沉淀的运维经验开发集群测试集群生

2、产集群纯开源技术栈，工程化水位低无规划化流程，缺少技术风险防控低协同性，大量文件拷贝平台SRE业务研发业务SRE平台研发陷阱 1：没有把配置作为一种编程语言如果你不是为之专门设计一种语言，那么最终用到的“语言”就不太可能是一种好语言。尽管配置语言描述的是数据而不是行为，但它们仍然具有编程语言的其他特征。陷阱 2：设计特殊的语言功能特殊的语言比正式设计的等效语言更复杂，并且通常具有低效的表达能力。与其祈祷配置系统不会复杂到需要一定的编程结构，不如在初始阶段就考虑到这些需求。陷阱 3：使用现有的通用脚本语言 e.g.Python使用通用脚本语言的实现方式往往是重量级的，并且/或则需要使用侵入式沙盒

3、来确保密闭性。由于通用语言可以访问本地系统，处于安全考虑，可能还是需要沙盒。Polyrepo（多仓库）Monorepo（单体仓库）配置跟着业务代码仓库走，开发者不需要感知额外的配置仓库，认知成本低代码量和复杂性可控，不用担心可扩展问题利于权限控制，权限分配粒度可以做非常细优势难以建立统一的代码规范，平台团队缺少约束力依赖管理与升级非常复杂，不利于 SRE 进行批量的配置变更劣势易于规范代码，中心化流水线更容易把控代码质量和风格，同时依赖管理与升级更加简单利与 SRE 进行批量配置变更与重构，且易于代码重用利于构建中心化的配置自动化层，便于上游即成优势开发者需要感知额外的配置仓库，有一定的学习成

4、本难以实现细粒度的权限控制，并且随着代码文件、数量越来越多，复杂性会越来越高，可能存在可扩展性问题劣势Platform build ModulesDeveloper choose ModulesCodingPre-ApplyApplyPost-ApplyDeployValidationResourceLive DiffPreviewLLVM 优化器Native+WASM Target代码索引、增量编译高性能强不可变性静态类型系统面向约束稳定多语言 SDK内置函数+系统库YAML/JSON 亲和 包管理工具Plugin工程化KCLHCLCUE建模能力通过 KCL Schema 进行建模，通过语言

5、级别的工程和部分面向对象特性，可以实现较高的模型抽象通过 Terraform Go Provider Schema 定义，在用户界面不直接感知，此外编写复杂的 object 和必选/可选字段定义时用户界面较为繁琐通过 Struct 进行建模，无继承等特性，当模型定义之间无冲突时可以实现较高的抽象。由于 CUE 在运行时进行约束检查，在大规模建模场景可能存在性能瓶颈约束能力更丰富的 check 声明式约束语法，编写更加容易，对于配置字段组合约束编写更加简单（比 CUE 多了 if guard 组合约束，all/any/map 等集合约束编写更容易）通过 Variable 的 condition

6、字段对动态参数进行约束，Sentinel/Rego 等策略语言完成，语言本身的完整能力不能自闭环，且实现方式不统一CUE 将类型和值合并到一个概念中，通过各种语法简化了约束的编写，比如不需要泛型和枚举，求和类型和空值合并都是一回事扩展性KCL 可以自定义配置分块编写方式和多种合并策略，KCL 同时支持幂等和非幂等的合并策略,可以满足复杂的多租户、多环境配置场景需求Terraform HCL 通过分文件进行 Override,模式比较固定，能力受限支持语言内部配置合并，CUE 的配置合并是完全幂等的，对于满足复杂的多租户、多环境配置场景的覆盖需求可能无法满足语言化编写能力复杂的结构定义、循环、条