前言
这一段刚开始接触spring cloud，但对于整个spring cloud的运行流程还是不是太清楚，所以通过前辈的博客，还有书籍等资料，对于spring cloud的运行有了一定认识，所以记录下来，如果内容有错，还望谅解。
首先，spring cloud 是一个微服务一站式解决方案，那么，先来了解一下微服务的概念。
微服务简介
“微服务”最初是由Martin Fowler 在2014年写的一篇文章《MicroServices》中提出来的。
Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首
席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的 专家，现为Thought
Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集
成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几 本经典书籍：
《企业应用架构模式》、《UML精粹》和《重构》等。
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
这里放一张微服务的架构图
spring cloud 简介
Spring Cloud是一个基于SpringBoot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
spring cloud 核心组件
服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
这里Netflix 和 spring cloud 的关系可以参考
https://blog.csdn.net/qq_34246546/article/details/79862573
spring cloud 核心组件运行流程
业务场景
Spring Cloud 核心组件：Eureka
由于微服务架构都是分布式式架构，前面微服务简介也说了，微服务就是把服务进行拆分，按照业务流程,即可拆分成三个服务，订单服务，库存服务，发货服务。但是由于每个服务都是分开部署，每个服务之间有时存在调用过程，那么在spring cloud 中，每项服务之间又是知道对方存在的呢？
这就依赖组件Eureka（服务的注册和发现）。
什么是Eureka?
和 Consul 、 Zookeeper 类似， Eureka 是一个用于服务注册和发现的组件， i民开始主要应用
于亚马逊公司旗下的云计算服务平台 AWS o Eureka 分为 Eureka Server 和 Eureka Client, Eureka
Server 为 Eureka 服务注册中心， Eureka Client 为 Eureka 客户端 。
在这里，我们先了解一下Eureka的基本架构。
Eureka主要包括三种角色：
- Register Service: 服务注册中心，它是一个Eureka Server，提供服务注册和发现功能。
- Provider Service：服务提供者，Eureka client ,提供服务。
- Consumer Service ：服务消费者，Eureka client，消费服务。
服务消费的基本过程如下：首先前要一个服务注册中心 Eureka Server，服务提供者 Eureka
Client 向服务注册中心 Eureka Server 注册，将自己的信息（比如服务名和服务的 IP 地址等）
通过Restful API的形式提交给服务注册中心 Eureka Server。同样，服务消费者 Eureka Client 也
向服务注册 中心 Eureka Server 注册，同时服务消费者获取一份服务注册列表的信息 ， 该列表
包含了所有向服务注册中心 Eureka Server 注册的服务信息。获取服务注册列表信息之后 ，服
务消费者就知道近服务提供者的 IP 地址，可以通过 Http远程调度来消费服务提供者的服务。
spring cloud 核心组件 feign
现在每一个服务之间都有了一份注册表，但是服务之间如何通信？？？
这里有两种解决方案：
1.ribbon + RestTemplate
2.feign
由于使用feign 更加方便优雅（feign内部也使用了ribbon做负载均衡） ，所以这里就介绍feign吧。
什么是feign？
Feign 是一个声明式的 Web Service 客户端。使用 Feign 能让编写 Web Service 客户端更加简单，同时支持与Eureka、Ribbon 组合使用以支持负载均衡。
spring cloud 核心组件 zuul
现在服务之间可以互相发现，可以实现通信调用，那么，当用户访问微服务架构下的网站时应该访问那个IP呢？
如果每换一个服务就需要改变一个IP地址，那么这对用户也是太不友好了，不用着急，车到山前必有路，访问同一个网站的需要换IP？那么可不可以用户直接访问一个IP，后台在由用户访问的服务类别进行请求转发呢？当然可以，zuul 就是解决方案.
什么是zuul？
zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。
Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
注：由于netflix 项目组进入了维护阶段，spring 官方给出了zuul的代替解决方案----spring cloud gateway.
spring cloud 核心组件 ribbon
现在问题来了，作为微服务框架，肯定能支持大用户访问，具有不错的负载能力，在后台同一个服务可以部署多个，但是如何是用户访问时可以合理的访问相同的服务？避免一个服务被大量用户访问，而其他相同的服务却‘’门可罗雀‘’ ，ribbon 就作为负载均衡器出现了。。。。
什么是ribbon？
Ribbon是Netflix下的负载均衡项目，它在集群中为各个客户端的通信提供了支持，它主要实现中间层应用程序的负载均衡。Ribbon提供以下特性：
1.负载均衡器，可支持插拔式的负载均衡规则。
2.对多种协议提供支持，例如HTTP、TCP、UDP。
3.集成了负载均衡功能的客户端。
spring cloud 核心组件 Hystrix
现在看来，微服务架构似乎已经“非常完美了”，但是如果项目正在运行，忽然出现了 网络连接缓慢，资源繁忙，暂时不可用，服务脱机等.异常情况，那么一个服务调用另一个服务，长时间没有回应，那么整个服务是不是就挂了？？成千上万的用户都在一个地方出现了错误，那么最终服务怎能不挂？
此时，Hystrix出现了，嘿嘿嘿。
什么是Hystrix？
hystrix的出现即为解决雪崩效应，它通过四个方面的机制来解决这个问题
隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
优雅的降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。
熔断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。
缓存：提供了请求缓存、请求合并实现。
支持实时监控、报警、控制
京公网安备 11010502036488号