## 12.2 单体系统到系统拆分 如果你对上一节还有疑惑，在想为什么我不把所有系统放到一个工程里，打成一个war包，也就是我们所谓的单体系统呢？ 单体系统确实是一种常见系统设计方式，这十几年年来最主要的设计方式。单体系统的所有功能都在一个工程里，打成一个war包，部署。这样有如下明显好处 * 单体系统开发方式简单，我们从刚开始学习编程，就是完成的单体系统，开发人员只要集中精力开发当前工程 * 容易修改，如果需要修改任何功能，都非常方便，只需要修改一个工程范围的代码 * 测试简单，单体系统测试不需要考虑别的系统，避免本书下册要提到的各种REST，MQ调用 * 部署也很容易：不需要考虑跟别的系统关系，直接打war包部署到Web服务器即可 * 性能容易扩展，可以通过Nginx，把一个应用部署到多个服务器上。 随着业务发展，重构，单体系统越来越多，在开发一个庞大的单体系统的时候，就会有如下弊病 * 单体系统庞大，越来越难理解单体系统，微小的改动牵涉面广泛导致开发小组小心谨慎，开发速度会越来越慢。另外，启动一个庞大的单体系统，可能需要3分钟，或者更多时间 * 多个功能在同一个单体系统上开发，导致测试越来越慢，比如，测试必须排期，串行测试 * 单体系统如果想对技术进行更新换代，那代价非常大，如果是个小系统构成，则可以选取一个小系统先做尝试。单体大系统是几乎不可能做技术升级的 * 单体系统的所有功能运行在同一个JVM里，功能会互相影响，比如一个统计上传word文档的页码的功能由于非常消耗CPU，因此，会因为调用统计功能，导致整个系统短暂都不可用，出现假死的现象 因此，越来越多的架构师在设计系统的时候，会考虑系统拆分成多个单体小系统甚至是微服务。对于传统企业应用，拆成小系统更合适，对互联网系统，使用微服务个更合适，这是因为 * 传统IT系统本质上还是会用一个数据库，而微服务提倡的是一个服务一个数据库 * 传统IT系统很少需要调用其他模块服务。传统IT系统通过工作流来串联其他子系统。而电商类的微服务则是通过RPC等方式进行交互，是一个轻量级协议。传统IT系统也可以通过SOA，JMS跟其他系统(非子系统)交互，采用重量级协议 * 微服务对系统的基础设施要求很高，比如微服务治理，弹性库等等，只要电商系统才有人力物力去做这种事情，而传统IT系统，及时财大气粗，也暂时不具备微服务那样的IT基础设置 因此，对于大多数传统IT应用来说，单体拆分小系统在技术上没有风险，是一个可以立即实施的架构。如下是一个单体系统拆分后的物理架构  对于用户来说，访问不同的菜单功能，讲定位到不同的子系统，提供服务。 > 关于如上物理架构实现，在本书的下册。plus系统即可以拆分成小系统，也可以作为一个单体系统来设计。这一章主要介绍plus系统的核心功能和开发方法