我是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。这些组件如何发现＆＃39;其他组件的REST URL？由于组件URL仅在将服务推送到云代工厂后才知道。
云代工厂如何在服务启动和服务关闭期间控制组件依赖性？说A在B启动之前无法启动。如果A关闭，则需要关闭B.
答案 0 :(得分：3)
ref-app＆＃39;应用程序＆＃39;由几个应用程序组成＆＃39;和Predix＆＃39;服务＆＃39;。应用程序通过manifest.yml中的条目绑定到服务。因此，它通过此绑定获取服务端点和其他重要配置信息。当应用程序绑定到某个服务时，＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;命令返回所需的信息。
属性文件中可能仍然存在一些服务端点信息，但这些信息会随着时间的推移而被重构。
ref-app应用程序的各个应用程序放在单独的微服务中，因为它们被用作其他应用程序的组件。因此，微服务方法。如果跨应用程序存在启动依赖关系，则将应用程序推送到云的CI / CD管道将需要管理这些依赖关系。 ref-app中的依赖项只是显而易见的，请继续阅读。
虽然微服务的耦合不在设计中，但确实如此。这可能会发生一些明显的原因。语言和功能。如果你有一个＆＃34;后端＆＃34;用#E;前端＆＃34;使用的用Java编写的微服务。在NodeJS上使用Javascript编写的UI微服务然后将它们作为两个单独的应用程序推送。理论上，如果没有后端，UI将无法正常工作，但有一个计划可以通过一些罐装JSON实现这一点。那里仍有一些逻辑耦合。
您从微服务中获得的好处是，他们可能需要进行不同的扩展，而云代工厂可以通过＆＃c; cf scale＆＃39;命令。它们可能被多个其他微服务使用，因此产生了新的规模要求。因此，考虑需要扩展的内容以及功能的发布周期有助于确定构成微服务的内容。
至于订购，例如，您的应用程序可能需要Google Maps api，因此可以说应该首先启动它，然后再推出您的应用程序。但实际上，您的应用程序应该考虑到地图api可能已关闭。您的目标应该是当依赖微服务不可用时，您的应用程序表现良好。
＆＃39;应用＆＃39;的应用程序＆＃39;由于他们的名字和云给它的URL而知道每一个。实际上有很多参考应用程序在各种云和空间中运行。他们的前言是Dev或QA或Integration等。我们可以让Dev前端与QA后端微服务交谈，当然，它只是一个URL。
除了前面提到的etd（我还没有尝试过），你还可以创建一个CUPS服务＆＃39;定义＆＃39;。这也是一组键/值对。您可以绑定到Space（dev / qa / stage / prod）并通过清单绑定它们。这样你就可以从环境中获得道具。
答案 1 :(得分：1)
如果微服务确实需要相互通信，通常是通过REST注意到的。但是微服务纯粹主义者可能会反对这种依赖。除此之外，通过将可用端点发布到服务注册表来启用服务发现 - 如果是CloudFoundry，则etcd。一旦注册了端点，给定服务的各种实例就可以使用POST操作将自己注册到注册表。客户只需知道已发布的终点而不是单个服务实例的终点。这是self-registration.客户端将与负载均衡器（如ELB）进行通信，后者会查找服务注册表或客户端应该知道服务注册表。
对于（2），如果设计这样一组指示一些即将出现的问题（例如编排和同步）的耦合服务，则微服务定义之间不应存在这种硬依赖关系。如果出现这种依赖关系，您将依赖服务注册管理机构，健康检查和断路器进行后备。