我有一個8內部互相呼叫的彈簧微服務。調用其他微服務的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代理在內的整個服務器結構？
這不一定是正確的。部署（藍綠色或金絲雀，不管你的部署策略是什麼）應該是transparent它的消費者（在你的情況下，其他7個微服務）。這意味着，其他服務交互的服務DNS名稱（或IP）應該保持不變。恕我直言，在微服務部署的情況下，只要您保留合同的一部分，您就不必考慮生態系統中的其他服務;畢竟這是「微型」服務的重點。正如其他的SOer指出的那樣，如果你不能在不改變其他服務的情況下部署你的微服務，那不是一個微服務，它只是一個討論http的龐然大物。
我建議你閱讀這篇文章 https://www.thoughtworks.com/insights/blog/implementing-blue-green-deployments-aws
我引用此相關的部分
如果您通過負載均衡服務的內容背後，那麼相同的 技術將無法正常工作，因爲您無法將彈性IP與 ELB關聯。在這種情況下，當前藍色環境是EC2 實例池，負載均衡器將請求路由到池中任何健康的 實例。要在同一個 負載均衡器後面執行藍綠色交換機，您需要用包含新版本軟件的一組新的 EC2實例替換整個池。有兩種方法可以實現這一點 - 自動執行一系列API調用或使用AutoScaling組。
有喜歡使用Route53
反而露出彈性IP地址或長時間ELB主機名到您的 用戶這也
DNS重定向其他廣告方式，你可以有一個域名所有您公開的網址。 在AWS之外，您可以通過更改 DNS中的CNAME記錄來執行藍綠交換機。在AWS中，您可以使用Route53實現相同的 結果。通過Route53，您可以創建託管區域並定義資源記錄集，以告知域名系統如何爲該域的 路由流量。
要回答其他問題。
但是那麼在application.properties文件中硬編碼 的外部微服務dns怎麼樣呢？
如果你這樣做，我建議你閱讀有關12factor應用;尤其是config部分。如果您還沒有這樣做，您也應該查看服務發現選項。
我有一種感覺，你這裏有什麼是不是微服務的意大利麪條。如果這是一個綠地項目，並且如果您的時間表預算允許的話，我建議您着眼於將您的應用程序及其基礎設施（單個詞：Dockerizing）集中化，並使用任何容器編排技術，如kubernetes，Docker swarm或AWS ECS （最簡單的，假設你已經在AWS-land上），我知道這個問題超出了這個問題的範圍，只是一個建議。
我會建議dockerizing你的微服務（容易與彈簧啓動），然後使用ECS（Elastic Container Service）和ELB（Elastic Load Balancer）與應用程序負載均衡器。 （可以是內部的，也可以是互聯網）。
當您部署新版本時，ECS和ELB會利用您的微服務/health端點。
然後，您可以在spring-boot中實現更復雜的HealthIndicator，以確定應用程序是否健康（並且因此準備好接收輸入請求）。只有當新的應用程序健康時，它纔會投入使用，並且舊的應用程序會進入睡眠狀態。
然後在test environment上測試您的所有業務邏輯，由於Docker在所有環境中都運行完全相同的映像，所以在部署到生產環境時，您不需要運行（任何）測試。 （因爲它已經被測試過了，如果它啓動了，你很好走）。
通常，對於B/G測試，您不會爲新功能使用不同的dns，而是定義規則，例如每100個用戶發送到新功能，或者只有來自特定區域或辦公室的ips才能訪問新功能功能等。
假設您使用的是AWS，您應該能夠在ELB之前爲基於上下文的路由創建ALB，其中您應該能夠定義到B或G的路由的規則。在這種情況下，您必須獨立運行獨立環境（儘管可能使用相同的數據庫）。
對於更復雜的規則，您可以在Spring引導應用程序中使用諸如leanplum或omniture之類的工具。通過這種方法，您可以擁有一個託管新舊功能的單一環境，稍後您將移除過期的代碼。
我個人會使用綠色部署的測試DNS條目進行更簡單的路由，當您完全驗證了您的綠色部署是好的之後，該條目將換爲實況DNS條目。
所以，什麼意思呢：
幽州，你的在線部署具有以下DNS條目：
我建議你創建一個模式，其中每個微服務部署也得到一個測試dns條目：
在部署你的微服務的 「綠色」 版本，您部署的一切（包括ELB）和地圖將ELB的CNAME添加到路由53中的測試DNS條目。這意味着您已準備好了綠色版本，但尚未被您的實時應用程序使用。綠色版本擁有自己的DNS條目，因此您可以在test.a.mydns.com域中運行完整的測試套件。
如果（且僅當）測試套件通過，則將a.mydns.com的CNAME條目交換爲作爲綠色部署的一部分而創建的ELB。這意味着一旦DNS傳播，您的現有微服務就開始與您的綠色部署進行通話。如果出現問題，只需將DNS更新反轉爲舊的CNAME條目即可完全回滾。
它需要一點協調，但您應該能夠通過諸如Jenkins和AWS CLI自動化整個事情。
如果您必須一次替換所有微服務，那麼這意味着您沒有微服務。 –
你爲什麼試圖在生產中測試？你應該有獨立的測試環境。 –
@JakubKania我沒有必要一次部署所有的微服務。可能是1，但部署的微服務對其他微服務有內部調用。此外還有一個測試環境來測試應用程序，但是另外有一個BVT在部署完成後也運行在生產環境中。 – Harshana