技術架構閒聊：為什麼你不該用微服務架構

大家虎年快樂！下週是除夕，休刊一次。

這次的想跟大家討論的主題是微服務架構。微服務最近很紅，但他跟所有的技術名詞一樣，都有它擅長的地方和不擅長的地方，並不是可以套用在所有場景中的。

微服務的定義是：專注於單一責任與功能的小型功能區塊，利用模組化的方式組合出複雜的大型應用程式。在網路服務中，功能區塊之間通常以RPC或RESTful的方式溝通。

如果各位讀者有用過 Unix-like 作業系統，通常都會使用 grep, awk, head, tail 這些工具程式。這些工具程式組合起來，可以完成複雜的邏輯，也就是交通大學的SA課程裡面 1 liner command line 的作業。

舉例來說：

cat in.txt | head -40 | tail -20

這樣可以取出 in.txt 第 20-40 行的內容。

有沒有感覺很複雜呢？如果寫普通的程式可能不用繞這麼遠。這就是 micro service 的一個特性。它最佳化一個單一職責，讓這個模組區塊最有效率，但如果要完成比較複雜的功能，就需要多個模組通力合作，透過模組間互相的串接來完成。

也因此，如果有一個特別的 campaign 要做，在 micro service 的世界裡面，會另外開一個模組，類似寫一個 shell script的方式來處理。

微服務有幾個特性：

1. 模組間溝通頻繁，會有更多的網路額外負擔（overhead）要處理

2. 每個模組獨立，正常來說不會互相影響，也不會互相修改狀態

3. 模組和模組之間，會用異步溝通的模式（例如 Message Queue），避免互相緊密相依

因此微服務其實比較不適合：

1. 人數少的團隊，因為不容易把團隊的負責人也切出來。當負責人沒有切分出來的時候，會需要比較多的 peer review 避免模組溝通間的相依性

2. 不太需要 Scale 的服務，例如公司內的後台系統

3. 抽象化能力不好的團隊，因為會很難把商業邏輯化約成幾個簡單的模組，還要夠有彈性可以串接出新的模組

那有沒有比較折衷的方案呢？我覺得 SOA (Service-Oriented Architecture) 或許是一個中間的過度方案，如果團隊對於 Micro Service 的經驗不足，先嘗試 SOA 會是一個可行的方案。當團隊能順利掌握 SOA 的時候，再來挑戰微服務就會比較容易了。

---

接下來，固定每週一會推出一篇文章，如果你對技術管理也有興趣，歡迎按下面的按鈕來訂閱電子報喔！

如果你有興趣跟我聊聊關於技術管理，可以加入我的 LINE@。