大家虎年快樂!下週是除夕,休刊一次。
這次的想跟大家討論的主題是微服務架構。微服務最近很紅,但他跟所有的技術名詞一樣,都有它擅長的地方和不擅長的地方,並不是可以套用在所有場景中的。
微服務的定義是:專注於單一責任與功能的小型功能區塊,利用模組化的方式組合出複雜的大型應用程式。在網路服務中,功能區塊之間通常以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的方式來處理。
微服務有幾個特性:
模組間溝通頻繁,會有更多的網路額外負擔(overhead)要處理
每個模組獨立,正常來說不會互相影響,也不會互相修改狀態
模組和模組之間,會用異步溝通的模式(例如 Message Queue),避免互相緊密相依
因此微服務其實比較不適合:
人數少的團隊,因為不容易把團隊的負責人也切出來。當負責人沒有切分出來的時候,會需要比較多的 peer review 避免模組溝通間的相依性
不太需要 Scale 的服務,例如公司內的後台系統
抽象化能力不好的團隊,因為會很難把商業邏輯化約成幾個簡單的模組,還要夠有彈性可以串接出新的模組
那有沒有比較折衷的方案呢?我覺得 SOA (Service-Oriented Architecture) 或許是一個中間的過度方案,如果團隊對於 Micro Service 的經驗不足,先嘗試 SOA 會是一個可行的方案。當團隊能順利掌握 SOA 的時候,再來挑戰微服務就會比較容易了。
接下來,固定每週一會推出一篇文章,如果你對技術管理也有興趣,歡迎按下面的按鈕來訂閱電子報喔!
如果你有興趣跟我聊聊關於技術管理,可以加入我的 LINE@。
技術架構閒聊:為什麼你不該用微服務架構
請問 SOA 與 Microservice 的差異是?