架構風格：微服務

時間 2019-11-12

標籤架構風格微服欄目系統架構简体版

原文原文鏈接

本文探討：html

什麼是微服務
微服務的約束
微服務對架構屬性的影響

什麼是微服務

「微服務」是一種架構風格，也就是說，「微服務」是一組架構約束。前端

前面說到REST是一種複合式的架構風格，微服務也是！微服務的約束面更廣，它對開發過程和開發人員也進行了約束！程序員

微服務的約束

MartinFlower在Microservices一文中，詳細闡述了微服務所須要具備的約束！算法

- Componentization via Services：基於服務的組件化
- Organized around Business Capabilities：圍繞業務能力進行組織
- Products not Projects：產品而不是項目
- Smart endpoints and dumb pipes：智能終端和靜默管道
- Decentralized Governance：去中心化治理
- Decentralized Data Management：去中心化數據管理
- Infrastructure Automation：基礎設施自動化
- Design for failure：容錯性設計
- Evolutionary Design：進化式設計數據庫

實際上這些約束回答了架構設計所關心的幾個問題：編程

系統如何切分:圍繞業務能力進行組織，去中心化數據管理
模塊之間如何通訊:基於服務的組件化，智能終端和靜默管道
如何進行技術選型:去中心化治理
容錯性:容錯性設計
擴展性:產品而不是項目,進化式設計
可維護性:基礎設施自動化

下面一個個的說明！後端

系統如何切分？

在「架構風格：萬金油CS與分層」一文中，最後提到，通常狀況下，當你不知道一個系統使用何種架構比較好時，能夠先使用分層架構。分層架構就是將系統一層一層的切分，下層爲上層提供服務。架構

每一層的邊界是什麼呢？是「系統功能」！展示、業務邏輯、數據存儲。你會發現，這種切分方式和業務自己沒有任何關係，因此纔是「萬金油」！併發

另外，這種切分方法也將開發人員劃分紅了前端、後端、DBA！這是目前主流的作法，好像也沒有出現什麼大問題！框架

若是你在大公司待過，你就會發現進行一個需求變動是多麼麻煩的一件事。即便一個很簡單的需求，均可能要全部團隊都參與進來。

致使這個問題的緣由是什麼呢？是溝通成本！

項目管理算法的複雜度是O（N 2），當人員變得愈來愈多時，溝通成本成倍增加：

5人團隊，須要溝通的渠道是 5*(5–1)/2 = 10
15人團隊，須要溝通的渠道是15*(15–1)/2 = 105
50人團隊，須要溝通的渠道是50*(50–1)/2 = 1,225
150人團隊，須要溝通的渠道是150*(150–1)/2 = 11,175

咱們都知道「技術是爲業務服務的」！若是一個架構和業務沒有關係，如何爲業務服務呢？若是溝通要花費大量的時間，如何快速推動項目呢？

因此，微服務「圍繞業務能力進行組織」！

既包括了系統的切分
也包括了對人員的組織

由於康威定律提到：

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." - Melvin Conway (1967).

在微服務中，每一個模塊（這裏的模塊和咱們日常所理解的模塊有些區別，它的粒度更大，因此在微服務裏通常稱爲是服務，下面均使用「服務」）都是一個完整的業務系統！包括了展示、業務邏輯和數據存儲！相應的，負責開發的人員須要具有開發這個服務所須要的全部技能！

也就是說，在微服務中服務的邊界是業務的邊界！

這很相似韓都衣舍的「以產品小組爲核心的單品全程運營體系（IOSSP）」！將企業劃分爲「小集體」，像自由自在重複分裂的「阿米巴」——以各個「阿米巴」爲核心，自行制訂計劃，獨立覈算，持續自主成長。以3人一組的產品組爲例，這三我的分別是設計師、頁面製做、庫存管理員。這三人全權負責某一單品的頁面製做、款式設計、尺碼以及庫存深度的預估等工做。

對應到微服務中，即兩到三我的負責一個服務，這個服務包含了完整的業務流程，開發人員須要掌握開發這個服務所須要的完整的技能，包括UI、編程、DBA!

這裏的難點是：

一是要劃分好業務邊界，使得每一個服務可以高內聚、低耦合！
二是制定規範，利於各個服務之間的通訊
三是人員技能的要求更高

如何進行業務劃分，須要根據具體的業務來具體進行。這裏暫不展開。只提一點，就是要將事務考慮在內！

就是說在切分系統的時候，要考慮事務問題！咱們都知道遠程事務是一個比較難處理的問題！兩階段提交、三階段提交都不能很好的解決分佈式事務問題！Paxos算法過於複雜，且性能較差。

因此微服務的建議是：

儘可能保證事務在一個服務中執行
經過補償的方式來彌補事務操做的問題

服務如何通訊？

對於通常系統來講，咱們都是使用的進程內通訊，即經過調用同一內存內的方法的方式進行通訊！公用的代碼咱們能夠以「庫」的形式進行組織，避免代碼重複！這種系統咱們通常稱爲「單體系統」！

「單體系統」的伸縮性不理想！好比說，雙11須要作個活動，瞬間用戶量大增！若是須要應對流量峯值，就須要對系統進行擴容。可是由於是單體系統，擴容只能總體擴容，而實際上須要擴容的只是那個活動頁面！這就致使了資源的浪費。另一個問題就是，若是這個活動致使了系統崩潰，這將致使這個系統的全部功能都不能使用！

一種解決方案是進行「服務化」！即將須要多個系統公用的邏輯或TPS較高的模塊獨立部署，經過進程間通訊的方式，進行服務調用。好比上面的活動模塊，當活動模塊以服務的方式對外服務後，須要擴容時，只須要擴容活動服務就能夠了。同時，若是活動服務出現了問題，只會致使這個活動相關內容沒法訪問，而不會影響系統的其它功能。今年雙11淘寶的地址服務就掛了，可是並不影響淘寶自己的訪問。

這裏所說的「服務化」是使用dubbo這類服務化框架進行的服務化，而不是使用ESB的SOA！

基於ESB的SOA主要是爲了將企業中的各個系統鏈接起來！ESB像一根「聰明」的管道，用來鏈接各個「愚笨」的節點。爲了集成不一樣系統，不一樣協議的服務，ESB作了不少事情：

消息路由
編排
轉換
業務處理規則

這就致使ESB很重、很複雜。這也是基於ESB的SOA被人詬病的一個緣由。

dubbo這類服務化框架主要解決的是運行時代碼複用、系統伸縮性以及高性能問題！可是服務粒度相對較小，帶來的問題就是維護的成本相對較高！

而微服務能夠說作了一些折中：

服務粒度較大，包含了一個完整的業務的展現、邏輯和存儲。相對的數量就較服務化少，維護相對較容易
以進程間通訊的方式提供服務。包括對外服務、以及其它服務。保證了伸縮性。
業務邏輯處理都在服務內部進行，通訊組件只提供單純的通訊功能。保證了簡單性。

這樣既擺脫了繁重的ESB，也下降了維護難度！

如何進行技術選型？

對於「如何進行技術選型」，微服務不強制開發平臺！由於「沒有銀彈」！微服務偏向於「適合的工具解決適合的問題」！

每一個程序員都有本身喜歡的技術體系！有喜歡Java的、有喜歡.Net的、有喜歡C++的，還有喜歡Lisp的。。。。

那開發系統時須要選擇哪一種技術體系呢？按微服務的觀點就是：哪一種技術合適就用哪一種技術吧！這個服務須要高併發，能夠用Go來進行開發！這個服務須要快速推動，能夠用PHP！這個服務須要穩定，能夠用Java！看起來很完美！

而實際上內，這致使的是不可控！爲何Java語言會被不少企業使用？其中一個緣由就是可控！

舉個例子，國內公司的技術棧相對比較單一！好比，公司的主流語言是Java,.Net,PHP等，其它語言就只是輔助！通常不會有兩種、甚至三種主流語言！
假設一家公司的主流語言是Java！開發一個系統，可能須要10我的。那公司能夠招5~6個通常的，2~3個不錯的，1個牛逼的！公司只要穩住那個牛逼的就好了！若是有人走了，只要其餘人頂上就好了！
而若是每種服務都使用不一樣的語言，那一個系統使用了三個左右的語言，每種語言得有個熟練掌握的吧？每種語言，公司都得穩住個相對牛逼的吧？成本高不說，難度也大了很多！

容錯性

系統按照業務切分爲一個個的服務，相對單體應用來講，運行的系統多了，系統總體不可用的概率下降了，可是單個服務出現問題的概率卻變大了！這就須要微服務系統須要有比單體應用更好的容錯性！

任何服務可能由於供應商的不可靠而故障，客戶端須要儘量的優化這種場景的響應。與單體構架相比，這是一個缺點，由於它帶來額外的複雜性。這將讓微服務團隊時刻須要關注服務故障的狀況下的用戶體驗。
因爲服務可能隨時出現問題，因此快速故障檢測，甚至自動恢復就變動很是重要。微服務應用把實時的監控放在應用的各個階段中，檢測構架元素（每秒數據庫的接收的請求數）和業務相關的指標（每分鐘接收的訂單數）。監控系統能夠提供一種早期故障告警系統，讓開發團隊跟進並調查。

這又無形中提升了對開發人員的技術要求！