clo*_*jur 7 architecture configuration docker-secrets
为了好玩,我正在使用微服务架构设计一些Web应用程序.我正在尝试确定进行配置管理的最佳方法,我担心我的配置方法可能会有一些巨大的陷阱和/或更好的存在.
为了解决这个问题,假设我有一个用c ++编写的身份验证服务,用rust写的身份服务,用haskell编写的分析服务,用scala编写的一些middletier,以及用javascript编写的前端.还有相应的身份DB,auth DB,分析数据库,(可能是会话的redis缓存)等...我正在使用docker swarm部署所有这些应用程序.
每当部署其中一个应用程序时,它必须发现所有其他应用程序.由于我使用的是docker swarm,因此只要所有节点共享必需的覆盖网络,发现就不是问题.
但是,每个应用程序仍然需要上游服务host_addr,可能是端口,某些数据库或密封服务的凭据等...
我知道docker secrets可以让应用程序从容器中读取配置,但是我需要为每个服务用每种语言编写一些配置解析器.这看起来很乱.
我宁愿做的是拥有一个configuration service,它维护着如何配置所有其他服务的知识.因此,每个应用程序都会从一些RPC调用开始,这些调用旨在在运行时获取应用程序的配置.就像是
int main() {
AppConfig cfg = configClient.getConfiguration("APP_NAME");
// do application things... and pass around cfg
return 0;
}
AppConfig将在IDL中定义,因此该类将立即可用且与语言无关.
这似乎是一个很好的解决方案,但也许我真的错过了这里的重点.即使在规模上,一些配置服务也可以轻松地提供数万个节点,因此我不会预见到任何扩展问题.再一次,它只是一个爱好项目,但我喜欢考虑"假设"场景:)
如何在微服务架构中处理配置方案？这看起来像是一种合理的方法吗？Facebook,谷歌,LinkedIn,AWS等主要参与者都做了什么？
我不会构建自定义配置管理解决方案，而是使用以下现有解决方案之一：
Spring Cloud Config是一个用 Java 编写的配置服务器，提供 HTTP API 来检索应用程序的配置参数。显然，它附带了一个 Java 客户端和一个很好的 Spring 集成，但由于服务器只是一个 HTTP API，因此您可以将它与任何您喜欢的语言一起使用。配置服务器还具有配置值的对称/非对称加密功能。
配置源：外部化配置存储在 GIT 存储库中，Spring Cloud Config 服务器必须可以访问该存储库。然后可以通过 HTTP API 访问该存储库中的属性，因此您甚至可以考虑实施配置属性的更新过程。
服务器位置：理想情况下，您可以通过域（例如）访问您的配置服务器config.myapp.io，以便您可以根据需要实现负载平衡和故障转移方案。此外，您需要向所有服务提供的只是该确切位置（以及一些身份验证/解密信息）。
入门：您可以查看Spring 文档上的集中配置入门指南，或阅读Spring Cloud Config 快速介绍。
Netflix Archaius是 Netflix OSS 堆栈的一部分，“是一个 Java 库，提供 API 来访问和利用可以在运行时动态更改的属性”。虽然仅限于 Java（与您所要求的上下文不太匹配），但该库能够使用数据库作为配置属性的源。
confd使用外部源（etcd、consul、dynamodb、redis、vault 等）中存储的数据使本地配置文件保持最新。配置更改后，confd 会重新启动应用程序，以便它可以获取更新的配置文件。
在您的问题的上下文中，这可能值得尝试，因为 confd 不对应用程序做出任何假设，并且不需要特殊的客户端代码。大多数语言和框架都支持基于文件的配置，因此 confd 应该很容易添加到当前使用环境变量并且不预期分散配置管理的现有微服务之上。