在微服务架构中，我很难掌握如何管理特定于环境的配置（例如，数据库或消息代理的IP地址和凭据）。
假设您有三个微服务（“A”，“B”和“C”），每个服务由不同的团队拥有和维护。每个团队都需要一个团队集成环境......他们使用微服务的最新快照，以及所有依赖微服务的稳定版本。当然，您还需要QA /登台/制作环境。大图的简化视图如下所示：
“微服务A”团队环境
- 微服务A（ SNAPSHOT ）
- 微服务B（稳定）
- 微服务C（STABLE）
“微服务B”团队环境
- 微服务A（稳定）
- 微服务B（ SNAPSHOT ）
- 微服务C（STABLE）
“微服务C”团队环境
- 微服务A（稳定）
- 微服务B（稳定）
- 微服务C（ SNAPSHOT ）
质量保证/分期/制作
- 微服务A（稳定，释放等）
- 微服务B（稳定，释放等）
- 微服务C（稳定，释放等）
这是很多部署，但这个问题可以通过持续集成服务器解决，也可能像Chef / Puppet等。 真的 困难的部分是每个微服务都需要一些特定于其部署的每个地方的环境数据。
例如，在“A”团队环境中，“A”需要一个地址和一组凭据才能与“B”进行交互。但是，在“B”团队环境中， 部署“A”需要不同的地址和凭据才能与 部署“B”进行交互。
此外，随着您越来越接近生产，像这样的环境配置信息可能需要安全限制（即只有某些人能够修改甚至查看它）。
那么，使用微服务架构，如何维护特定于环境的配置信息并使其可供应用程序使用？我想到了一些方法，尽管它们似乎都有问题：
- 让构建服务器在构建时将它们烘焙到应用程序中 - 我想您可以创建每个环境属性文件或脚本的存储库，并让每个微服务的构建过程都能实现并拉入相应的脚本（您还可以为生产资料提供单独的，有限访问的回购）。但是，你需要一个 ton 的脚本。对于可以部署微服务的每个地方的每个微服务，基本上都是单独的。
- 将它们烘焙到每个环境的基础Docker镜像中 - 如果构建服务器将您的微服务应用程序放入Docker容器中作为构建过程的最后一步，那么您可以为每个环境创建自定义基本映像环境。基本映像将包含一个shell脚本，用于设置所需的所有环境变量。您的Dockerfile将设置为在启动应用程序之前调用此脚本。这与上一个要点有类似的挑战，因为现在你正在管理大量的Docker镜像。
- 在运行时从某种注册表中提取环境信息 - 最后，您可以将每个环境的配置存储在Apache ZooKeeper（甚至只是一个普通的数据库）之类的内容中，并且让你的应用程序代码在启动时在运行时将其拉入。每个微服务应用程序都需要一种方法来告知它所处的环境（例如启动参数），以便它知道从注册表中获取哪组变量。这种方法的优点是，现在您可以从团队环境到生产一直使用完全相同的构建工件（即应用程序或Docker容器）。另一方面，您现在将拥有另一个运行时依赖项，并且您仍然必须管理注册表中的所有数据。
人们如何在微服务架构中解决这个问题？看来这听起来很常见。