SpringCloud版本Hoxton SR5 --- 第一讲：认识

什么是SpringCloud ？我用好理解的方式作比喻：

这里我们拿京东的网站做解释，京东不一定这么搞得，但是思想是一致的。首先SpringCloud一种微服务架构的实现；首先京东支持14亿人访问，这个架构一定不简单，而这个架构就是微服务架构。看例子：京东的首页网站：https://www.jd.com/ 京东的商品列表：https://list.jd.com/ 京东商品详情：https://item.jd.com/ ，购物车：https://cart.jd.com/ 等等。有没有发现一个问题，就是他们的网站地址不一样？这就证明了他们的业务是拆分开了，他们用到了微服务架构。

比如说，我们进京东，首先访问的是，京东的首页，首页也是访问人数最多的一个网站。这时候用一台、几台tomcat肯定是支撑不了这么大的并发访问量的。第二，选商品肯定要在很多商品列表中看一个自己喜欢的，这时候就是https://list.jd.com/对应的服务器返回的数据，还比如说京东的订单功能：https://order.jd.com/，我们一定是选好商品，准备付款的时候跳转到订单列表，这个功能用的人相对首页来说，并发访问量就没那么大了。

这时候为了不浪费资源，程序员可以怎么做呢？举个例子：我把首页部署 1000台服务器，因为用的人最多，把订单部署200台服务器，因为用的人相对较少，我把订单的评论功能用50台服务器。想想如果没有架构的京东会是什么样子？就是把上面所有的功能都写在一个项目中，然后用很多很多的服务器部署这个一个项目，而且还不一定在618的时候，可以抗的住大量的访问。

所以什么是微服务呢？

就是把功能单独拆分开来，单独集群部署，这么一个思想，就是微服务架构思想。

把原本臃肿的一个项目的所有模块拆分开来并做到互相没有关联，甚至可以不使用同一个数据库，这就是微服务。

而SpringCloud就是为微服务提供技术支持的。SpringCloud不是微服务，只是为微服务提供解决方案。

这么说，还是很抽象，SpringCloud不是有很多很多技术吗？

下面就是用举例子的方式讲解：SpringCloud组件

再举例子（讲解eureka 集群、心跳与zookeeper类似）：

传送门：SpringCloud版本Hoxton SR5 --- 第二讲：eureka 、eureka与zookeeper的区别与使用场景。

比如现在京东首页展示的代码写好了，我们把这个代码项目名管叫：jd-index ，然后把这个项目复制1000份部署到1000台服务器上，这时候就有一个问题，1000台服务器，1000个ip地址，我访问谁呢？这时候一定有人会说用nginx做反向代理。没错这是一个解决方案。

但是nginx还有个缺点，就是比如说 1000台，宕机500台，nginx在访问的时候，大多都是轮循机制，什么意思呢？比如说，1000个人访问nginx，但是宕机500台，这500台正好是配置的前500台宕机了，每台服务器自动访问两次再换服务器访问。就会造成所有人访问都是失败的，后1000-2000的访问是成功的。这就会造成很大一部分人，手机或者电脑提示404或者一直再访问中。而eureka就可以解决这个问题，eureka自动识别到这500台服务器故障，然后自动将这500台服务器剔除去，那么这1000个人，就不可能访问到故障服务器。eureka把故障机踢出去后，就只剩下500台可以访问的机器，这样所有用户就都能访问成功。大大提高了用户的体验，当500个故障服务故障排除之后，又会自动重连。但值得注意的是，eureka解决的仅仅是将故障服务器剔除，他没有nginx的负载均衡功能，所以还要配合Ribbon的负载均衡策略，才可以完成一个真正的具有健壮性的负载均衡。

所以：eureka可以做到的仅仅是是微服务之间的心跳检测和微服务之间的相互注册。把故障微服务剔除，再把留下来的健康的服务的接口交给Ribbon做负载均衡。所以eureka 需要与 Ribbon + Fegin一起，才能实现负载均衡的完整功能。

接着上面的例子（讲解Ribbon 与nginx类似）

传送门：SpringCloud版本Hoxton SR5 --- 第三讲：Ribbon 、Ribbon与Feign配合使用

上面说到了把500个故障服务器踢出eureka群聊。然后用nginx做负载均衡转发，还可以给某个服务器配置权重，或者简单的轮循、随机访问等。但这些功能虽然可以解决一部分并发访问的问题，但是访问规则较为固定。这时候就有了ribbon，ribbon在负载均衡的访问上提供了7中访问规则，并且ribbon也可以配置权重，不仅如此，还可以自定义服务器的访问规则，由程序员重写，以适应公司需求。

所以： Ribbon可以做到配置服务器访问权重、7种已经写好的访问规则、重写服务器访问权重的规则（英文名：IRule 也就是负载均衡策略）、可以实现功能比较复杂的负载均衡功能。

还是接着上面的例子（讲解Feign）

还是上面的传送门，这里只是单独说一下：SpringCloud版本Hoxton SR5 --- 第三讲：Ribbon 、Ribbon与Feign配合使用

在日常工作中，一定用到过 webService、Apache cxf。他们的作用就是一样的。比如写一段代码，调用一个 https://order.jd.com 类似的连接，然后再获取该链接返回的数据。再比如说，当用到微服务架构的时候，京东用户登录后，可以看到购物车有多少件商品的提示, 这时候其实就是用户模块的代码中，调用了购物车这个模块的查询功能。但是这两个模块，是两份不同的代码，也是部署到不同的服务器的，所以一定会在用户的模块中，调用一个http的链接，这个链接就是指向购物车模块的查询功能，并将查询到的结果返回给用户模块。

所以： Feign就是可以调用http链接，并且支持SpringMvc的注解，支持与Eureka和Ribbon组合使用以支持负载均衡。

继续（讲解Hystrix 熔断、限流、降级）

传送门： SpringCloud版本Hoxton SR5 --- 第四讲：Hystrix 熔断、限流(线程)、降级

在大型的微服务项目中，有很多实际会发生的问题：比如：访问的人数太多了，淘宝节那一天晚上，每一台服务器压力都是特别大的。如果服务器压力太大，前面还有无穷无尽的访问进来，而服务器端的响应，比如查询数据库这时候就特别慢。这时候，就会发生雪崩效应。无数的访问进来，得不到及时处理，服务器CPU不堪重负，最终全部死机。淘宝节只能草草落幕，当天晚上就可以上世界新闻了。

Hystrix解决的就是，在访问的过程中，访问超过自定义的时间，访问异常（不管是系统Bug还是数据库超时，mq超时等）立即将该请求中断，防止服务调用端的线程被长时间占用，从而避免故障在分布式架构中蔓延，乃至雪崩。

比如:

访问到一个异常，或者超时了，或者熔断了。就调用一个一定会返回数据的方法。比如降级方法返回：商品没有了，或者系统升级，再或者等一会儿再试，这就叫降级。

与此同时，一定时间范围内该服务被调用一定次数都失败了并且调用失败率达到配置程度（默认50%），就触发熔断。当一个微服务调用多次出现问题时（默认是10秒内20次调用失败，这个可以自己配置）并且调用失败率达到配置程度（默认50%），hystrix就会采取熔断机制，不再继续调用有问题的接口（然后有问题的调用链会在默认5秒钟内，先试探性的先关闭熔断机制，但是如果这时候再（10秒内20次调用失败，失败率达到50%）又会重新进行熔断，直到该服务正常。这个现象就叫熔断。

后面的尝试重连的机制就是监控起作用。（运用中，其实就是对超时时间、熔断条件的配置）

限流就是限制某个微服务的使用量，这里涉及到线程。比如只允许10个线程同时访问该微服务，其他的请求，访问其他的微服务。并且这项技术，适用于Feign。也就是远程调用，不单单适用于服务器内部，这就叫限流。（应用场景：比如某台服务器的性能比较低）

所以： Hystrix就是解决当系统出现不正常情况的时候，让原本要完成的工作，停下来，节约系统资源，防止系统在等待中崩溃。

继续（zuul路由、过滤器、容错与回退）

传送门： SpringCloud版本Hoxton SR5 --- 第五讲：zuul 路由、过滤、容错与回退、集群、高可用

当没有Zuul的时候，我们调用微服务就是这种格式：

http://微服务ID + 接口访问详细路径。例如：http://SERVER-ORDER/order/query

有了zuul以后，可以这样访问： http:// zuul的ip:zuul的port/zuul配置地址 /order/query (隐藏了微服务的名称)

Zuul会把自己与Eureka整合，并把自己注册成为Eureka服务下的应用，然后获取Eureka中注册上来的所有调用接口，最后，当准备调用服务、接口的时候，直接由zuul完成调用，脱离Eureka的控制。

路由：没有zuul的时候，当我们再调用微服务的时候，几乎都是通过微服务名或者直接ip+端口号来调用的，如果暴露微服务名可能导致黑客集中火力进攻一部分服务器，导致服务瘫痪，这时候就是用zuul的路由功能做映射，暴露一个集群的统一访问路径，以减轻对服务器的威胁，这就是路由。

过滤：当一个ip或者国外某个地区的ip同时攻击服务器的时候，就可以用zuul的过滤功能，将这些地方的ip限制起来，让其请求还没有进入服务器的时候，被拦截掉，保证系统安全，还或者可以禁用某些客户等。主要就是可以在过滤器里写代码，跟java的过滤器差不多。比如：可以鉴权，过滤ip等等。

 * 过滤器(filter)是zuul的核心组件 zuul大部分功能都是通过过滤器来实现的。* <p>* zuul中定义了4种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期如下：* PRE：这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在 集群中选择请求的微服务、记录调试信息等。* ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服 务的请求，并使用 Apache HttpCIient或 Netfilx Ribbon请求微服务* POST:这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准 的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。* ERROR：在其他阶段发生错误时执行该过滤器。

容错与回退：zuul默认是整合了hystrix和ribbon的，提供降级回退，那如何来使用hystrix呢? 我们自行写一个类，继承FallbackProvider 类，然后重写里面的方法。但是这个降级有点不一样的地方就是，因为zuul这个组件本身设计的位置就决定了，zuul 是在前端调用与微服务之间的组件。那么使用zuul的容错回退，相当于对整个系统设置统一的降级方法，所以使用起来要格外注意。

这里的降级，不是针对某一个接口降级，而是对整个微服务，比如：有order和item两个微服务，item微服务没有启动、或者宕机了。

这时候调用item所有接口都会走zuul的降级方法，但是同时order微服务启动是正常的，这时候order微服务的某些接口比如 /order/query 调用的接口有bug。这时候是不会走zuul的降级方法，而是走调用order的降级方法，如果没有配置降级方法，那么一定是404, 调用报错。

继续（HystrixDashbord 监控）

传送门： SpringCloud版本Hoxton SR5 --- 第六讲：hystrixDashboard监控

上面的例子说了，当访问人数特别特别多的时候，微服务一定也是特别特别多的，一两个运维工程师肯定是不行的，至少也得3-4吧。（开玩笑自嘲一下，目前太多公司没有专门的运维工程师，全都是由程序员解决，导致程序员太多时间浪费在了修电脑上，并且不专业导致系统出问题也是很不应该的）事实上，HystrixDashbord就不该是程序员该管的事，他的作用就是监控，当一个请求进来了，直到请求结束，他监控的是：请求经过了哪些微服务、调用了哪些接口、在哪个微服务出了问题，

所以：HystrixDashbord监控：出问题的频率、成功数、熔断数、请求出错的数量、超时数、延迟统计等等。

spring-cloud config （动态配置）

传送门：SpringCloud版本Hoxton SR5 --- 第七讲：SpringCloud Config 分布式配置中心+整合bus、rabbitmq、actuator

springcloud config解决的就是：比如我们有50个微服务，他们的数据库密码被修改了。现在要修改这50个微服务的数据库密码。

再比如，我们可以在代码里用@Value("xxx")获取配置数据吧，现在配置的xxx的数据值为false，某一天我们要需求变了，这些false要全部修改为true。

通常情况下，是不是打开代码？一个一个的修改？然后再一个一个的部署？至少这个过程是特别麻烦的吧。

而springcloud-config解决的就是这一类的问题。springcloud config 可以在外部修改配置文件(例如：git仓库)，代码完全不用修改，然后重新启动一下被修改的微服务就好了。另外springcloud-config有客户端，也有服务端。服务端可以是单独的一个微服务。

他的原理就是：

我们按照一定规则将配置信息写好，保存到本地或者 git云端。然后部署springcloud-config的服务端，就可以获取本地或者 git云端的配置文件。然后所有使用了springcloud-config客户端的微服务，重启一下，就会通过springcloud config服务端拿到git仓库这些配置然后启动微服务。在git仓库中的配置，还可以分环境部署（dev/test/pro/uat等）非常的方便，使用起来更加轻松，不需要程序员自己打开代码一个一个修改，运维工程师，可以直接修改git仓库里的配置，然后重启服务器就好了。这就是spring-cloud-config 可以完成的一些主要功能。

有没有感觉上面的springcloud config并没有想象中的那么好？我还需要重启服务器？那我还不如就在代码里改了，然后上传到git仓库，然后用Jenkins自己去git仓库获取代码，完成自动部署啊。

当然如果在代码里修改配置，还需要编译，打包，这也是不理智的。但是重启服务器，有点不开心。修改数据库配置，我重启服务器，我能接受，但是修改一个简单的controller里需要的属性，还要重启，就不是很开心。

这时候又有了另一个技术。springcloud的消息总线： SpringCloud Bus 这个消息总线呢，又需要整合消息组件（kafka/rabbitmq，springcloud他有专门整合kafka和rabbitmq的包）还有spring的 spring-boot-starter-actuator 组件（其实springcloud config动态修改配置的功能，就是actuator组件触发的，并且用的是post调用一个http地址，调用成功之后没有返回值）。写到这里我真的想吐槽springcloud了。太特么麻烦了。你直接集成好了不好吗？还要劳资去集成，组件多的一箩筐，学习成本也太大了吧。他的这个原理呢：上面不是说了么，springcloud config的服务端是用来读取git仓库中配置的。springcloud config客户端是用来读取 springcloud config服务端在git中获取到的配置信息。那这个消息总线bus呢，需要添加到所有使用了springcloud config客户端的微服务中去，还要配置mq的ip、端口、用户名密码。配置好了之后，所有微服务还要配置 spring-boot-starter-actuator,他的这个作用就好比监控,当调用某一个使用了springcloud config+bus+actuator的微服务的 http://ip:端口/actuator/bus-refresh 这个地址的时候，就通过消息总线给mq发送一条信息，然后呢，其他所有使用bus消息总线的的微服务，都会通过mq收到一条命令，这个命令就是告诉所有使用了springcloud config的客户端，需要修改配置了，你去获取配置。这还没完，上面只是说，各个微服务已经拿到了修改的配置，还需要指定某个类，是否使用这个更改了的配置，这时候还需要在修改的类上加@RefreshScope注解，表示如果配置修改了，这个类，及时使用修改过的配置。

使用起来就简单多了：当在git仓库修改好配置后，直接使用post请求调用一个 http://localhost:8080/actuator/bus-refresh 这个地址，springcloud config的动态配置就完成了。上面那个http://localhost:8080/actuator/bus-refresh的localhost:8080,必须是任意一个使用了springcloud config + bus +actuator的微服务的 ip和端口。这样springcloud config的动态配置的功能才算真正的完成。

最后一个了（分布式链路跟踪 Sleuth 整合Zipkin +Elasticsearch 做数据持久化用于查看日志）

传送门：SpringCloud版本Hoxton SR5 --- 第八讲：Sleuth 分布式链路跟踪整合Zipkin + Elasticsearch持久化

解决的问题：

如何串联调用链，快速定位问题
如何理清楚，微服务之间的依赖关系
如何进行各个服务接口的性能分折
如何跟踪业务流的处理

在调用关系复杂的微服务中，如果某个微服务的接口出了问题，要快速的定位到该请求经过哪些微服务，调用了哪些接口，就需要Sleuth 分布式链路跟踪：

比如说当调用开始的时候，会为这个请求生成一个Trace ID(类似UUID的序号)，调用过程中，会把这个Trace ID一直传递下去，用于标记该请求,后面可以根据Trace ID找到该请求经过了哪些微服务。

再说该调用链中，比如：A微服务调用B微服的过程，有多个Span ID的标识，比如代码运行A微服务的时候有个Span ID，A微服务调用B微服务的网络请求过程中也会有一个Span ID，B微服务代码执行的过程也会有一个Span ID，最后可以通过这些ID计算出执行时间。用于调优。

Spring Cloud Sleuth可以追踪10种类型的组件：async、Hystrix，messaging，websocket，rxjava，scheduling，web（Spring MVC Controller，Servlet），webclient（Spring RestTemplate）、Feign、Zuul

所以 Sleuth的作用就是记录：请求过程中，调用的每个微服务，请求路径，经过了哪些服务组件等等信息给生成出来。

然后使用Zipkin的客户端将这些信息，发送给Zipkin的服务端，然后Zipkin服务端整合这些数据，并提供UI界面用于查看Sleuth记录的信息。

这里又有一个问题，Zipkin服务端，是将这些信息保存在内存中的，当数据量太大的时候服务器的内存不够用，并且当停掉Zipkin服务端的时候，这些信息就会在内存中被清除。这时候，就使用Elasticsearch保存数据 (这里可以理解为数据库) ，他就将Zipkin整合好的信息，保存在硬盘中（持久化）。

到这里，SpringCloud的组件我就写的差不多了，谢谢观看。

嘿嘿。

SpringCloud版本Hoxton SR5 --- 第一讲：认识相关推荐

SpringCloud版本Hoxton SR5 --- 第七讲：SpringCloud Config 分布式配置中心+整合bus、rabbitmq、actuator
传送门:SpringCloud版本Hoxton SR5 --- 第一讲:认识先看SpringCloud Config 可以完成的功能,或者说他在项目中的定位和作用. SpringCloud conf ...
SpringCloud版本Hoxton SR5 --- 第八讲：Sleuth 分布式链路跟踪整合Zipkin + Elasticsearch持久化
传送门:SpringCloud版本Hoxton SR5 --- 第一讲:认识先看Sleuth.Zipkin.Elasticsearch 可以完成的功能,或者说他在项目中的定位和作用. Sleuth比 ...
SpringCloud版本Hoxton SR5 --- 第四讲：Hystrix 熔断、限流(线程)、降级
传送门:SpringCloud版本Hoxton SR5 --- 第一讲:认识先看Hystrix 可以完成的功能,或者说他在项目中的定位和作用. 上篇文章主要讲:功能和作用都是用大白话,主要是通俗易懂 ...
SpringCloud版本Hoxton SR5 --- 第三讲：Ribbon 、Ribbon与Feign配合使用
传送门:SpringCloud版本Hoxton SR5 --- 第一讲:认识先看Ribbon.Fegin可以完成的功能,或者说他在项目中的定位和作用. 上篇文章主要讲:功能和作用都是用大白话,主要是 ...
SpringCloud 微服务工具集 SpringCloud 版本: Hoxton SR6
SpringCloud 微服务工具集v1.1 SpringCloud版本: Hoxton SR6 SpringBoot版本: 2.2.x --2.3.x 1.什么是微服务官网: https://ww ...
Spring Cloud入门 -- Ribbon服务消费者（Hoxton.SR5版）
Ribbon简介 Ribbon是Netflix公司开源的客户端负载均衡器,可以控制Http和Tcp客户端的负载均衡. Ribbon默认提供了很多负载均衡算法,如:轮询.随机等,也可以实现自定义的负载均 ...
SpringCloud笔记(Hoxton)——Netflix之Eureka服务注册与发现
基础应用 Eureka简介 Eureka是一个基于REST的服务,主要在AWS云中使用,定位服务来进行中间层服务器的负载均衡和故障转移. SpringCloud封装了Netflix公司开发的Eurek ...
Spring Cloud入门 -- Eureka服务注册与发现（Hoxton.SR5版）
什么是Spring Cloud Spring Cloud是一系列框架的有序集合.它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册.配置中心.智能路由.消息总 ...
Spring Cloud入门 -- Consul服务注册与发现（Hoxton.SR5版）
Consul简介 Consul 是 HashiCorp 公司推出的开源产品,用于实现分布式系统的服务发现.服务隔离.服务配置,这些功能中的每一个都可以根据需要单独使用,也可以同时使用所有功能.Cons ...

SpringCloud版本Hoxton SR5 --- 第一讲：认识

SpringCloud版本Hoxton SR5 --- 第一讲：认识相关推荐

最新文章

热门文章