Spring Cloud 学习笔记(六) 之服务治理模块之“基础架构”，“服务治理机制”讲解

1、前言

上一篇文章主要讲了对于spring cloud的高可用注册中心的调用，本章节主要对前几章的一些概念的总结以及补充一些新的概念。

2、概念总结

    1.基础架构

        a.服务注册中心

            Eureka提供的服务端，提供服务注册和发现的功能，也就是以前实现的 eureka-server

        b.服务提供者

            提供服务，他将本身的服务注册到Eureka-server，以供其余应用调用，也就是以前实现的hello-ervice服务

        c.服务消费者  

             消费者从服务注册中心获取服务列表，从而使得消费者能够知道去何处调用想要的服务，在以前的章节中咱们使用Ribbon来实现服务消费。

    2.服务治理机制

        

        a.服务注册中心

            失效剔除

                有时候，服务并非正常下线，可能会由于内存溢出、网络故障等缘由使得服务不能正常工做，从而服务注册中心未收到 “服务下线”的请求。 为了使得服务列表中将这些没法提供服务的示例剔除，Eureka Server 再启动的时候会建立一个定时任务，默认每隔一段时间（60s）将当前清单中超时（90s）没有续约的服务剔除

            自我保护

                当咱们在本地调试Eureka的时候，常常会出现一行警告

                

                这是因为服务注册中心检测到服务提供者挂掉的状态触发了注册中心的保护机制，若是是这种状态，咱们服务调用者若是调用其中一个失败的服务是会返回调用失败的，因此客户端必需要有容错机制，好比可使用请求重试，断路器等机制。咱们在本地开发的时候，能够经过 eureka.server.enable-self-preservation=false.先关闭保护机制，这样，咱们客户端调用的时候，只会调用到正常的服务上来。

        b.服务提供者

            服务注册

                “服务提供者”在启动的时候会经过发送REST请求的方式将本身注册到Eureka Server上，同时带上了一些自身服务的一些元数据信息。Eureka Server 接收到这个REST请求后，将元数据信息存储在一个双层结构MAP中，其中第一层key是服务名，第二层的key是具体服务的示例名。

                注意：在服务注册时，须要确保 eureka.client.register-with-eureka=true 。若为false，将不会启动服务注册。

            服务同步

                如上面架构图所示，这里两个服务分别注册到了两个注册中心，也就是，他们的信息被两个注册中心维护。此时，因为注册中心之间互相注册为服务，当服务提供者发送注册请求到一个注册中心时，他会将请求自动转发到另外一个注册中心上，从而实现注册中心间的服务同步，经过服务同步，两个服务提供者的服务信息就能够经过这两台注册中心的任何一台获取到。

            服务续约

                在注册完服务后，服务提供者会和注册中心之间维护一个心跳机制，告诉注册中心，我还活着，以防被剔除。这种神操做叫作服务续约。

                服务续约有个重要属性，能够进行调整注册服务的心跳

                eureka.instance.leaseRenewalIntervalInSeconds = xxx

Why Is It so Slow to Register a Service?
Being an instance also involves a periodic heartbeat to the registry (through the client’s serviceUrl) with a default duration of 30 seconds. A service is not available for discovery by clients until the instance, the server, and the client all have the same metadata in their local cache (so it could take 3 heartbeats). You can change the period by setting eureka.instance.leaseRenewalIntervalInSeconds. Setting it to a value of less than 30 speeds up the process of getting clients connected to other services. In production, it is probably better to stick with the default, because of internal computations in the server that make assumptions about the lease renewal period.

做为一个实例还须要按期检查注册表（经过客户端的serviceUrl），默认持续时间为30秒。 服务不可用于客户端发现，直到实例，服务器和客户端在其本地缓存中都具备相同的元数据（所以可能须要3次检测信号）。 您能够经过设置eureka.instance.leaseRenewalIntervalInSeconds来更改期间。 将其设置为小于30的值可加快客户端与其余服务的链接。 在生产中，因为服务器中的内部计算对租约续订期做出了假设，因此最好坚持使用默认值。

        c.服务消费者

            获取服务

                当咱们启动服务消费者的时候，他会发送一个REST请求到服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回到客户端

            服务调用

                咱们能够看到架构图是两个服务提供者，当服务消费者拿到清单后，能够本身选择调用哪一个注册中心的哪一个服务，在Ribbon会默认采起轮训的方式调用，从而实现客户端的负载均衡。

            服务下线

在系统运行过程当中必然会面临关闭或重启服务的某个示例的状况，在服务关闭期间，咱们天然不但愿客户端会继续调用关闭了的示例。因此在客户端程序中，当服务示例进行正常的关闭操做时，他会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心，我要下线了。服务端在收到请求后，将该服务STATUS 置为 DOWN ，并把下线事件传播给其余注册中心。