让我们考虑一种情况,其中多个服务依赖的数据可以随时更改,并且应该在每个微服务中大致同时更新 - 例如,有一个受支持的语言列表或一些通用策略可能有一天会更改并影响许多人立即服务。
我能想到的一个解决方案是拥有另一个可以保存该数据的微服务,并且任何需要当前状态的服务都可以请求它。缺点是这些数据变化不是很频繁,通过 HTTP 请求并不便宜,而且这个比方说全局注册表服务有很多流量。由于它不经常更改,因此许多服务可能只是缓存数据(以便不必每次都请求数据),并且在配置更改时无法足够快地响应更改。
另一种解决方案可能是将此类配置外部化 - 例如,在 AWS 中,S3 上可能有一些可供其他人使用的配置文件。这里的缺点是(据我所知)无法跟踪此类文件中的更改,并且无法添加一些逻辑来验证配置中更改的值是否正确(没有拼写错误等), ETC。
所以我的问题是如何在微服务世界中处理全局配置/注册表,以便几乎没有 HTTP 开销,您可以在许多服务中审核更改并同时引入更改?
我更喜欢选项 1。除了 HTTP 开销之外,这还会导致您的系统处于不一致的状态。服务 1 可能会使用新值,但服务 2 将使用旧值。
由于这是我们正在讨论的分布式系统,因此我愿意冒可用性的风险。
拥有允许您计划配置更改的配置服务。你不是说将 A 的值从 x 更改为 y,而是说在时间 t 从 x 更改为 y。这允许您将更改一致地传播到您的所有系统。您需要努力了解您的服务集的 t 最小值应该是多少,如何使所有服务承认更改并使它们处于正确的位置时间以及您将如何管理其间出现的新服务。
另一种方法是使用 Spring Cloud Config (或类似的东西)。它要求服务向集中配置服务注册,并对所有服务进行刷新调用以更新配置。限制是并非所有配置都可以刷新,如果您位于负载均衡器后面,您仍然需要采取一些方法来确保所有实例都得到更新。
| 归档时间: |
|
| 查看次数: |
4144 次 |
| 最近记录: |