我是 Cloud Foundry 的新手。按照 Predix 提供的参考应用程序 ( https://www.predix.io/resources/tutorials/tutorial-details.html?tutorial_id=1473&tag=1610&journey=Connect%20devices%20using%20the%20Reference%20App&resources=1592,1473 ,1600），该应用程序由几个模块组成，每个模块都实现为微服务。
我的问题是，这些微服务如何相互通信？我知道他们必须使用某种 REST 调用，但问题是：
服务注册表：假设我有服务 A、B、C。这些组件如何“发现”其他组件的 REST URL？因为组件 URL 只有在服务推送到 Cloud Foundry 后才知道。
Cloud Foundry 在服务启动和服务关闭时如何控制组件依赖？假设 A 在 B 启动之前无法启动。如果 A 关闭，则 B 需要关闭。
ref-app“应用程序”由几个“应用程序”和 Predix“服务”组成。应用通过 manifest.yml 中的条目绑定到服务。因此，它通过此绑定获取服务端点和其他重要的配置信息。当应用程序绑定到服务时，“cf env”命令会返回所需的信息。
属性文件中可能仍有一些服务端点信息，但随着时间的推移，这些信息将被重构。
ref-app 应用程序的各个应用程序被放置在单独的微服务中，因为它们被用作其他应用程序的组件。因此，微服务方法。如果应用程序之间存在启动依赖项，则将应用程序推送到云的 CI/CD 管道将需要管理这些依赖项。ref-app 中的依赖项只是显而易见的，请阅读。
虽然微服务的耦合确实不在设计中。有一些明显的原因可能会发生这种情况。语言和功能。如果您有一个用 Java 编写的“后端”微服务，该微服务由一个在 NodeJS 上用 Javascript 编写的“前端”UI 微服务使用，那么这些微服务将作为两个单独的应用程序推送。从理论上讲，如果没有后端，UI 将无法很好地工作，但有计划通过一些罐装 JSON 来实现这一点。那里仍然存在一些逻辑耦合。
您从微服务中获得的好处是它们可能需要以不同的方式进行扩展，而 Cloud Foundry 使用“cf scale”命令使这变得非常容易。它们可能被多个其他微服务使用，因此产生了新的规模要求。因此，考虑需要扩展的内容以及功能的发布周期有助于确定微服务的组成部分。
至于排序，例如，您的应用程序可能需要 Google Maps api，因此可以说它应该首先启动，然后是您的应用程序。但实际上，您的应用程序应该考虑到地图 API 可能已关闭。您的目标应该是当依赖的微服务不可用时，您的应用程序表现良好。
“应用程序”的“应用程序”由于它们的名称和云提供的 URL 而了解每个应用程序。实际上有许多参考应用程序的副本在各种云和空间中运行。它们以 Dev 或 QA 或 Integration 等内容开头。我们能否让 Dev 前端与 QA 后端微服务对话，当然，它只是一个 URL。
除了前面提到的 etcd（我还没有尝试过），您还可以创建 CUPS 服务“定义”。这也是一组键/值对。您可以将其绑定到空间 (dev/qa/stage/prod) 并通过清单绑定它们。这样你就可以从环境中获得道具。
如果微服务确实需要相互通信，通常是通过 REST，正如您所注意到的。但是，微服务纯粹主义者可能会反对这种依赖关系。除此之外，通过将可用端点发布到服务注册表来启用服务发现 -在 CloudFoundry 的情况下为etcd。注册端点后，给定服务的各种实例可以使用 POST 操作将自己注册到注册表。客户端将只需要了解已发布的端点，而不是单个服务实例的端点。这是自注册。客户端将与负载均衡器（例如 ELB）进行通信，后者会查找服务注册表，或者客户端应该知道服务注册表。
对于（2），根据微服务定义，如果一个人正在设计这样一组耦合的服务，表明一些迫在眉睫的问题，例如编排和同步，那么微服务之间不应该存在如此硬的依赖关系。如果确实出现了这种依赖关系，您将不得不依赖服务注册表、健康检查和断路器来进行回退。