#冲刺创作新星#云原生架构之服务发现与注册-总述 原创

一 服务注册与发现

1.1 服务发现概述

在微服务架构中，由于服务众多且单个服务具有多个实例，同时部署在Kubernetes集群中，实例的IP地址是可能随时变化的，需针对该情况对服务调用进行集中统一管理，因此引入服务注册发现机制。
服务注册和发现的意思是服务进程在注册中心注册自己的位置，客户端应用进程向注册中心发起查询，来获取服务的位置，服务发现的一个重要作用就是提供一个可用的服务列表。
通过统一集中化管理，使得服务直接仅通过服务名称即可调用，无需知道具体实例的IP地址。

1.2 业界主流服务注册发现方案

1.2.1 Eureka

Eureka 强调最终一致性（在有限的时间内（例如 3s 内）将数据收敛到一致状态）采用AP ，在牺牲数据一致性的情况下最大程度保障服务的可用性，服务端和客户端都是 Java 编写的，针对微服务场景，并且和 Netflix 的其他开源项目以及 Spring Cloud 都有着非常好的整合，具备良好的生态。
服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功，当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
参考链接：https://spring.io/projects/spring-cloud-netflix?spm=a2c6h.12873639.article-detail.4.296c46cf7GjUZa

1.2.2 Nacos

Spring Cloud Alibaba 技术体系中的 Nacos，提供了两个重要的功能：注册中心（服务注册与发现）功能和配置中心功能。
其中注册中心解决了微服务调用中，服务提供者和服务调用者的解耦，让程序开发者可以无需过多的关注服务提供者和调用者的运行细节，只需要通过 Nacos 的注册中心就可以实现两者的互联互通，相当于实现了远程服务本地化，并且提供了健康检查等机制。

1.2.3 Consul

Consul 由 HashiCorp 开源，是支持多个平台的分布式高可用系统。Consul 使用 Golang 语言实现，主要用于实现分布式系统的服务发现与配置，基于 Raft 算法，其是分布式、高可用和可横向扩展的，提供以下主要特性：

• 服务发现：可以使用 HTTP 或者 DNS 的方式将服务实例的元数据注册到 Consul，和通过 Consul 发现所依赖服务的元数据列表。
• 检查检查：Consul 提供定时的健康检查机制，定时请求注册到 Consul 中的服务实例提供的健康检查接口，将异常返回的服务实例标记为不健康。
• Key/Value：Consul 提供了 Key/Value 存储功能，可以通过简单的 HTTP 接口进行使用。
• 多数据中心：Consul 使用 Raft算法来保证数据一致性，提供了开箱即用的多数据中心功能。
  服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
  Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

参考链接：https://www.consul.io/docs/discovery/services

1.2.4 Zookeeper

是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题。ZooKeeper是按照CP原则构建的，也就是说它能保证每个节点的数据保持一致，而为ZooKeeper加上缓存的做法的目的是为了让ZooKeeper变得更加可靠（available）。
Zookeeper的服务注册与发现，主要应用的是Zookeeper的Znode数据模型和Watcher机制，主要分为如下几个步骤：
服务注册：服务提供者（Provider）启动时，会向Zookeeper服务端注册服务信息，即会在Zookeeper服务器上创建一个服务节点，并在节点上存储服务的相关数据（如服务提供者的ip地址、端口等），比如注册一个用户注册服务（user/register）:
服务发现：服务消费者（Consumer）启动时，会根据本身依赖的服务信息，向Zookeeper服务端获取注册的服务信息并设置Watch，获取到注册的服务信息之后将服务提供者信息缓存在本地，调用服务时直接根据从Zookeeper注册中心获取到的服务注册信息调用服务，比如发现用户注册服务（user/register）并调用。

1.2.5 Etcd

Etcd 是由 CoreOS 开源，采用 Golang 语言编写的分布式、高可用的 Key/Value 存储系统，主要用于服务发现和配置共享，并通过Raft 一致性算法处理日志复制以保证强一致性。Ectd 的经典应用场景有：

• Key/Value 存储：Etcd 支持 HTTP RESTful API，提供强一致性、高可用的数据存储能力。
• 服务发现：通过在 Etcd 中注册某个服务的目录，服务实例连接 Etcd 并在目录下发布对应 IP 和 Port 以供调用方使用，可以有效实现服务注册与发现的功能；
• 消息发布与订阅：通过 Etcd 的 Watcher 机制，可以使订阅者订阅他们关心的目录。当消息发布者修改被监控的目录内容时，可以将变化实时通知给订阅者。
  Raft 一致性算法处理日志复制以保证强一致性。etcd像是专门为集群环境的服务发现和注册而设计，它提供了数据 TTL 失效（etcd的 租约模式:客户端申请 一个租约 并设置 过期时间，每隔一段时间 就要 请求 etcd 申请续租。客户端可以通过租约存key。如果不续租 ，过期了，etcd 会删除这个租约上的 所有key-value。类似于心跳模式。）、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。
  服务注册与发现内容：
• 服务注册：同一service的所有节点注册到相同目录下，节点启动后将自己的信息注册到所属服务的目录中。
• 健康检查：服务节点定时发送心跳，注册到服务目录中的信息设置一个较短的TTL，运行正常的服务节点每隔一段时间会去更新信息的TTL。
• 服务发现：通过名称能查询到服务提供外部访问的 IP 和端口号。比如网关代理服务时能够及时的发现服务中新增节点、丢弃不可用的服务节点，同时各个服务间也能感知对方的存在。
  Etcd与Zookeeper功能有很多类似，但Zookeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世；另外，Zookeeper的使用也比较复杂，需要安装客户端，官方只提供了java和C两种语言的接口。

参考链接：http://devo.ps/blog/zookeeper-vs-doozer-vs-etcd/

1.2.6 K8s service

参考：云原生架构之服务发现与注册-Kubernetes中服务注册发现
总体来说K8s的服务注册与发现通过Etcd+CordDNS来实现，其中又包含了endpoints/kube-proxy等组件的协同。

1.3 方案对比

二 架构迭代转下

目前业务架构使用consul 进行服务注册发现，将Consul部署在K8s集群中。

Consul Server采用StatefulSet部署，Consul client采用DaemonSet部署。

三 遇到问题

部署有Consul 相关服务的Node异常重启后，consul server发生变化，单服务内使用HOST仍然为老的consul 地址，造成服务异常，需要深入分析，待dev环境K8s部署完成后，进行模拟测试，进一步复现故障，找寻解决方案。

四 改进方向

由于目前业务采用容器部署在在k8s环境中,在考虑上isito之前，尽可能贴近云原生架构进行改造。

4.1 东西流量

• 采用springboot+原生K8s service进行服务注册发现。
• 采用springcloudkubernetes方式引入jar包进行服务注册发现。

4.2 南北流量

南北流量主要为gateway 的服务注册发现使用K8s 原生资源实现。

五 改进方案

5.1 Springcloudkubernetes服务注册发现方案（东西流量）

通常将spring cloud应用上K8s集群，使用spring cloud kubernetes，服务注册依旧为使用k8s服务注册，服务发现利用其discover可以通过K8s api发现一个服务后的一组实例，负载均衡使用spring cloud kubernetes ribbon实现（改方案负责均衡为客户端负载均衡）。

5.2 SpringBoot+K8s service服务注册发现方案（东西流量）

将spring cloud应用上K8s集群，服务注册直接使用K8s service，即为服务绑定service，服务发现使用K8s service（该方案负责均衡为服务端负载均衡）。

5.3 Springboot gateway+K8s服务注册发现方案（南北流量）

springboot gateway 服务利用spring cloud kubernetes进行调用K8s API获取service服务发现，进行路由转发。

参考链接

• https://spring.io/projects/spring-cloud-kubernetes