单体架构的好处：
应用的开发很简单：IDE和其他开发工具只需要构建这一个单独的应用程序。易于对应用程序进行大规模的更改：可以更改代码和数据库模式，然后构建和部署。测试相对简单直观：开发者只需要写几个端到端的测试，启动应用程序，调用RESTAPI,然后使用PostMan这样的工具测试用户界面。部署简单明了：开发者唯一需要做的，就是把WAR文件复制到安装了Tomcat的服务器上。横向扩展不费吹灰之力：可以运行多个实例，由一个负载均衡器进行调度。但是，随着时间的推移，开发、测试、部署和扩展都会变得更加困难。
下面我们盘点一下单体架构的缺点：
过度的复杂性会吓退开发者
当单体系统本身过于庞大和复杂，以至于任何一个开发者都很难理解它的全部。因此，修复软件中的问题和正确地实现新功能就变得困难且耗时。各种交付截止时间都可能被错过。
更糟糕的是，这种极度的复杂性正在形成一个恶性循环：由于代码库太难于理解，因此开发人员在更改时更容易出错，每一次更改都会让代码库变得更复杂、更难懂。
开发速度缓慢
因为系统极度复杂，这个巨大的项目把开发人员的IDE工具搞得很慢，构建一次应用需要很长时间，更要命的是，应为应用太大，每启动一次都需要很长的时间。因此，从编辑到构建、运行到测试这个周期花费的时间越来越长，这严重地影响了团队的工作效率。
从代码提交到实际部署的周期很长，而且容易出问题
众多开发人员都向同一个代码库提交代码更改，这常常使得这个代码库的构建结果处于无法交付的状态。当尝试采用功能分支来解决这个问题时，带来的是漫长的且痛苦的合并过程。紧接着，一旦团队完成一个冲刺任务，随后迎接他们的将是一个漫长的测试和代码稳定周期。
把更改推向生产环境的另一个挑战是运行测试需要很长时间。因为代码库如此复杂，以至于一个更改可能引起的影响是未知的，为了避免牵一发而动全身的后果，即使是一个微小的更改，开发人员也必须在持续集成服务器上运行所有的测试套件。系统的某些部分甚至还需要手工测试。如果测试失败，诊断和修复也需要更多的时间。因此，完成这样的测试往往需要数天甚至更长时间。
难以扩展
因为在有些情况下，应用的不同模块对资源的需求是相互冲突的。例如，餐馆数据保存在一个大型的内存数据库中，理想情况下运行这个应用的服务器应该有较大容量的内存。另外，图片处理模块又需要比较的CPU来完成图形运算，这需要应用部署在具有多个高性能的CPU的服务器之上。因为这些模块都是在一个应用程序中，因此在选用服务器时必须满足所有模块的需要。
交付可靠的单体应用是一项挑战
系统不可靠的一个原因是应用程序过于庞大而无法进行全面和彻底的测试。缺乏可靠的测试意味着代码中的错误会进入生成环境。更糟糕的是，应用程序缺乏故障隔离，因为所有的模块在同一个进程中运行。每隔一段时间，在一个模块中的代码错误，例如内存泄露，将会导致应用程序的所有实例都崩溃。开发人员不喜欢在半夜因为生产环境的故障而被叫醒，业务人员也对由此造成的收入损失和丧失客户信任而头痛不已。
需要长期依赖某个可能已经过时的技术栈
单体地狱的最终表现，也体现在团队必须长期使用一套相同的技术栈方面。单体架构使得采用新的框架和编程语言变得极其困难。在单体应用上采用新技术或者尝试新技术都是极其昂贵和高风险的，因为这个应用必须被彻底重写。结果就是，开发者被困在了他们一开始选择的这个技术之中。有时候这也就意味着，团队必须维护一个正在被废弃或过时的技术所开发的应用程序。
互联网用户应该了解的——web安全漏洞，看看你都知造吗
SQL注入是普通使用的一种攻击手段，为了防止SQL注入，我们必须
开源介绍——基于binlog的mysql增量订阅组件(一)