单体应用确实有问题！
人类发展的历史就是一个社会分工不断细化的历史，从这个角度来讲，微服务这种将一个复杂的大项目拆分为众多小项目，然后程序员分工合作，共同完成项目，这种协作方式是符合历史潮流的。
这是我们站在今天的角度来说的，曾经的单体应用也是先进生产力的代表。
但是，随着互联网的发展，我们对一个系统的要求越来越高，单体应用已经很难适应当前的开发，因此在回答我们为什么要使用微服务这个问题之前，我们有必要来聊一聊单体应用目前都面临哪些问题。
面临的问题
1.项目过度复杂
你要创建一个简单的用户管理系统，二话不说，直接创建 Maven 项目然后开干就完事了，这没问题，因为这很简单。
但是你要说想搞一个淘宝网站，或者你想搞一个用友 U8 系统，那你恐怕就得先慢慢设计系统架构了。单体应用，由于就是一个项目，所有的功能都是写在一个项目中，不可避免的出现项目过度复杂的情况。而且这种复杂情况会不断恶化。
有的小伙伴可能有这样的经验，刚入职了一家公司，新接手了一个项目，上面催的很急，让你赶快修复几个 bug ，项目复杂，光是实体类的包就有好几个 bean、model、pojo 等，一个项目被很多人经手之后，到你手里，早已经一团乱麻，你小心翼翼尽量不碰触到已有的功能，终于修完了几个 bug，搞了俩礼拜，你觉得这个项目太坑爹了，不想干了，于是接盘侠从你手里接到了一个复杂度又上升了一步的项目。
就这样，一个原本简简单单的单体项目，在变复杂的路上一去不复返。
2.开发速度缓慢
单体应用开发速度缓慢，因为单体应用复杂了之后，项目变得异常臃肿而且庞大，每一次编译构建、运行以及测试，都需要花费大量时间，而且如果测试有问题，又得从头来一遍，注意，这里的每一次从头编译构建等都是整个项目的从头编译构建。
即使你可能只要修改某一个参数，你也得把上面整个流程走一遍，相当于每一次的修改都是牵一发而动全身的操作。
速度没法快。
3.不易扩展
项目中不同模块对计算机的性能要求不一样，例如使用 Redis 来保存了大量的热点数据，那么我们希望服务器的内存非常大，另外有一个模块涉及到了图片处理，我们又希望服务器的 CPU 非常强，如果是单体应用部署的话，那么这些条件服务器都要满足。
4.技术栈不易扩展
单体应用还有一个劣势就是技术栈不易扩展，一旦你选定了某一个技术栈来开发项目，以后很难在技术栈上做切换。有的公司还会自己搞一套系统，这种在当时看起来好像都没有啥问题，可是经过几年之后，回头再看，已经很过时了，很 low 了，当初设计系统的人可能已经离职了，刚入职的新手也不敢动这个老古董，只能在这个老古董上面忍痛开发。
有的时候，有一个服务需要处理高并发，你很想用 Go 语言来做，可是做不到，没法引入其他语言。
这些都是单体应用的劣势，如果有微服务，上面这些问题都将得到解决。
曾经的优势
当然，事物都是有两面性的，单体应用也有它自己的优势，例如：
- 开发简单，一个 IDE 就可以快速构建出一个单体应用
- 测试简单
- 部署简单，Tomcat 安装好之后，应用扔上去就行了
- 集群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟就搭建好集群环境了
这么多优势，还是难掩劣势。
不过大家在做项目的时候，还是要结合实际情况来选择，不能因为微服务厉害，所有项目都是微服务，如果你仅仅只想做一个用户的增删改查，那么很明显，创建一个简单的单体应用是最合适的。
标签：服务,项目,一个,吹微,单体,天天,复杂,应用 来源： https://blog.csdn.net/weixin_45154607/article/details/98057272
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。