通過例子，讓你徹底搞懂微服務的演化過程

雖說微服務 [1] 早已是一個老生常談的話題了，在 infoq[2] 或者 thoughtworks[3] 上可以找到很多案例，不過可惜的是其中相當比例的案例是失敗的案例，究其原因，除了技術門檻 [4] 之外，主要是因爲很多人脫離了實際情況，只是爲了微服務而微服務。本文通過一個例子帶領大家從頭到尾體驗一下微服務的演化過程，不僅要做到知其然，更要做到知其所以然。

假設我們正在開發一個在線購物項目，其主要功能包括商城、推薦、評論、用戶等，它是一個典型的單體架構 [5]：不同團隊的技術人員工作在同一個版本庫上，系統功能按模塊劃分，不同模塊之間通過本地函數調用，通常操作同一個數據庫。

微服務

在項目早期，單體架構往往能很好的適應快速迭代的需求，不過隨着項目的發展，項目本身會變得複雜，其弊端不可避免的出現，比如下面列舉的一些情況：

如何解決此類問題？康威定律 [6] 給出了很好的建議：「設計系統的架構受制於產生這些設計的組織的溝通結構」，通俗點說就是：「有什麼樣的組織架構就會設計出什麼樣的系統架構」。在本例中，因爲不同的團隊負責不同的模塊，所以很自然的可以通過模塊來把系統切分成商城、推薦、評論、用戶等幾個獨立的服務：每個服務有自己獨立的版本庫和數據庫，服務之間通過 RPC 來通信。不同的服務擁有自己的版本庫，可以使用適合自己的技術棧和硬件，獨立開發獨立部署。

一個需要注意的問題是如何確定服務粒度的大小，雖然按照康威定律的描述只要按照組織架構的大小來確定服務的大小即可，但是如何規劃一個合理的團隊規模呢？實際上並沒有一個精確的答案，我們需要按照客觀情況來確定一個適合自己的大小適中的服務粒度，過小的粒度會導致服務之間強耦合，過大的粒度則背離了微服務的初衷，Uber 甚至還針對服務粒度大小問題發明了一個宏服務的概念，有興趣的讀者不妨看看。

微服務

當我們把單體架構切分成獨立的服務之後，原本模塊間本地的函數調用變成了服務間遠程的 RPC 調用，我們不得不處理服務治理之類的問題，隨着微服務數量的增加，問題會變得越來越棘手，好在隨着雲原生的發展，特別是 K8S[7] 和 istio[8] 等技術的成熟，我們的架構可以演化到 service mesh[9] 階段，通過 sidecar 透明實現服務治理。

微服務

如果僅僅是把原本模塊間本地的函數調用變成了服務間遠程的 RPC 調用的話，那麼我們的微服務很可能會淪爲「分佈式單體 [10]」。問題的癥結在於過度使用 RPC，導致服務與服務之間強耦合，解決方法是引入 Event，通過 Event 實現服務與服務的解耦。

看看如何實現下面的業務邏輯：當一個用戶註冊後，要在商城裏給用戶一張優惠券。

實際情況中應該按需求來選擇使用 RPC 或者 Event：如果是業務邏輯的實現部分，傾向於選擇使用 RPC；如果是業務邏輯完成之後的後續通知部分，強烈建議選擇使用 Event。

微服務

服務部署好了之後，接下來我們還需要考慮如何暴露服務以供前端調用，比如用戶瀏覽某個商品的詳情頁，內容包括商品數據、以及對應的推薦數據和評論數據，如果直接操作服務的話，那麼需要多次查詢商品服務、推薦服務、評論服務，並不可取，此時可以加入 API Gateway[11] 充當代理，前端只要請求 API Gateway 一次就可以拿到數據。

微服務

有了 API Gateway 之後，它可以幫我們完成聚合之類的邏輯。不過有一個問題是前端可能有多種不同的類型，比如 PC 前端，Mobile 前端，它們的業務邏輯不可避免的會有各種各樣的差異，如果在 API Gateway 中處理這些差異的話，那麼會出現壞味道，爲了解決此類問題，我們引入 BFF[12]（Backend For Frontend），每一種前端都有屬於自己的 BFF，用來處理專屬於自己的業務邏輯，至於 API Gateway，則只處理鑑權，日誌等公共業務邏輯。

微服務

微服務是個極其複雜的概念，本文僅就一些表面問題淺談一二，其他諸如 SAGA[13] 之類的複雜問題，由於篇幅所限，並未涉獵，大家如果有興趣的話請自行查閱。

最後把 Martin Fowler[14] 在 PoEAA[15] 中提出的分佈式對象第一定律 [16] 送給大家：不要分佈你的對象！套用這個說法的話，不難引申出微服務第一定律：不要使用微服務！雖然話裏有一些戲虐的成份，但是它至少告誡我們在面對微服務的時候要懷揣着一顆敬畏的心。

本文作者：老王

博客「火丁筆記」

地址：https://blog.huoding.com/2021/05/11/904

參考資料

[1]

微服務: https://martinfowler.com/articles/microservices.html

[2]

infoq: https://www.infoq.cn/topic/microservice

[3]

thoughtworks: https://insights.thoughtworks.cn/tag/microservices/

[4]

技術門檻: https://microservices.io/index.html

[5]

單體架構: https://microservices.io/patterns/monolithic.html

[6]

康威定律: https://zh.wikipedia.org/wiki / 康威定律

[7]

K8S: https://kubernetes.io/

[8]

istio: https://istio.io/

[9]

service mesh: https://www.servicemesher.com/

[10]

分佈式單體: https://skyao.io/talk/202007-microservice-avoiding-distributed-monoliths/

[11]

API Gateway: https://microservices.io/patterns/apigateway.html

[12]

BFF: https://microservices.io/patterns/apigateway.html

[13]

SAGA: https://microservices.io/patterns/data/saga.html

[14]

Martin Fowler: https://martinfowler.com/

[15]

PoEAA: https://www.martinfowler.com/books/eaa.html

[16]

分佈式對象第一定律: https://martinfowler.com/bliki/FirstLaw.html

我是 polarisxu，北大碩士畢業，曾在 360 等知名互聯網公司工作，10 多年技術研發與架構經驗！2012 年接觸 Go 語言並創建了 Go 語言中文網！著有《Go 語言編程之旅》、開源圖書《Go 語言標準庫》等。

堅持輸出技術（包括 Go、Rust 等技術）、職場心得和創業感悟！歡迎關注「polarisxu」一起成長！也歡迎加我微信好友交流：gopherstudio

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wWBlrjUUn-tx0v7ZTkha1g

猜你喜歡