[TOC] # 業務場景  一開始,業務復雜性不高 剛開始,開發的系統是驗證業務是否能存活 一開始不推薦使用,微服務需要基礎設施投入 單塊開發,成本低,先驗證下商業模式 --- 當業務成長起來,業務變復雜了,生產力也下降了 當交叉的時候,就是我們考慮微服務了 這個點的把控,需要架構師把控和權衡,團隊接近百人的話,應該要考慮了 # 場景 一開始我們是把架構設計成微服務,還是設計成單塊呢? **單塊優先**  上面路線是微服務路線,直接走向微服務 當我們一開始就這樣做,但是我們并不能完全把控這個微服務中問題,們對業務不清晰,業務多變,不能把控這個服務的邊界 就算我們把控住了,我們開發的產品,不一定被用戶接受 <br> 下面路線,單塊路線,我們先把功能打包在一起,當業務成長,我們對業務越來越清晰 我們可以把服務一個個拆分開來 一步步演化成微服務 # 問題 架構是設計出來的,還是演化出來的?