SpringCloud服务注册

什么是服务注册中心

        服务注册中心是服务实现服务化管理的核心组件，只要用来存储服务信息等。

        服务注册中心的作用就是服务的注册和服务的发现。

例如：

        当下我给张三打电话，那我就需要在通讯录中按照名字找到张三，然后就可以找到他的手机号拨打电话---------服务发现。

        李四办了新的手机号并把手机号存进通讯录，后面我就可以通过通讯录找到李四了--------服务注册。

        通讯线就是服务注册中心。

常见的注册中心

        Netflix Eureka、Alibab Nacos、HashCorp Consul、Apache Zookeeper、CoreOS Etcd、CNCF CoreDNS。

 注册中心解决了什么问题

        1.服务管理。   2.服务的依赖关系管理。

下面分别介绍下consul和Eureka。

Consul    

        用于实现分布式系统的服务发现与配置。

        特性：1.Raft算法  2.服务发现  3.健康检查  4.Key/Value存储  5.多数据中心  6.支持http和dns协议接口  7.官方提供web管理界面。

 Consul角色：

        client:客户端，无状态，将HTTP和DNS接口请求转发给局域网内的服务集群。

        server:服务端，保存配置信息，高可用集群，每个数据中心的server数据推荐3或5个。

         上图是一个简单的Consul Cluster架构，Consul Cluster有server和client两种角色。不管是server还是client，统称为Agent, Consul client是相对无状态的，只负责转发RPC到server，资源开销很少。Server是一个有一组扩展功能的代理，这些功能包括参与Raft选举，维护集群状态，响应RPC查询，与其他数据中心交互等。
 

Consul工作原理：

 服务发现及注册：

        当服务Producer（也就是需要注册到consul上的服务）启动时，会将自己的IP/HOST等信息通过发送请求告知Consul,Consul接收到Producer的注册信息后，每隔10S会向Producer发送一个健康检查的请求，检验Producer是否健康。

服务调用：

        当Consumer（服务调用者）请求Producer时，会先向Consul中拿到Producer服务的IP和PORT的临时表（temp table）,从temp table表中任选一个Producer的IP和PORT，然后根据这个IP和PORT，发送访问请求；temp table表只包含通过了健康检查的Producer信息，每隔10S更新。

 Consul安装：

        Eureka其实就是一个Server程序，跑在Servlet容器中；Consul则是用go语言编写的第三方工具，需要单独安装使用。就只有一个.exe的文件。

启动命令：https://blog.csdn.net/qq_35433926/article/details/96477211

访问后台：http://localhost:8500/ui/

consul代码示例：

        在工程的父POM里面需要添加springCloud的依赖，需要注意springCloud和springBoot的版本。

         需要注册到consul上的服务provider的POM：

        provider的配置文件中配置consul的信息及服务信息：

         这样就可以将一个服务注册到consul上了。

        服务调用者consumer的POM依赖和配置文件信息配置和provider类似。

        在consumer启动类中开启服务寻址：

         服务寻址DiscoveryClient及RestTemplate使用示例：

RestTemplate 说明：

        RestTemplate 是从 Spring3.0 开始支持的一个 HTTP 请求工具，它提供了常见的REST请求方案的模版，例如 GET 请求、POST 请求、PUT 请求、DELETE 请求以及一些通用的请求执行方法 exchange 以及 execute。RestTemplate 继承自 InterceptingHttpAccessor 并且实现了 RestOperations 接口，其中 RestOperations 接口定义了基本的 RESTful 操作，这些操作在 RestTemplate 中都得到了实现。

        这里在说下直接在RestTemplate 做负载均衡，首先需要先配置RestTemplate 的负载均衡。

         那么使用RestTemplate进行调用的时候，就可以直接这样调用：

        

请求失败重试（https://blog.csdn.net/jinjiniao1/article/details/100849601）：

      具备了负载均衡功能的 RestTemplate 也可以开启请求重试功能。有的时候，在微服务调用的过程中，由于网络抖动等原因造成了访问失败，这个时候如果直接就认定访问失败显然是不划算的，可以多尝试几次，多次尝试之后，如果还是请求失败，再判定访问失败。默认情况下，重试功能是没有开启的，开启重试功能很简单，开发者只需要在 consumer 中添加 Spring Retry 依赖即可，如下：  

        只要添加了该依赖，我们的 RestTemplate 此时就自动具备了请求失败重试的功能（注意，加入依赖后请求失败重试功能就会自动开启了），如果开发者加入了该依赖，但是又不想开启请求失败重试功能，可以在application.properties中添加如下配置：

         表示关闭请求失败重试功能。至于请求失败重试的次数以及切换实例的次数，可以通过如下配置实现：

在说下@FeignClient注解：

        上面的demo中通过最原始的手动利用 DiscoveryClient 发现服务，然后使用RestTemplate 进行调用，这样写有点麻烦，每次都要写请求 Url 、配置响应数据类型，最后还要组装参数，更重要的是这些都是一些重复的工作，代码高度相似，每个请求只有 Url 不同，请求方法不同、参数不同，其它东西基本都是一样的，既然如此，那有没有办法简化请求呢？有！这就是声明式微服务调用 OpenFeign。

       首先是POM依赖：

         开启feign的支持：

         未完待续！！！

Eureka

        Eureka是Netflix开发的服务发现组件，本身是一个基于REST的服务。Spring Cloud将它集成在子项目Spring Cloud Netflix中，实现Spring Cloud的服务注册与发现，同时还提供了负载均衡、故障转移等能力。  

        Eureka注册中心三种角色：

         

        Eureka Server：通过Register、Get、Renew等接口提供服务的注册和发现。

        Server Provider：服务提供方，把自身的服务实例注册到Eureka Server中。

        Server Consumer：服务调用方，通过Eureka Server获取服务列表，消费服务。

 Eureka构架原理：

        Register(服务注册)：把自己的ip和port注册给Eureka。

        Renew（服务续约）：发送心跳包，每30S发送一次，告诉Eureka自己还活着，如果90S未发送心跳，宕机。

        Cancel（服务下线）：当Provider关闭时，会向Eureka发送消息，把自己移除服务列表。

        Get Register(获取服务注册列表)：获取其他服务列表。

        Replicate（集群中数据同步）：Eureka集群中的数据复制与同步。

        Make Remote Call(远程调用)：完成服务的远程调用。

Eureka自我保护：

        启动自我保护条件：一般情况下，服务在Eureka上注册后，每隔30S发送一个心跳包，Eureka通过心跳来判断服务是否健康，同时会定期删除超过90S没有发送心跳包的服务。

        两种情况导致Eureka Server 收不到微服务的心跳：

        1.微服务自身的原因。2.微服务与Eureka之间的网络故障。

        自我保护模式：Eureka Server在运行期间会统计心跳失败比例在15分钟之类是否低于85%，如果低于85%，Eureka Server会将这些实例保护起来，让这些实例不会过期，同时提供一个警告。这种算法叫做Eureka Server的自我保护模式。

Eureka管理界面地址：http://localhost:8761/

Ribbon

        Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它是基于Netflix Ribbon实现的。

        它不像Spring Cloud服务注册中心、配置中心等独立部署，但是它几乎存在于每个Spring Cloud微服务中。包括Feign提供的声明式服务调用也是基于Ribbon实现的。

负载均衡

        负载均衡，简单的说就是将用户的请求平摊分配到多个服务，从而达到系统的 HA（高可用）。负载均衡又分为集中式负载均衡和进程内负载均衡。

        集中式负载均衡（服务器负载均衡）：即在consumer和provider之间使用独立的负载均衡设施（可以是硬件，如F5，也可以是软件，如nginx）,由该设施负责把访问请求通过某种策略转发置provider。

        进程内负载均衡（客户端负载均衡）：将负载均衡逻辑集成到consumer（客户端），consumer从服务注册中心获知有哪些地址可用，然后自己在从这些地址中选择一个合适的provider。Ribbon属于后者，它只是一个类库，集成于consumer进程，consumer通过它来获取provider的地址。

集中式负载均衡：

 进程式负载均衡：

Ribbon负载均衡策略：

        轮询策略（RoundRobinRule）：轮询选择， 轮询index，选择index对应位置的Server。

        响应时间加权重策略（ResponseTimeWeightedRule）：根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间

        随机策略（RandomRule）：随机选择server

        最低并发数策略（BestAvailableRule）：逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server。

        重试策略（RetryRule）：先按照选定的策略获取服务，如果获取服务失败则在指定时间内会进行重试，获取可用的服务。

        可用过滤策略（AvailabilityFilteringRule）：过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个Server的运行状态。

        区域敏感性策略（ZoneAvoidanceRule）：默认规则，符合判断Server 所在区域的性能和 Server 的可用性选择服务器。

Ribbon负载均衡设置：

          1.全局。在启动类或配置类中注入负载均衡策略对象。所有服务请求均使用该策略。

        给RestTemplate加一个@LoadBalanced注解，就能让这个RestTemplate在请求时拥有客户端负载均衡的能力。

         2.局部。修改配置文件可指定服务的负载均衡策略。

https://www.zhihu.com/topic/21215889/hot