微服务注册中心如何选型？这几个维度告诉你！( 二 ) _微服务

文章插图
服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负载均衡策略的需求。
客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导致服务提供者出现热点，或者压根就拿不到任何服务提供者。
服务端负载均衡典型的代表就是Nginx，客户端负载均衡典型代表是Ribbon，每种方式都有经典的代表，我们都是可以深入学习的。
常见的负载均衡器的算法的实现，常见的算法有以下六种:
1、轮询法
将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
2、随机法
通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多；其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。
3、哈希算法
哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
4、加权轮询法
不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。
5.加权随机法
与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。
6.最小连接数法
最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。
五、注册中心如何选型？现在注册中心的选择也是五花八门，现阶段比较流行有以下几种:

文章插图
在介绍这个之前大家有些需要了解的知识有CAP、Paxos、Raft算法这里我就不进行过多介绍了。开始介绍以上5种实现注册中心的方式。
1、Zookeeper**Zookeeper:**这个说起来有点意思的是官方并没有说他是一个注册中心，但是国内Dubbo场景下很多都是使用Zookeeper来完成了注册中心的功能。

文章插图
当然这有很多历史原因，这里我们就不追溯了，我还是来聊聊作为注册中心使用的情况下，Zookeeper有哪些表现吧。

文章插图
Zookeeper基础概念1、三种角色
Leader 角色：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
Follower角色：一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
Observer角色：与Follower类似，但是无投票权。
2、四种节点
PERSISTENT-持久节点：除非手动删除，否则节点一直存在于Zookeeper上
EPHEMERAL-临时节点：临时节点的生命周期与客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。
PERSISTENT_SEQUENTIAL-持久顺序节点：基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
EPHEMERAL_SEQUENTIAL-临时顺序节点：基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
3、一种机制
Zookeeper的Watch机制，是一个轻量级的设计。因为它采用了一种推拉结合的模式。一旦服务端感知主题变了，那么只会发送一个事件类型和节点信息给关注的客户端，而不会包括具体的变更内容，所以事件本身是轻量级的，这就是推的部分。然后，收到变更通知的客户端需要自己去拉变更的数据，这就是拉的部分。