image.png
ETCD
etcd 是一个 分布式 的高一致性的 键值存储系统。我们每次网关 后面加一个服务，只需要向etcd 注册 该服务（其实就是 存一个值）然后向etcd 发送心跳，当etcd 没有检测到心跳就会 把这个键值对 删了(这整个动作是etcd里的租约模式)，网关那边 就只需要 watch 这个 key ，就能够知道 所有服务的所有动态了。

Nacos

服务发现和服务健康监测：

  • Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
  • Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

动态配置服务：

  • 动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
  • 动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
  • 配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
  • Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

动态 DNS 服务：

  • 动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。

  • Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表。

    Consul

    Consul 是一种服务网格解决方案，提供具有服务发现、配置和分段功能的全功能控制平面。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建完整的服务网格。Consul 提供的核心功能：

  • 服务发现：服务启动时将服务相关信息（地址、端口、配置、tag等）注册到 Consul 中，由它统一管理，当需要访问其他服务时向 Consul 查询所依赖服务的相关信息。查询方式支持 HTTP、RPC、DNS等。

  • 健康检查：在将服务注册到 Consule 时可以配置健康检查，Consul 会对其定期进行检查，如果检查失败，就会认为该服务不可用，当有其他服务过来查询这个服务的地址时，返回时可以把不可用的地址剔除（注：同一个服务一般会有多个服务/地址）。
  • 安全服务通信：Consul 可以为服务生成和分发 TLS 证书，以建立相互的 TLS 连接。Intentions 可用于定义允许哪些服务进行通信。通过实时地更改Intentions 来管理服务服务分段，控制服务间的是非否可访问。
  • KV存储：Cousul 可以用来做简单的键值存储场景，比如：动态配置、功能标记、协调、领导者选举等。提供简单的 HTTP API。
  • 多数据中心：Consul 支持开箱即用的多个数据中心，用以支持高可用的场景需要。

怎么找到服务发现服务端的地址？

  • 在应用的配置文件中指定服务注册中心的地址，类似于 zookeeper 和 eureka。
  • 指定一个地址服务器的地址，然后通过这个地址服务器来获取服务注册中心的地址，地址服务器返回的结果会随着服务注册中心的扩缩容及时更新。

    当服务有节点退出或新的节点加入时，订阅者如何及时收到通知 ？

    很经典的 Push 和 Pull 问题。
    Push 的经典实现有两种，基于 socket 长连接的 notify，典型的实现如 zookeeper；另一种为 HTTP 连接所使用 Long Polling。但是基于 socket 长连接的 notify 和基于 HTTP 协议的 Long Polling 都会存在notify消息丢失的问题。
    所以通过 Pull 的方式定时轮询也必不可少，时间间隔的选择也很关键，频率越高服务注册中心所承受的压力也越大。需要结合服务端的性能和业务的规模进行权衡。
    还有一种方式，真实的 Push，客户端开启一个 UDP server，服务注册中心通过 UDP 的方式进行数据推送，当然这个也受限于网络的连通性。

客户端容灾策略

  1. 首先，本地内存缓存，当运行时与服务注册中心的连接丢失或服务注册中心完全宕机，仍能正常地调用服务。
  2. 然后，本地缓存文件，当应用与服务注册中心发生网络分区或服务注册中心完全宕机后，应用进行了重启操作，内存里没有数据，此时应用可以通过读取本地缓存文件的数据来获取到最后一次订阅到的内容。
  3. 最后，本地容灾文件夹。正常的情况下，容灾文件夹内是没有内容的。当服务端完全宕机且长时间不能恢复，同时服务提供者又发生了很大的变更时，可以通过在容灾文件夹内添加文件的方式来开启本地容灾。此时客户端会忽略原有的本地缓存文件，只从本地容灾文件中读取配置。

    服务端容灾与高可用

  • 当有新节点加入集群时，节点启动后能自动添加到地址服务器中，并通过地址服务器找到其他节点，自动从其他节点同步数据，以达到数据的最终一致性。
  • 当某个节点宕机时，此服务注册中心节点的信息会自动地址服务器中摘除，客户端能及时感知到此节点已下线。