为何要引入服务注册组件及组件对比

news2024/11/16 2:14:35

我的后端学习大纲

SpringCloud学习大纲

1.为什么要引入服务注册中心：

1.微服务所在的IP地址和端口号硬编码到订单微服务中，属于硬编码，会存在非常多的问题
- 如果订单微服务和支付微服务的IP地址或者端口号发生了变化，则支付微服务将变得不可用，需要同步修改订单微服务中调用支付微服务的IP地址和端口号。
- 如果系统中提供了多个订单微服务和支付微服务，则无法实现微服务的负载均衡功能。
- 如果系统需要支持更高的并发，需要部署更多的订单微服务和支付微服务，硬编码订单微服务则后续的维护会变得异常复杂。

总结：在微服务开发的过程中，需要引入服务治理功能，实现微服务之间的动态注册与发现，从此刻开始我们正式进入SpringCloud实战

1.Eureka停更维护
2.Eureka对初学者不友好，首次可以看到自我保护机制
3.注册中心独立且微服务功能解耦，目前主流服务中心，希望单独隔离出来而不是作为一个独立服务嵌入到系统中：
- 按照Netflix的之前的思路，注册中心Eureka也是作为一个微服务且需要程序员自己开发部署,与业务模块的服务混在一起
- 我们希望的实际情况：
  - 希望微服务和注册中心分离解耦，注册中心和业务无关的，不要混为一谈。
  - 提供类似tomcat一样独立的组件，微服务注册上去使用，是个成品。

Nacos和Consul均可做服务注与服务发现，Eureka仅仅可以做服务注册

1.CAP分别是什么：
- C:Consistency（强一致性）
- A:Availability（可用性）
- P:Partition tolerance（分区容错性）
2.CAP理论关注粒度是数据，而不是整体系统设计的策略

最多只能同时较好的满足两个

在这里插入图片描述

CAP理论的核心是：

1.一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：

CA架构：

CP 架构：

1.当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性，Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。
2.虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。结论：违背了可用性A的要求，只满足一致性和分区容错，即CP

AP架构:

1.当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统的可用性。
2.当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性结论：违背了一致性C的要求，只满足可用性和分区容错，即AP