1.1-单体项目的不足
- 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
- 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
- 测试的难度越来越大，单体应用的业务都在同个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给其他业务带来定的影响，导致测试难度增加。
1.2-什么是微服务
就是将一个大的应用，拆分成多个小的模块，每个模块都有自己的功能和职责，每个模块可以进行交互，这就是微服务
简而言之，微服务架构的风格，就是将单一程序开发成一个微服务,每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。
1.2.1-特点
- 不同存储技术
- 不同语言
- 集中管理
- 分布式
- 独立运行
- 程序之间通过HTTP连接
1.3-微服务特点
1.3.4-自动化部署CI/CD
- CI: 持续集成
- CD: 持续交付
- CICD: 持续部署的组合
1.5-微服务优势
1.5-微服务不足
- 复杂度
- 分布式事务问题
- 服务的划分与分工（功能|组件）
- 服务的部署（自动化|人工）