服务注册发现

需要服务注册发现的场景

服务分布式部署的情况下，假设 Service-A 调用 Service-B，如下图：

当然也可以使用其他的负载均衡代替Nginx, 原理都是一样的需要提前将 Service-B 所有机器的 ip 和 端口配好，以便负载均衡可以按照一定的规则找到 Service-B。

在微服务的架构中，可能需要调用的服务不止一个 Service-B，还有 Service-C、Service-D、Service-E 等等， 更重要的是服务具有很强的伸缩性，当流量峰值的时候可能需要瞬时扩容，峰值过后还需要缩减服务。为了增强服务的伸缩性，服务实例的网络地址最好是动态分配的。由于自动扩展，失败和更新，服务实例的配置也经常变化。这样一来，服务端需要完善的快速注册的机制，客户端需要一套精细的服务发现机制。

服务注册

自注册模式（The Self-Registration Pattern）

自注册就是服务实例负责从服务注册表中注册、注销、维持心跳。

Netflix 的 Eureka 就是一个自注册模式的例子。
它主要包括两个组件：Eureka Server 和 Eureka Client
Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端）
Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心）

第三方注册模式（The Third-Party Registration Pattern）

在third-party registration模式中，服务实例不会自己在服务注册表中注册，由另一个系统组件service registrar负责。service registrar 通过轮询部署环境或订阅事件去跟踪运行中的实例的变化。当它注意到一个新的可用的服务实例时，就会到注册表中去注册。service registrar也会将停止的服务实例注销。

两种注册方式的对比：

self-registration 模式简单，不需要其它组件。缺点是服务实例和服务注册表相对应，必须要为服务中用到的每种编程语言和框架实现注册代码。

third-party registration 模式主要的优势在于解耦了服务和服务注册表。不需要为每个语言和框架都实现服务注册逻辑。服务实例注册由一个专用的服务集中实现。缺点是除了被内置到部署环境中，它本身也是一个高可用的系统组件，需要被启动和管理。

服务注册表

服务注册表就是服务注册和服务发现的中介，存储着服务注册者访问地址和维持心跳相关信息。服务注册将服务的信息存储在服务注册表，需要调用该服务时服务发现从注册表中获取（实际使用中可以不用每次都去服务注册表中获取，而是缓存服务信息每隔一段时间进行更新）。为了确保服务注册表本身的高可用，服务注册表由一个服务器集群组成，通过应用协议来保持一致性。

下面是服务注册表的几种选择：
Etcd：一个高可用，分布式，一致的key-value存储，用来共享配置和服务发现。Kubernetes和Cloudfoundry都使用了etcd；

Consul：一个发现和配置服务的工具。客户端可以利用它提供的API，注册和发现服务。Consul 可以执行监控检测来实现服务的高可用。也可以使用 Consul 的扩展工具，Consul-template是 Consul的一个方扩展工具，通过监听Consul中的数据可以动态修改一些配置文件，大家比较热衷于应用在Nginx,HAProxy上动态配置健康状态下的客户端反向代理信息。

Apache Zookeeper：一个常用的，为分布式应用设计的高可用协调服务，最开始Zookeeper是Hadoop的子项目，现在已经顶级项目了。zk本来就是分布式协调工具，可以保持高度的一致性，有时候可能在可用性方面较差（Zookeeper 在 CAP 理论中选择了 CP 一致性、分区容错性）

服务发现

当服务调用方调用某个服务的时候，可以通过服务名字去服务注册发现中心获取可用的服务，服务发现中心会从内存的服务列表获取所有可用的服务，然后负载均衡根据既定的规则选择一个服务将 HTTP 服务 ip port 返回给调用方，如果是 grpc 服务, 从连接池获取该服务的连接返回给调用方。

参考资料：
https://www.cnblogs.com/kaleidoscope/p/9605958.html
https://segmentfault.com/a/1190000018731395
https://www.cnblogs.com/knowledgesea/p/11208000.html