单体架构：把业务模块写在一个项目中，最终打包成war包，然后部署。例如—
单体架构的不足：
<一> 业务越来越复杂，可维护性和可扩展性下降，业务扩展带来的代价越来越大。
<二>随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
<三>测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张、复杂度.。
单体架构优点：
<一> 部署简单，因为都在一个war包里。
<二>技术简单，基础的就SSM
<三>用人简单
————————————————————————————————————————————————————————
为服务系统架构
微服务系统框架的优点：
而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。
<一> 每个微服务可由不同团队开发
传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。
<二> 微服务是松散耦合的
微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用Restful的方式。
<三> 可用不同的编程语言与工具开发
传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用Node.js来开发一个简单的报表页面，使用C++来编写一个实时聊天组件。