
從管道部署與釋出 |
247
一切都從健康檢查開始(與結束)
在持續交付變成標準做法之前,當組織仍然手動將 app 部署到生產環境時,有一種明確
的方式可以在部署之後檢查一切是否正確運作:手動檢查。但是現在,因為一天可能會
發生多次自動部署,而且為了實現橫向擴展,每一個服務都有可能被部署到多個實例,
手動檢查服務是不切實際的做法。
此外,在自動擴展的世界,部署隨時會在我們沒有注意的情況下發生:需求的尖峰期可
能告知協調平台需要額外的資源,平台的回應可能是部署多個特定服務的新副本。此時
手動檢查這些新部署的服務是否正常運作同樣是行不通的。
使用自動化的手段來確定服務都有正確地運行還有一個理由,現代的微服務架構都提供
前所未有的彈性,但你必須管理更多變動元件。因為元件數量增加了,在系統各處發生
故障的機率也隨之增加,最後變成不可避免的情況:硬體故障、通訊連線中斷、核心鎖
死等等,除了它們之外,還有許多其他因素會讓節點失靈,但所有的服務都在那些節點
裡面運行。你可能會隨時失去服務,所以你必須偵測何時發生這種事,並且修復它。
健康檢查的概念就是從這裡產生的。
健康檢查
是服務的專用介面,例如 RESTful API 的
/health
端點,服務會用這種介面來顯示其內部狀態。這個介面被呼叫時,會執行一些快
速的檢查,來確定一切是否正常運作,再提供正面或負面回應。你可以設置協調平台,
要求它定期對著服務的所有實例詢問健康檢查的結果,並採取相應的行動:
• 如果服務回應正面結果,代表實例是健康的。
• 如果服務回應負面結果,代表實例是不健康的。 ...