微服務專欄地址
目錄
1 什麼是微服務
Loosely coupled service oriented architecture with bounded contexts.
鬆散耦合的、面向服務的、基於有界上下文的。
- 一組基於業務劃分的服務
- 獨立的進程
- 服務間輕量級通訊機制
- 獨立技術棧
- 獨立研發、部署
- 無集中式管理
- 微服務是一種架構風格
1.1 理解
基於微服務的概念與期望解決的問題，對微服務的理解：
- 它將傳統的單一系統按照業務劃分成不同的服務，服務之間互相協作、配合，爲用戶提供最終價值
- 每個服務運行在獨立的進程中，服務與服務之間採用輕量級通訊機制相互協作（通常是基於HTTP協議的RESTful API）
- 每個服務圍繞具體的業務來構建，並且能夠獨立的部署到生產環境中
- 很少有集中式的服務管理，每個服務可以使用不同的開發技術，使用不同的存儲技術
2 與單體應用區別
2.1 單體特點
- 集中式設計、研發、部署
- 資源利用相互影響，如某個業務模塊資源需求很高必須要通過提升整體資源配置來解決，反之亦然
- 需求迭代與維護成本隨應用規模擴展“指數”提升，如某業務模塊需求變更，需應用整體更新
- 穩定性差，很可能一個小的問題導致整個系統不能正常運行
- 開發效率低：代碼的迭代更新造成的衝突等問題會頻繁發生，且隨着項目規模的增長更加突出
- 可擴展性較低：很難應對高併發、高可擴展要求
2.2 微服務特點
如概念與理解所述，可很好的解決單體應用的特點帶來的弊。
3 微服務的利弊
任何事情都有兩面性，在享受或者實現微服務帶來的優勢同時，也必須要面臨以及解決微服務帶來的挑戰：
3.1 利
- 強模塊化邊界：系統中的不同功能模塊拆分成多個不同的服務，每個團隊負責自己的模塊
- 可獨立部署：每個服務都運行在自己的進程內，在部署上有穩固的邊界，這樣每個服務的更新都不會影響其他服務的運行，由於是獨立部署的， 我們可以更準確地爲每個服務評估性能容量，通過配合服務間的協作流程也可以更容易地發現系統的瓶頸位置，以及給出較爲準確的系統級性能容量評估
- 技術多向性：分散式治理，支持多種語言與技術（實際過程中非特殊需求不建議無限制擴展，技術多樣性同樣伴隨着學習成本與通用性）
- 系統穩定性，高可擴展性：分佈式技術帶來的優勢。
3.2 弊
- 接口的一致性：如何應用各種情況下接口的表現不一致問題，如重複調用等
- 分佈式複雜性：如分佈式事務、數據一致性、分佈式鎖、服務的治理、服務的監控等等。
- 運維的新挑戰：如何實時、有效的監控整個應用，如何合理有效分配資源，如何跟蹤、定位、發現問題等等
- 測試複雜性：需要很多團隊聯合集成測試
4 思考
4.1 微服務架構與單體應用架構該如何選擇？
選型沒有統一的標準或者條件，肯定是結合公司或者部門的現狀、目標以及微服務與單體應用的特點來抉擇，有的時候甚至可以存在的單體向微服務的轉型或者改造。
- 初創型公司：單應用優先。初創型公司首驗證商務模式，業務領域不是很清晰，微服務前期投入大，複雜性高
- 大型公司：微服務。業務成熟，單塊應用不滿足需求
- 發展中如何取捨：單塊優先，隨着業務領域清晰、一步一步轉向微服務，根據業務將對應模塊從單塊應用抽出來獨立爲服務
4.2 如何實施？
- 技術選型？
- 組織架構調整？
- 團隊劃分？
- 業務梳理？
- DevOps強推？