服务发现简介

微服务架构火了之后,伴随而来的一个问题就是如何做服务注册和发现(Service Register and Discovery)。

为什么需要服务注册与发现

对于微服务架构来说,每个服务都可以单独地管理和部署。比如把服务部署在多个节点上,前端请求过来之后采用负载均衡策略把流量打到具体的机器上。如果某个节点宕机(比如最常见的原因Out of Memory),这时候用户的请求达到了宕机的机器上就会造成很不好的用户体验。又比如说横向扩展的时候,手动添加配置也很繁杂。

服务注册与发现就是用来解决这些问题的。所有服务的IP地址以及端口都存放在一个强一致性的数据中心。对于服务宕机以及添加能够自动发现,不再需要人工干预。

服务注册中心

服务注册中心是一个高可用强一致性的服务发现存储仓库,主要用来存储服务的api和地址对应关系。为了高可用,服务注册中心一般为一个集群,并且能够保证分布式一致性。目前常用的有ZooKeeper(ZooKeeper除了存储还有其他功能), Etcd等,这两者的区别主要在于ZooKeeper使用Paxos来保证强一致性,而etcd使用Raft协议。相比于Paxos,Raft实现起来要更容易一点。而相比ZooKeeper,etcd要轻量很多,目前使用的也比较多,特别是现在和docker一起使用。

服务注册的策略

服务注册的一般做法是注册中心提供一个RESTful API,这样服务就可以访问这个API来实现服务注册了。当然也可以使用其他方式,比如consul可以通过配置文件的形式来实现新服务的注册(前提是service的节点上运行着consul agent)。如果要强行将服务注册分类的话,可以分为主动注册和被动注册,前面提到的注册中心提供API的方式就是服务的主动注册,被动注册一般是通过第三方组件监控服务状态(或者事件监控)来实现。可以用下面两张图来简单表示。


服务发现的策略

服务发现的策略主要有两种:Client端和Server端发现策略。

客户端服务发现

客户端服务发现就是客户端(通过SDK)自己去发现最终的IP和端口。首先客户端向服务注册中心发请求,得到服务的IP地址和端口,然后使用负载均衡算法选择一个节点。流程可以用下图所示。在服务启动的时候,它的地址会存放在服务注册中心。之后注册中心负责更新或摘除节点(节点宕机)。这种策略在某些App上应用的比较多。

服务端发现策略

服务端发现策略也就是说服务端负责服务的定位。大部分情况下客户端通过负载均衡器向服务发送请求。负载均衡器然后向服务注册中心请求。

总结

这里先简单介绍一下,后面会分别讨论Etcd和Consul等。