让我们考虑一种情况，其中多个服务中继可以随时更改的数据，并且应该在每个微服务中大致同时更新 - 例如，有一个受支持的语言列表或一些可能有一天会更改并影响许多的公共(public)策略一次服务。
我能想到的一个解决方案是拥有另一个可以保存该数据的微服务，任何需要当前状态的服务都可以直接请求它。缺点是这些数据变化不是很频繁，通过 HTTP 请求并不便宜，而且有很多流量，比如说全局注册服务。由于它不经常更改，许多服务可能只是缓存数据 - 以免每次都要求它 - 并且在对配置进行更改时无法足够快地响应更改。
另一种解决方案可能是将此类配置外部化——例如，在 AWS 中，S3 上可能有一些配置文件可供其他人使用。这里的缺点是无法(据我所知)跟踪此类文件中的更改，并且无法添加一些逻辑来验证配置中更改的值是否正确(没有拼写错误等)，等等。
所以我的问题是如何在微服务世界中处理全局配置/注册，以便几乎没有 HTTP 开销，您可以审计更改以及在许多服务中同时引入更改？
最佳答案
我更喜欢选项 1。除了 HTTP 开销之外，这也会导致您的系统处于不一致的状态。服务 1 可能正在处理新值，但服务 2 将使用旧值。
由于这是我们正在谈论的分布式系统，因此我愿意承担可用性的风险。
拥有允许您计划配置更改的配置服务。与其说将 A 的值从 x 更改为 y，不如说在时间 t 从 x 更改为 y。这 t 允许您一致地将更改传播到您的所有系统。您需要努力了解 t 的最小值对于您的服务集应该是多少，您将如何让所有服务确认更改并使其正确时间以及您将如何管理中间出现的新服务。
另一种方法是使用 Spring Cloud Config(或类似的东西)。它要求服务向集中配置服务注册，并对所有服务进行刷新调用以更新配置。限制是并非所有配置都可以刷新，如果您在 LB 后面，您仍然需要处理确保所有实例都得到更新的方法。
关于microservices - 如何处理微服务架构中的常见变量？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48961984/