架構師進階,微服務設計與治理的16條常用原則

語言: CN / TW / HK


上一篇文章我們從「儲存選型」角度學習了架構師的基本能力。


今天將從儲存的上一層「服務維度」學習架構師的第二項常用能力——微服務設計與治理。

  • 如何設計合理的微服務架構?

  • 如何保持微服務健康執行?

這是我們對微服務進行架構設計過程中非常關注的兩個問題。


本文對微服務的生命週期定義了七個階段,如下圖所示。

圍繞這七個階段總結了16條常用原則。

1、微服務規劃

原則1:按照業務能力(business capabilities)來規劃或拆微服務。

康威定律:Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.
(設計系統的組織,其產生的設計和架構等價於組織間的溝通結構。)


組織的溝通和系統的設計之間緊密相連,特別是複雜系統,解決好人與人的溝通才能有一個更好的系統設計。


《人月神話》中總結出了隨著人員的增加溝通成本呈指數增長的規律:溝通成本 = n(n-1)/2。舉例說明:

  • 5人專案組,需要溝通的渠道是 5*(5–1)/2 = 10

  • 15人專案組,需要溝通的渠道是15*(15–1)/2 = 105

  • 50人專案組,需要溝通的渠道是50*(50–1)/2 = 1,225


系統越複雜,人手越多,溝通成本也呈指數增長。因此,分而治之便是大多數公司選擇的解決方案。分不同的層級,分不同的小團隊,讓團隊內部完成自治理。


原則2: 按照領域驅動設計(Domain-Driven Design,DDD)來規劃或拆解微服務。

領域驅動設計是微服務領域的熱門話題,本文不展開說明,僅說明幾點重要事項:

  • 基本過程:抽象業務、分析流程、識別邊界、建立模型、對映到服務和程式碼

  • 避免過度耦合、存在貧血領域物件等情況

  • 劃分界限上下文,釐清上下文之間的對映關係,比如合作關係、共享核心、客戶方-供應方開發、防腐層、開放主機服務等等。

  • 細化上下文物件,區分實體、值物件、聚合根、領域服務、領域事件

原則2與原則1的區別在於,原則1關注組織架構領域,原則2更偏向軟體工程設計領域。

2、微服務設計

原則3:微服務的設計應該遵循「單一職責」原則

所謂單一職責原則,就是對一個服務而言,它的功能要單一,只做與它相關的事情。在微服務的設計過程中要按職責進行設計,彼此保持正交,互不干涉。


什麼樣的單一領域物件的單一職責微服務才是有價值的?就是不斷有業務變化,能夠維持業務永續性,有業務生命力的領域物件。舉例來說:

  • 與別的功能點相比,呼叫頻率非常高

  • 或者其資料量存量大,資料增速快,TB級甚至是PB級的。


那麼就很有價值獨立為一個微服務,實現獨立演進、個性化的彈性伸縮。


所以,我們在進行微服務設計時,要能夠分析、預測出需求變化的點在哪裡?高併發的點在哪些?資料增長的位置在哪裡?與DDD分析相結合,找出最有價值的那個單一職責,進行合理、適度的領域、子領域、有界上下文分解,才能更好的應對複雜的業務、不斷變化的業務。


原則4: 微服務的設計應該遵循「高內聚」原則

過度追求「單一職責」,或者拆分微服務過細,往往會帶來不良後果。微服務的設計並不是越細越好,過度拆分會導致呼叫效能變差、資料一致性難以保障、系統可用性降低等問題。


因此,「高內聚」原則要求:

  • 完全獨立。微服務粒度的下界是它至少應滿足獨立,能夠獨立釋出、獨立部署、獨立執行與獨立測試

  • 足夠內聚。強相關的功能與資料在同一個服務中處理

  • 足夠完備。一個服務包含至少一項業務實體與對應的完整操作


原則5:微服務的設計應該遵循「低耦合」原則

  • 避免資料過度暴露

  • 避免資料庫共享

  • 最小化同步呼叫,如有必要,引入事件驅動進行非同步呼叫


3、微服務實現

原則6:服務無狀態。

什麼是「狀態」?如果一個數據需要被多個服務共享,才能完成一筆交易,那麼這個資料被稱為狀態。


依賴這個「狀態」資料的服務被稱為有狀態服務,反之稱為無狀態服務。


「無狀態」原則並不是說在微服務架構裡就不允許存在狀態,而是要把有狀態的業務服務改變為無狀態的計算類服務,那麼狀態資料也就相應的遷移到對應的“有狀態資料服務”中。



場景說明:例如我們以前在本地記憶體中建立的資料快取、Session快取,到現在的微服務架構中就應該把這些資料遷移到分散式快取中儲存,讓業務服務變成一個無狀態的計算節點。遷移後,就可以做到按需動態伸縮,微服務應用在執行時動態增刪節點,就不再需要考慮快取資料如何同步的問題。


只有服務無狀態,才能實現快速彈性擴縮容,應對流量峰谷。


原則7:服務高可用。

接入高可用中介軟體(如sentinal),實現限流、熔斷、降級,增強可用性


原則8:服務可觀測。

除了預設系統監控外,微服務需要梳理並定義必要的「業務監控指標」。


原則9:服務配置可管理。

微服務相關配置需要統一接入配置中心進行管理、控制。


4、微服務呼叫

原則10:避免「分散式大單體」

只做單向呼叫,避免迴圈呼叫。

多個服務迴圈依賴呼叫形成集中式“分散式大單體”,違背微服務的原則。


原則11:非同步解耦。

按需接入訊息佇列,實現「依賴解耦」、「流量削峰」

  • 串行同步呼叫非同步化,提高響應能力和響應速度

  • 應對突發流量,實現流量削峰與流量控制

  • 解耦核心業務邏輯不必要的依賴

  • 業務設計中的最終一致性


原則12:引入BFF層,降低客戶端與後端微服務之間的耦合

儘量設計BFF層,把前端的特殊需求交給BFF層,使後端服務邏輯具有高內聚、高複用性的精簡核心邏輯。

5、微服務釋出

原則13:服務釋出遵循安全釋出三板斧

保證「可灰度」、「可監控」、「可回滾」。

6、微服務治理

原則14:正視「架構腐化」,遵循「持續演進」原則

「架構腐化」的常見場景:

  • 多人維護一個微服務,出現「頻繁程式碼衝突」,影響快速迭代,那麼這個微服務就需要拆分了。

  • 當你修改了一個邊角的小功能,但是你不敢馬上上線,因為你依賴的其他模組才開發了一半,出現大量「功能耦合」,那麼這個微服務就需要拆分了。

  • 當你發現微服務A內聚合a的功能變成了海量高頻業務。這時聚合a就會拖累整個微服務A,並且因為聚合a面臨效能瓶頸,在微服務A進行彈性擴縮時,也會造成資源浪費。這時,我們就可以將聚合a從微服務A中整體拆分,獨立為一個新微服務B。在資源配置方面也可以更加有針對性的投入到微服務B,可以隨時滿足高頻訪問的效能要求了。

  • 當你發現在領域建模時錯誤地將聚合d放到了微服務C裡,或者隨著業務發展聚合d更適合放在微服務D裡。由於領域模型的不合適,可能會導致微服務之間出現頻繁呼叫,進而導致微服務之間出現「緊耦合關係」。這時,我們就可以對領域模型做出調整,將聚合d從微服務C整體遷移到微服務D裡。


原則15:參考「AKF擴充套件立方」模型,服務除了「水平擴容」外,還可以考慮「功能拆分」或者 「資料分割槽」

  • X軸:服務和資料的水平擴容。

  • Y軸:功能/業務拆分

  • Z軸:沿客戶邊界的服務和資料分割槽


「水平擴容」比較容易理解,直白點說就是加機器。根據AKF模型,除了加機器外,我們還可以考慮「功能拆分」或者 「資料分割槽」。


「功能拆分」相對複雜,一般包括幾種模式:

  • 微服務拆分。根據具體業務模型、領域模型拆分更細粒度的微服務。

  • 業務隔離拆分。利用訊息佇列,將線上業務(OLTP)和耗費大量資源的計算任務拆分隔離。

  • 核心與非核心隔離。對於一個微服務,可以將SKA客戶與普通客戶進行隔離,SKA客戶使用獨立的叢集資源,提高穩定性。


「資料分割槽」往往指的是資料庫層面。需要引入資料庫中介軟體,像 sharding-jdbc、mycat 等,在資料層面需要配置相應的分片邏輯。正確的拆分對提高系統的容量有很大的幫助,失敗的拆分可能會造成熱點集中,得不償失。常用的分割槽邏輯包括 按照時間分割槽、按照使用者id取模分割槽等。

7、微服務下線

原則16:對於「廢棄服務」,需要做好「下線」工作,包括服務下線、儲存釋放等。

清理無效程式碼、環境,減少維護成本。同時釋放資源,節約成本。

8、總結

架構師在進行微服務設計和微服務治理時,可以圍繞微服務生命週期的七個階段展開。

本文總結了16條常用原則,希望能提供一些思路和啟發。

如果你有其他補充和建議,歡迎留言討論。





往期熱門筆記合集推薦:


原創:阿丸筆記(微信公眾號:aone_note),歡迎 分享,轉載請保留出處。

沒有留言功能的悲傷,掃描下方二維碼「加我」聊些有的沒的吧~

                                                                              覺得不錯,就點個  再看 吧👇



本文分享自微信公眾號 - 阿丸筆記(aone_note)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。