程序员的成长之路
互联网/程序员/技术/数据共享
关注
大概需要阅读这篇文章 3 分钟。
来自：https://blog.csdn.net/weixin_46115725/
一、先看一张springCloud的图片:
二、简单介绍下什么是springCloud
Spring Cloud为开发人员快速构建分布式系统（如配置管理、服务发现、断路器、智能路由、微代理、控制总线由、微代理、控制总线）。
样板模式是由分布式系统的协调引起的， 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等待托管平台
三、假设一个商业场景很容易理解
假设现在开发一个电子商务网站来实现支付订单的功能：流程如下
创建订单后，如果用户立即支付订单，我们需要将订单状态更新为（已支付）
扣除相应的商品库存
通知仓储中心发货
如何为用户购物添加相应的积分？
对于上述流程，我们需要订单服务、库存服务、仓储服务、积分服务，整个流程的总体思路如下：
付款完成后，用户回到订单服务，更新订单状态
订单服务呼叫库存服务，完成相应的功能
订单服务呼叫存储服务，完成相应的功能
订单服务调用积分服务，完成相应的功能
四、SpringCloud核心组件Eureka（类似于zookeeper）
首先考虑一个问题，如何调用库存服务、仓储服务和订单服务？
答:订单服务不知道上述服务在哪个服务器上，不能调用。Eureka它的功能是告诉订单服务它想调用哪个服务器，Eureka有客户端和服务端，每个服务都有Eureka客户端可以在本服务中注册相关信息Eureka服务端上，然后我们的订单服务可以找到库存服务、仓储服务、积分服务。
使用上述业务Eureka后如下图：
Eurake客户端：负责将服务信息注册到Eureka服务端中
Eureka服务端:相当于一个有注册表的注册中心。每个服务所在的机器和端口号都保存在注册表中，可以通过Eureka在服务端找到各种服务
五、SpringCloud核心组件：Feign（类似于dubbo）
通过上面的Eureka，现在订单服务确实知道库存服务、积分服务和存储服务在哪里，但我们如何呼叫这些服务？如果我们自己写很多代码，那就太麻烦了，SpringCloud为我们准备了一个核心组件：Feign。
接下来看看怎么通过Feign让订单服务调用库存服务，注意Feign也用于消费者端；
订单服务：
库存服务：
无底层建立连接、结构要求、分析响应代码，直接用注释定义 FeignClient接口，然后调用接口。
人家Feign Client根据底层的注释，与您指定的服务建立联系、构造请求、发起你、获取响应、解决响应等。这一系列肮脏的工作，人们Feign全给你。
问题来了，Feign是怎么做到的？实际上，Feign的一个机制就是使用了动态代理：
首先，如果你定义了一个
@FeignClient注解，Feign为此界面创建动态代理然后如果你调用那个接口，本质就是调用 Feign创建的动态代理是核心的核心
Feign根据你在界面上的情况，动态代理会
@RequestMapping等待注释，动态构建您要求的服务地址最后，发起请求，分析响应地址
六、springCloud核心组件:Ribbon
上面可以通过Eureka可以找到服务，然后通过Feign调用服务，但如果库存服务部署在多台机器上，我应该使用它Feign调用上面哪个服务？这个时候需要Ribbon闪亮的外观，它在服务消费者端配置和使用，均衡。
然后默认使用的负载平衡算法是轮询算法，Ribbon会从Eureka在服务端获取相应的服务注册表，然后了解相应服务的位置，然后Ribbon根据设计的负载均衡算法选择机器，Feigin这些机器结构将被发送请求
如下图所示：
七、SpringCloud核心组件：Hystrix
在微服务架构中，系统将有多个服务，以本文的业务场景为例：订单服务需要在业务流程中呼叫三个服务，现在假设订单服务本身只有100个线程可以处理请求，如果积分服务错误，每个订单服务呼叫积分服务，将卡住几秒钟，然后抛出-加班异常。
这会导致什么问题？如果系统并发性高，大量请求涌来，订单服务的100个线程会卡在积分服务中，导致订单服务没有多余的线程来处理请求。这个问题是微服务架构中可怕的服务器雪崩问题。如果这么多服务互相调用，如果不做任何保护，某个服务会引起连锁反应，导致其他服务
如下图所示：
但我们认为，即使积分服务挂断，订单服务也不应该挂断。我们只需要让存储服务和存储服务正常工作。至于积分服务，我们可以在后期手动向用户添加积分。Hystrix闪亮出现，Hystrix是隔离、熔断、降级的框架，说白了就是Hystrix会做很多小线程池，然后让这些小线程池要求服务，返回结果。
Hystrix相当于一个中间过滤区，如果我们的积分服务挂断，那么我们要求积分服务直接返回，不需要等待超时抛出异常，这就是所谓的熔断，但也不能回来，否则我们手动添加积分，然后我们每次呼叫积分服务记录数据库，这就是所谓的降级，Hystrix隔离、熔断、降级的全过程如下：
八、SpringCloud核心组件：zull(类似于服务器端nginx）
该组件负责网络路由。假设你在后台部署了数百项服务，现在有一个前端兄弟，他们的请求是直接从浏览器发送的。例如，如果人们要求库存服务，你还让人们记住这项服务的名字吗？inventory-service，并部署在五台机器上。即使人们愿意记住这一个，你的背景中有数百个服务的名称和地址吗？如果有人要求一个，你必须记住一个吗？
上面这种情况，压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。
九、简单总结
服务启动的时候，服务上的Eureka客户端会把自身注册到Eureka服务端，并且可以通过Eureka服务端知道其他注册的服务
服务间发起请求的时候，服务消费者方基于Ribbon服务做到负载均衡，从服务提供者存储的多台机器中选择一台，如果一个服务只在一台机器上面，那就用不到Ribbon选择机器了，如果有多台机器，那就需要使用Ribbon选择之后再去使用
Feign使用的时候会集成Ribbon，Ribbon去Eureka服务端中找到服务提供者的所在的服务器信息，然后根据随机策略选择一个，拼接Url地址后发起请求
发起的请求是通过Hystrix的线程池去访问服务，不同的服务通过不同的线程池，实现了不同的服务调度隔离，如果服务出现故障，通过服务熔断，避免服务雪崩的问题 ，并且通过服务降级，保证可以手动实现服务正常功能
如果前端调用后台系统，统一走zull网关进入，通过zull网关转发请求给对应的服务
图片总结更清晰：
<END>
一个可以超越 VS Code 的新 IDE？
面试官：有一种数据类型，Redis 要存两次，为什么？
内容包含Java基础、JavaWeb、MySQL性能优化、JVM、锁、百万并发、消息队列、高性能缓存、反射、Spring全家桶原理、微服务、Zookeeper......等技术栈！
⬇戳阅读原文领取！ 朕已阅