服务注册中心

注册中心基本原理

在使用注册中心时，一共有三种角色：服务提供者（Service Provider）、服务消费者（Service Consumer）、注册中心（Registry）。

服务发现原理：服务发现机制就是通过一个中间件去记录服务提供者的ip地址，服务名以及心跳等数据（比如用mysql去存储这些信息），然后服务消费者会去这个中间平台去查询相关信息，然后再去访问对应的地址，这就是服务注册和服务发现。

Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

服务提供者：向注册中心注册为一个服务实例，并且向外部暴露调用接口。

服务消费者：向注册中心订阅需要调用的服务，并缓存服务的实例列表再内存中。后续，Consumer 向对应服务的 Provider 发起调用时，从内存中的该服务的实例列表选择一个，进行远程调用。

注册中心：当注册的实例超过一定时间未心跳（nacos默认30s心跳一次，若下一次未收到，将不再路由请求至该实例），则注册中心判断这个服务已下线，将从服务实例列表移除。

不同的注册中心可能在实现原理上会略有差异。例如说，Eureka 注册中心，并不提供通知功能，而是 Eureka Client 自己定期轮询，实现本地缓存的更新。

当然，一个服务消费者，也可以是一个服务提供者。

nacos

• 作为注册中心时，Namespace + Group + Service
• 作为配置中心时，Namespace + Group + DataId

元数据：

Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签（label），从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。

负载均衡

服务器端负载均衡：

由中间件Ng进行路由

客户端负载均衡：

根据负载均衡规则，自行请求。

Ribbon：提供丰富的负载均衡算法。

手写一个客户端侧负载均衡器

• 手写负载均衡器部分代码如图：

  这段代码的意思就是在实例列表中随机进行请求。这段代码只是粗略展示负载均衡的其中一个算法。

手写负载均衡器主要原理就是获取到此服务的所有url，然后以轮询、随机等方式进行调用指定的url

Ribbon与Nginx的区别

既然提到了负载均衡，怎么能少得了Nginx呢，Ribbon和Nginx之间的不同在于，Nginx是集中式的对接收的请求进行负载均衡，而Ribbon是在消费者端进行负载均衡，形象一点就是如下图。

Nginx

Nginx的工作模型如下图：

Ribbon

Ribbon的工作模型如下图

Ribbon的负载均衡与Ng的负载均衡之不同就是，Ng是被动负载均衡，Ribbon是主动负载均衡。

Ribbon会在收到Http请求后，去拉取注册中心中的服务实例List，获取到List以后，会使用负载均衡策略，在List中挑选一个服务实例进行请求。

Ribbon默认是懒加载，懒加载会使项目启动速度加快，但是同时在第一次请求时，会去拉取注册中心的服务实例，以及初始化负载均衡容器，导致请求响应速度相对较慢。同时可选定服务进行配置饥饿加载。

同时Ribbon有多种负载均衡的策略模式可供选择，默认的就是同区域轮训模式：ZoneAwareLoadBalancer 是一个根据区域（Zone） 来进行负载均衡器，因为如果不同机房跨区域部署服务列表，跨区域的方式访问会产生更高的延迟，ZoneAwareLoadBalancer 就是为了解决此类问题，不过默认都是同一区域

Ribbon负载均衡策略：

策略类	命名	描述
RandomRule	随机策略	随机选择server
RoundRobinRule	轮询策略	轮询选择， 轮询index，选择index对应位置的Server；
RetryRule	重试策略	对选定的负载均衡策略机上重试机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的server；
BestAvailableRule	最低并发策略	逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server
AvailabilityFilteringRule	可用过滤策略	过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个Server的运行状态；
ResponseTimeWeightedRule	响应时间加权重策略	根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间
ZoneAvoidanceRule	区域权重策略	综合判断server所在区域的性能，和server的可用性，轮询选择server并且判断一个AWS Zone的运行性能是否可用，剔除不可用的Zone中的所有server