我有 8 个 Spring Boot 微服务，它们在内部相互调用。其他微服务的调用dns，定义在每个服务的application.properties文件中。
假设，微服务 A 由 A -> a.mydns.com 和 B-> b.mydns.com 等表示
所以基本上每个微服务都包含一个 ELB 和两个 HA 代理（分布在两个区域中）和 4 个应用服务器（分布在两个区域中）。
目前我正在创建新的绿色服务器（仅限应用程序服务器）并从 HA 代理级别切换实时流量。在这种情况下，当新版本的微服务正在测试时，它也会暴露给实时客户。
理想情况下，方法应该是为每个微服务创建整个服务器结构，包括 ELB 和 HA 代理，对吗？
但是，我怎么会面临使用测试 dns 进行测试的挑战。我可以将 ELB 映射到测试 dns。但是，在 application.properties 文件中硬编码的外部微服务 dns 呢？
在这种情况下我应该采取什么方法？
理想情况下，方法应该是为每个微服务创建整个服务器结构，包括 ELB 和 HA 代理，对吗？
这不一定是真的。部署（蓝绿色或金丝雀，无论您的部署策略是什么）应该对其消费者（在您的情况下为其他 7 个微服务）透明。这意味着，与其他服务交互的服务 DNS 名称（或 IP）应该保持不变。恕我直言，在微服务部署的情况下，只要您遵守合同的一部分，您就不必考虑生态系统中的其他服务；毕竟这就是“微”服务的全部意义所在。正如其他 SOer 指出的那样，如果您不能在不更改其他服务的情况下部署您的一个微服务，那么这不是微服务，它只是一个通过 http 进行通信的单体。
我建议您阅读这篇文章 https://www.thoughtworks.com/insights/blog/implementing-blue-green-deployments-aws
我在这里引用相关部分
如果您通过负载均衡器提供内容，那么相同的技术将不起作用，因为您无法将弹性 IP 与 ELB 相关联。在这种情况下，当前的蓝色环境是一个 EC2 实例池，负载均衡器会将请求路由到池中任何健康的实例。要在同一负载均衡器后面执行蓝绿切换，您需要将整个池替换为包含新版本软件的一组新 EC2 实例。有两种方法可以做到这一点——自动执行一系列 API 调用或使用 AutoScaling 组。
还有其他类似的创意方式
您可以为所有面向公众的 URL 提供一个域名，而不是向您的用户公开弹性 IP 地址或长 ELB 主机名。在 AWS 之外，您可以通过更改 DNS 中的 CNAME 记录来执行蓝绿切换。在 AWS 中，您可以使用 Route53 来实现相同的结果。使用 Route53，您可以创建一个托管区域并定义资源记录集，以告知域名系统如何为该域路由流量。
回答其他问题。
但是，在 application.properties 文件中硬编码的外部微服务 dns 呢？
如果您这样做，我建议您阅读有关12factor应用程序；尤其是配置部分。如果您还没有这样做，您也应该看看服务发现选项。
我有一种感觉，你在这里拥有的是不那么微服务的意大利面条。如果它是一个新建项目并且如果您的时间线预算允许，我建议您考虑将您的应用程序连同它的基础设施（一个词：Dockerizing）一起容器化，并使用任何容器编排技术，如 kubernetes、Docker swarm 或 AWS ECS （最简单的是，只要您已经在 AWS 上），我知道这超出了这个问题的范围，只是一个建议。
我个人会走一条更简单的路线，使用绿色部署的测试 DNS 条目，然后在您完全验证绿色部署良好时将其换成实时 DNS 条目。
那么我的意思是：
您声明您的实时部署具有以下 DNS 条目：
我建议您创建一个模式，其中每个微服务部署也获得一个测试 dns 条目：
在部署微服务的“绿色”版本时，您部署所有内容（包括 ELB）并将 ELB 的 CNAME 映射到 Route 53 中的测试 DNS 条目。这意味着您已经准备好使用绿色版本，但还没有由您的实时应用程序使用。绿色版本有它自己的 DNS 条目，因此您可以针对 test.a.mydns.com 域运行完整的测试套件。
如果（且仅当）测试套件通过，您将 a.mydns.com 的 CNAME 条目交换为作为绿色部署的一部分创建的 ELB。这意味着一旦 DNS 传播，您现有的微服务就会开始与您的绿色部署对话。如果出现问题，只需将 DNS 更新反向到旧的 CNAME 条目，您就已完全回滚。
这里需要一点协调，但您应该能够使用 Jenkins 和 AWS CLI 之类的东西来自动化整个事情。
通常对于 B/G 测试，您不会为新功能使用不同的 dns，而是定义规则，例如每 100 个用户发送到新功能，或者只有来自某个区域或办公室的 ips 可以访问新功能等。
假设您使用的是 AWS，您应该能够在 ELB 前面为基于上下文的路由创建一个 ALB，您应该能够在其中定义路由到 B 或 G 的规则。在这种情况下，您必须分离运行的环境独立（尽管可能使用相同的数据库）。
对于更复杂的规则，您可以在 Spring Boot 应用程序中使用诸如leanplum 或omniture 之类的工具。使用这种方法，您将拥有一个托管新旧功能的单一环境，然后您将删除过时的代码。
我建议将您的微服务 docker 化（使用 spring-boot 很容易），然后将 ECS（弹性容器服务）和 ELB（弹性负载均衡器）与应用程序负载均衡器一起使用。（可以是内部的，也可以是面向互联网的）。
然后，ECS 和 ELB/health在您部署新版本时利用您的微服务端点。
然后你可以在 spring-boot 中实现一个更复杂HealthIndicator的，以确定应用程序是否健康（并因此准备好接收传入的请求）。只有当新应用程序健康时，它才会投入使用，而旧应用程序才会进入睡眠状态。
然后在 a 上测试您的所有业务逻辑test environment，并且由于 Docker，您在所有环境中运行完全相同的映像，在部署到生产时您不需要运行（任何）测试。（因为它已经过测试，如果它启动了，你就可以开始了）。