微服务架构系列（一）-服务注册与发现（2）

服务注册与发现之go语言设计与实现，为什么需要租约模式？watch机制解决了什么问题？

1.定义接口

首先确认整个流程需要做的事情；

1. 创建注册表对象,建立连接;
2. 服务注册到注册表,定期续租;
3. 服务从注册表中注销;
4. 从注册表中获取服务列表;
5. 监听key,当key变化时更新服务列表;

从这些需要做的事情可以抽象出三个角色注册者（Registrar）、发现者（Discovery）、观察者（Watcher）以及方法。伪代码如下：

type Registrar interface {
  Register()
  DeRegister()
}

type Discovery interface { 
  Discover() []*Service
  Watch(key string) *Watcher
}

type Watcher interface {
  Naxt() []*Service
}

2.实现接口

Consul

go get -u github.com/go-kratos/kratos/contrib/registry/consul/v2

Etcd

go get -u github.com/go-kratos/kratos/contrib/registry/etcd/v2

zookeeper

go get -u github.com/go-kratos/kratos/contrib/registry/zookeeper/v2

Nacos

go get -u github.com/go-kratos/kratos/contrib/registry/nacos/v2

kubernetes

go get -u github.com/go-kratos/kratos/contrib/registry/kubernetes/v2

polaris

go get -u github.com/go-kratos/kratos/contrib/registry/polaris/v2

3.问题

为什么需要租约模式？定期续租是为了什么？

服务注册到注册表中，如果服务挂了，不从注册表中移除，它还会在注册表中，请求就可能进入异常服务中，这并不是我们想要的结果。于是便有了租约模式，服务需要定期发送续租请求，在指定时间（keepalive）内未发送请求，就认为服务处于异常状态，将被从注册表中移除。

watch机制是解决什么问题？

服务发现是从注册表中发现一组服务列表，服务列表并未更新，我们还是需要主动从注册表中获取服务列表，在我们看来服务列表未更新，这种操作是没必要的，为了避免这种反复轮询，便有了watch机制，从主动变成了被动，我们对key进行监听，如果key的value更新了，便进行通知，我们才去获取服务列表进行更新。

最后

虽然服务注册与发现的基础使用是有了，但实际使用下来会有以下两个问题：

1. 服务发现获取到是服务列表，从中选择一个涉及负载均衡算法

2. 服务发现获取的是服务连接信息，其中可能是http服务，可能是grpc服务，不能很好的使用；

从这两个问题我们可以抽象几个角色选择器（Selecter）、均衡器（Banlancer）、解析器（Reslover）等。下一篇从这两个问题出发介绍这几个角色的实现。