今天学习单体架构到微服务架构的拆分
首先明白为什么需要进行拆分服务：
1.1耦合性高：单体架构多个模块可能会出现互相调用的情况，举一个简单的案例，比如在我们进行购物（淘宝为例）的购物车，这里的购物车会出现“比加入购物车时降价XX元”。
想要完成这个功能，需要调用到购物车模块和商品模块，购物车模块的原价与当前商品的现价进行相减。这样当我们需要调用购物车接口时，显然需要调用到商品接口。
1.2健壮性不足（可用性差）：当其中的某个模块崩掉了，那么对应其他与其有联系的模块很可能也会崩溃。因为单个线程是顺序执行的，执行到某个模块出错，那么大概率会返回报错，而不是继续执行能够成功执行的部分。
1.3部署成本高：如果对某个模块进行修改升级，那么需要重新部署整个项目。
1.4维护性差：单体架构的测试困难，不容易找bug，不宜与维护。
1.5难以扩展：比如，某个模块的流量剧增，这个模块的压力很大，想要为其分配更多资源，只能整个项目重新部署，这需要很高的时间花销。
如何进行拆分：
1.拆分方式：横向拆分与纵向拆分
横向拆分和纵向拆分是微服务架构设计中密不可分且相互补充的策略。纵向拆分建立了基于业务能力的系统骨架，横向拆分则为其提供了可复用、统一管理的基础技术能力支撑层。它们协同工作，共同解决了大型复杂系统在业务与技术层面的双重挑战，最终实现微服务的核心价值：高内聚、低耦合、独立部署、弹性伸缩和团队高效自治。将两者有机结合起来，是设计和构建成功微服务架构的关键。
简单来说纵向拆分将整个项目按照功能模块进行拆分，比如一个电商系统、
纵向（业务）层：
- 用户管理服务
- 商品目录服务
- 订单服务
- 支付服务
- 库存服务
- 推荐服务 (这也属于业务功能)
横向拆分将整个项目的高复用的模块单独进行提取，比如：
- 横向（基础设施/平台）层：
- 认证授权服务
- API网关服务
- 配置中心服务
- 日志聚合与分析服务 (如ELK)
- 监控告警服务 (如Prometheus/Grafana)
- 消息队列服务 (如Kafka/RabbitMQ)
- 缓存服务 (如Redis)
- 搜索基础设施服务 (如Elasticsearch服务)
拆分完后，各个模块之间如何进行通信
1.由于微服务各个模块独立，拥有自己的数据库、端口号、服务器，如果模块间需要进行调用，应该怎么处理？
处理方式采用网络通信的形式，A模块调用B模块的接口，让B模块执行A模块需要的功能，然后将功能输出的结果返回给A即可。这种方式和前端通过网络请求后端在本质上是相似的。
2.由于模块之间的相互调用，可以将模块之间的关系抽象为消费者生产者的关系。
又由于每个模块会有多个服务器进行负载均衡，所以模块之间也是多对多的关系。
3.那么模块之间如何进行通信才能保证通信的稳定性？
这里就要引入注册中心，注册中心就是消费者生产者之间的桥梁。生产者只要上线部署，就会被注册中心登记，当消费者模块请求某个某个生产者模块时，注册中心会将该生产模块对应的注册登记表全部传递给消费者，消费者通过负载均衡选取一个生产者进行调用完成功能。
4.生产者挂掉了，注册表如何更新？
这里引入心跳契约，生产者与注册中心通过心跳契约进行维护，当生产者没有心跳（挂了），生产者就会更新登记表，然后给消费者传递新的登记表，保证消费者不会空军。
具体的组件有哪些？
1.首先就是注册中心，国内使用较多的是nacos，部署完nacos后，在各个微服务的配置文件中，对nacos进行配置，注意：nacos在部署时，就需要与数据库进行绑定，所以可以看作nacos默认模块需要有数据库。
nacos这个注册中心基本不会出现在代码中，其管理端在ip地址:8848/nacos，新版好像是ip地址：8080/index.html
也就是说nacos这个内容对于初学者来说，基本只需要会部署就够了。
2.其次就是网络通信与负载均衡，可以使用openfeign这个组件，这个组件可以完整模拟SpringMVC的接口调用机制进行网路通信，从而省去了使用Rest自行建立连接的繁琐过程。