新創何時要考慮轉成微服物架構?

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

代碼維護性

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

系統錯誤隔離性差

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

可伸縮性差

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

部屬出錯率

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

多種程式語言

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

部門權責分工

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