微服务架构下的服务注册中心

1. HTTP & RPC:

二者出发点不一样: ①.http是为了解决网络通讯的问题; ②.RPC是为了解决服务与服务之间的调用

2. 为何要使用服务注册中心:

例如一个大型的电商系统要叫进行若干个子系统的拆分(e.g. 订单服务,卡券服务,会员服务, 库存服务等),那么每一个服务又有N多台机器: ①.那么经过http的形式去调用服务那么势必须要记录不少个URL地址,若是某一个服务须要扩容那么全部须要用到的地方都要改,地址管理是一个问题(因此须要一个组件去统一的管理这么多的地址信息,而后对外只须要暴露注册中心组件的地址便可.); ②.负载均衡如何作: 负载均衡算法(e.g. 随机、轮询). ③.服务的动态感知: 能够经过定时器轮询的方式进行健康检查, e.g. 每隔3s检查一次,若是服务挂了须要修改相应的服务的健康状态,而且将状态同步给客户端

3. 注册中心技术选型:

• zookeeper(分布式协调组件,基于Google的 chubby (非开源)实现)

主要是为了解决分布式一致性问题,分布式琐。

分布式一致性:
每一个节点都发出一个请求最终选择一个请求.
分布式一致性所面临的问题(拜占庭将军问题): e.g. 有N个将军分散在各个方位,若是须要攻打某一个国家须要全部将军赞成方可进行,由于须要远程通讯因此可能会面临有叛军的状况致使传递虚假信息.所以须要一种协议.
分布式一致性协议:(paxos).

Google一致性解决方案->服务(chubby):
多个节点须要选择一个节点(每一个节点作一个分布式一致性协议算法), Google是将这一步抽取出来作成一个服务(chubby),先来先服务, e.g. A,B,C三个节点若是A建立节点成功,B,C都会失败.那么A即master. 由于chubby不开源,因此雅虎也面临着相似的场景作了一个相似的服务最后捐献给apache(即zookeeper)。

分布式锁:
①. 数据结构 : A.B.C三个节点基于chubby的理论只能有一个节点注册成功(e.g. 写数据<具备惟一性>),例如A成功,其余等待,直到A处理完并删除相关的.其余节点继续抢占, 那么若是有1000个节点的话那么就会很是耗时及消耗流量,(i.e. 惊群效应).
zookeeper是怎么作的: 全部节点往zookeeper上写数据(e.g. 写数据编号),例若有N个节点那么A先写成功(10001),那么B紧接着(10002)......10000N, 只须要下一个节点监听上一个节点便可,不须要排队等待再抢占.(树形结构). ②.单点故障:

• 带中心节点的集群(kafka , elasticsearch) 好处在于事务性的请求由master处理,非实物的请求由slave处理 NOTE : 若是全部的节点都能处理事务请求的话那么全部节点信息须要保持同步 (A的数据同步给B,B的同步给A....).
• 不带中心节点的集群(redis-cluster)

• eureka:

• consul