背景
微服務架構指的是將大型復雜系統按功能或者業務需求垂直切分成更小的子系統,這些子系統以獨立部署的子進程存在,它們之間通過輕量級的、跨語言的同步(比如REST,gRPC)或者異步(消息)網絡調用進行通信。
現象
在微服務生態系統堆棧的頂層是各個微服務。對於開發團隊來說,因為它們完全依賴於良好的開發實踐、良好的部署實踐以及開發團隊構建、運行和維護其單個微服務的方式。
假設微服務層下面的基礎設施相對穩定,微服務經歷的大多數事件和中斷幾乎都是自行造成的。應該讓的開發人員針對其微服務中,自己發現完整的根本原因和故障,即他們收到的告警,將來自其微服務的關鍵指標的變更觸發(有關監視、日志記錄、告警和微服務密鑰指標的詳細信息)。
如是一個服務失敗示例, 通常需要隔離它
還有一些情況是,服務之間有依賴的,其有一個服務失敗導致多個服務失敗。這時你需要多個故障轉移Failover
代碼審查Code Review不完整、缺乏適當的測試覆蓋率以及不規范開發流程(具體來說,缺乏標准化開發流程)會導致將錯誤代碼部署到生產環境中,而通過跨微服務團隊標准化開發流程是可以避免故障。如果沒有一個穩定可靠的部署管道,其中包含Staging、金絲雀和生產階段的設置,在將任何錯誤完全部署到生產服務器之前捕獲任何錯誤,在開發階段測試未捕獲的任何問題都可能導致微服務本身、其依賴項以及依賴於它的微服務生態系統的任何其他部分出現嚴重事件和中斷。
當我們平台缺少微服務應用層監控時,不能及時收到告警,做出決策,最終可能會引起大規模的微服務實例失敗。
那些本身模塊或服務設計有問題,如不規范的程序重試邏輯,不正確的緩存使用場景。這些都會導致某個微服務的失敗,這些需要在測試過程時需要發現與解決,包括架構設計評審。
任何特定於微服務體系結構也可能失敗,包括任何數據庫、消息中間件、任務處理系統等。這也是微服務中的常規和特定代碼錯誤會導致故障以及不正確的錯誤和異常處理:當微服務失敗時,未處理的異常是經常被忽視的罪魁禍首。最后,如果服務未做好突發增長做好准備,流量的增加可能會導致服務失敗。
總結
一些最常見的微服務故障包括:
• 不完整的代碼審查
• 糟糕的架構和設計
• 缺乏適當的單元和集成測試
• 部署錯誤
• 缺乏適當的監控
• 錯誤和異常處理不當
• 數據庫故障
• 可伸縮性限制
注意: 我們不能依賴容器編排平台Kubernetes來解決以上問題,很多時候是研發流程的問題,通過事前過程來預防微服務的失敗,而不是通過事后控制。
今天先到這兒,希望對雲原生,技術領導力, 企業管理,系統架構設計與評估,團隊管理, 項目管理, 產品管管,團隊建設 有參考作用 , 您可能感興趣的文章:
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平台的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計划
構建高效的研發與自動化運維
某大型電商雲平台實踐
互聯網數據庫架構設計思路
IT基礎架構規划方案一(網絡系統規划)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之采購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
如有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊,請關注我的微信訂閱號:
作者:Petter Liu
出處:http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。 該文章也同時發布在我的獨立博客中-Petter Liu Blog。