到底怎麼切微服務這是個蠻好發起的問題，以下是我跟我的前同事 丁丁 再吃晚餐時隨口聊的，覺得蠻有趣的所以寫寫文章。
為什麼要切微服務
- 當一個組織想做一些架構重構的時後，首先要想的並不是服務怎麼切，應該要想為什麼要切
對於一個對技術有相對熱忱的工程師來說，我知道遇到問題不去想解法是件很難的事情。但就我自己的再經歷的前公司的微服務後加上前前後後看到的一些架構後，回頭反思一下，得到了一個啟發：
當遇到問題的時候，是不是應該先想一下眼前這個問題是不是問題，又應該說目前這個情況的問題點在哪？
仔細想想後，會讓工程師想要切微服務的問題應該有以下幾種
- 效能瓶頸
- 架構複雜導致更改
效能瓶頸
如果是因為這個問題而想切服務… 好像不會比較好反而會更差哈。 主要是因為微服務會將專案切成一個個的 container 運作嘛，那當服務之間要互相溝通時，就會需要透過 http 或是 grpc 這種協定去做溝通，而不是像單體式架構一樣簡單透過 reference的方式進行引用。所以效能瓶頸不會是我想要切微服務的問題點。
架構複雜導致更改
這是個蠻值得思考的問題，首先先來針對複雜 這件事情來做思考，甚麼樣的架構會複雜到需要拆分？
- 以一個工程師的角度，想法是職責不單一，專案負責的功能太多了
- 就我目前的看法是，什麼架構的東西都馬是人想出來的。與其說是架構複雜，不如來思考看看是不是組織過於複雜？
會有這個想法，也是近期與保哥共事時有稍微講到的 康威定律 Conway’s Law 有關，詳細的可以到這邊做 reference。 總之康威定律指出團隊的組織結構及溝通的模式會直接呈現在專案架構上。
基於這點其實就可以讓工程師們思考這件事情
職責單不單一的到底是專案還是自己。
怎麼切微服務
以下步驟是我自己的見解：
- 先切好組織架構也就是分 team，這邊我們分法會是以功能為角度去分。
- 規定 team 之間各自維護各自的專案
- code 之間僅能使用 api 進行資源上的依賴。
- 不可以共用 table/DB
- 讓時間慢慢過，靜觀其變
- 步驟 1~3 每隔一段時間做一次
結論
其實上面所說的都是想表達一件事情
不要為了微服務而微服務
還有… 晚餐的牛排還不錯吃，能吃出一篇文章。