单体应用会遇到的问题

这里主要针对比较庞大的单体应用来讲，因为微服务本身在带来各种优势的同时也会引入非常多的问题，而处理这些问题需要攻克很多技术难题，而这些代价对于整个业务功能而言并没有什么好处。所以如果是小型应用，单体会更好一些。就像istio最终回归单体应用就是一个很好的例子，并不是微服务就比单体应用好，具体问题具体分析

代码庞大

单体应用规模非常庞大，导致一个开发者很难了解代码的全貌，修改问题成本非常高，而且很有可能出错。而不能完全理解所有场景，在修复错误时候可能导致代码更加难以理解，从而进入一个恶性循环。

开发速度慢

代码过大对IDE会造成很大的压力，代码的编译，启动都会比较慢

测试复杂，开发周期长

因为所有团队都要把代码提交到一个库里面，一次更新所有团队都有修改，这些要合并在一起并不容易，而且代码涉及的功能非常复杂，测试很难覆盖所有场景，各团队之间修改，调用沟通成本也会增加。导致一次开发周期比较长

难以横向扩展

每个模块对环境的依赖都不一样，例如有的模块需要大块的内存，有的模块如图形处理模块需要大量的CPU资源用作图形计算。而一个单体应用要部署的环境需要满足所有模块的需求

高质量交付困难

功能过于集中复杂导致难以全面测试，缺乏可靠测试容易出现bug。单体应用由于所有模块集中在一起，因而缺乏有效的故障隔离，一块出问题，就意味着整个应用都有问题。

需要长期依赖可能过时的技术栈

这个也好理解，早期开发的时候，使用的技术栈，包括语言，框架等，随着技术的变革就会慢慢的落后。但是想要更新这些框架的话所有模块都会受到影响，风险无法预估，所以技术变更代价将会非常高昂，让人望而却步。