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

本文主要是介绍为何要引入服务注册组件及组件对比，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

我的后端学习大纲

SpringCloud学习大纲

---

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

1.1.原因说明

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

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

---

2.注册中心对比：

2.1.为何不再使用Eureka:

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

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
  

c.三个服务注册中心的比较：

---

这篇关于为何要引入服务注册组件及组件对比的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---