響應式微服務 in java 譯 <十一> Are We Reactive Now?

 Are We Reactive Now?

咱們以前寫的這段代碼和基於 HTTP 微服務很是接近，區別就是咱們用了 event bus 取代了 HTTP，這個能夠改變個人響應式服務嗎？是的，咱們來看看爲何。

Elasticity

彈性的分佈式是以前的 HTTP 版本作不到的，由於 microservice 調用服務的時候用了一個固定的 URL，沒有提供咱們須要的分佈式（固然改進經過其餘技術仍是能夠的），可是如今咱們使用消息發送到某個地址，改變了這個遊戲，讓咱們看看這個微服務系統怎麼行爲吧。

你還記得以前執行的輸出，返回的JSON 顯示了 verticle 計算的輸出，輸出顯示老是同一個 verticle，消息也是顯示是同一個實例，由於咱們只有一個實例在運行，而後咱們運行兩個實例會發生什麼。

中止 Hello microservice 的執行，而後運行下面的命令：

而後，打開兩個終端在 hello-microservice 消息目錄，執行如下命令（在每個終端）：

這樣啓動了兩個 hello microservice 的實例，回到瀏覽器，刷新頁面，你可能看到以下的結果：

咱們使用了來給你個 Hello 實例，Vert.x 集羣鏈接了不一樣的節點，event bus 也是一個集羣，得益於 event bus 的 round-robin ，Vert.x event bus 分發消息到不一樣的可執行的實例，並且作了負載均衡的事情。

所以用了 event bus ，咱們有了須要的彈性分佈式特性。

Resilience

關於快速恢復（失敗）呢？在如今的節點裏，若是hello microservice 失敗了，咱們獲得一個 failure 和執行下面的代碼：

即便用戶獲取到一個 error mesage，咱們沒有崩潰，也沒有限制了拓展性，咱們仍然能夠處理這個請求。而後，爲了改善咱們的用戶體驗，咱們應該老是及時回覆給用戶，即便咱們沒有從service獲取響應，爲了實現這個邏輯，咱們可使用超時的代碼。

爲了說明這一點，讓咱們修改hello microservice 注入故障和問題行爲。這段代碼在microservices/ hello-microservice-faulty 文件下。

這個start 方法隨機從三種啓動策略中選好一種：1.響應失敗，2.忘記響應（調用方超時），3.發送正確的結果

從新打包和啓動這兩個 hello microservice 的實例。

由於注入了失敗的狀況，因此咱們改進消費房錯誤的容忍度，實際上，消費方可能獲取一個超時或者失敗的狀況，在 hello consumer microservice 中，咱們改變代碼調用方式：

代碼位於microservices/hello-consumer- microservice-timeout 文件夾下，超時的方法在給定時間內沒有獲取服務的迴應就會提出失敗，重試的方法將會執行重試，在響應失敗或者超時的狀況下。subscribeon方法指出哪一個線程調用須要作，咱們使用event bus loop 調用 callbacks。若是沒有這個，方法將會執行默認Rxjava 線程池，打破了 Vert.x 線程模型。Vert.x 提供的 RXHelper 類盲目嘗試調用服務並非一個很聰明的容錯策略。它甚至能夠是有害的，下一章詳細介紹了不一樣的方法。

如今你能夠從新載入這個頁面，你老是會獲取一個結果，即便是失敗或者超時，當調用服務的時候線程沒有被阻塞，所以你能夠繼續接收請求，而且即便響應，因此這裏實現的超時重試形成的傷害大於好處，咱們將在下一章接續討論。

Summary

在這個章節中，咱們先是用HTTP實現微服務，URL使用硬編碼打破了響應式編程的其中一個特性，所以接下來咱們使用了消息機制，看到 event bus 怎麼幫助咱們實現響應式服務。

咱們構建了響應式服務，可是這裏還有一些短板咱們須要關注。若是咱們僅僅使用HTTP 服務呢？咱們怎麼避免硬編碼呢？關於快速恢復？咱們在這裏看到了超時和重試，可是斷路器，失效備援，隔離呢？讓咱們繼續以後的學習。

 

原文地址：

https://developers.redhat.com/promotions/building-reactive-microservices-in-java/

有什麼討論的內容，能夠加我微信公衆號：