如何在多个部署环境中管理微服务架构中的配置文件？

Question

我正在寻找一种使用微服务架构（.NET Core）管理大型系统中多个模块的配置文件的方法。

目前我们有 5 个模块并且还在增加。每个模块包含 2 个项目（例如 UI 和 API）。每个项目对于 Dev、Staging、Production 3 个环境都有不同的配置。

5 个模块 x 2 个项目 x 3 个环境 = 30 个配置文件。

许多项目需要在所有开发环境中逐字重复相同的配置值（例如，共享包需要配置）。

大多数时候，每个项目和环境都需要相同的配置，但有时它会有所不同，有时它完全是特定于项目的。

这只会变得更糟。更多模块将被添加，配置文件将变得更大。我正在考虑的一个解决方案是编写一个脚本，根据主配置文件在所有配置文件中进行查找和替换，该主配置文件具有所有项目和环境的所有值。

但即使这看起来也令人畏惧，因为我还不确定如何布局主配置文件或明确哪些配置键属于哪些项目。

这变得非常难以管理，我想知道是否有人有一个好的流程来管理这个问题？

Answer 1

Common configuration is anathema in microservices architecture. The entire point is that they're suppose to be discrete, self-contained units of functionality. If one or more are doing the same thing(s), then you haven't properly subdivided your domain.

The one exception to this is instrumentation: logging, profiling, tracing, etc. If that is what you're talking about here, then there's a number of ways you can handle it.

1. You can have a separate configuration source for your instrumentation, which doesn't even need to be local to the project. For example, you can create a file like instrumentation.json, put it in a common shared location, and then in Program.cs:

   CreateDefaultWebBuilder()
       ConfigureAppConfiguration(builderContext, config) =>
       {
           config.AddJsonFile(@"\\path\to\instrumentation.json", optional: false, reloadOnChange: true)
        })
        .Run();
   

   You can even have environment specific JSON for the instrumentation:

   IHostingEnvironment env = builderContext.HostingEnvironment;
   config.AddJsonFile($@"\\path\to\instrumentation.{env.EnvironmentName}.json", optional: true, reloadOnChange: true)
   

2. Docker has its own configuration/secrets setup, which you can use to set environment variables or basically however you want to provide it to the app. See: https://docs.docker.com/engine/swarm/secrets/

3. You can use an distributed configuration source like Azure Key Vault. If you don't want to use that specifically, something like SQL Server or Redis would work just as well, but you'd have to either create custom configuration providers for those or source existing third-party libraries.