如何处理微服务架构中的公共变量？答案

【问题标题】：How to handle common variables in microservices architecture?如何处理微服务架构中的公共变量？
【发布时间】：2021-12-13 06:50:50
【问题描述】：

让我们考虑一种情况，多个服务中继的数据可以随时更改，并且应该在每个微服务中大致同时更新 - 例如，有一个支持的语言列表或一些可能在一天内更改的通用政策并同时影响许多服务。

我能想到的一个解决方案是拥有另一个可以保存该数据的微服务，并且任何需要当前状态的服务都可以请求它。缺点是这些数据的变化不是很频繁，通过 HTTP 请求并不便宜，并且有很多流量到这个假设是全局注册服务。由于它不经常更改，因此许多服务可能只是缓存数据 - 为了不每次都请求它 - 并且在对配置进行更改时无法足够快地响应更改。

另一种解决方案可能是将此类配置外部化 - 例如，在 AWS 中，S3 上可能有一些配置文件可供其他人使用。这里的缺点是（据我所知）无法跟踪此类文件中的更改，并且如果配置中的更改值正确（没有拼写错误等），也无法添加一些逻辑进行验证，等等

所以我的问题是如何处理微服务世界中的全局配置/注册表，以便几乎没有 HTTP 开销，您可以审计更改以及在许多服务中同时引入更改？

【问题讨论】：

我也遇到了这个问题。我的案例是在多个项目或微服务之间共享一些常见的constants 或config。我的选择： 1. 将此通用模块发布到npm 注册表。 2. 由于使用 GCP，请考虑将这些常量或配置存储到 Datastore 或 metadata。但我不知道哪种方式更好。

标签： microservices

【解决方案1】：

我更喜欢选项 1。除了 HTTP 开销之外，这还会导致您的系统处于不一致的状态。服务 1 可能正在使用新值，但服务 2 将使用旧值。

由于这是我们正在谈论的分布式系统，我愿意冒可用性的风险。

拥有允许您计划配置更改的配置服务。不是说将 A 的值从 x 更改为 y，而是说在时间 t 从 x 更改为 y。这 t 允许您始终如一地将更改传播到您的所有系统。您需要努力了解 t 的最小值对于您的服务集应该是什么，您将如何让所有服务确认更改并使其正确时间以及您将如何管理介于两者之间的新服务。

另一种方法是使用 Spring Cloud Config（或类似的东西）。它要求服务向集中配置服务注册，并对所有服务进行刷新调用以更新配置。限制不是所有配置都可以刷新，如果您落后于 LB，您仍然需要处理确保所有实例都得到更新的方法。

【讨论】：

配置服务可以有一个获取 API 来请求在特定时间有效的配置，而不是显式地将更改传播到其他服务（比如未来一个小时），并让它返回一个生存时间。然后，客户端服务实例可以管理自己的缓存并暂存配置更改，而无需配置服务明确了解它们。
“我愿意为可用性冒险”是什么意思？您正在引入依赖关系和单点故障，“所有”其他微服务现在都必须依赖，这会给您的架构带来脆弱性。具有高度弹性的集中式键值存储具有 HTTP 接口（例如 Consul、etcd），可以让您免去头痛。
那是关于 CAP 的，我在那里选择了一致性和分区。同意我们有集中的密钥存储，但要么你必须继续从 etcd 读取值，要么需要通知服务来更新这些配置的机制在内存中，这就是我所说的这项服务应该做的。

【解决方案2】：

使用 Config Server(spring cloud config server) 会维护集中配置，你需要对配置相关的配置服务器进行更改，每个微服务都会在启动时配置到配置服务器，即使在一定间隔后启动微服务可以到配置服务器来验证配置的任何更改并进行相应的更新。

【讨论】：

感谢您的意见。据我所知，Spring Cloud Config 在基于 Spring 的应用程序上运行。我们应该假设服务可以在 nodejs 或 Scala 上，所以我不太确定这是否会有所帮助。如果我错了，你能纠正我吗？
spring-cloud-config 服务器提供属性以响应定义明确的 REST 调用。 nodejs 可以进行 REST 调用...我们通过使用多个活动的 spring 配置文件来部署带有自定义后端（Web 服务器）的 cloud-config-server 来支持共享和特定于应用程序的属性文件，从而实现了这一点。

【解决方案3】：

有几种方法可以做到这一点，特别是在 prod 中更好的方法是使用外部配置存储模式。

您可以将配置保存在 Azure Key Vault 或 Azure 应用配置等外部存储中

在此处查找有关 Azure 密钥保管库的更多详细信息：

Azure key vault

5-Minute quickstarts of Azure key vault integration

【讨论】：

【解决方案4】：

如果你绝对必须有一个共享配置，我遇到的最好的解耦架构如下：

您有一个独立的配置服务，对外部世界完全私有，只能通过内部网络访问您的微服务
ON STARTUP：微服务从 Config Service 请求每个服务所需的内容并存储在内存中。如果它无法从配置服务中提取，则不允许它启动。在这方面有重试机制。
配置服务的ON CHANGE：向您的消息传递层发布一个事件，该事件将强制服务更新其各自的配置。

注意事项：

不要在此处放置时间敏感配置，因为我们在此处使用异步通信（如果您有时间关键配置，为什么首先要共享它们，您可能需要重新访问）
您需要处理自己的管道、重试机制、内存管理等。

【讨论】：