让我们考虑一种情况，即多个服务在可以随时更改的数据上进行中继，并且应该在每个微服务中大致同时更新 - 例如，有一个支持的语言列表或一些常见的策略可能会改变一天并立即影响许多服务。
我能想到的一个解决方案是让另一个可以容纳数据的微服务和任何需要当前状态的服务都可以请求它。缺点是这些数据并没有经常变化，通过HTTP询问并不便宜，而且这种流量有很多流量可以说是全球注册服务。由于它不经常变化，许多服务可以只缓存数据 - 为了不每次都要求它 - 并且在对配置进行更改时无法足够快地响应变化。
另一个解决方案可能是外部化此类配置 - 例如，在AWS中，S3上可能存在一些可供其他人使用的配置文件。这里的缺点是，没有办法（据我所知）跟踪此类文件中的更改，如果配置中的更改值正确（没有拼写错误等），则无法添加一些逻辑进行验证，等
所以我的问题是如何在微服务世界中处理全局配置/注册表，以便几乎没有HTTP开销，您可以审计更改以及在许多服务中同时引入更改？
答案 0 :(得分：2)
我更喜欢选项1.除了HTTP开销之外，这还会导致系统处于不一致状态。服务1可能正在处理新值，但服务2将处于旧状态。
由于这是我们正在谈论的分布式系统，我愿意承担可用性风险。
拥有允许您规划配置更改的配置服务。不是说将A的值从x改变为y，而是说在时间t从x到y的变化。这可以让您始终如一地将更改传播到您的所有系统。您需要努力了解t的最小值对于您的服务集，您将如何使所有服务确认更改并使其在右侧时间以及如何管理两者之间出现的新服务。
另一种方法是使用Spring Cloud Config（或类似的东西）。它要求服务注册集中配置服务并对所有服务进行刷新调用以更新配置。限制不是所有配置都可以刷新，如果你在LB后面，你仍然需要处理方法来确保所有实例都得到更新。
答案 1 :(得分：0)
使用Config Server（spring cloud配置服务器）将维护集中配置，你需要对配置相关的配置服务器进行更改，每个微服务都会启动配置到配置服务器，即使在启动后经过一定的间隔后也是如此。时间微服务可以来配置服务器验证配置的任何变化并相应地更新。
答案 2 :(得分：0)
有两种方法可以做到，特别是在生产中，更好的方法是使用外部配置存储模式。
您可以将配置保存在外部存储中，例如Azure Key Vault或Azure App配置
在此处查找有关Azure密钥库的更多详细信息：