聊
随着《云原生》的学习，我计划同步开启一项开源项目，来将所学实践到项目中去，先简单介绍一下CNAdmin，全称Cloud Native Admin，云原生后台管理系统，后端使用SpringBoot 2.3.0 ，并且尽可能少的加载其他依赖。
目的是重点体现出SpringBoot 对云原生的构建，业务方面我借鉴了几个admin类的项目，后续只做简单功能实现，所以这不是一个功能全面的后台管理系统，开发期间所有代码不涉及任何开源协议。
只看不练恐怕真正用起来的时候还是会遇到很多坑，就比如这个项目，虽然已经创建过很多次了，但在构建过程中还是会遇到各式各样的小坑，话不多说开整。
记
十二要素程序中的配置要求
程序的代码应与配置严格分开。
程序的配置应由各自环境管理。
所依赖服务的信息应存储为环境变量，易于修改，无须部署配置文件。
应用程序在环境之间的任何差异，都认为是一种环境配置，应存储在环境中。
根据上述要求，以SpringBoot项目为例，第一点比较容易而且大多数项目已经这么实践了，例如查看一下自己的项目是否都有一个resource文件夹，并且分别存有dev、test、prod等环境配置。
这就是做到了代码与配置分开并且区分了不同环境的配置，但仍然不满足十二要素的2、3、4条（后续会详细说明），在看看不符合的例子，是否代码中有将mysql、redis、oss又或者某openapi的key硬编码到了代码中。
如果有这些都是不利于管理和维护的。比如说，要更换一个简单的配置，必须重新提交代码，打包，发布。
开篇的两个小例子估计大多数人都会经常在项目中遇到过。我们现在讨论一下第二点【程序的配置应由各自环境管理】，还是先举一个常见的例子，接着图一的模式举例，像这种区分环境运行的配置，虽然可以在不同的环境指定不同的启动参数来控制加载不同的环境配置，但同样会遇到类似于这样的问题，你是否在项目中遇到过开发一个新功能，在开发环境增添了配置项而忘记在测试或预发布甚至生产环境中忘记配置，亦或者有几个特殊的参数只有开发环境用到而其他环境缺不必使用，即时代码和配置已经做了分开处理，同样也会导致一些因环境差异或者配置不同而产生的故障。而解决此类故障，还是要重新修改代码配置，提交，审核，打包，发布。
再来看一下应如何理解配置应由各自环境管理，其目的是让程序本身一次编译，来保障不同环境下运行的是同一套程序，不会因为环境不同而无法复现某个bug或其他差异。这么做还有一个好处是当环境自己管理配置时，可以更安全的保护资源的配置，假设代码意外泄漏，配置文件中的明文密码等信息，改为了变量，而真正有效的信息却放在了环境中管理。再或者你是否碰到过一套产品，部署给不同的客户，都是生产环境，因为客户不同，所以配置信息也不一样，但需要频繁修改配置，打包，上传，部署
