單體式系統與微服務
最近重讀 Sam Newman的『建構微服務』，覺得實在精彩。真心以為，想作微服務系統的開發人員，都值得花點時間讀一下第一章，絕對值回票價。
我把讀完的感想和摘要寫在下面，希望能夠幫助大家釐清什麼是微服務(以及什麼不是)。
傳統來說，古典的單體式應用(Monolith)大多意指在同一個行程內運行的應用系統，底下是典型的單體式應用程式與其變形。
古典的單體應用程式
一個應用程式，後面搭配一套DB，但上面這樣的系統已經愈來愈少了，只剩下像是手機app或是極端傳統的desktop app。
如今大部分的單體式應用系統(不管是desktop或web)，大多會是底下這樣：
模組化單體式應用程式
- 模組採用同樣(或近乎類似)的開發技術。
- 模組間有共用的基礎設施(infrastructure)，像是log, security…etc.
- 即便模組可以獨立運行，但依舊必須一起佈署。
單體式應用系統的優點
相較於微服務，單體式應用系統其實有很多優點:
- 簡化開發人員工作流程
- 簡化監控、故障排除、與測試
這是事實，但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專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。
留言