微服务架构之服务注册中心

在微服务的架构中， 服务注册中心是一个核心的概念。 就像上节所讲， 服务注册中心是服务发现中不可缺少的一部分。

服务注册中心， 通俗来讲， 是一个存储网络实例的网络地址和数据库， 一个服务注册中心应该是高可用的， 而且其数据是最新的。

客户端在查询服务注册中心后， 会缓存一部分网络地址的数据， 但是， 这些信息需要设置过期时间， 因为数据会实时的发生变化。

因此， 一个服务注册中心， 应包含一个服务器的集群， 在这个集群中， 各个机器中的数据需要保持一致， 机器之间通过replication协议来实现这个功能。

Netflix Eureka是服务注册中心的一个很好的实例。它提供了一个用于注册和查询服务实例的REST API。服务实例使用POST请求注册其网络位置。每30秒，它必须使用PUT请求刷新注册。通过使用HTTP删除请求或实例注册超时来删除注册。客户端可以使用HTTP GET请求检索已注册的服务实例。

Netflix 通过在多个Amazon服务器上运行多个Eureka来保证服务注册中心的高可用性，每个Eureka服务器运行在一个EC2实例上, 而且具有一个可变IP地址。DNS TEXT 用于存储Eureka集群配置，这个是个映射关系，用来得到可用的Eureka服务器的网络位置列表。

当Eureka服务器启动时，它查询DNS来检索Eureka集群配置，定位它的对应节点，并为自己分配一个未使用的IP地址。

Eureka客户端通过查询DNS来发现Eureka服务器的网络地址， 客户端更倾向于访问相同区域的Eureka服务器， 当然， 如果没有找到服务器， 也会访问其他区域的服务器。

其他的比较好的服务注册中心是：

1. etcd： 一个高可用的，分布式的，一致性key-value结构， 用于共享配置信息和服务发现， Kubernetes使用了etcd。
2. consul： 一个发现和配置服务的工具， 提供API供注册和发现服务， 为了确保可用性， consul会执行健康检查。
3. zookeeper： 一个被广泛使用的分布式的高性能服务。

下面探讨下服务注册中心的实现机制：
主要有两种模式： 一种是自注册模式； 另一种是第三方的注册模式。

自注册模式

自注册模式，就是每个服务实例都需要负责向服务注册中心来注册和解除注册，同时， 还需要发送心跳来保持注册信心不被过期。

Netflix OSS Eureka Client 使用了这种模式。
Eureka Client负责注册和解除注册， 在Spring Cloud工程中，向Eureka注册服务是很方便的，只需要加个注解即可@EnableEurekaClient

自注册模式的好处是： 简单，不需要其他的组件。
不过， 缺点就是： 耦合度比较高，需要和服务注册中心适配， 使用编程语言和框架会受到限制。

第三方注册模式

使用第三方的注册模式， 服务实例将不再负责直接向服务注册中心注册和解除注册， 实际上， 另外一个第三方的系统组件来做这个注册的操作。

这个第三方组件通过轮询部署环境或者订阅一个事件来实现对运行实例集群的监控， 当它发现有新的实例出现的时候， 它会注册到服务注册中心， 同样，也会解除注册。

有一个开源软件叫Registrator，就实现了这个注册组件的功能，它会自动注册和解除注册部署在Docker环境中的服务实例。支持etcd和consul。

另外一个就是NetflixOSS的Prana， 支持非JVM语言，支持用于Eureka。

使用第三方的模式，好处就是： 很好的实现了和服务注册中心的解耦，不需要按照服务注册中心的要求来实现代码。

缺点就是： 这个第三方的注册组件必须保证高可用，这样增加了管理的复杂度。