随着业务的发展，用户量日益上升，单一的系统越来越复杂，越来越庞大，单纯的提升服务器性能始终有顶天的一天，我们可以通过分布式技术，例如：服务器集群，水平业务划分，应用分解，系统分流，微服务架构等方式来解决系统性能问题和复杂业务问题。
第一篇：架构演进
在分布式体系下服务注册与发现将会以核心组件而存在，也将是接下来讨论的话题。
Lazy服务注册与发现(一）
由于应用的分解，微服务的引入，服务越来越多，业务系统与服务系统之间的调用，都需要有效管理。
在服务化的早期，服务不是很多，服务的注册与发现并不是什么新鲜的名词，Nginx+内部域名服务器方式，甚至Nginx+host文件配置方式也能完成服务的注册与发现。
架构图如下：
（架构一）
各组件角色如下：
Nginx通过多域名配置实现生产者服务路由，通过upstream对生产者提供负载均衡，通过checkhealth对生产者提供健康检查。
在内部域名服务器/本地host文件配置服务域名的方式，实现域名与服务的绑定。
生产者提供服务给消费者访问，并通过Nginx来进行请求分发。在服务化的早期，服务较少，访问量较小，解决了服务的注册与发现与负载均衡等问题。随着业务的发展，用户量日益上升，服务也越来越多，该架构的问题暴露出来：
1）最明显的问题是所有的请求都需要nginx来转发，同时随着访问量的提升，会成为一个性能瓶颈。
2）随着内部服务的越来越多，服务上线nginx的配置，内部域名的配置也越来越多，不利于快速部署。
3）一旦内部网络调整，nginx upstream也需要做对应的配置调整。
Lazy服务注册与发现（二）
由于所有的请求都需要nginx来转发，同时随着访问量的提升，会成为一个性能瓶颈，为了解决这个瓶颈，引入下面这个架构。
（架构二）
这个架构在nginx的上层加入了LVS，LVS基于第四层的IP转发，一定限度提高了并发能力,但是所有请求都通过LVS来转发。
同时nginx分组，服务分组，虽然nginx不再是瓶颈的所在，但是这样带来的代价太高，配置越来越多，工作量越来越大，对系统压力需要有预见性，有效nginx分组，服务分组部署。
Lazy服务注册与发现（三）
由于所有的请求都需要LVS来转发，同时随着访问量的提升，会成为一个性能瓶颈，为了解决这个瓶颈，引入下面这个架构。
（架构三）
在这个架构基础上需要做两件事情：
对系统压力需要有预见性，有效nginx分组，服务分组部署。
消费端需要编程实现分组选择，可以是轮训，random等实现，我们每一个消费者同时承担了的负载均衡的职责。
ZK服务注册与发现 （一）
通过架构三解决了nginx的瓶紧，但是服务上下线需要在nginx，域名服务器做相应的配置，一旦服务的IP端口发生变化，都需要在nginx上做相应的配置，为了解决这个问题引入下面这个架构。
（架构四）
服务在启动的时候就将endpoint注册到Zookeeper对服务进行统一管理。
服务节点增加Endpoint不需要做任何配置，ZK将以Watch机制通知消费者。
消费者本地缓存了提供者服务列表，不需要转发，直接发起服务调用。
缺点：
需要通过zookeeper API来实现服务注册与发现，负载均衡，以及容错，为了解决nginx的瓶紧架构三也是需要通过编程的方式实现负载均衡。
ZK服务注册与发现 （二）
Zookeeper数据模型结构是一个树状层次结构。每个节点叫做Znode，节点可以拥有子节点，同时允许将少量数据存储在该节点下，客户端可以通过NodeCacheListener监听节点的数据变更，PathChildrenCacheListener监听子节点变更来实时获取Znode的变更(Wather机制)。
以下是点融成都服务注册结构，见下图，接下来的讲解也将以这个结构为基础：
ZK服务注册与发现 （三）
1./com/dianrong/cfg/1.0.0/rpcservice: 命名空间，用来跟其他用途区分。
2./com/dianrong/cfg/1.0.0/rpcservice下的所有子目录由两部分组成，
“应用名称” + “-” + “分组名称”例如：ProductService-SG1,ProductService-SG2, 对应Nginx注册中心Nginx-SG1, Nginx-SG2
3. 服务分组下的所有子节点为临时节点，key为“PROVIDER”+ IP(去符号.) + “-” + 端口,Value为endpoint信息。
例如：PROVIDER1921681010-8080 = http://192.168.10.10：8080
第二篇：代码分析
项目说明
有了上面的理论我们接下来针对基于ZK的服务与发现的代码分析，代码已经提交到git
GIT地址：
https://code.dianrong.com/projects/PLAT/repos/platform/compare/commits?sourceBranch=refs%2Fheads%2FEVER-81-zk&targetBranch=refs%2Fheads%2Fmaster
说明:
1. 该组件建立在Curator基础之上，Curator是Netflix开源的一套ZooKeeper客户端框架封装ZooKeeper client与ZooKeeper server之间的连接处理。
2. Curator提供如下机制，保证我们不需要关注网络通信，而把主要精力放在业务逻辑的处理。
重试机制:提供可插拔的重试机制, 它将给捕获所有可恢复的异常配置一个重试策略, 并且内部也提供了几种标准的重试策略
连接状态监控: Curator初始化之后会一直的对zk连接进行监听, 一旦发现连接状态发生变化, 将作出相应的处理
ZK客户端实例管理:Curator对zk客户端到server集群连接进行管理. 并在需要的情况, 透明重建zk实例, 保证与zk集群的可靠连接
基于ZK的服务与发现UML类图：
目标
1. 统一配置中心
数据实时性，一旦zk节点发生变化，实时通知本地hash同步刷新。
2. 服务注册
服务启动完成，服务IP,端口以临时节点的形式注册到zk，在网络正常的情况下，一直存在。
3. 服务发现
服务启动完成，将服务注册信息刷新到本地hash。
4. 服务上下线
服务注册到zk将实时通知服务发现方，更新本地hash，服务下线也将实时通知服务发现方，更新本地hash。
5. 负载均衡
服务发现方获取服务缓存在本地hash,通过random，robin等负载均衡算法完成服务选择性调用。
6. 网络中断容灾
针对注册方网络中断，服务下线，网络恢复，服务上线，并通知服务发现方更新本地Hash；
针对发现方网络中断，通过本地hash负载均衡，网络恢复重刷hash，负载均衡重新分配。
7. Zookeeper宕机容灾
针对注册方Zookeeper宕机，服务下线，尝试重连， Zookeeper 启动重连成功，服务上线，并通知服务发现方更新本地hash，针对发现方Zookeeper宕机，通过本地hash负载均衡，尝试重连， Zookeeper 启动重连成功，重刷hash，负载均衡重新分配。
基本配置
PathConfig.java
包含服务注册的命名空间和统一配置的命名空间的配置。
SgConfig.java
包含服务名和分组名的配置
ZookeeperConfig.java
包含zookeeper地址，会话超时时间，连接超时时间，命名空间以及认证信息的配置
ZK操作框架
IzookeeperManager.java
定义了一套zookeeper操作规范（类似JDBC操作数据数据库规范），有待继续完善。
ZookeeperManager.java
针对IzookeeperManager接口规范的实现（类似Mysql驱动对Mysql操作的实现）
ZookeeperManagerPool.java
针对ZookeeperManager实例的缓存，不同配置缓存不同ZookeeperManager实例，避免zookeeper连接创建的开销，同时可以根据zookeeper水平分组扩展zookeeper
实例。
统一配置，服务注册与发现
AbstractZookeeperFeature.java
内部两个接口定义：
IConfigService 提供针对统一配置接口的定义， IManagementService提供服务注册与发现接口的定义。
ConfigService.java
统一配置的实现。
ManagementService.java
服务注册与发现的实现。
负载均衡
LbStrategy.java
负载均衡策略接口定义，目前实现了两种负载均衡算法，Random负载均衡和Robin负载均衡。
RandomStrategy.java
基于随机负载均衡的实现。
RobinStrategy.java
基于轮循负载均衡的实现。
统一配置Listener
ConfigPathChildrenCacheListener.java
统一配置结点监听， 针对CHILD_REMOVED，CHILD_ADDED，CHILD_UPDATED事件对本地hash实时更新。
服务注册与发现Listener
ZookeeperStateListener.java
Zookeeper状态监听接口定义，定义需要关心的三种事件：
LOST-断开连接达到一定时间
CONNECTED-第一次连接成功
RECONNECTED-重连成功触发事件。
ServiceRegistStateListener.java
服务注册状态监听实现:
1.一旦网络丢包严重/ zk宕机/ zk重启,客户端将会与zk断开，服务下线，网络恢复将触发reconnected连接，服务重新注册。
2.一旦zk断开服务下线，长时间连接不上触发Lost事件，ServiceRegistStateListener将会尝试不断连接直到连上为止，服务重新注册。
ServiceDiscoverStateListener.java
服务发现状态监听实现：
1.一旦网络丢包严重/ zk宕机/ zk重启,客户端将会与zk断开，网络恢复将触发reconnected连接，重新获取服务列表，刷新本地hash。
2.一旦zk断开服务下线，长时间连接不上触发Lost事件，ServiceDiscoverStateListener将会尝试不断连接直到连上为止,以便刷新本地hash。
ServicePathChildrenCacheListener.java
服务发现结点监听， 针对CHILD_REMOVED，CHILD_ADDED，CHILD_UPDATED事件消费者对本地hash实时更新，以便及时刷新服务上下线。
第三篇：单元测试
环境准备
1. 在zookeeper中准备结点 com/dianrong/cfg/1.0.0/rpcservice
create /com/dianrong/cfg/1.0.0/rpcservice “”
2. 模拟docker/JVM启动参数设置
由于点融网是通过物理机IP加端口映射到docker实例IP加端口的方式对外提供服务，因此需要通过java -D配置宿主机的IP加端口以便应用程序获取服务IP加端口用来进行服务注册。
服务注册
1. 在服务注册之前通过zookeeper控制台查看，期望的注册节点目前为空。
2. 启动服务注册单元测试，sleep 10s。
3. 观察zookeeper中注册结点，期望的临时节点已经存在。
服务发现
通过服务注册以后然后服务发现，发现节点与预期注册结点一致。
负载均衡
通过服务注册以后然后负载均衡，负载均衡获取节点与预期节点一致。
服务上下线
1. 准备两套单元测试并模拟docker/JVM启动参数设置。
2.启动服务注册，服务发现，负载均衡集成单元测试，测试控制台按照预期打印出服务注册信息,注册了两个服务节点通过负载均衡交叉出现。
3. 通过zookeeper控制台查看成功注册两个节点。
4.关闭机器1单元测试，结点1在zookeeper离线，结点2在zookeeper在线。
负载均衡只有一个节点存在达到预期目的
网络中断
1. 启动服务注册，服务发现，负载均衡集成单元测试，测试控制台按照预期打印出服务注册信息。
2. 通过Linux iptables开启防火墙，模拟网络中断。
服务掉线，通过zookeeper控制台查看注册节点消失。
服务发现方任然可以从本地Hash中获取服务节点。
3. 关闭Iptables，服务上线。
服务上线，通过zookeeper控制台查看注册节点出现。
服务发现方获取服务节点重刷本地Hash中。
Zookeeper宕机
1. 启动服务注册，服务发现，负载均衡集成单元测试，测试控制台按照预期打印出服务注册信息。
2.关闭zookeeper，单元测试出现连接拒绝错误，但是任然能按照预期获取本地hash中的服务注册信息。
3. 启动zookeeper，单元测试打印出重连信息，并重刷本地服务hash。
本文作者：秦瑜 Chris.Qin(点融黑帮)，来自点融BE Team, 2015年10月加入点融，多年大并发分布式互联网架构经验。
