• ????歡迎點贊 ：???? 收藏 ?留言 ???? 如有錯誤敬請指正，賜人玫瑰，手留余香！

• ????本文作者：由webmote 原創，首發于 【掘金】

• ????作者格言：生活在于折騰，當你不折騰生活時，生活就開始折騰你，讓我們一起加油！????????????

???? 序言

“滾滾長江東逝水，浪花淘盡英雄。”

技術之路上，繁星點點，今天且來看看“微服務 ”，如何稱雄。

“微服務” 這個詞好像已經出來十年了吧，我有幸從好早之前就一直從事相關的開發實踐。所以一直想寫有關微服務拆分的題材，但都覺得自己理解不到位，難以下筆。

因為沒有系統的理論知識，很難寫出什么新花樣。????????????

直到最近參加了ThoughtWork的系列直播課，我覺得是時候系統的整理下學習心得，也算給最近的聽課以交代。

里面夾雜了自己的實踐感悟，寫的不一定能面面俱到，也不可能準確無誤，歡迎大家糾正！共同????交流探討。

???? 01.微服務是啥？

微服務(Microservice)概念據說是在2012年出現，其一出現就對互聯網行業產生了巨大影響，因為其理念剛好符合“分而治之”的思想，在日益巨大化的互聯網行業內，不免逐步產生了無法把控的思緒混亂，而“微”剛好能解決這個痛點。

先不上定義，僅從字面意思，我們就能看出，微服務即是小服務，巨大的服務怎么看也和“微”格格不入。

掘金牙醫曾經寫過一篇《我在掘金這3年 - 如何給飛行中的飛機換引擎》，在其中有段闡述，我覺得理解的很有地氣。

我們將?Wordpress(一款php語言編寫的個人博客系統) 無限拆分, 拆分到每個?function?都構成一個服務 (因為再細分已經毫義, 把一個大小, 功能適當的?function?再拆開只會降低性能徒增復雜度). 那么以?function?為服務最小單位的 repo 組成的業務就是服務中的最小模式了.

為了討論的簡便, 我們直接把最小服務模式叫 Picoservice. 最大模式叫 Polyservice. Polyservice 的話我們剛才說的 Wordpress 就是個很好的例子, 現實中 Polyservice 有很多, 傳統業務可能都是這樣組織代碼的, 相信大家也都見到過. 但每個 function 都拆分成服務的業務可不多見, 我粗略統計了下 Wordpress 大概有一萬個 function. 可以想象將 Wordpress 拆分成 Picoservice 最后組織成業務是多么可怕的事情. 現實中只有 FAAS 平臺上運行的業務可能是以單個?function?的形式組成并運行的.

依據服務大小的定義, 我們可以把現有的服務類型按照大小進行排序:

Picoservice <= FAAS(or ServerLess) < Microservice < Monoservice <= Polyservice

注意:?服務大小跟服務部署規模沒有關系, 無論是 Picoservice 還是 Polyservice, 只要設計得當都可以多機部署以提升性能.

看過接地氣的描述外，回頭我們再看看微服務真正的定義是啥？

“微服務”是是一種架構模式，它提倡將單一的應用程序劃分成一組小的服務，每個服務運行在其獨立的進程中，服務間采用輕量級的通信機制互相溝通。每個服務都圍繞具體業務進行構建，并且能夠被獨立的部署到生產環境。

簡而言之，微服務是一種將單個應用以許多微小服務所組成的服務套件的形式來構建軟件的方法，每個微服務擁有自己的輕量級數據處理模塊以及通信機制（通常是 HTTP API 的形式）。微服務圍繞業務能力和各自獨立的自動化部署機制構建而來。由于微服務需要極少的集中管理，因此各個服務可以使用不同的編程語言以及存儲技術。

當年寫三國的羅貫中雖然沒有做過碼農，編寫過前后端代碼，經歷過內卷的996、007，承擔過系統架構師，但其憑借自己敏銳的洞察力，在當時已經提出了IT界技術發展更迭的規律:?話說天下大勢，分久必合，合久必分。周末七國分爭，并入于秦。及秦滅之后，楚、漢分爭，又并入于漢。漢朝自高祖斬白蛇而起義，一統天下，后來光武中興，傳至獻帝，遂分為三國。

你品，你細品！中文文化的博大精深，底蘊深厚令人折服！

“分而治之”是微服務的精髓！理解了這個精髓，就可以如庖丁解牛般設計你的系統架構。當然以后肯定有某架構，一統江山，又是大勢所趨，這是后話，按下不表。

???? 02.微服務的誕生軌跡？

既然明白了“分久必合，合久必分”的理論知識，那我們來看看微服務的誕生軌跡。

沿著分分分的路，越走越遠。

由于把許多獨立的業務拆成不同的微服務，因此帶來的微服務構建的復雜度，一般表現為下列幾點：

• 微服務的注冊和發現

• 微服務的部署和彈性伸縮

• 微服務間的通訊

• 微服務間通訊的效率

• 微服務間的事務性（ACID）

• 微服務的對外網關、限流熔斷

• 微服務的全局配置

• 微服務的認證授權（OAuth2）

• 微服務間的異步通訊、消息

• 微服務的日志

• 微服務的監控

以上難題也是大型分布式應用的難題。

因此在我們的應用規模沒有上去之前，考慮到時間成本和其他復雜度要素，仍然可以按照單體 > SOA > 微服務的進階步驟一步步實施。

???? 03.微服務的打開方式？

從A點到B點，直線距離永遠是最短的，然而往往這條路也是走的最艱難的！所以這世上多了很多的盤山公路！

不管是舊系統的改造，還是新系統的構建，直接沖向微服務是有很大的風險的。

因此一般的實踐建議是：

• 單體或粗粒度服務優先，避免過度設計；

• 業務演進過程中加深對業務邊界的理解；

• 避免前期因服務劃分不合理帶來的大量重構工作；

當然如果在團隊中壞味道已經肆意彌漫了，那就是時候先動手了。是的，是我先動的手。

有幾種重要的拆分方式：

???? 03.1 事件風暴法

該方法來自傳統的DDD領域建模界，DDD方式在互聯網應用中被使用的很少，原因有很多了，這里指出的重要的幾點供你參考：

• 爭端太大，大家對DDD的理解各不相同，并沒有太好的標準說服對方；

• 慢，畢竟要理清楚各個業務邊界不是那么容易的，而互聯網應用一般是說好了就干；

• 事件、命令、聚合根、實體等概念諸多，理解不易。

雖然有諸多缺點，但瑕不掩瑜，在微服務劃分上，DDD異軍突起，起到了關鍵的理論指導意義。

事件風暴法是集合業務人員、領域專家、技術人員、架構和測試人員等一起尋找事件、命令、領域模型，直到劃分界限上下文和識別出問題域。

以下步驟略顯枯燥，謹慎閱讀。

03.1.1 尋找領域事件

• 領域事件：捕獲建模領域中所發生的事情

• 識別：領域專家所關心的事情，業務上真實發生，有事件順序

• 甄別：領域事件必須是對業務有價值的，必須將導致進一步業務操作的

一個例子：在商品訂單業務中。

領域事件：

• 商品已創建、商品已編輯

• 商品已發布

• 訂單已創建、訂單已取消

• 庫存已扣減

• 出庫單已生成

• 出庫單已配貨

• 出庫單已發貨

• 訂單已發貨

• 訂單已簽收

• 訂單已確認收貨

03.1.2 尋找命令

• 命令：產生事件的領域行為或領域活動

• 識別：用戶的動作、外部系統觸發、定時任務

接上個例子，有可能的命令：

• 添加商品、編輯商品

• 發布商品

• 添加訂單、取消訂單

• 定時生成出庫單

• 配貨

• 發貨

• 訂單簽收

• 訂單確認

03.1.3 尋找領域模型

• 領域模型：是對業務領域內的概念類或現實世界中對象的可視化表示

• 識別：是否可以被獨立訪問（可以：就是聚合，不能：屬于它依賴的聚合）

• 做法：留下聚合即時貼，命令在左，事件在右。

03.1.4 劃分限界上下文

• 限界上下文：某場景或環境下的業務邊界

• 識別：定義業務場景，然后找尋業務邊界

• 方法：識別出相鄰事件的關系，確立上下游角色。一般來說，發布事件的為下游，訂閱事件的為上游。

例如下面：

03.1.5 識別問題域

• 問題域：需要討論的問題范圍

• 識別：站在業務專家的角度看待問題，只能通過與最理解該領域的人一同協作才能完成。

???? 03.2 8X Flow業務建模法

8X Flow是ThoughtWorks 中國區CTO徐昊研究并設計的方法論。

DDD解釋中最容易混淆的是領域的概念本身，通俗的認為領域是問題的集合，問題又是業務的抽象。

那么，領域和業務到底有啥區別呢？

徐昊觀點：Domain + operation（運維） = business， 領域比較抽象，再更進一步抽象可以變成領域專家系統， 專家可以支撐業務。

8x Flow的分析方法步驟：

主要思想是尋找業務合約（訂單支付憑據、訂單發貨憑據、訂單收貨憑據等等），基于這些憑據，構造支付流程、發貨流程、收貨流程等。甚至于演化為限界上下文。

???? 04. 拆分微服務的原則

微服務拆分應遵循的原則，描述如下：

• 低耦合，單一職責
  微服務的設計和面向對象的設計原則類似，也需要符合低耦合、單一職責的設計原則。

• 單向依賴
  杜絕循環和雙向依賴。采用消息解耦上下游服務。

• 定義上下游
  下面的圖說的非常清晰，上下游服務應遵循下述調用方式。

• 數據操作獨立
  數據隔離，讓服務操作自身數據。

• 構造BFF
  為前端應用構造BFF服務，整合微服務間的融合。

???? 05. 結語

微服務按照DDD拆分太燒腦了，也許正如徐昊所說，很多公司的應用應該是業務優先，而不是領域優先，也即很多的業務邏輯，很少的領域邏輯，那么我們拆分這些業務時，完全按照DDD必將陷入迷茫之中。

適合自己的才是最好的，我們掌握這么多方法是為了靈活解決實際的問題，而不是被困在這些武器內不可自拔，甚至發出沒有DDD就不是好的微服務的謬論。

后續還會有很長的真實的實踐，實踐之后再回來總結下。

例行小結，理性看待！

結的是啥啊，結的是我想你點贊而不可得的寂寞。????????????

????都看到這了，還在乎點個贊嗎？

????都點贊了，還在乎一個收藏嗎？

????都收藏了，還在乎一個評論嗎？

總結

以上是生活随笔為你收集整理的你也可以搞懂的微服务第一篇——来自ThoughtWork的学习体验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。