这是关于系统配置管理开发系列文章的第三部分，主要内容如下：

• 系列概述：文章是多部分系列的第三部分，完整系列包括介绍、迁移与演进（包括在 Go 中处理机密、IaC 和反序列化数据、构建 CLI 和 API、处理独占配置和相关模板）、性能考虑、总结与反思。

• 性能方面：

  • 缓存：在 ClickHouse 集群中集成新 SCM 时出现性能问题，构建完整配置需至少 5 秒，导致 API 过载。在 Consul 级别引入缓存可改善情况，API 扫描主机组的声明性配置并将配置存储在 Consul 中，提高了速度，但配置的总体部署时间从 10 秒增加到 5 分钟，通过实现 goroutine 解决了此问题。
  • goroutine：读取主机组配置文件的循环为每个主机组创建一个 goroutine，为每个主机创建一个新的 goroutine，虽提高了速度，但导致 Consul 的 IOPS 过载。通过将临时配置存储在 API 主机的本地内存中，并开始读取和写入配置的校验和，解决了此问题，降低了 Consul 主机的 IOPS 利用率。
  • 与 goroutine 和缓存方案相关的问题：识别配置错误的复杂性增加，Go HTTP 客户端不将服务器的 4xx 响应视为错误，导致生成错误的配置，通过修改代码来检查响应代码解决了此问题。

• 开发过程中初始观点的变化：

  • 模板文件的处理方式发生了变化，新 SCM 可以在代理级别和服务器级别进行模板配置。
  • 最初认为不需要对主主机组的文件进行模板化，现在由于需要支持多种操作系统，在所有级别使用模板已解决此问题。
  • 认为主机组中的每个主机不一定需要具有相同的配置，这是受部署需求和部署期间不同主机上的过渡配置的影响。
• 在其他团队中重用 SCM：公司有多个 SRE 团队，但新 SCM 仅为一个团队开发，目前正在将其适应其他团队，通过将每个管理器和许多函数设为公共模块，并将这些模块作为核心功能公开，让团队有机会使用核心模块或自行编写。
• 数据提供程序作为模块：目前有两个数据来源和两个集成，这是 SCM 不能通用的原因之一，许多开源产品使用数据提供程序作为可插拔模块来解决此问题，有多种方法可以创建可插拔模块。
• 两个或更多 API 实例：多个 API 可以高效响应代理请求，但在扩展 API 时遇到了与在 Consul 中构建缓存的调度程序进程相关的问题，通过锁定系统可以解决竞争条件，但会导致主机停机时配置锁定，未来可将主机组的组装拆分到不同的 API 进行配置构建。
• 开发人员和生产环境：为了便于在生产和开发之间迁移主机组并验证新功能，希望在测试和生产中使用统一的配置存储库，通过创建描述 API URL 的对象来实现，一个 Git 推送即可将生产环境转换为 SCM 的测试环境。
• 测试：新 SCM 目前仅提供手动测试，使用开发集群进行测试，自动化测试面临一些挑战，如许多可测试函数只是 Go 标准库的包装器，不需要测试，许多操作系统接口不是幂等的，操作可能需要回滚，低级别接口管理不便，使用 shell 命令与操作系统交互并解析 stdout/stderr 来做决策也很繁琐。