單體式系統與微服務

最近重讀 Sam Newman的『建構微服務』,覺得實在精彩。真心以為,想作微服務系統的開發人員,都值得花點時間讀一下第一章,絕對值回票價。

我把讀完的感想和摘要寫在下面,希望能夠幫助大家釐清什麼是微服務(以及什麼不是)。

傳統來說,古典的單體式應用(Monolith)大多意指在同一個行程內運行的應用系統,底下是典型的單體式應用程式與其變形。

圖片

古典的單體應用程式

一個應用程式,後面搭配一套DB,但上面這樣的系統已經愈來愈少了,只剩下像是手機app或是極端傳統的desktop app。

如今大部分的單體式應用系統(不管是desktop或web),大多會是底下這樣:
圖片

模組化單體式應用程式
  1. 模組採用同樣(或近乎類似)的開發技術。
  2. 模組間有共用的基礎設施(infrastructure),像是log, security…etc.
  3. 即便模組可以獨立運行,但依舊必須一起佈署。

單體式應用系統的優點

相較於微服務,單體式應用系統其實有很多優點:

  1. 簡化開發人員工作流程
  2. 簡化監控、故障排除、與測試

這是事實,但Sam Newman強調『最近人們開始將單體式系統視為「時代遺產」的同義詞,仿佛這種系統有著什麼本質上的問題,是一個需要避免的東西…』

但其實,單體式架構只是一種選擇,甚至是一種有效的選擇。Sam Newman認為:『這是一個作為架構風格合理的預設選項(我欣賞這句話)』,換句話說,我也認為,面對架構選擇,人們應該尋找一個能被說服使用微服務的理由…

微服務架構

圖片

我們很久以前就談過微服務,但到底什麼是微服務?

Sam Newman在書中,對微服務的核心概念做了說明,我覺得包含幾個重點:

  • 可獨立佈署:微服務的每一個單元應該能夠單獨部署,而不需要依賴其他服務。這種可抽換性使得應用程式更加靈活,可以更快地部署和更容易地維護。這也意味著,當你抽換一個微服務、另一個微服務不該受到影響。
  • 圍繞著Business Domain塑模:每個微服務都應該圍繞一個具體的Business Domain來設計,而不是根據技術或企業組織架構來劃分。這種業務驅動的作法使得應用程序更加緊密地與業務相關,並能夠更好地支撐業務需求的變化。(這一點很多公司其實先天就無法做到,參考底下『架構和組織的調整』)
  • 大小:微服務應該要足夠小,以便能夠單獨佈署和管理。這也意味著每個微服務應該只關注一個特定的Business Domain,而不是試圖做太多的事情。
  • 擁有自己的狀態:每個微服務都應該擁有自己的狀態,包括自己的資料庫、Configration和State。這種狀態的獨立性使得微服務更加可靠,並能夠更好地處理高併發流量和分散式操作。這也表示,多個微服務不該共用同一個資料庫或資料表。如同物件導向程式設計的封裝概念,微服務應當可以自己決定如何與其他服務共享資料、或是隱藏資料。如此才能夠自由的變更修改服務內部的行為(而不影響其他單元)。
  • 架構和組織的調整(這一點很殺,幾乎沒收了台灣大部分有規模的企業進入微服務的入場券):傳統的三層式架構之所以會出現,除了它本身容易理解與簡單之外,還應驗了康威定律(Conway’s Law),也就是,系統的架構會自然相似於組織架構。請看這個傳統的架構:
    圖片

有沒有發現,上面每一層剛好是由不同的團隊負責的。這導致在許多大公司內,一個系統需要多個部門一起負責。

但在上面這個架構底下,當我們想要變更(或增加)一個功能時,就得動用到三個部門的人,而部門的設計所造成的Silo(穀倉效應),使得三個部門的人多半有著彼此不同的立場和目標,導致新功能的實現曠日廢時。

隨著敏捷開發與自組織概念的發展,現在軟體開發團隊逐漸採用混合型組織來設計。意即,每一個團隊直接對應到一個客戶的商業需求或服務,而非對應到一項企業內員工的專業技能:
圖片

DB、後端、前端、UIUX設計、業務商業人員…都被打散重組在一個團隊中(所謂的團隊,是擁有著共同的目標,或說的通俗一點,有共同KPI和考績的一群人)。這樣的一個混合型團隊中,會有各種不同技能的人員,以便於能夠好好地滿足客戶的一種服務需求。而我們的系統架構,也從傳統(以職能為區分)的三層式的架構,轉換成(以Business Domain為導向)的微服務系統設計。請注意這也意味著若微服務如前述的以Business Domain塑模,那企業的團隊結構就很可能會被打散重新調整,這樣的微服務才更有意義。

以上這些就是微服務的本質,也是切分服務邊界的重要思路。有沒有發現很多人卡關在哪裡?很多公司常常想要在不動組織架構和既定思維的狀況下,實踐敏捷或微服務,若是這樣,又何苦找自己麻煩呢?

微服務並不意味著比單體式應用程式更優秀,相反的,為了得到微服務所可能帶來的好處(像是獨立佈署、獨立運行、資訊隱藏、高延展性、技術異質性、企業組織對齊…等),必須附上許多代價,像是應用程式開發的複雜度就大大提升。

因此開發團隊必須認真找到你使用微服務的理由,正如同 Sam Newman說的:『…面對架構選擇,人們應該尋找一個能被說服使用微服務的理由,而非尋找一個不使用的理由。


相關教育訓練:
https://www.studyhost.tw/NewCourses/Architecture
https://www.studyhost.tw/NewCourses/aspnetcoreauth

若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...