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

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

转载于:https://my.oschina.net/u/2486137/blog/3086389