【SpringCloud】⼏⼤组件搭建⼼得及源码
这两天⽤了⼀些空余的时间，看了⼀位博主的博客，感觉写的还不错，跟着这博主的Spring Cloud系列的博⽂，从头到尾搭建了⼀番，中间也遇到了好多的问题，不过还好，算是都搭建起来了，感觉对SpringCloud⼜多了⼀层的认识，之前都是拿来⽤，没有去⼼思怎样去搭建，觉得跟着这位博主从头到尾搭建下来，收货还是不少的。
头⼀回，在写博客的时候提到其他不认识的博主，真⼼觉得他写的博客通俗易懂，⽽且⼜不缺失逻辑，觉得⾮常棒，像我这样的⼩⽩都能跟下来，都能学会，嘿嘿，本来是想，从头跟着做的时候，每做⼀步总结⼀下，⾃⼰整理⼀下，但是我觉得博主写的很好，我不需要再写⼀遍了，有问题，或者忘记的情况下，去看⼀下就好咯。在本⽂的末尾我会把该博主写的SpringCloud系列⽂档分享给⼤家。
如果⼤家想看代码的话，可以去看博主的博客⾥⾯有，最后我也会把我搭建好的分享给⼤家。
接下来我就从我最开始学习的开始简单的总结⼀下：
1、maven 的分布式项⽬框架的搭建
我来总结⼀下精髓，嘿嘿，在我现在的开发项⽬中，就是多个微服务是属于同⼀个⼯程，他们只是提供不同的服务⽽已，但是IDEA 是默认⼀个窗⼝打开⼀个项⽬⼯程，就像我现在如果我想开发⼩程序端，和
pc管理端 ，还有APP端，这样的⼏个业务，我就需要打开⾄少4个⼯程，也就是启动4个idea，maven分布式项⽬就是解决了这个问题，⽽且在项⽬中有⼦项⽬，可以直接继承⽗项⽬中的pom依赖，这点很好，就像版本直接在⽗项⽬中写好，⼦项⽬中就不需要定义了，省着每个独⽴的微服务的版本都不⼀样，产⽣⼀些不必要的⿇烦。给⼤家截⼀个图看看我搭建好的⼯程⽬录：
其中在连接数据库的时候，会遇到⼀些版本上的问题，导致我⼀直都连接不上数据库，⽤的是博主⽂章中的版本，也不好使，我尝试了好多种，最后好使了。这种情况下就需要不断去尝试，不断去百度各个版本的兼容问题，如果你遇到了同样的问题，欢迎来我，我们⼀起解决。
2、Eureka 服务注册与发现与集
这块我印象⽐较深刻的是博主的⼀段话，把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 的总结。
5、Hystrix-服务熔断和服务降级
对于Hystrix来说，我还是想引⽤该博客作者的⼀段话，来解释他，⾮常合理和准确。
《服务熔断机制是应对雪崩效应的⼀种微服务链路保护机制。当扇出链路的某个微服务不可⽤或者响应时间太长，就会进⾏服务的降级，快速熔断该节点微服务的调⽤，返回默认的响应信息。当检测到该节点微服务调⽤响应正常后即可恢复。
上⾯提到服务的降级，什么意思呢？我打个⽐⽅：⽐如你去银⾏办理业务，本来有四个窗⼝都可以办理，现在3号窗⼝和4号窗⼝的办理⼈员有事要离开，那么⾃然地，⽤户就会跑去1号窗⼝或者2号窗⼝办理，所以1号和2号窗⼝就会承担更多的压⼒。3号窗⼝和4号窗⼝的⼈有事⾛了，不能让⼈还在这排队等着吧，否则就出现了上⽂说的雪崩了，所以会挂⼀个牌⼦：暂停服务。这个牌⼦好⽐上⽂提到的熔断，然后返回⼀个默认的信息，让⽤户知道。等3号和4号窗⼝的⼈回来了，就会把这个牌⼦拿⾛，这两个窗⼝⼜可以继续回复服务了。服务降级是在客户端完成的，不是服务端，与服务端是没有关系的。就像银⾏某个窗⼝挂了“暂停服务”，那客户会⾃然去别的窗⼝》，使⽤⽅法看博客就可以喽，我只是总结⼀下。
6、Zuul-路由⽹关
nginx和网关怎么配合使用Zuul是从设备和⽹站到Netflix流媒体应⽤程序后端的所有请求的前门。作为边缘服务应⽤程序，Zuul旨在实现动态路由，监视，弹性和安全性。它还可以根据需要将请求路由到多个Amazon Auto Scaling组。
Netflix API流量的数量和多样性有时会导致⽣产问题迅速出现⽽没有警告。我们需要⼀个能够快速改变⾏为以对这些情况做出反应的系统。
Zuul使⽤了各种不同类型的过滤器，这使我们能够快速灵活地将功能应⽤于边缘服务。这些过滤器帮
助我们执⾏以下功能：
⾝份验证和安全性-确定每个资源的⾝份验证要求，并拒绝不满⾜要求的请求。
洞察和监控-在边缘跟踪有意义的数据和统计信息，以便为我们提供准确的⽣产视图。
动态路由-根据需要将请求动态路由到不同的后端集。
压⼒测试-逐渐增加到集的流量以评估性能。
减载-为每种类型的请求分配容量，并丢弃超出限制的请求。
静态响应处理-直接在边缘构建⼀些响应，⽽不是将其转发到内部集
多区域弹性-跨AWS区域路由请求，以多样化我们的ELB使⽤并将我们的优势拉近我们的成员
7、config-配置中⼼
分布式系统中⾯临的配置问题：微服务意味着要将单体应⽤中的业务拆分成⼀个个⼦服务，每个服务的粒度相对较⼩，因此系统中会出现⼤量的服务。由于每个服务都需要必要的配置信息才能运⾏，所以⼀套集中式的、动态的配置管理设施是必不可少的。
SpringCloud提供了ConfigServer来解决这个问题—我们每⼀个微服务⾃⼰带着⼀个l，项⽬中可能会有⼏⼗个上百个配置⽂件。
如上图所⽰，SpringCloudConfig为微服务架构中的微服务提供集中化的外部配置⽀持，配置服务器为各个不同微服务应⽤的所有环境提供了⼀个中⼼化的外部配置。ConfigServer从SVN/Git/本地⽂件系统中获取配置⽂件，然后(⼿动或⾃动)推送给Client，当然Client 也可以⾃⼰从ConfigServer拉取。
SpringCloudConfig分为服务端和客户端两个部分。
1、服务端也称为分布式配置中⼼，它是⼀个独⽴的微服务应⽤，⽤来连接配置服务器并为客户端提供
获取配置信息，加密/解密信息等访问接⼝。故⽽服务端作为⼀个微服务应⽤在设计⾼可⽤时可以使⽤Eureka注册中⼼注册多个ConfigServer构成ConfigServer集。
2、客户端则是通过指定的配置中⼼来管理应⽤资源，以及与业务相关的配置内容，并在启动的时候从配置中⼼获取和加载配置信息。配置服务器默认采⽤git来存储配置信息，这样就有助于对环境配置进⾏版本管理，并且可以通过git客户端⼯具来⽅便的管理和访问配置内容。
以上就是我对这两天搭建的⼼得，觉得这位博主的博客写的真⼼不错，希望我以后也能认真对待每⼀篇博客，以上内容部分出⾃该博主，我把该博主的⽂章标注出来，希望可以帮助到⼤家。
代码涉及到⼀些数据库之类的，如果⼤家有需要，私信我，我单独发给你！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。