1.为什么要引入服务注册中心:
1.1.原因说明
- 1.
微服务所在的IP地址和端口号硬编码到订单微服务中,属于硬编码,会存在非常多的问题
- 如果订单微服务和支付微服务的IP地址或者端口号发生了变化,则支付微服务将变得不可用,需要同步修改订单微服务中调用支付微服务的IP地址和端口号。
- 如果系统中提供了多个订单微服务和支付微服务,则无法实现微服务的负载均衡功能。
- 如果系统需要支持更高的并发,需要部署更多的订单微服务和支付微服务,硬编码订单微服务则后续的维护会变得异常复杂。
总结:在微服务开发的过程中,需要引入服务治理功能,实现微服务之间的动态注册与发现,从此刻开始我们正式进入SpringCloud实战
2.注册中心对比:
2.1.为何不再使用Eureka:
- 1.Eureka停更维护
- 2.Eureka对初学者不友好,首次可以看到自我保护机制
- 3.
注册中心独立且微服务功能解耦
,目前主流服务中心,希望单独隔离出来而不是作为一个独立服务嵌入到系统中:- 按照Netflix的之前的思路,注册中心Eureka也是作为一个微服务且需要程序员自己开发部署,与业务模块的服务混在一起
- 我们希望的实际情况:
- 希望微服务和注册中心分离解耦,注册中心和业务无关的,不要混为一谈。
- 提供类似tomcat一样独立的组件,微服务注册上去使用,是个成品。
- 按照Netflix的之前的思路,注册中心Eureka也是作为一个微服务且需要程序员自己开发部署,与业务模块的服务混在一起
Nacos和Consul均可做服务注与服务发现
,Eureka仅仅可以做服务注册
2.2.三个注册中心异同点
a.什么是CAP介绍:
- 1.CAP分别是什么:
- C:Consistency(强一致性)
- A:Availability(可用性)
- P:Partition tolerance(分区容错性)
- 2.CAP理论关注粒度是数据,而不是整体系统设计的策略
b.经典CAP图:
最多只能同时较好的满足两个
CAP理论的核心是:
- 1.
一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求
,因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类:
CA架构:
- 1.单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大
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