系統架構：每秒1萬次請求的系統要做成服務化拆分嗎？
DAU(Daily Active User)日活躍用戶數量
1 一體化架構的痛點
項目剛開始的時候，爲了儘快搭建項目，儘快上線，一般都採用一體化架構，即單體應用。
- 開發簡單直接，代碼和項目集中式管理
- 只需要維護一個工程，節省維護系統運行的人力成本
- 排查問題的時候，只需要排查這個應用進程就可以了，目標性強
但是隨着系統功能越來越複雜，開發團隊越來越大，一體化架構的缺陷也就顯露出來了
-
技術層面，數據庫連接數可能成爲系統的瓶頸
-
研發成本上，團隊增加導致溝通成本呈指數級增長
《人月神話》中曾經提到：一個團隊內部溝通成本和人員數量 n 有關，約等於 n(n-1)/2，也就是說隨着團隊人員的增加，溝通的成本呈指數級增長，一個 100 人的團隊需要溝通的渠道大概是 100（100-1）/2 = 4950。爲了減少溝通成本，我們一般會把團隊拆分成若干個小團隊，每個小團隊 5～7 人負責一部分功能模塊的開發和維護。
-
一體化架構對於系統的運維，每次修改上線都需要構建整個項目
2 如何使用微服務化解決痛點
將一體化架構進行拆分，按照業務橫向拆分。各個拆分出來的子系統分別連接自己對應的數據庫，解決數據庫連接瓶頸；各個小團隊負責自己單獨的服務，降低大團隊中溝通成本；某個子系統修改上線，降低對其他服務的影響。
但是，微服務化之後，原有單一系統被拆分成多個子服務，在開發和運維方面也會引入額外的問題。