響應式微服務 in java 譯 <十七> Deploying a Microservice in OpenShift

Scale Up and Down

若是咱們使用雲平臺，主要是出於可伸縮性的緣由。咱們但願可以根據負載增長和減小應用程序實例的數量。在OpenShift儀表板中，咱們能夠上下縮放吊艙的數量，如圖5-5所示。

您還可使用oc命令行設置副本的數量：

讓咱們建立Hello微服務的第二個實例。而後，等到第二個微服務正確啓動(等待時間很煩人，但稍後咱們會修復它)，而後返回瀏覽器中的hello-consumer 頁面。你應該能夠看到如下的：

 

若是您屢次刷新，您將看到OpenShift服務平衡了兩個實例之間的負載。你還記得咱們禁用的「keep-alive」設置嗎？當HTTP鏈接使用一個 keep-alive 的鏈接時，OpenShift將請求轉發到相同的 pod ，從而提供鏈接的密切性。請注意，在實踐中， keep-alive 是一個很是理想的頭部，由於它容許重用connec-tions。

在前面的場景中，有一個小問題。當咱們進行擴展時，OpenShift開始向新的 Pod 發送請求，而不檢查應用程序是否準備好處理這些請求。所以，咱們的消費者可能會調用一個一個尚未準備好的微服務，而後失敗。有幾種方法能夠解決這一問題：

1.在微型服務中使用健康檢查

2.準備好面對消費者代碼的失敗

Health Check and Failover

在OpenShift中，您能夠聲明兩種類型的檢查。準備狀態檢查用於在更新微服務時避免停機。在滾動更新中，openShift會等到新版本準備好後再關閉上一個版本。ping新的微服務的就緒狀態檢查端點，直到它準備好爲止，並驗證微服務是否已成功初始化。活性檢查用於肯定一個 Pod 是否還活着。OpenShift按期調用活性檢查端點。若是 pod 沒有正面回覆檢查，它將被從新啓動.。活性檢查的重點是微服務須要哪些關鍵資源才能正常工做。在下面的示例中，咱們將對兩個檢查使用相同的端點。可是，最好使用兩個不一樣的端點。

此示例的代碼包含在OpenShift/hello-microservice-OpenShift-Health-Check目錄中。若是打開verticle，您將看到HealthCheck處理程序驗證HTTP服務器是否已經啓動。

Fabric8Maven插件被配置爲使用/健康來進行就緒和活性健康檢查。一旦部署了這個版本的hellomicroservice，全部後續部署都將使用就緒檢查來避免停機，如圖5-6所示：

當 Pod 準備好後，OpenShift將請求路由到這個 Pod 並關閉舊的。當咱們擴大規模時，OpenShift不會將請求路由到還沒有準備好的 Pod。

原文地址：

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

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