SpringCloud Alibaba实战(7:nacos注册中心管理微服务)

源码地址:https://gitee.com/fighter3/eshop-project.git

持续更新中……

在上一节我们已经完成了Nacos Server的本地部署,这一节我们学习如何将Nacos作为注册中心,管理微服务。

1、注册中心简介 1.1、什么是注册中心

在微服务的体系里,注册中心是最重要的组件之一,我们来简单了解一下什么是注册中心。

注册中心和DNS类似,大家想一想,我们平时访问百度,是访问 ,还是直接访问ip地址呢?

 注册中心就承担了这样一个“名单”的角色,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址,进行调用。

注册中心

注册中心的作用就是服务的注册服务的发现

1.2、常见的注册中心

Netflix Eureka

Alibaba Nacos

HashiCorp Consul

Apache ZooKeeper

CoreOS Etcd

CNCF CoreDNS

特性 Eureka Nacos Consul Zookeeper
CAP   AP   CP + AP   CP   CP  
健康检查   Client Beat   TCP/HTTP/MYSQL/Client Beat   TCP/HTTP/gRPC/Cmd   Keep Alive  
雪崩保护          
自动注销实例   支持   支持   不支持   支持  
访问协议   HTTP   HTTP/DNS   HTTP/DNS   TCP  
监听支持   支持   支持   支持   支持  
多数据中心   支持   支持   支持   不支持  
跨注册中心同步   不支持   支持   支持   不支持  
SpringCloud集成   支持   支持   支持   支持  
1.3、CAP原则与BASE理论 1.3.1、CAP原则

CAP原则

CAP 原则又称 CAP 定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出。该猜想在提出两年后被证明成立,成为我们熟知的 CAP 定理。CAP 三者不可兼得。

特性 定理
Consistency   也叫做数据原子性,系统在执行某项操作后仍然处于一致的状态。在分布式系统中,更新操作执行成功后所有的用户都应该读到最新的值,这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。  
Availability   每一个操作总是能够在一定的时间内返回结果,这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是,在可以容忍的范围内返回结果,结果可以是成功或者是失败。  
Partition tolerance   在网络分区的情况下,被分隔的节点仍能正常对外提供服务(分布式集群,数据被分布存储在不同的服务器上,无论什么情况,服务器都能正常被访问)。  

取舍原则

CAP 三个特性只能满足其中两个,那么取舍的策略就共有三种:

CA without P:如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署子节点,这是违背分布式系统设计的初衷的。

CP without A:如果不要求A(可用),相当于每个请求都需要在服务器之间保持强一致,而P(分区)会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务),一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少,最典型的就是分布式数据库,如 Redis、HBase 等。对于这些分布式数据库来说,数据的一致性是最基本的要求,因为如果连这个标准都达不到,那么直接采用关系型数据库就好,没必要再浪费资源来部署分布式数据库。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zysdgz.html