我们来编个故事
咕咕哒公司是一家新型数字化养鸡场企业。养鸡场使用基础设施即代码的理念。操控流水线完全自动化构建和部署新的养鸡场及更新旧养鸡场。这一举措致使公司可以统一管理旗下养鸡场，生产的鸡蛋质量统一，部署过程完全自动化，无人化，极大的避免了人为错误。目前公司业务进展顺利，开始全面开始拓展市场。
事件
因为不同地域的气候特征以及饲料供应链差异，公司发现使用同一种品种已无法满足适应市场拓展的需求。于是公司决定使用在不同地区饲养适应该地区的特殊品种。这些地域性的配置一开始是作为参数被各地区在基础设施构建后，以手动复写配置文件的方式独立管理的，在实际的应用过程中产生了几个问题：
- 配置分散：自动化构建生成的基础设施相关配置（如数据库连接串）由基础设施脚本管理，而地域性配置由当地环境线上部署文件管理，总部不可控。
- 配置不可见：一个地域的配置需要下载这个地域线上的配置文件才能知道这个地域环境的配置是什么。
- 配置无唯一可信源：自动化构建生成的配置可被区域性配置复写，省级配置可被市级配置复写。最终环境上一项配置是由谁配的，被谁复写过，为什么最终是这个配置无法溯源。
- 配置修改门槛高：因为修改或增加配置需要复写线上部署文件，需要了解底层部署原理才能进行操作。这个任务往往最终转变成DevOps的任务，给DevOps带来了不必要的负担。而且人为错误可能性大幅提升。
为保证不影响作为公司核心竞争力的自动构建和自动部署。公司决定在基础设施构建过程中引入使用配置即代码的配种（配置）中心来解决上述问题，集中并自动化管理配置。
争议
是先有配置中心（?鸡）还是先有基础设施及代码（?蛋）？如果先有配置中心，那配置中心又是如何构建出来的？如果先有基础设施及代码，那配置其实是由基础设施及代码来管理吗？
方案一：先有配置中心
配置中心管理所有配置并独立于基础设施及代码之上存在。
（图一）
（图二）
方案一的实现
- 在原有的养鸡场基础设施即代码之外新增一个配置中心。这个配置中心可以是在运行养鸡场构建之前手动创建的，或（如图二）由另一套基础设施及代码脚本独立构建的。
- 配置中心里保存养鸡场基础设施及代码的所有通用配置（包含基础设施参数和业务配置），各区域管理人员统一在总部这个唯一的配置中心里添加自己区域的特殊配置（包含特殊的基础设施参数和业务配置）。
- 在构建基础设施时由配置中心中所有带有基础设施标签的配置生成配置文件用于构建。
- 养鸡场直接连接配置中心（或连接中央配置中心的只读副本）并获得所有适用于改地域的业务配置。
讨论
- 问：是否坚持遵循基础设施即代码？ 答：应该，否则无法使用流水线自动化构建。
- 问：是否引入配置即代码？ 答：应该，因为上一个问题决定了这个配置中心应该可以自动被构建，所以配置也要在构建过程中写入。
结果
需要拆出（如图二）的第二套基础设施即代码。
优势
- 基础设施配置与业务配置在同一地点集中管理。
- 利用配置中心UI展示配置，所见即所得。标签区分基础设施 vs. 业务，通用 vs. 地域等。至多一次复写。
- 配置中心即为唯一可信源，方便公司可以统一管理。
- 利用配置中心UI维护配置简单方便。
劣势
- 配置中心成为基础设施构建部署整套流程的单点故障。
- 配置中心引入与养鸡场基础设施生命周期不同的基础设施，破坏基础设施即代码的完整性。
- 讨论结果导致最终方案需要实现了方案一与方案二的混合策略。这引入了方案二的所有缺点，直接破环了这个设计的初衷。
方案二：先有基础设施及代码
配置中心只管理所有业务配置，并由基础设施及代码（配置即代码）管理。
（图三）
实现
- 在原有的养鸡场基础设施即代码中加入一个配置中心的构建模块。
- 公司集中为每一个地域管理一套配置即代码（包括基础设施的参数与业务配置），并在这个地域的基础设施构建时将业务配置写入为这个地域构建的配置中心中。
- 养鸡场直接连接配置中心获取业务配置。
讨论
- 问：如果通过手动修改配置中心的方式改变业务配置，会不会导致配置即代码不可信？ 答：会，配置即代码并不能代表线上环境真实使用的配置。
- 问：配置即代码是不是应只管理业务配置的初始值？ 答：不，基础设施即代码或配置即代码修改后应用时会覆盖修改过的配置。
结果
引入“业务修改配置后应相应修改配套配置即代码”规则。
优势
- 基础设施配置与业务配置在同一地点集中管理，并原生遵循配置即代码。
- 利用配置中心UI展示业务配置，所见即所得。没有复写。基础设施参数与业务配置相隔离，可以只由DevOps管理。
- 配置即代码为唯一可信源，方便公司统一管理。
- 修改配置即代码相对与修改线上部署降低了修改配置的门槛。
劣势
- 引入的规则导致配置新增或修改后需要修改配置即代码，相比方案一维护门槛上升。
- 如果规则执行力度不够，也会直接破环可信度。
- 引入的规则导致配置中心不能直接用来管理配置，UI只用做配置展示，配置中心成为鸡肋。
实操迭代：分离基础设施配置和应用配置
分治基础设施配置和应用（业务）配置。应用配置使用方案一，基础设施配置使用方案二。
（图四）
实现
- 在原有的养鸡场基础设施即代码中加入两个配置中心的构建模块。
- 公司集中为每一个地域管理一套配置即代码（只包括基础设施的参数）和一套含有默认业务配置的脚本。在这个地域的基础设施构建时，将基础设施配置的实际值和业务配置的默认值分别写入为这个地域构建的两个配置中心中。
- 地域管理者在基础设施构建完成后自行修改并确认业务配置后开始运作。
- 养鸡场连接基础设施配置中心获得如数据库连接串等在基础设施构建时生成的配置，并连接应用配置中心获得如缓存时间等业务配置。
优势
- 基础设施配置与业务配置各自在同一地点集中管理，基础设施配置原生遵循配置即代码。
- 利用配置中心UI展示业务配置，所见即所得。没有复写。
- 基础设施配置即代码即为唯一可信源，方便公司可以统一管理。
- 基础设施参数与业务配置完全隔离。
- 区域业务配置中心为该区域唯一可信源，方便该区域统一管理。
- 区域业务配置可以直接利用配置中心UI维护配置简单方便。
劣势
- 业务配置不遵循配置即代码，要求上线前由区域业务人员手工确认配 置。
- 公司无法集中管理业务配置，仅限管理业务配置的默认值。
- 两套配置中心，增加成本和维护复杂度。
结语
虽然文章的最后提出了我们在实际项目中经过筛选和迭代后实操的方案，但这一方案也并没有完美的解决配置即代码的鸡生蛋蛋生鸡的问题。反而相比于方案二，迭代方案在业务配置上对配置即代码的管理方式做出了让步，从而去除了强制业务使用代码管理配置的门槛。
方案一是认定先有鸡（配置中心），而对第一只鸡从哪里来做出了让步（手工创建）。方案二则推崇绝对的现有蛋（代码），放弃了鸡生蛋的循环，只能通过修改蛋产生变化。最终的方案，融合两者，在需要绝对控制而不易变化的基础设施配置上使用方案二保证自动化，而在需要便捷和变化的业务配置上使用方案一保证可用性。
做出让步可能是现阶段让我们走出鸡生蛋蛋生鸡这个死胡同的最好的办法，而做出什么让步，则取决于项目的价值优先级。最重要的，是利用DevOps的理念，在不引入新的痛点的基础上，最大限度的解决我们现有的痛点。
