单体应用
单体应用：所谓的单体应用就是指一个war包包含了项目的所有功能。尽管有一个逻辑模块化架构，但应用程序被作为一个单体进行打包和部署。例如，我们所熟知的许多Java应用程序被打包成WAR文件部署在如Tomcat或者Jetty之类的应用服务器上。其他Java应用程序被打包成可执行JAR包。
单体应用的特点：
-
容易开发：开发者只需要在专用的开发工具上比如（Eclipse，myEclipse)等就可以管理整个项目代码，完成代码开发工作。
-
容易运行和测试：既然我们能够在本地开发工具上完成整个项目的功能开发和调试，自然也就很容易在我们本地环境上进行测试调试。
-
容易部署：正如我们在举例单体应用构建项目时所说，当应用程序开发，调试，测试完成以后，我们只需要将代码进行打包，然后将打包好的应用程序拷贝到服务器上进行部署即可。
我们拿一个常见的互联网公司的静态逻辑架构来举例，我们通过如下的架构图将系统切分成五层，如下图所示：
应用层：面向客户的最终软件产品，直接暴露给互联网的各种App、Web站点以及Wap站点。
前置服务层：各种重业务的聚合入口，对具体引用层做大量工作，实现业务调用链条的封装，达成业务逻辑的强实现。
业务服务层：包含各种基础的业务服务单元，比如借款系统、还款系统、征信系统、活动系统、爬虫系统、引流系统、文件系统等。
基础服务层：不包含状态的基础业务服务，包括但不限于短信网关、文件网关、服务监控等。
数据层：包括各种形态的数据存储层，但不限于各种数据库、缓存、消息队列等。
走向单体地狱
我们在进行开发一个新的应用时，可以构建一个整体的应用系统，我们称之为单体应用。当我们的应用刚开始起步，业务功能少，代码量可控时，我们还能正常的开发。
局限性
但是，随着系统业务的不断增长，代码量不断增加，我们维护创建的单体应用系统的性能和维护成本都会受到限制，限制了我们继续新增新业务的能力。
单体应用发展趋势
成功的应用有一个趋势，整个项目随着时间推移会变得越来越臃肿。而开发团队在每个迭代开发周期中都要实现更多的用户需求，这意味着需要添加许多行代码。当原来的单体应用运行维护几年之后，小而简单的应用将会逐渐成长成一个庞大的应用。
问题与困境
一旦应用程序成为了一个庞大、复杂的单体应用，整个开发团队可能就会陷入一个痛苦的境地，可能会遇到很多很多的问题，比如说：
-
敏捷开发受挫
主要问题是：应用程序实在非常复杂，其对于任何一个开发人员来说显得过于庞大。最终，正确修复 bug 和实现新功能变得非常困难而耗时。
就拿应用启动时间这一项指标来说，应用程序越大，启动时间越长。曾经听说过某应用程序启动需要 40 分钟以上的怪事。如果开发人员经常要重启应用服务器，那么很大一部分时间都是在等待中度过，这将极大的影响我们的工作效率。
-
持续部署受挫
另一个大问题是，复杂的单体应用本身就是持续部署的障碍。如今，SaaS（Software-as-a-Service软件即服务）应用发展到了可以每天多次将变更推送到生产环境。这对于复杂的单体来说非常困难，因为这需要重新部署整个应用程序才能更新其中任何一部分。联想到之前提到的漫长启动时间，这也不会是什么好事。
此外，因变更所产生的影响通常不是很明确，开发者很可能需要做大量的手工测试。比如，我们仅仅是修改某个部分的代码，但是因为是全部部署，因此我们必须要重新将整个系统进行全链路测试，这样将耗费非常多额外的时间。
因此，持续部署是不可能做到的。
-
应用难以扩展
当不同模块存在资源需求冲突时，单体应用可能难以扩展。例如，一个模块可能会进行密集型图像处理逻辑，理想情况下是部署在云服务器A实例中；另一个模块可能是一个内存数据库，最适合部署到云服务器B实例中。但是，由于这些模块是属于同一个应用，只能被部署在一起，此时就要求运维人员必须在硬件选择上做出妥协和让步，因此就使得原本我们设计的系统处理业务的能力会受到硬件环境的限制。
-
可靠性低
单体应用的另一个问题是可靠性低。因为所有模块都运行在同一进程中。任何模块的一个 bug，比如内存泄漏，可能会拖垮整个进程。
此外，由于应用程序的所有实例都是相同的，该错误将影响到整个应用的可用性，对整个应用都造成影响。
-
技术升级困难
单体应用因为提及庞大，使得采用新框架和语言变得非常困难。假设有50万行代码使用了某个框架编写。如果使用较新的一个框架来重写整个应用，这将非常昂贵（在时间和成本方面）。因此，这对于团队采用新技术，对系统进行技术升级来说是一个非常大的障碍。