單一業務開發和迭代困難
有人可能不太理解，認爲有一個業務變更，我們開發就是了。那其實就牽扯到三個部分：
- 有可能只是針對剛纔的用戶模塊，新增了很多需求，而其他模塊沒有任何的變更。首先不談開發的難度，就說將用戶模塊所有的業務都開發完畢了，在測試領域有一個叫“冒煙測試”，有一個叫“迴歸測試”，測試人員要針對用戶模塊的修改除了要測試用戶模塊外，還要測試很多其他的模塊，那這種情況就帶來一個問題——哪怕一個微小的改變，對測試人員來說工作量都是非常大的。
- 用戶模塊的開發，很有可能會影響其他的模塊，比如我們的公共代碼，可能其中有些工具類出問題了，公共類我們是輕易不能動的，因爲動了公共類，就會對所有的代碼產生影響。
- 當我們發現一種新的技術，準備在使用時候。比如說，傳統的業務開發中，發現數據庫是瓶頸，那我們有可能要集成一些緩存系統、搜索引擎系統，這時候要對原來的代碼進行很大的修改。尤其是需要增加一些依賴包，這些新增的包可能跟原來的包起衝突，如果衝突了，雖然這個模塊調好了，但是其他的模塊又不能用了。
這樣說來，對於傳統的單一模塊，對我們來說開發是相當的困難的。
擴容困難
比如說，我們的一個業務系統，包含了用戶模塊、訂單模塊、影院模塊，我們的用戶模塊併發量其實並不是很大，而影院模塊也不是特別大，可是訂單模塊已經不足以支撐業務了。就是現在的配置已經不夠了，原來內存是256G，現在需要512G了。這時候要想到原來的傳統應用是統一部署的，它們是共享256G的內存，那再增加256G內存，訂單模塊有可能只增加了256/3的內存，因爲有3個業務模塊，3個模塊是共享的一個jvm。這種情況下，訂單模塊不夠了要增加256G內存，那可能需要增加到一個T的內存，才能達到目標。
部署和回滾困難
- 傳統應用在部署的時候，會牽扯到很多東西。比如用戶模塊需要ES，訂單模塊需要Rdis，院線模塊需要搜索引擎，那這種情況部署一個應用就要把ES、Redis、搜索引擎全都要部上，應用系統才能跑起來。
- 回滾說起來就比較簡單了。比如我們用戶模塊和訂單模塊都做了修改，用戶模塊沒有問題，訂單模塊上線後出問題了，那就要將全部的東西都回滾。假如一個300人的團隊開發一個電商平臺，上線一個版本將是很麻煩的，光測試就要4-6月的時間。上線都是要熬通宵的，在半夜3點時候發現訂單模塊出問題了，那用戶模塊的項目組也要跟着，因爲回滾後他們要做測試。只是因爲訂單模塊的一個小問題，導致所有人都留在公司。所以說，回滾起來是相當麻煩的。
