一个工程对应一个war包，这个war包包含了该工程的所有功能。我们称这种应用为单体应用，也就是我们说的单体架构。
优点：
①架构简单明了，从前端到后台结构清晰，没有其他花里胡哨的东西
②开发测试，部署简单（尤其运维，睡着都会笑醒)
缺点：
①随着业务发展，代码越来越复杂，代码质量参差不⻬（开发人员水平不一）
②部署慢(想象一下几百M的代码部署速度)
③扩展成本高，如用戶模块是一个cpu密集型（涉及大量运算）的模块，我们需要更加牛逼的cou，订单模块是一个io密集型（涉及大量磁盘读写）的模块，那么我们就需要更加牛逼的内存以及更加牛逼的内存和高效的磁盘，但是我们单体架构无法针对单个功能模块进行扩展
④阻碍了新技术的发展（将struts2迁到spingboot，将是灾难性的）
1.3微服务架构微服务核心就是将传统的单机应用，根据具体的业务将单机应用拆分成一个一个的服务，彻底解耦，每一个服务提供一个特定的功能，一个服务只做一件事，职责划分，每个服务都能单独部署，这样一个一个小的服务就是微服务
优点：
①每个服务只针对一个业务功能点，代码更加容易理解
②开发简单，一个服务员只干一件事情，提高效率
③按需伸缩，前后端分离，只需关心后端接口的安全性以及性能
④一个服务可以有自己的数据库
缺点：
①增加运维人员的工作量，单体只部署一个war包，现在可能需要部署成百上千的包
②服务之间相互调用，增加通信成本，代理一系列超时，限流熔断，以及兜底处理
③数据一致性问题（分布式事务）
④系统全链路监控，问题定位
1.5微服务适用场景适合:
①大型复杂的项目（单体架构几百M的代码）
②快速迭代的项目（一天发一版）
③并发高（考虑弹性伸缩扩容）
不适合：
①业务稳定，就是改改bug，改改数据库
②迭代周期⻓，半个月或者一个月发版一次
,
