一、传统应用带来的问题

单一业务开发和迭代困难

有人可能不太理解，认为有一个业务变更，我们开发就是了。那其实就牵扯到三个部分：

1. 有可能只是针对刚才的用户模块，新增了很多需求，而其他模块没有任何的变更。首先不谈开发的难度，就说将用户模块所有的业务都开发完毕了，在测试领域有一个叫“冒烟测试”，有一个叫“回归测试”，测试人员要针对用户模块的修改除了要测试用户模块外，还要测试很多其他的模块，那这种情况就带来一个问题——哪怕一个微小的改变，对测试人员来说工作量都是非常大的。
2. 用户模块的开发，很有可能会影响其他的模块，比如我们的公共代码，可能其中有些工具类出问题了，公共类我们是轻易不能动的，因为动了公共类，就会对所有的代码产生影响。
3. 当我们发现一种新的技术，准备在使用时候。比如说，传统的业务开发中，发现数据库是瓶颈，那我们有可能要集成一些缓存系统、搜索引擎系统，这时候要对原来的代码进行很大的修改。尤其是需要增加一些依赖包，这些新增的包可能跟原来的包起冲突，如果冲突了，虽然这个模块调好了，但是其他的模块又不能用了。

这样说来，对于传统的单一模块，对我们来说开发是相当的困难的。

扩容困难

比如说，我们的一个业务系统，包含了用户模块、订单模块、影院模块，我们的用户模块并发量其实并不是很大，而影院模块也不是特别大，可是订单模块已经不足以支撑业务了。就是现在的配置已经不够了，原来内存是256G，现在需要512G了。这时候要想到原来的传统应用是统一部署的，它们是共享256G的内存，那再增加256G内存，订单模块有可能只增加了256/3的内存，因为有3个业务模块，3个模块是共享的一个jvm。这种情况下，订单模块不够了要增加256G内存，那可能需要增加到一个T的内存，才能达到目标。

部署和回滚困难

1. 传统应用在部署的时候，会牵扯到很多东西。比如用户模块需要ES，订单模块需要Rdis，院线模块需要搜索引擎，那这种情况部署一个应用就要把ES、Redis、搜索引擎全都要部上，应用系统才能跑起来。
2. 回滚说起来就比较简单了。比如我们用户模块和订单模块都做了修改，用户模块没有问题，订单模块上线后出问题了，那就要将全部的东西都回滚。假如一个300人的团队开发一个电商平台，上线一个版本将是很麻烦的，光测试就要4-6月的时间。上线都是要熬通宵的，在半夜3点时候发现订单模块出问题了，那用户模块的项目组也要跟着，因为回滚后他们要做测试。只是因为订单模块的一个小问题，导致所有人都留在公司。所以说，回滚起来是相当麻烦的。