我是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）中，應用程序由多個模塊組成，並且每個模塊都實現爲微服務。Cloud Foundry中的微服務如何通信？
我的問題是，這些微服務如何相互交談？我明白他們必須使用某種REST調用的，但問題是：
服務註冊表：說我有服務A，B，C如何這些組件「發現」其他組件的REST網址嗎？由於只有在將服務推送到雲代工後才知道組件URL。
雲代工廠如何在服務啓動和服務關閉期間控制組件依賴關係？在B開始之前說A不能開始。如果A關閉，B需要關閉。
如果微服務確實需要互相交談，通常其通過REST你有noticed.However的microService純粹主義者可能對這種依賴關係。除此之外，通過將可用端點發布到服務註冊表來啓用服務發現 - CloudFoundry的情況下爲etcd。一旦註冊了端點，給定服務的各種實例就可以使用POST操作向註冊中心註冊自己。客戶只需要知道已發佈的終點而不是單個服務實例的終點。這是self-registration.客戶端將與負載均衡器（如ELB）進行通信，該負載均衡器查找服務註冊表或客戶端應該知道服務註冊表。對於（2），如果微服務定義中設置了這樣一組耦合的服務，以表明諸如編排和同步等一些即將發生的問題，則對於（2），微服務之間不應該存在如此微弱的依賴關係。如果確實出現這種依賴關係，那麼您將需要依靠服務註冊管理機構，健康檢查和斷路器進行回退。
ref-app'application'由幾個'apps'和Predix'services'組成。應用程序通過manifest.yml中的條目綁定到服務。因此，它通過該綁定獲取服務端點和其他重要的配置信息。當應用綁定到服務時，'cf env'命令返回所需的信息。
屬性文件中可能仍然存在一些Service端點信息，但這會隨着時間的推移重構。
ref-app應用程序的各個應用程序被放在單獨的微服務中，因爲它們被用作其他應用程序的組件。因此，微服務方法。如果跨應用程序存在啓動依賴性，將應用程序推送到雲的CI/CD管道將需要管理這些依賴關係。 ref-app中的依賴關係只是顯而易見的，可以繼續閱讀。
確實，微服務的耦合不在設計中。這可能會發生一些明顯的原因。語言和功能。如果你有一個用Java編寫的「前端」UI微服務所使用的「後端」微服務，那麼這些服務將作爲兩個獨立的應用程序推送。理論上說，如果沒有後端，用戶界面將無法工作得太好，但是有一個計劃可以讓一些罐裝JSON實現這一點。仍然有一些邏輯耦合。
從微服務中獲得的好處是，它們可能需要不同的縮放比例，而云代工廠通過'cf scale'命令可以非常容易地實現。它們可能會被多個其他微服務使用，從而創造新的規模需求。因此，考慮需要擴展的功能以及功能的發佈週期有助於確定包含微服務的內容。
至於訂購，例如，Google Maps API可能是您的應用程序需要的，因此可以說它應該首先啓動，而您的應用程序則應該是第二個。但實際上，你的應用程序應該考慮到map api可能會下降。您的目標應該是您的應用程序在從屬的微服務不可用時表現良好。
「應用程序」的'應用程序'通過它們的名稱和雲提供的URL來了解每個應用程序。實際上有很多參考應用程序在各種雲和空間中運行。他們的開頭是Dev，QA或Integration等等。我們可以讓Dev前端與QA後端微服務交談，當然，這只是一個URL。
除了前面提到的etcd（我還沒有嘗試過），您還可以創建一個CUPS服務的「定義」。這也是一組鍵/值對。你可以綁定到Space（dev/qa/stage/prod）並通過清單綁定它們。這樣你就可以從環境中獲得道具。