【Spring Cloud】几大组件搭建心得及源码

     这两天用了一些空余的时间，看了一位博主的博客，感觉写的还不错，跟着这博主的Spring Cloud系列的博文，从头到尾搭建了一番，中间也遇到了好多的问题，不过还好，算是都搭建起来了，感觉对SpringCloud又多了一层的认识，之前都是拿来用，没有去心思怎样去搭建，觉得跟着这位博主从头到尾搭建下来，收货还是不少的。

     头一回，在写博客的时候提到其他不认识的博主，真心觉得他写的博客通俗易懂，而且又不缺失逻辑，觉得非常棒，像我这样的小白都能跟下来，都能学会，嘿嘿，本来是想，从头跟着做的时候，每做一步总结一下，自己整理一下，但是我觉得博主写的很好，我不需要再写一遍了，有问题，或者忘记的情况下，去看一下就好咯。在本文的末尾我会把该博主写的SpringCloud系列文档分享给大家。

   如果大家想看代码的话，可以去看博主的博客里面有，最后我也会把我搭建好的分享给大家。

   接下来我就从我最开始学习的开始简单的总结一下：

 

1、maven 的分布式项目框架的搭建

      我来总结一下精髓，嘿嘿，在我现在的开发项目中，就是多个微服务是属于同一个工程，他们只是提供不同的服务而已，但是IDEA 是默认一个窗口打开一个项目工程，就像我现在如果我想开发小程序端，和pc管理端 ，还有APP端，这样的几个业务，我就需要打开至少4个工程，也就是启动4个idea，maven分布式项目就是解决了这个问题，而且在项目中有子项目，可以直接继承父项目中的pom依赖，这点很好，就像版本直接在父项目中写好，子项目中就不需要定义了，省着每个独立的微服务的版本都不一样，产生一些不必要的麻烦。给大家截一个图看看我搭建好的工程目录：

      其中在连接数据库的时候，会遇到一些版本上的问题，导致我一直都连接不上数据库，用的是博主文章中的版本，也不好使，我尝试了好多种，最后好使了。这种情况下就需要不断去尝试，不断去百度各个版本的兼容问题，如果你遇到了同样的问题，欢迎来找我，我们一起解决。

2、Eureka 服务注册与发现与集群

      做过微服务项目的人对这个应该很熟悉了吧，之前我的博文中也有关于这个系列的文档，不懂得小伙伴欢迎去学习，下面是博文的链接：https://blog.csdn.net/weixin_36775115/article/details/80408887。

      这块我印象比较深刻的是博主的一段话，把Eureka解释的很清楚，我在这引用一下喽：《现在有很多创业公司，很多城市都有一些经济开发区，在经济开发区有很多写字楼，多个创业公司都会注册进经济开发区大楼，租一间写字楼作为办公基地。 那么这里的创业公司就相当于微服务，而开发区大楼的注册登记表就相当于 Eureka。每个创业公司都要定期向开发区负责人或者机构交房租和物业费，如果某个创业公司不交物业费了，那么该开发区大楼负责人员就会去要，若多次不给，那么就会将其移出开发区大楼。这就是 Eureka 的心跳机制》，其他的地方就是跟着博主搭建就好了。

      还有就是集群很重要，需要去好好看一下，还有一句话写的很好，再做一下引用：《所以分布式的每一个节点，完成的是不同的业务，一个节点挂了，那么这个业务功能就无法访问了，甚至可能会影响到其他业务。而集群是一个比较有组织的架构，正因为有组织性，一个服务节点挂了，其他服务节点可以顶上来，从而保证了服务的健壮性。所以说，集群可以理解为：你中有我，我中有你，手拉手肩并肩，一起保证服务的健壮性》

      如下图为我搭建好的Eureka 服务：

 

 

3、Ribbon-负载均衡

      引用一张图，很好的解释了负载均衡，如下图所示：

      Ribbon作为后端负载均衡器，比Nginx更注重的是承担并发而不是请求分发，可以直接感知后台动态变化来指定分发策略。它一共提供了7种负载均衡策略：

      使用负载均衡带来的好处很明显：

      当集群里的1台或者多台服务器down的时候，剩余的没有down的服务器可以保证服务的继续使用，使用了更多的机器保证了机器的良性使用，不会由于某一高峰时刻导致系统cpu急剧上升，简单的给大家介绍了一下Ribbon实现负载均衡的原理，以及为啥用他，希望可以帮助到你哦。

4、Feign组件-服务间的调用-负载均衡

      其实采用Spring Cloud微服务框架后，经常会涉及到服务间调用，服务间调用采用了Feign组件，它封装了Http调用流程，更适合面向接口化的变成习惯，在服务调用的场景中，我们经常调用基于Http协议的服务，而我们经常使用到的框架可能有HttpURLConnection、Apache HttpComponnets、OkHttp3 、Netty等等，这些框架在基于自身的专注点提供了自身特性。而从角色划分上来看，他们的职能是一致的提供Http调用服务。

 

 

 

      在使用feign 时，会定义对应的接口类，在接口类上使用Http相关的注解，标识HTTP请求参数信息。feign的使用也很简单，只需要添加一个依赖即可，如下图所示：

      以上就是对feign 的总结。

 

5、Hystrix-服务熔断和服务降级

      对于Hystrix来说，我还是想引用该博客作者的一段话，来解释他，非常合理和准确。

      《服务熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长，就会进行服务的降级，快速熔断该节点微服务的调用，返回默认的响应信息。当检测到该节点微服务调用响应正常后即可恢复。

      上面提到服务的降级，什么意思呢？我打个比方：比如你去银行办理业务，本来有四个窗口都可以办理，现在3号窗口和4号窗口的办理人员有事要离开，那么自然地，用户就会跑去1号窗口或者2号窗口办理，所以1号和2号窗口就会承担更多的压力。3号窗口和4号窗口的人有事走了，不能让人还在这排队等着吧，否则就出现了上文说的雪崩了，所以会挂一个牌子：暂停服务。这个牌子好比上文提到的熔断，然后返回一个默认的信息，让用户知道。等3号和4号窗口的人回来了，就会把这个牌子拿走，这两个窗口又可以继续回复服务了。服务降级是在客户端完成的，不是服务端，与服务端是没有关系的。就像银行某个窗口挂了“暂停服务”，那客户会自然去别的窗口》，使用方法看博客就可以喽，我只是总结一下。

6、Zuul-路由网关

      Zuul是从设备和网站到Netflix流媒体应用程序后端的所有请求的前门。作为边缘服务应用程序，Zuul旨在实现动态路由，监视，弹性和安全性。它还可以根据需要将请求路由到多个Amazon Auto Scaling组。

Netflix API流量的数量和多样性有时会导致生产问题迅速出现而没有警告。我们需要一个能够快速改变行为以对这些情况做出反应的系统。

      Zuul使用了各种不同类型的过滤器，这使我们能够快速灵活地将功能应用于边缘服务。这些过滤器帮助我们执行以下功能：

• 身份验证和安全性-确定每个资源的身份验证要求，并拒绝不满足要求的请求。
• 洞察和监控-在边缘跟踪有意义的数据和统计信息，以便为我们提供准确的生产视图。
• 动态路由-根据需要将请求动态路由到不同的后端群集。
• 压力测试-逐渐增加到群集的流量以评估性能。
• 减载-为每种类型的请求分配容量，并丢弃超出限制的请求。
• 静态响应处理-直接在边缘构建一些响应，而不是将其转发到内部集群
• 多区域弹性-跨AWS区域路由请求，以多样化我们的ELB使用并将我们的优势拉近我们的成员

7、config-配置中心

      分布式系统中面临的配置问题：微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。

      SpringCloud提供了ConfigServer来解决这个问题—我们每一个微服务自己带着一个application.yml，项目中可能会有几十个上百个配置文件。

 

 

 

      如上图所示，SpringCloudConfig为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。ConfigServer从SVN/Git/本地文件系统中获取配置文件，然后(手动或自动)推送给Client，当然Client也可以自己从ConfigServer拉取。

      SpringCloudConfig分为服务端和客户端两个部分。

1、服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。故而服务端作为一个微服务应用在设计高可用时可以使用Eureka注册中心注册多个ConfigServer构成ConfigServer集群。

2、客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。

 

      以上就是我对这两天搭建的心得，觉得这位博主的博客写的真心不错，希望我以后也能认真对待每一篇博客，以上内容部分出自该博主，我把该博主的文章标注出来，希望可以帮助到大家。

      代码涉及到一些数据库之类的，如果大家有需要，私信我，我单独发给你！