我是相當新的微服務...微服務：服務發現/斷路器事件驅動的架構
我已經採取的興趣更多地瞭解兩個主要模式，如service discovery和circuit breaker我已經對這些如何實施進行了研究。
作爲Java開發人員，我使用Spring Boot。據我所知，如果微服務通過HTTP進行通信，這些模式是有用的。
一個我最近看到的主題是事件驅動的架構的重要性，這使得利用事件消息總線的那個服務將使用將消息發送到其他服務，訂閱總線 和過程消息。
考慮到這種事件驅動的特性，考慮到這些通常適用於通過HTTP進行通信的服務，如何實現/實現服務發現和斷路器？
Spring Boot與Spring Cloud很好地結合在一起。 Spring Cloud提供Eureka（用於服務發現）以及Hystrix（用於斷路器模式）。此外，春季雲流，以便提供事件驅動模式
非常容易使用與Spring引導
從我的理解，如果微服務通過HTTP進行通信，這些模式是有益的。
通信是HTTP並不重要。斷路器對於防止在使用通信方式的架構中更可能發生的級聯故障很有用。 事件驅動體系結構通常是異步因此級聯失敗的可能性較小。
服務發現用於微服務彼此發現，但在事件驅動體系結構中，微服務僅與消息傳遞基礎結構（即事件源中的事件存儲）通信，因此僅可在基礎架構級別使用可發現性。
I. circuit breaker和service discovery是模式。當我們說Pattern時，它們可以用任何編程語言來實現。 'HTTP'協議用於傳輸數據。
circuit breaker可以在Java中實現。您可以在github上找到許多實現（當然，具有不同的功能和模式解釋）。
一些知名的，對目的的實現內置的是：
Hysterix from NetflixOSS對於使用Hysterix：您可以按照春指南 - Spring Circuit Breaker
Apache Polygene - 其中有例如JMX斷路器
二，關於，
鑑於這種事件驅動的本質，如何能服務發現和電路斷路器 實現/實施，因爲這些通常是 適用於通過HTTP通信服務？
看來您需要更多關於微服務交互主題的研究。 微服務交互有兩種可能。你必須選擇一個。你可以/不應該混用兩者。
編排：具有智能控制器，它能將事件過程的交互方式。請注意這裏代表業務流程的'流程'一詞。編排風格在舊的SOA實現中也是首選。
編排：一種交互風格，允許進程訂閱事件並獨立處理它們，或者通過與其他進程集成而不需要中央控制器。
隨着舞美，兩個或兩個以上微服務可以協調他們的活動和流程，以共享信息和值：
這些主題下 Orchestration vs. Choreography
需要服務發現大大覆蓋。
但是，這些微服務可能不知道彼此的存在，即沒有配置或編碼到其中的依賴端點的硬編碼或服務引用。爲什麼我們這樣做，是爲了避免服務之間的任何耦合。那麼，問題仍然是如果一項服務需要找到另一個服務的端點？這是使用service discovery機制的地方。
另一個角度是，通過容器等微服務部署，微服務端點甚至不會被綁定到任何主機等[由於容器的旋轉和旋轉]。因此，對於這種情況，我們需要「服務發現」機制。
因此，在服務發現機制中，集中式服務發現工具可幫助服務註冊自己並通過DNS或HTTP接口發現其他服務。
服務發現可以用 2. Client Side service discovery
領事ETCD，動物園管理員來實現一些服務發現空間中的關鍵工具的名稱。
我相信在這個問題上存在誤解，因爲您認爲事件驅動的體系結構無法在HTTP之上實現。
事件驅動的體系結構可以以許多不同的方式實現，並且（當體系結構是分佈式系統時），可以在許多不同的協議之上實現。
它也可以使用消息代理（即Kafka，RabbitMQ，ActiveMQ等）來實現。但是，這只是一個選擇，當然不是唯一的方法。
例如，重要著作Building Microservices由山姆·紐曼，在第4章：集成，基於事件實現異步協作下稱：
「另一種方法是嘗試使用HTTP作爲傳播的一種方式 事件。 ATOM是一個符合REST的規範，它定義了用於發佈資源提要的語義 （等等）。許多客戶端存在 庫，這些庫允許我們創建和使用這些供稿。所以 當我們的客戶服務發生變化時，我們的客戶服務可能會將活動發佈到這樣的訂閱源。我們的消費者只是輪詢飼料， 尋找變化。一方面，我們可以重複使用現有的ATOM規範和任何相關庫的事實很有用，我們知道HTTP處理能夠很好地擴展。然而，HTTP不是 擅長於低延遲（一些消息代理商擅長），我們仍然需要處理消費者需要跟蹤他們看到的消息並管理他們自己的輪詢時間表的事實。
我看到人們度過一個時代實現你得到的開箱即用適當的消息 經紀人才能ATOM工作了一段用例的 行爲越來越多。例如，競爭消費者模式描述了一種方法，通過這種方法，您可以調用多個工人實例來競爭消息，這可以很好地工作來擴大工作人員的數量，以處理獨立的 作業列表。但是，我們希望避免兩個或更多工作人員看到相同消息的情況，因爲我們最終會完成比 需要更多的相同任務。使用消息代理，標準隊列將處理這個問題。 通過ATOM，我們現在需要管理我們自己在所有 工作人員之間的共享狀態，以儘量減少複製工作的機會。如果您的 已經擁有可用的良好彈性消息代理，請考慮使用它來處理髮布和訂閱事件。但是 如果你還沒有一個，請給ATOM一看，但要注意沉沒成本謬誤。如果您發現自己希望獲得消息代理提供的越來越多的支持，那麼在某個時候，您可能想要改變您的方法 。」
同樣的，如果你的設計採用事件驅動架構的消息代理，然後我不知道是否需要一個斷路器，因爲在這種情況下，消費應用控制的速率事件消息正在從隊列中消耗。生產者應用程序可以按照自己的速度發佈事件消息，消費者應用程序可以添加儘可能多的競爭消費者，以便跟上這一步伐。如果服務器應用程序關閉，則客戶端應用程序仍然可以繼續使用隊列中剩餘的任何消息，並且一旦隊列爲空，它們將繼續等待更多消息到達。但是這並沒有給生產者應用帶來任何負擔。在這種情況下，生產者和消費者應用程序是分開的，斷路器在其他情況下所做的所有工作都將由消息代理應用程序解決。
可以說服務發現功能有些類似。由於生產者和消費者之間並不直接對話，而只能通過消息中介，所以你需要發現的唯一服務就是消息中介。