1 传统单体系统介绍
在很多项目的业务初期阶段，高速迭代上线是首要考虑的事情，对后期的容量预估、可扩展性和系统健壮性、高可用一般没有那么重视。但随着业务的发展，用户量、请求量的暴增，
发现原来的单体系统已经远远不满足需求了，特别是随着互联网整体的高速发展，对系统的要求越来越高。
但是物理服务器的CPU、内存、存储器、连接数等资源有限，单体系统能够承受的的QPS也是有限的，某个时段大量连接同时执行操作，会导致web服务和数据库服务在处理上遇到性能瓶颈。
为了解决这个问题，伟大的前辈们发扬了分而治之的思想，对大数据库、大表进行分割，可以参考我的《分库分表》，以便实施更好的控制和管理。
同时创建多个服务实例，使用多台服务机进行CPU、内存、存储的分摊，提供更好的性能。
1.1 单体系统的问题
1、复杂性高：由于是一个单体的系统，所以整个系统的模块是耦合在一起的，模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。
2、服务性能问题：单体系统遇到性能瓶颈问题，只能横向扩展，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。
3、扩缩容能力受限：单体应用只能作为一个整体进行扩展，影响范围大，无法根据业务模块的需要进行单个模块的伸缩。
4、无法做故障隔离：当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题（如某个请求堵塞），那么都有可能会造成整个系统的崩溃。
5、发布的影响范围较大：每次发布都是整个系统进行发布，发布会导致整个系统的重启，对于大型的综合系统挑战比较大，如果将各个模块拆分，哪个部分做了修改，只发布哪个部分所在的模块即可。
1.2 单体系统的优点
1、系统的简易性：系统语言风格、业务结构，接口格式均具有一致性，服务都是耦合在一起的，不存在各个业务通信问题。
2、易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，简化了测试过程，无需额外测试服务间的依赖，测试均可在部署完成后开始。
3、易于部署与升级：相对于微服务架构中的每个服务独立部署，单体系统只需将单个目录下的服务程序统一部署和升级。
4、较低的维护成本：只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统，微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集，成本呈指数级增长。
1.3 单体服务到微服务的发展过程
EUREKA的注册中心逐渐被ZooKeeper和Nacos等替代了。