開發七年的微服務概念解析
微服務概念解析
特點
1 粒度微小
2 責任單一
3 隔離性好
4 管理容易
作用
1 傳統軟體架構
2 微服務架構
3 單體架構和微服務架構比較
微服務應用場景
1記錄型系統System of Record
2互動型系統System of Engagement
3分析型系統System of Insight
微服務架構的缺點
1運維開銷及成本增加
2必須有堅實的DevOps開發運維一體化技能
3隱式介面及介面匹配問題
4程式碼重複
5分散式系統的複雜性
6非同步機制
7可測性的挑戰
概念
微服務是一種以 業務功能為主的服務設計 概念， 每一個服務都具有自主執行的業務功能，對外開放不受語言限制的 API (最常用的是 HTTP) ，應用程式則是由一個或多個微服務組成。 微服務 的另一個對比是 單體式應用程式 。 單體式應用表示一個應用程式內包含了所有需要的業務功能，並且使用像主從式架構 (Client/Server) 或是多層次架構 (N-tier) 實作，雖然它也是能以分散式應用程式來實作，但是在單體式應用內，每一個業務功能是不可分割的。若要對單體式應用進行擴充套件則必須將整個應用程式都放到新的運算資源（如：虛擬機器器） 內，但事實上應用程式中最吃資源、需要運算資源的僅有某個業務部分（例如跑分析報表或是數學演算法分析），但因為單體式應用無法分割該部分，因此無形中會有大量的資源浪費的現象。
微服務運用了以業務功能的設計概念，應用程式在設計時就能先以 業務功能 或 流程設計 先行分割，將各個業務功能拆分為 獨立 獨立部署、獨立執行的子系統（能自主執行的個體服務），然後再利用相同的協定將所有應用程式需要的服務都 組合 起來，形成一個應用程式。若需要針對特定業務功能進行擴充時，只要對該業務功能的服務進行擴充套件就好，不需要整個應用程式都擴充套件，同時，由於微服務是 以業務功能導向的實作 ，因此 不會受到應用程式的干擾 ，微服務的管理員可以視運算資源的需要來配置微服務到不同的運算資源內，或是布建新的運算資源並將它配置進去。雖然使用一般的伺服器虛擬化技術就能應用於微服務的管理，但容器技術 (Container Technology) 如 Docker 會更加地適合發展微服務的運算資源管理技術。總結起來就是：
1. 服務種類根據業務劃分
2. 每個服務可獨立部署運維且相互隔離
3. 服務之間通過 API 呼叫服務
4. 服務需保證良好的高可用性
5. 分散式管理以及分散式資料。每個微服務團隊有充分自由選擇自己團隊熟悉的程式語言、資料庫和其他中介軟體等技術棧。
微服務的一些常見誤解
關於一些比較概念的澄清：
在同一範疇內比較才有意義：
微服務架構 vs. SOA
兩者都是架構風格範疇，但其關注領域與涉及範圍不同。SOA更關注企業規模範圍，微服務架構則更關注應用規模範圍。
微服務元件 vs. 服務元件
兩者都是描述業務功能的具體實現，其區別在於粒度不同，此外還有在可管理性、靈活性上的差異。
-------------------------------------------------
概念混淆的不恰當比較
微服務 vs. SOA – 不恰當的比較。
微服務是元件範疇，而SOA是一種架構設計風格。因此應該比較的是微服務架構與SOA。
微服務 vs. API – 不恰當的比較。
API是介面，是業務功能暴露的一種機制。微服務架構是用於實施業務功能的元件架構。因此直接比較它們是沒有意義的。
微服務 vs. 服務– 不恰當的比較。
“服務”在不同的場景下有不同的含義，需要進一步澄清其描述的語境，是指服務實施、服務暴露、服務定義還是其他？
微服務亦是如此，需要有特定語境才可判斷比較是否有意義。
特點
搭建一個微服務架構需要具備四大特性
1 粒度微小
微服務的粒度是根據業務功能來劃分的，對於某些複雜的業務來說，可能粒度較大，
對於相對簡單的業務而言，可能粒度較小。
總之，微服務的粒度可大可小，但往往我們更希望它儘可能的小，
但又不希望微服務之間有任何的依賴，因此粒度的劃分是非常考驗架構師水平的事情。
2 責任單一
我們需要確保每個微服務只做一件事情，也就是我們經常提到的“單一職責原則”，
該原則對微服務的劃分提供了指導方針。
3 隔離性好
每個微服務相互隔離，且互不影響。
也就是說，每個服務執行在自己的程序中。眾所周知，程序之間是隔離的，是安全的，而程序內部或執行緒之間資源共享的。
換句話說，一個微服務出了問題，不會影響到其它微服務受到任何影響。
4 管理容易
隨著業務功能不斷增多，微服務的數量也會逐漸增加，我們需要對微服務提供自動化部署與監控預警的能力，才能更加高效地管理微服務。
微服務架構的特點非常明顯，可能還有很多，但同時微服務架構也給我們帶來了許多挑戰。
作用
在之前 傳統的軟體開發架構 中尤其是 單體應用 中，我們會發現隨著系統的 業務需求越來越大 ， 系統越來越臃腫 ，不僅 難以管理和維護 ，也不利於 橫向擴充套件 ，這就會 限制軟體的開發以及公司的發展 。
1 傳統軟體架構
擴充套件後
只需將這個應用程式複製一份，一模一樣的程式，將其部署到另一臺 Web Server 上，下方還是連線到同樣的 Database，只是在這些 Web Server 的上方架設一臺 Load Balancer （負載均衡器，簡稱 LB）。請求會首先發送到 LB 上，通過 LB 上的路由演算法（例如輪詢或雜湊），將請求轉發到後面具體的 Web Server 上，這類請求轉發技術被稱為 Reverse Proxy （反向代理） 。由於進入 LB 的請求（流量）被均衡到下方各臺 Web Server 中了，流量得到了分攤，負載得到了均衡，因此該技術也稱為 LoadBalance（負載均衡） 。如果流量加大，理論上可以無限水平擴充套件，只要 LB 扛得住巨大的流量。
通過以上技術方案，將負載進行了均衡， 一定程度上緩解了流量對 Web Server的壓力 ，但此時卻造成了 大量的系統資源浪費 ，比如對系統資源暫用率不高的 ModuleA 與 Module B 也進行了水平擴充套件，其實我們只想對 Module C 進行水平擴充套件而已。
2 微服務架構
在設計階段，架構師將產品功能拆分為若干微服務，為每個微服務設計 API 介面（例如REST API），需要給出 API 文件，包括 API 的名稱、版本、請求引數、響應結果、錯誤程式碼等資訊。在開發階段，開發工程師去實現 API 介面，也包括完成 API 的單元測試工作，在此期間，前端工程師會並行開發 Web UI 部分，可根據 API 文件造出一些假資料（我們稱為“mock 資料”），這樣一來，前端工程師就不必等待後端 API 全部開發完畢，才能開始自己的工作了。在測試階段，前後端工程師分別將自己的程式碼部署到測試環境上，測試工程師將針對測試用例進行手工或自動化測試，隨後產品經理將從產品功能上進行驗收。在部署階段，運維工程師將程式碼部署到預發環境，測試工程師再次進行一些冒煙測試，當不再發現任何問題時，經技術經理確認，運維工程師將程式碼部署到生產環境，這一系列的部署過程都需要做到自動化，才能提高工作效率。在以上交付流程中，開發、測試、部署這三個階段可能都會涉及到對程式碼行為的控制，我們還需要制定相關開發模式，以確保多人能夠良好地協作。在以上交付流程中，開發、測試、部署這三個階段可能都會涉及到對程式碼行為的控制，此外還需要制定相關開發模式，以確保多人能夠良好地協作。
通過比較我們會發現微服務比我們傳統的軟體架構更加靈活和容易擴充套件，當然也會有一些挑戰，比如對服務的劃分，管理以及運維要求都是比較高的
3 單體架構和微服務架構比較
單體架構 微服務架構
整體部署 分散式部署
緊耦合 鬆耦合
基於整體系統擴充套件 基於獨立服務按需擴充套件
集中式管理 分散式管理
應用無依賴管理 微服務中服務之間有較強依賴
區域性修改整體部署 區域性修改區域性部署
故障全域性性 故障隔離非全部
程式碼會臃腫、難維護 程式碼易於理解，容易維護
開發效率低 開發效率高
資源利用率低 資源利用率高
部署簡單 部署複雜
微服務應用場景
1、記錄型系統(System of Record)
將從微服務方法中獲益最多。例如可將大型應用按相對獨立的業務功能分解成若干個微服務實現。
2、互動型系統(System of Engagement)
也將受益於微服務方法，例如渠道應用可以應用“後端服務前端”的模式實現。
3、分析型系統(System of Insight)
則可能對微服務受益不多。其他架構模式如管道及過濾模式可能更適用於分析型系統。
微服務架構的缺點
微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其複雜性。
1、運維開銷及成本增加：
整體應用可能只需部署至一小片應用服務區叢集，而微服務架構可能變成需要構建/測試/部署/執行數十個獨立的服務，並可能需要支援多種語言和環境。這導致一個整體式系統如果由20個微服務組成，可能需要40~60個程序。
2、必須有堅實的DevOps開發運維一體化技能：
開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的資料儲存技術如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰。
3、隱式介面及介面匹配問題：
把系統分為多個協作元件後會產生新的介面，這意味著簡單的交叉變化可能需要改變許多元件，並需協調一起釋出。在實際環境中，一個新品釋出可能被迫同時釋出大量服務，由於整合點的大量增加，微服務架構會有更高的釋出風險。
4、程式碼重複：
某些底層功能需要被多個服務所用，為了避免將“同步耦合引入到系統中”，有時需要向不同服務新增一些程式碼，這就會導致程式碼重複。
5、分散式系統的複雜性：
作為一種分散式系統，微服務引入了複雜性和其他若干問題，例如網路延遲、容錯性、訊息序列化、不可靠的網路、非同步機制、版本化、差異化的工作負載等，開發人員需要考慮以上的分散式系統問題。
6、非同步機制：
微服務往往使用非同步程式設計、訊息與並行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得複雜化。
7、可測性的挑戰：
在動態環境下服務間的互動會產生非常微妙的行為，難以視覺化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或採取其他必要的行動。但對於特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意
寫在最後：歡迎留言討論，加關注，持續更新！！！