springcloud底层原理与组件理解

自己总结了一张流程图
大致描述了一下请求在各个组件中是怎样流转的，各个组件又发挥了什么作用

---

微服务架构相关的一些理论备忘

1. 实现微服务架构要解决的一些问题
   微服务如何通讯？
   1）首先我们要考虑通讯是一对一还是一对多的，一对一就是请求响应模式，最常见。一对多就是发布订阅／发布异步响应，比如滴滴打车就是一个一对多的关系，用户发出消息，很多的司机都能接收到这个消息。
   从通讯协议角度考虑
   一对一：REST API (http)
   一对多：RPC (dubbo motan dubbox grpc thrift)
   2） 微服务如何发现彼此？
   服务发现的本质是服务调用者如何知道服务的提供者的IP与端口号。
   3）微服务怎么部署？更新？扩容？
   doker k8s 等，就是解决服务数量很多，服务器不好维护的缺点。--------------------******
2. Spring Cloud包含的重要的组件，他们如何解决这些问题的
   常见的微服务框架：
   - 服务的注册和发现中心（Spring Cloud Eureka；Dubbo；Consul）
   - 服务消费者便出现（rest+ribbon）
   - ribbon的服务消费者feign
   - 断路器（Hystrix）断路器的作用是当远程服务访问不到，可以改成访问本地的某一方法
   -路由网关（zuul）作用就是负载均衡统一服务端口和反向代理，比如统一过滤，统一权限认证等等统一的东西都可以放在这里
   - 分布式配置中心（Spring Cloud Config；Disconf）将所有服务的配置文件都抽取到一个统一的地方。解决服务一多，改配置太麻烦了，需要有个东西来管理，最好还能在线修改配置的问题
   - 消息传递工具——消息总线（Spring Cloud Bus）更改配置的时候，服务能够知道并且热更新配置，通过这个总线向其他服务传递消息
   - 服务追踪组件（zipkin ，SpringCloud Sleuth集成了zipkin）知道各个服务之间的调用关系间接得到服务之间的依赖
   - 批量任务框架Spring Cloud组件中的Task
3. spring Cloud全家桶
   1）Spring Cloud Eureka 服务的注册和发现中心；可以将自己定义的API 接口注册到Spring Cloud Eureka上服务的注册和发现，构成Eureka体系的包括：服务注册中心、服务提供者、服务消费者。
   2）Spring Cloud Ribbon 客户端负载均衡器；Eureka只是维护了服务生产者、注册中心、服务消费者三者之间的关系，真正的服务消费者调用服务生产者提供的数据是通过Spring Cloud Ribbon来实现的。就是说服务消费者调用哪一个节点是由ribbon通过算法选择的。
   3）Spring Cloud Feign 是一个声明web服务客户端，这使得编写Web服务客户端更容易，使用Feign 创建一个接口并对它进行注解, Spring Cloud 集成 Ribbon 和 Eureka 提供的负载均衡的HTTP客户端 Feign。Spring Cloud Feign 的出现使得Eureka和Ribbon的使用更为简单。
   4）Spring Cloud Hystrix 断路器，防止对某一故障服务持续进行访问，配合降级，把错误的数据进行数据库记录
   5）Spring Cloud Config 分布式配置中心组件 它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。Spring Cloud Config 组件中，分两个角色，一是Config Server，二是Config Client。Config Server用于配置属性的存储，存储的位置可以为Git仓库、SVN仓库、本地文件等，Config Client用于服务属性的读取。
   6）Spring Cloud Zuul 服务网关 通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了统一降级，限流，权限，安全等功能。提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性
   7）Spring Cloud Bus 消息总线 动态更新服务配置