SpringCloud微服务之 Eureka(一)

╰+哭是因爲堅強的太久メ 2022-05-09 12:20 231阅读 0赞

## 前言 ##

本节我们将学习微服务中的服务的注册与发现机制。

我们知道SpringCloud在微服务架构中对服务注册与发现的集成与封装使用**Eureka**。因而学习本小节需要对Eureka有纵向(**什么是Eureka,Eureka提供了那些功能**)和横向(**同类型的服务注册与发现机制有哪些**)了解。

## 服务注册与发现机制 ##

不论是在微服务还是在分布式中都会牵涉到一个概念那就是服务的注册与发现。在现有的开源中有很多技术栈实现了服务的注册与发现机制比如Zookeeper、Consul、Eureka等等。其中SpringCloud对以上都做了集成和封装。但是SpringCloud官方推荐使用的Eureka所以我们将以Eureka作为学习案例。

在学习Eureka之前我们需要学习一下服务注册与发现机制中的一些概念

*  服务注册表  
    服务注册表是一个记录当前可用服务实例的网络信息数据库，是服务发现机制的核心。服务注册表提供查询API和管理API。使用查询API可以获得可用的服务实例，使用管理API可以实现服务的注册与注销。
 *  服务注册  
    服务启动时将服务的网络地址注册到服务注册表中
 *  健康检查  
    服务发现组建会通过一些机制定时地检测已注册服务，如果发现某服务无法访问(基于心跳机制周期)，就将该服务从服务注册表中移除。

服务发现方式：  
关于服务的注册与发现有两种方式一种是客户端发现，一种是服务端发现方式。更多信息看这里：[服务注册与发现][Link 1]

*  客户端发现方式
    
     *  Eureka  
        ![在这里插入图片描述][70]
     *  Eureka简介
        
         *  Eureka是Netflix开发的服务发现框架，本身是一个基于RESTful服务的服务，主要用于定位运行在AWS域中的中间层服务，已达到均衡负载和中间层故障转移的目的。
         *  Eureka主要包含两个组件即Eureka Server和Eureka Client。  
            Eureka Server提供服务注册服务，各个节点启动之后会在Eureka Server中注册，这样Eureka Server中的服务注册表中将会保存所有可用服务节点的信息，服务节点在Eureka Dashborad中可以直观呈现。  
            Eureka Client是一个JAVA客户端，用于简化Eureka Server的交互，同时Eureka Client也是一个内置的使用轮询负载算法的负载均衡器。
         *  在应用启动之后将会项Eureka Server发送心跳(默认周期为30s)。如果Eureka Server一定心跳周期内未收到来自节点的心跳，Eureka Server将会从服务注册表中把该节点的服务移除掉(默认为90s且未开启自发保护机制)。
         *  Eureka Server(Cluster)之间会通过复制的方法完成数据同步。
         *  Eureka还提供了客户端缓存机制即使所有的Eureka Server宕机，客户端依然可以利用缓存中的信息消费其他服务API。
         *  Eureka通过心跳机制、健康检查、客户端缓存机制确保了系统的高可用性、灵活性和可伸缩性。
     *  Zookeeper  
        ![在这里插入图片描述][70 1]
 *  服务端发现方式
    
     *  Consul+Nginx  
        ![在这里插入图片描述][70 2]

## VS ##

下面我们看看Eureka、Zookeeper和Consul之间的优劣势：  
![在这里插入图片描述][70 3]

*  服务的健康检查  
    Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。
 *  多数据中心支持  
    Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现；
 *  KV 存储服务  
    除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。
 *  产品设计中 CAP 理论的取舍  
    Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次 CA 类型的场景 Consul,也能提供较高的可用性，并能 k-v store 服务保证一致性。 而Zookeeper,Etcd则是CP类型 牺牲可用性，在服务发现场景并没太大优势；
 *  多语言能力与对外提供服务的接入协议  
    Zookeeper的跨语言支持较弱，其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。
 *  Watch的支持（客户端观察到服务提供者变化）  
    Zookeeper 支持服务器端推送变化，Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知；
 *  自身集群的监控  
    除了 Zookeeper ,其他几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的；
 *  安全  
    Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https.
 *  Spring Cloud的集成  
    目前都有相对应的 boot starter，提供了集成能力。

## 小结 ##

在微服务架构或者分布式架构中如何选择服务注册与发现机制因有需求和业务场景决定。

[Link 1]: http://blog.daocloud.io/microservices-4/
[70]: /images/20220509/e6aba5ee9e7e4b3f85e1010e20ace247.png
[70 1]: /images/20220509/c2d4f67692c243b1899cb5c1505d937c.png
[70 2]: /images/20220509/44cabca763bc47ac96e1e7e605286baf.png
[70 3]: /images/20220509/77046c44ee5642ffa4f9a1c438430a56.png