微服务拆分——nacos/Feign

今天学习单体架构到微服务架构的拆分

首先明白为什么需要进行拆分服务：

        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自行建立连接的繁琐过程。