SpringCloud初步理解

1.什么是SpringCloud？
SpringCloud是就是一个微服务架构的框架，实际上微服务SpringCloud就是一个全家桶式的技术栈，包含了很多的组件，主要的有：Eureka，Ribbon，Feign，Hystrix，Zuul。
2.我们首先来了解一下业务背景。

• 假如我们现在要去开发一个电商网站，现在需要去实现一个支付的功能。
• 那么现在实现这个支付的功能我们需要连带着几个操作
• 1.修改订单状态为已支付
• 2.减少库存
• 3.仓库进行发货
• 4.增加用户积分
• 接下来我们就分别把这几种业务部署到对应的服务器上
  【支付服务】【库存服务】【厂库分发服务】【用户积分服务】

3.了解过我们业务背景，我们就需要考虑怎么通过SpringCloud来进行实现。
首先支付成功后我们需要去修改库存，可是库存在另一台服务器上面，就算我们想发一个请求都不知道往那个服务器上发。这时候我们就用到了SpringCloud的组件【Eureka】。
【Eureka】是微服务架构中的注册中心，专门用于服务的注册和发现。

• 我们在进行服务注册时每个服务都会存在一个Eureka Client组件，这个组件会把我们负责的这个服务器的信息注册到Eureka服务中心上。其实Eureka server注册中心里面有一个注册表，记录着各个服务所在的机器以及端口号。

  流程就是 我们的【订单服务】在调用【库存服务】时，因为不知道要去访问那台服务器，就先向【Eureka Server】注册中心询问一下，然后【Eureka Server】在注册表中把【库存服务】所在的服务器，端口号等相关信息告诉【订单服务】，【订单服务】在收到这些信息后，会把在注册表里拉取下来的信息在本地缓存起来，这样下次访问就可以直接访问【库存服务】不用再通过访问【Eureka Server】了。 得到响应后再去调用 扣减库存的接口。
  总结：
  Eureka Client 负责把服务的信息注册到Eureka Server注册中心
  Eureka Server 注册中心 用于服务的注册和发现 就相当于信息共享中心 服务把信息交给这个平台 需要的时候就可以在Eureka Server询问 Eureka Server根据相关信息在注册中心表中查询得到结果

以上啰嗦一大堆其实就是为了解决 服务调用该去访问那个服务器以及端口号的问题。
现在解决了服务访问的问题，我们就又迎来了另一个问题，就是有问就有答，
我们通过一顿复杂的操作建立好了服务器之间的联系，那么难道相应的结果我们又要写一大堆代码来处理吗？ 答案是不需要的 因为Spring的出现就是为了减少码农的工作量，然后让你去搬最有质量的砖。

下面我们就介绍一下SpringCloud的另一个插件Fegin
我们先看一段代码
[一时偷图一时爽 一直偷图一直爽 整文参考https://juejin.im/post/5be13b83f265da6116393fc7?utm_source=tuicool&utm_medium=referral ]
没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。人家Feign Client会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起靕求、获取响应、解析响应，等等。这一系列脏活累活，人家Feign全给你干了。

那么问题来了，Feign是如何做到这么神奇的呢？很简单，Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址最后针对这个地址，发起请求、解析响应。
四、Spring Cloud核心组件：Ribbon
我们刚解决完一个问题，另一个问题就来了
假如我们现在的用户量非常的巨大，然后我们把【库存服务】分别部署到了五台服务器上面
这时候Feign怎么能知道向那台服务器上面发送请求，而且既然部署到五台服务器肯定是为了降低服务器的压力，那么我们怎么把五台服务器完全利用起来?
这时候SpringCloud Ribbon就派上用场了，Ribbon的出现就是专门解决这个问题的，他的作用就是负载均衡，会把请求均匀的分配到每个服务器上。
Ribbon实现负载均衡默认采用的轮循的算法。

此外Ribbon和Eureka Feign是紧密协作的

• 首先Ribbon会通过Eureka Client获取到对应的服务器注册表，也就是知道了所有服务所在的服务器以及端口号

• 然后Ribbon通过自己的算法指向一台服务器

• 最后Fegin对这台机器进行构造发起请求
  五、Spring Cloud核心组件：Hystrix

  Hystrix是用来干什么的？ 隔离 服务降级 熔断
  什么是服务降级和熔断？
  就以本文为例
  假设我们【订单服务】有100个线程服务
  但是很不幸的是我们的【库存服务】挂了
  这时大量的请求涌入，我们每个请求在访问【库存服务】的时候都会卡住，
  并抛出一个超时异常
  最后的结果就是我们的【订单服务】的100个线程全部卡住，
  这时候就导致【订单服务】也会挂掉，也就是我们说的雪崩，牵一发而动全身。
  这对于整个程序来讲就是灾难级的影响。
  伟大的程序猿怎能容忍这种千里之堤溃于蚁穴的现象出现。
  于是救世主Hystrix横空出世，那个自带BGM的男人出现了。
  【Hystrix】觉得一个【库存服务】挂掉而已，怎么能让它威胁到整个家园，毕竟地球由我守护。
  【Hystrix】想了想自己的属性是一个 隔离 熔断 降级的框架，要怎样做呢？
  Hystrix为了不让【库存服务】的挂掉影响到其他服务的士气，
  决定在【订单服务】内部开辟多个线程池，
  就是一个服务对应一个线程池，
  这样就算是对应【库存服务】的线程池全部阻塞了也不会再影响其它线程的走向。
  只是后来想想 这【库存服务】的服务器都挂掉了，
  如果这段时间内还有其他请求访问，
  然后阻塞一段时间，
  抛出一个超时异常，
  那也是没有意义的啊，
  不如直接熔断好了，
  比如再五分钟时间内【库存服务】的请求直接返回，
  不再去走请求响应超时的这段时间，
  这个过程我们就称作【熔断】。
  虽然我们已经掌握了二技能【熔断】，
  但是就这样抛弃【库存服务】于不顾视乎显得我们也太不够江湖道义了，
  那怎么办呢？
  既然不能直接救活，
  但是我们出于人道主义，
  保留一下其魂魄与元神也算是出了一份力，
  将来怎样看命吧。
  说做就做：
  那就把【服务降级】吧，
  既然服务器挂掉线程一直阻塞，
  那我们只能把当前发生的一切都给记录下来，
  待事情平息之后再做回复了，
  于是我们就出现服务降级 ，
  每次调用【库存服务】我们就向数据库中记录一条，
  因为【库存服务】挂掉，导致某某商品库存减一失败，
  然后后期我们通过记录统一进行手动库存商品的数量调整，
  这个过程我们就称作服务降级。
  六、Spring Cloud核心组件：Zuul
  Zuul，也就是微服务网关。这个组件是负责网络路由的。
  网络路由是什么？
  它是做什么的？
  它为什么会出现在这里？
  它很牛B吗？
  下面就由我带你们走进Zuul的日常生活：
  假设你是马云你有淘宝你在后台部署了几百个服务，
  现在有个叫前端的兄弟，
  它要访问你的【库存服务】，
  可是你的【库存服务】分别在五台服务器上，
  难道你要让它把每个服务器的名字都记住？
  就算它都记住了，
  那几千几百个你能都让它记住？
  要是真的是那样，
  友谊的小船真的就说翻就翻了。
  上面这种情况，
  压根儿是不现实的。
  所以一般微服务架构中都必然会设计一个网关在里面，
  像android、ios、pc前端、微信小程序、H5等等，
  不用去关心后端有几百个服务，
  就知道有一个网关，
  所有请求都往网关走，
  网关会根据请求中的一些特征，
  将请求转发给后端的各个服务。
  而且有一个网关之后，还有很多好处，比如可以做统一的**降级、限流、认证授权、安全，**等等。
  七、总结：
  最后再来总结一下，上述几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：

• Eureka：各个服务在启动的时候，都会通过Eureka Client向Eureka Server中注册当前服务的信息，反过来Eureka Server也可以通过注册表提供其他服务的信息。

• Ribbon实现负载均衡，就是通过Ribbon的算法来决定最终请求被分发到哪台服务器处理。

• Feign采取动态代理机制，根据注解和选择的机器，来拼接Url地址发送请求。

• Hystrix是采用线程池的方式来实现隔离，不同的线程池指向不同的服务，实现了服务的隔离，避免了服务器出现雪崩的问题。

• Zuul网关如果前端，移动端要调用后端的系统，都需要通过Zuul网关统一进入，由网关转发请求给对应的服务。

以上内容均是个人学习记录，不做商业用途，参考至https://juejin.im/post/5be13b83f265da6116393fc7