基于zookeeper的微服务实践

该文章会阐述一些对微服务理解的个人观点，如有错误或者不恰当之处还请见谅。

1 前言

微服务的话题也火了好几年了，各类微服务架构的文章也是非常的多，这里也阐述下个人对微服务系统的见解。

1.1 为什么选择微服务系统

微服务系统之前是服务化系统，服务化系统提倡同构系统，比如系统内统一采用某种通信框架（AKKA、CORBA等），而且从某种层面上也限制了开发语言，为什么会这样，因为服务化系统一般是由一个团队打造的，考虑到维护成本，团队会采用相同的技术栈，这也印证了康威定律。

但是随着业务的增长，即使一个大型团队也无法支撑系统的复杂度，这就要求多团队协同合作，当然这也不可能违背康威定律的，但也总不能要求所有团队统一思想吧，所以就要求一套新的体系结构既能满足异构团队又符合康威定律。因此，微服务就诞生了，说到底，软件架构的演进都是为了解决人的问题。

1.2 微服务系统基础架构组成

微服务的基础架构组成服务太多了，这里不好一一详细介绍了，下图是一个大概的组成图，其中括号中是比较主流的服务。

微服务架构组成

2 服务注册中心

因为本篇主要是介绍一个注册中心的实践，所以特意介绍下服务注册中心。

在原来的单体软件架构中，组件间通信多是基于基础架构平台的，这是一个类似系统消息总线的机制，但这种通信方式不适用于微服务系统。由于微服务数量过多，所有通信消息都走总线的话，一来对总线服务部署环境的吞吐能力要求非常高；二来还要有很高的可靠性，不然一旦总线挂掉整个系统就瘫痪了。

但是微服务系统中还是需要一个角色来连接各个微服务的。因为每个服务部署的位置不同，甚至部署的位置可能会动态的变化，所以把每个服务的通信地址都写在配置项中是不太合理的。所以这个负责连接的角色需要实时感知每个服务位置的变化，并且及时的将变化通告到对其依赖的服务，这也就是服务注册中心的核心能力。而服务间的业务通信是通过定义的接口（REST、gRPC等）完成的，并不需要服务注册中心参与，由此以来，注册中心相比消息总线就没有很大的IO压力。下图是一个注册中心简单工作示意：

注册中心简单工作示意

3 基于zookeeper实现简单的微服务系统

现在开源社区已经有很多成熟的服务注册中心构件，如Eureka、Consul等，其实zookeeper在某些应用场景下也是一个很好的选择，这里选择它作为实践对象也是由于zookeeper的机制已经被大家熟知，理解起来更容易一些。

3.1 实现原理

大家应该了解zookeeper有两个特性：

• znode有两种类型：持久性znode和临时znode，而临时znode一旦回话过期就会被zookeeper回收；
• zookeeper的znode状态和子znode数量变化可以被多个会话watch（订阅），即每个会话可以被动感知znode的变化。 基于这两个特性，就可以提供一个服务注册中心的功能：
• 每个微服务作为zookeeper的客户端可以在zookeeper上发布自己的信息：首先创建一个持久性节点（服务名），然后在服务上线时持久性节点下创建一个临时节点（服务地址），这样当临时节点存在时即可认为服务在线；
• 当一个服务需要感知其他服务的位置时，即可watch对应服务节点下子节点的变换，一旦变化就可以获取最新的服务地址。

3.2 代码实现

本实践是基于go语言开发了一个服务注册客户端（略简陋，但稳定性和可靠性都有考虑到），服务端是zookeeper，每个服务会创建一个以服务名命名的持久性节点，而每当服务上线后会在持久性节点下创建一个“服务名(ip:port)”的临时节点用以发布服务地址。

程序对开源的go-zookeeper包有依赖，代码地址：go-zk-svc 请大家star支持一下。

4 后话

其实zookeeper也是一个很好的配置管理服务，大家有兴趣可以尝试一下，最后希望本文能对大家有所帮助。