新創公司一開始在做產品的時候,最一開始要考量的問題應該是這個 idea 是不是被市場所接受的,而非技術的問題 (擔心產品一上線就百萬人同時上線,每天百萬訂單等等議題),加上一開始的不確定因數太高了,市場給的反饋都可能造成產品需要做大幅度的調整,同時新創公司一開始的技術團隊可能都不到 5 為工程師,所以新創公司一開始的時候,單體架構 (monolith)是一個好的開始,然後一路快速迭代,到什麼時候適合評估轉換成使用微服物的時機? 同時微服務帶來那些好處呢? 這是一個很好的思考題目,歡迎一起研究。

代碼維護性

因為單體的代碼是一大包,可能在代碼裡面包含的各種模塊或服務,例如:身分認證服務、訂單服務、支付服務、設備服務等,當修改其中一個服務的代碼時然後運行CI測試,因為必須每個服務的測試都跑過一次,造成在執行自動化測試的時候會相對比較久,可能超過 20 分鐘以上等等,這時候如果已經造成維護上面的問題,可以考慮服務上面的分離

系統錯誤隔離性差

一個大的單體,裡面會包含很多服務,如果遇到某一個服務,錯誤處理沒有處理好、記憶體溢出等等造成系統掛掉,這時候是全系統都不能使用,因為服務之間沒有隔離性

可伸縮性差

單體裡面的某一個服務,可能占用的系統資源比較多,例如CPU等等,這時候如果要擴充擴容,都必須部屬完整的單體,造成有些資源的浪費,無法做到針對某個服務單獨進行擴充

部屬出錯率

因為修改一個小的 bug 當要部屬的時候,都會需要一次完整的部屬,其實有時候也會挺危險的

多種程式語言

目前有很多大數據的方案都使用 Python 的現有解決方案,所以當要使用這些方案的時候,就會遇到多程式語言的場景,這時候就要分割

部門權責分工

當公司發展越來越好,工作的任務一定會越分越細,每一個任務可以讓更專業的人來擔任,例如:金流相關的東西,會找專門的團隊來負責,數據相關方面或請數據團隊來負責,這時候就會需要進行服務的分離,這是比較好的微服務切割之一。