《微服務架構設計模式》讀書筆記 01.逃離單體地獄

單體架構的好處

• 應用開發簡單；
  • 一個Git，可以看到代碼全貌
• 易對應用程式進行大規模修改；
• 測試相對簡單直覺；
• 部署簡單明了；
• 橫向擴充不費吹灰之力；多執行個體+負載均衡即可。

  

單體架構的問題

• 過度複雜性會吓退開發者；
  • 了解複雜
  • 代碼難了解—更改時容易出錯—備援代碼—-更複雜
• 開發速度慢；
  • IDE卡頓，編譯慢，啟動慢。
• 從代碼送出到實際部署的周期很長，容易出問題；
  • 不同子產品分了團隊後，團隊的時間不一緻。
  • A團隊的代碼可能對B團隊産生影響。
• 難以擴充；
  • 有的子產品需要硬碟，有的子產品需要CPU，這樣就必須把伺服器配置拉滿，造成浪費。
• 傳遞可靠的單體應用是一項挑戰；
  • 沒有隔離。
• 需要長期依賴某個可能已過時的技術棧；
  • 難以重構，需要整體重寫。

    

系統的擴充

• X軸：負載均衡，随機算法、平均算法，複制多個單體就好了。
• Z軸：根據請求路由，有針對地擴容。
• Y軸：功能性拆分，将應用拆分成服務。

  

微服務的特點

• 根據業務拆分服務，獨立開發、測試、部署，并且擁有自己的資料庫。
• 服務間采用輕量級的通信機制。

  

和SOA的差別

• SOA是全局資料庫，微服務的獨立資料庫。
• 微服務的拆分更小。
• SOA的通信方式更重，采用了ESB企業總線，微服務采用的RPC。

  

微服務的好處

• 使大型的複雜應用程式可以持續傳遞和持續部署
  • 自動化測試—-持續傳遞和持續部署
  • 獨立部署
  • 開發團隊自主且松散耦合
• 每個服務都相對較小并容易維護；
  • IDE快，啟動快。
  • 提高調試、部署等環節效率。
• 服務可以獨立部署；
• 服務可以獨立擴充；
  • 有針對地選擇伺服器。
• 微服務架構可以實作團隊的自治；
  • 每個團隊可以有自己的技術和管理方法。
• 更容易實驗和采納新技術；
  • 友善試錯和疊代。
• 更好的容錯性；
  • 故障隔離了，程序和資料庫都隔離了。

    

微服務的弊端

• 服務的拆分與定義是一項挑戰；
  • 沒有具體的、良好的算法可以完成拆分工作，這讓服務的拆分更像一門藝術。
  • 如果拆分的不好，會成分布式單體，會包含單體和微服務兩者的弊端。
• 分布式系統帶來各種複雜性，使開發、測試和部署變得困難；
  • 跨服務的事務和查詢。
  • 資料一緻性。
  • 需要高度自動化。
• 當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊；
  • 需要根據服務依賴來制定開發計劃。
• 開發者需要思考到底應該在應用的什麼階段使用微服務架構；
  • 初創公司應該從單體開始。

新架構的推進

銀彈現象：

過熱期（迷戀和崇拜）—- 低谷期（失望）—- 成熟期（生産力的高地，理性地使用）

理性地看待新技術。

騎大象的人：大象代表思維中情緒化的部分，它完成了絕大部分決策。騎大象的人代表理性的部分，用來對大象的決策進行判斷。

團隊增大，溝通成本也會迅速增加，解決之道就是将大團隊劃分成小團隊。

讓團隊“自治”。

持續傳遞：

持續傳遞能夠以可持續的方式安全、快速地将所有類型的更改(包括新功能、配置更改、錯誤修複和實驗)傳遞到生産環境或使用者手中

• 部暑頻率:軟體部署到生産環境中的頻率。
• 傳遞時間:從開發人員送出變更到變更被部署的時間。
• 平均恢複時間:從生産環境問題中恢複的時間。
• 變更失敗率:導緻生産環境問題的變更送出百分比。

  

微服務帶來的管理問題

• 失落和放棄：改變總是痛苦的，要脫離舒适區，人們會叨念之前的好。
• 中立區：糾結并開始學習新的工作方式。
• 新的開始：體會到了新工作方式的好，開始熱情地擁抱新的工作方式。