基于Zookeeper实现的服务注册发现平台

在调研了多个开源服务发现，或服务治理平台之后，如Eureka、Consul，dubbo等，发现由于都不能完美的适配当前已有系统。

原方案的缺点，单个节点独立部署，可靠性差，扩展性差。不方便维护更新，更新一台服务器时，需要先把对应的服务调用方的流量切换到其他服务器，然后对服务进行更新，更新后再把流量切回来。整个过程操作复杂、容易出错。当服务器较多时，耗时耗力。

因此我们需要一个更好的架构来解决上面的问题，首先，服务端提供方对调用方来说不应该是被写死在配置文件中的一个地址端口，而应该是提供一种抽象的服务，调用方调用这种服务。这样，在整个架构中就隐藏了物理地址的信息，抽象出服务的概念后，服务提供方和调用方的部署中就不需要关注每台服务器的具体链接情况，这些全都交由服务发现平台完成。总结一下服务发现需要完成的功能：

• 服务提供方可以将自己的信息注册到平台。
• 服务消费方可以通过平台找到可用的服务提供方。
• 既然存在多个服务提供方，那么我们就需要实现各个提供方的负载均衡控制。

除了以上三个基本功能外，还有许多完善功能，如：服务权重设置，服务监控报警，容错控制，提供特定转发规则的调试模式等等。

由于服务发现平台充当的是整个系统的调度者，因此服务发现本身必须是高可用的。如果自己自己实现一套实时性高而且高可用的服务是比困难的，因此我们选择Zookeeper作为服务信息的存储（注意，当服务信息的数据量超过一定阈值，zookeeper的性能会急剧下降，所以该方案的适用场景有一定限制，对于有海量服务器的情况，应另外考虑其他方案）。所有的服务提供方在准备好提供服务之后把自己的提供的服务信息写入的zookeeper中。调用方启动后，从zookeeper中读取自己需要的服务信息，并做本地缓存，然后根据一定的均衡策略调用服务。而当提供方的服务信息有变化时，zookeeper也可以实现对调用方的及时通知。如下图所示：

服务展示以及数据统计：