springCloud的了解（二）

时间 2019-11-29

标签 springcloud 了解繁體版

原文原文链接

更新时间：2019年7月18日
复制代码

前言

今天的话，咱们将继续来学习springCloud。springCloud的组件是极其多的，而其中最为出色的厂家则是NetFlix，能够说这个厂家几乎包揽了springCloud中最为重要的一些服务，例如：服务发现——Netflix Eureka，客服端负载均衡——Netflix Ribbon，断路器——Netflix Hystrix，服务网关——Netflix Zuul。所以也是这个厂商，在去年宣布了再也不更新了Eureka和Hystrix，这其实对于springCloud的生态形成了巨大变化。前端

固然，即使如此，咱们在实际的生产过程当中，仍是在使用NetFlix的大部分组件，由于这些组件即使再也不更新了，可是在最近这几年，我相信市场仍是NetFlix的，由于他们作的组件确实是成熟的，也是符合市场要求的。nginx

所以，咱们今天的主题是springCloud的组件，这固然也就包括了NetFlix厂家的组件。git

Let's go party!!!程序员

ps：你们快去看《乐队的夏天》这个综艺节目，里面的刺猬乐队的主唱子健，听说是程序员里面最会唱歌的(￣▽￣)~*。github

springCloud的组件以及分析

在开始了解springCloud的组件以前，咱们必须先要了解一下微服务究竟是个什么东西，毕竟咱们的springCloud的基调是springboot，而springboot就是微服务。算法

一 .微服务

微服务就是把一个项目拆分为多个项目，项目之间进行独立运行。经过Http或者Socket来进行通讯处理数据和调用。这些小的Web服务能够独立地编译及部署，并经过各自暴露的API接口相互通信。它们彼此相互协做，做为一个总体为用户提供功能，却能够独立地进行扩充。spring

所以衍生出的是微服务的编程思惟：http restful。编程

确定有人问为何不使用RPC来编程，RPC的高效低延迟这个性能指标相信是不少微服务求之不得的，若是一个请求所须要的服务是3个以上而且各个服务业务逻辑复杂，甚至涉及众多IO操做，那是否是RPC的方式更为保障？后端

这个问题，咱们留到后面再去详细了解，今天咱们仍是先进入正题。缓存

二. 微服务组件的使用场景

1：咱们把整个系统根据业务拆分红几个子系统。
 2：每一个子系统能够部署多个应用，多个应用之间使用负载均衡（Netflix Ribbon）。
 3：须要一个服务注册中心，全部的服务都在注册中心注册，负载均衡也是经过在注册中
    心注册的服务来使用必定策略来实现（Netflix Eureka）。
 4：全部的客户端都经过同一个网关地址访问后台的服务，经过路由配置，网关来判断一
    个URL请求由哪一个服务处理。请求转发到服务上的时候也使用负载均衡（Netflix Zuul）。
 5：服务之间有时候也须要相互访问。例若有一个用户模块，其余服务在处理一些业务的
    时候，要获取用户服务的用户数据（Feign，本质上就是Ribbon+Hystrix，用注解的
    方式进行服务调用，代码更好看了）。
 6：须要一个断路器，及时处理服务调用时的超时和错误，防止因为其中一个服务的问题
    而致使总体系统的瘫痪（Netflix Hystrix）。
 7：还须要一个监控功能，监控每一个服务调用花费的时间等（Turbin）。
 8：也须要一个配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式，相似规章制
    度，每一个人都从这里获取规定配置。（Config）
复制代码

springCloud的组件太多，可是在实际的开发中，咱们使用的组件，可能没有这么多，所以在实际的开发中，咱们不须要一次性所有学会，只须要关注比较重要的几个就好了。固然，今天咱们仍是尝试着蜻蜓点水的将全部的组件了解一遍。

三. srpingCloud的组件解析

接下来咱们开始了解springCloud组件，请戴上你的耳机，我推荐一首歌，最近很喜欢的一首歌《say it again》，是国内的一个乐队“盘尼西林”的歌，也参加了《乐队的夏天》这个综艺。哈哈哈哈ヾ(๑╹◡╹)ﾉ"，没错，我就是传说中的自来水粉丝。

接下来，我会按照重要程度降序，来一一解析springCloud的部分重要组件。

1. Netflix Eureka——服务发现

毫无疑问，Eureka是springCloud的组件中的重要程度是要排第一的。

咱们须要分别下载 Eureka 官方源码和 Spring Cloud Netflix 适配 Eureka 的代码。

原生 Eureka 代码： github.com/Netflix/eur…

Spring Cloud针对于Eureka的Spring Cloud适配：github.com/spring-clou…

ps: 没有下载git的朋友请下载git，用来在github上下载源代码。

服务发现（Eureka）是NetFlix旗下的核心组件之一，它负责服务注册，管理服务列表。全部的微服务都须要在Eureka上面进行注册登记，各个服务之间不须要之间对方的ip和端口，都是经过服务发现中心来进行互相调用API（一个在注册中心注册的REST服务），这固然会出现额外的开支--这个开支也就是全部客户机必须实现某种逻辑来与这个中心点进行交互，这样在实现服务请求以前将增长一次额外的网络往返。

springCloud使用Eureka来进行服务发现，在微服务注册到Eureka的时候，它必须向Eureka发送心跳信息，以此Eureka会判断这个微服务是否在线上。

若是你相同的微服务你开了多个服务端，那么在Eureka也会在注册发现中心显现出来功能相同的微服务的不一样的服务端，那么也是依赖Eureka来进行相似nginx分发服务的负载均衡的功能。

到了这里，咱们发如今以前的学习过程当中，咱们仍是不够了解springboot。由于springboot实际上的开发解耦就是将后端和前端直接分离开了，不是说使用springboot或者springCloud不能进行先后端一体开发，而是springCloud乃至springboot的自己就是为了先后端分离而诞生的。（在springCloud中，后端接口的API都是注册到了Eureka中的，实际开发中，前端开发工做人员甚至能够直接在Eureka中直接查找须要的接口API。）

总结：

1. 是纯正的 servlet 应用，需构建成war包部署 
2. 使用了 Jersey 框架实现自身的 RESTful HTTP接口 
3. peer之间的同步与服务的注册所有经过 HTTP 协议实现 
4. 定时任务(发送心跳、定时清理过时服务、节点同步等)经过 JDK 自带的 Timer 实现 
5. 内存缓存使用Google的guava包实现
复制代码

其实不须要问为何使用的是HTTP协议，看看市面上有什么不支持HTTP的么？这其实就是为何要使用HTTP的缘由之一。

2. Netflix Ribbon——客服端负载均衡

Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务链接在一块儿。

咱们在配置文件中列出负载均衡全部的机器，Ribbon会自动的帮助咱们基于某种规则（如简单轮询、随机链接等等）去链接这些机器。

Ribbon客户端组件提供了一列完善的配置项（如链接超时、重试等等），咱们也能很容易的使用Ribbon实现自定义的负载均衡算法。

Ribbon和Eureka整合后服务消费方能够直接调用服务而不用再关心提供服务的地址以及提供服务的端口号。

Ribbon其实就是一个软负载均衡的客户端软件，它能够和其它所需请求的客户端结合使用，和Eureka结合只是其中的一个实例。

接下来贴出一些最基本的配置项：

RoundRobinRule：轮询
 RandomRule：随机
 AvailabilityFilteringRule：会先过滤掉因为屡次访问故障而处于断路器跳闸状态和并
                            发的链接数量超过阈值的服务，而后对剩余的服务列表按
                            照轮询策略进行访问。
 WeightedResponseTimeRule：根据平均响应时间计算全部服务的权重，响应时间越快服
                           务权重越大被选中的几率越高。
 RetryRule：先按照RoundRobinRule的策略获取服务，若是获取服务失败，则在指定时间
            内会进行重试，获取可用的服务。
 BestAvailableRule：会过滤掉因为屡次访问故障而处于断路器跳闸状态的服务，而后选
                    择一个并发量最小的服务。
 ZoneAvoidanceRule：默认规则，复合判断Server所在区域的性能和Server的可用性选择服
                    务器。
复制代码

若是须要修改的话也很简单，我在网络上找到了一些方法，如今贴出一个来：

固然，我如今也只是大概了解了一下，由于在实际开发中，颇有多是须要配置本身自定义的规则，那么修改方法可能不同了，具体状况你们感兴趣的话能够在网络上自行百度。

3. Netflix Zuul——服务网关

在下才疏学浅，不少的东西都解释很差，所以只能厚颜从网络上搬来一部分资料。刚刚在网络上的一个博客看到一个大神解释的关于Eureka和Ribbon的解释图，给你们看看。

其实在以前的Eureka的解析中，我多多少少有解释过，先后端分离的解耦，最重要的缘由是开发人员能够直接调用接口API。

可是在实际开发中，咱们在每个服务接口上面都会加上一些权限校验，那么在这里，若是咱们在每一次调用服务接口的时候都进行权限校验，那么咱们必须在每一次调用服务接口的时候必须加上权限校验的代码，这很明显的增长了咱们的工做量。

并且若是微服务数量多了，那么一些接口的调用规则，服务列表的维护工做也会变得十分的麻烦，甚至须要公司在开发以前都要作好接口的规则肯定。

因而，API网关（路由网关）应运而生。

在没有网关以前，客户端服务包括两个步骤：

1.从EurekaServer获取一个客户端服务的全部地址
2.经过Ribbon负载均衡选择一个机器进行访问
复制代码

引入网关以后，客户端经过 “http://gateway/服务ID/url” URL格式调用网关，网关执行包括两个步骤：

1.使用服务ID查找客户端服务
2.使用Netflix Ribbon对调用服务进行负载均衡。
复制代码

路径解释：

gateway:网关服务在Eureka注册的服务ID
服务ID:客户端服务在Eureka注册的服务ID
url:访问客户端服务的url。
复制代码

在上一个图片的基础上，咱们贴出有了路由网关的图：

咱们看到，整个系统的入口就是zuul，当咱们有参数校验的需求时，咱们就能够利用Zuul的Pre过滤器，进行参数的校验。例如我如今但愿请求都一概带上token参数，不然拒绝请求。固然，在这个图中，没有加入Pre过滤器。

这就是zuul的两大功能：过滤（权限控制）和路由转发。

4. Netflix Hystrix——断路器

Hystrix的中文翻译是豪猪，也就是身上长满了刺的猪。它的主要功能是-自我保护。Hystrix具备服务降级，熔断，线程池隔离，信号量隔离，缓存等功能，基本上能覆盖到微服务中调用依赖服务会遇到的问题。

为了保证其高可用，单个服务一般会集群部署。因为网络缘由或者自身的缘由，服务并不能保
证100%可用，若是单个服务出现问题，调用这个服务就会出现线程阻塞，此时如有大量的请求
涌入，Servlet容器的线程资源会被消耗完毕，致使服务瘫痪。服务与服务之间的依赖性，故
障会传播，会对整个微服务系统形成灾难性的严重后果，这就是服务故障的“雪崩”效应。
复制代码

当执行调用服务方法时，若调用方法出现问题，如：请求超时，抛出异常，线程池拒绝，熔断这些状况下，为该方法定义降级方法，以便在出现问题时执行，实现备用返回。以前咱们已经实现了服务降级功能，主要就是经过@HystrixCommand(fallbackMethod = "defaultMethod")注释到须要在出现问题时降级的方法。

fallbackMethod指定降级后执行的方法。方法定义在该类中，public，private，protected均可以。在注释的方法出问题后，如超时未返回(execution.isolation.thread.timeoutinMilliseconds来配置)，就会执行备用方法，返回备用方法的返回值。固然，降级的方法也能够定义再下一级的降级方法，实现和上面同样。

上面说到方法抛出异常也会触发服务降级，可是若是咱们自定义了异常，并须要将异常抛出给上层作操做，不但愿Hystrix捕捉到自定义异常执行服务降级时，可使用@HystrixCommand(ignoreExceptions ={MyException.class})来定义忽略捕捉的异常。多个异经常使用逗号隔开。也能够将抛出的异常经过入参传到降级的方法，来实现不一样类型异常的不一样处理。

小结

到了这里，我相信你们对springCloud有了一个总体的大概的了解，固然，实际状况中，springCloud的复杂程度是超出当前个人讲述的。明天，咱们将继续来了解springCloud。