我不會騙你，在雲服務上發生微服務崩潰，然後試圖弄清究竟發生了什麼事情是難以置信的令人沮喪。重新啟動並執行另外一個實體很簡單，但不知道前一個實體失敗的原因的話，你不能保證新服務的穩定性會比替換掉的更穩定。
在本文中，我們將看看你可以使用哪些策略來更好地瞭解什麼情況下會導致你的微服務崩潰。充分瞭解它失敗的原因將讓你有機會去實施更改以提高微服務的穩定性，並有望避免再次發生同樣的問題。
不幸的是，如果你找到這篇文章，我沒有很多有用的建議，因為你的微服務剛剛崩潰，你拼命想弄明白為什麼。透過提前準備支援基礎架構和監控，你將能夠更好的識別出哪些微服務崩潰以及為什麼。正確的準備工作是本文關註的主題，但這裡也提供一些提示以便我不會讓你停留太久。
在微服務環境中，每個服務可能對其他服務具有多個依賴關係。由於這些依賴關係，一個服務中的故障通常可能會表現為另一個服務的明顯故障，僅因為它作為其的依賴關係。識別哪個服務失敗是第一步。如果你懷疑某個服務是導致失敗的原因，那麼驗證其所有依賴項都是可操作的並按預期進行響應。
在生產環境中，您需要儘快恢復服務並執行。通常這個過程可能涉及到實體化一個新的虛擬機器或一個新的機器叢集。當任何一項完成後，自動化流程有時可能會破壞以前的實體或叢集。如果可能，採取措施保護這些裝置。日誌檔案，記憶體轉儲和在故障機器上執行診斷工具將能提供關於導致故障的原因的重要線索。
當你閱讀這篇文章，為遷移到微服務架構做準備並計劃一個全面的支援策略。一個精心設計的微服務架構允許獨立的開發團隊實現獨立的功能並建立高可擴充套件，松耦合的環境，並支援快速引入新功能。
這些對開發過程帶來的好處會導致一個難以使用傳統生產監控工具監控的環境。你將需要調研並實現一個應用效能監控工具（APM），該工具允許開發人員瞭解其應用程式的當前狀態，並自動化支援生產系統所涉及的許多過程，併在關鍵指標在規定的效能限制外時生成警報。
APM通常由安裝在微服務機器或容器上的代理組成，並與中央APM伺服器或伺服器叢集通訊。在某些情況下，APM代理可能本身作為獨立容器執行，特別是對於需要更深入檢測的服務。這種方法的優點是它可以將服務的監控與實際服務本身分離開來。即使標的計算機發生故障或意外關閉，它也允許持續分析資料併進行主動監控。
理想情況下，你選擇並實施的APM解決方案應包括趨勢分析或機器學習，以支援全自動監控。APM工具還應該包含動態基準和規則，並允許使用者自定義規則，然後可以在系統降級到無法使用之前用它們生成警報。
最後，APM解決方案應支援實時和歷史性的服務視覺化，以使開發人員能夠瞭解機器狀態，例如記憶體，處理和網路通訊等指標。日誌資料的收集，彙總和索引也是綜合監控解決方案的重要組成部分。
除了部署全面的APM解決方案外，當你在編寫你的微服務時也應該遵循一些開發最佳實踐，以便在發生故障時能給那些負責操作的人提供支援和使故障排除更簡單。
始終假定系統的各個方面都會故障，即使你的程式碼是完美的，它仍然依賴於基礎架構，相關服務和不可預測的使用者輸入。當你對應用程式進行編碼當以適當方式處理任何依賴性失敗，並使源識別更容易的方式進行編碼。在合適的地方新增全面的異常處理，描述性日誌訊息和驗證。
在服務之間傳遞訊息或請求時，請將相關令牌或跟蹤ID新增到源自同一客戶端的所有請求中。當您嘗試透過多個服務跟蹤客戶端的請求時，尤其是在將所有日誌聚合到索引日誌聚合系統中時，這些令牌非常有用。
最後，以啟用容錯的方式部署您的微服務。使用基於軟體的負載平衡器以及跨多個虛擬機器（如果可能的話，在不同的地理位置）分發單個微服務將有助於最大限度地減少使用者在其中一個實體發生故障時的停機時間。
要瞭解有關監控微服務的更多資訊，請獲取免費電子書：https://www.ca.com/us/info/docker-container-monitoring-essentials.html。
原文連結：https://thenewstack.io/help-my-microservice-crashed-a-guide-for-first-responders/
本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
文章已於修改
知識星球
