组件"/>
springcloud 核心组件
服务启动时,EurakeClient会将服务注册到EurekaService，从EurekaService拉去注册表
Ribbon：基于Ribbon服务会做负载均衡，所有客户端节点都维护着自己要访问的服务端清单，服务间发起请求的时候,选择多台服务器中的其中一个；
fegin：基于动态代理机制, 根据注解和选择服务器地址,拼接Url,发起请求；
Hystrix:发起的请求是通过Hystrix的线程池来走,不同的服务走不同的线程池,实现了不同的服务调度隔离,避免服务雪崩的问题 防止因依赖关系而引发故障的蔓延
Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能
Zuul: 不同的途径调用后台，统一走zuul网关，转发请求给对应的服务
dubbo架构中，为什么一般不用Gateway层？
- 去中心化，防止单点故障；
- 直连性能由于没有gateway转发，性能当然也更好。
服务治理、客户端负载均衡、熔断器 、服务网关
这些组件为开发提供了安全便利。
1. Eureka
结算中台、政策中台、用户中台中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。
而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号
Eureka有服务端和客户端。
服务端。
服务端用作服务注册中心、支持集群部署。
客户端。
客户端用来处理服务注册与发现。
2. Ribbon
提供软件负载均衡算法
Ribbon基于HTTP和TCP，Cloud封装了Ribbon，我们可以轻松使用。
Fegin也可以实现负载均衡。
Ribbon有很多负载均衡策略……
3. feign
Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：
首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
最后针对这个地址，发起请求、解析响应
4. 服务网关
Zuul
作用：api网关，路由，负载均衡等多种作用
简介：类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。
在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。
5. 熔断器
作用：断路器，保护系统，控制故障范围。
简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。
分布式的整体解决方案。
spring cloud为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，控制总线，一次性token，全局锁，leader选举，分布式session，集群状态）中快速构建的工具，使用spring cloud的开发者可以快速的启动服务或构建应用，同时能够快速和云平台资源进行对接。
REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合。 http rest
消息队列（区别于本地消息队列：jvm内的队列实现）是一种独立的队列系统。
. 非业务逻辑需要依赖其他系统，但是结果不重要，队列中有通知就行。
2. 可以有延迟，但只要一致就行
3. 消息广播：生产者负责生产消息，订阅者接受消息。
4. 错开高峰期，达到流量的控制。
服务熔断，服务降级
服务熔断：某个服务故障或异常，像“保险丝”，某个异常条件被触发就直接熔断整个服务。（不会一直等到超时）
服务降级：通过维护一个自己的线程池当线程池达到阈值的时候就启动服务降级。
微服务优缺点
每一个服务足够内聚,代码容易理解
开发效率提高,一个服务只做一件事
微服务能够被小团队单独开发
可以用不同的语言开发,面向接口编程
微服务技术栈
服务配置中心管理：springcloudConfig（配置）
服务路由：zuul （url地址）
注册：eureka （注册）
服务负载均衡：ribbon 服务接口调用：feign （controller）
消息队列：rabbitmq
服务调用：rest （服务间调用）
服务熔断器：hystrix （异常）
事件消息总线：springcloudBus
服务之间通过restful方式调用
两种方式：
- restTemplate+ribbon
- feign
客户端ribbon做负载均衡，解决服务发起方对调用的服务的加载load。
如：我们查询商品 调用显示库存和商品明细。通过商品服务的接口将两个服务组合，可以减少外部应用的请求。
zuul是可以对外部请求做负载均衡。
负载均衡
负载均衡是高可用网络基础架构的的一个关键组成部分，有了负载均衡，我们通常可以将我们的应用服务器部署多台（横向扩展），然后通过负载均衡将用户的请求分发到不同的服务器用来提高网站、应用、数据库或其他服务的性能以及可靠性。
CAP原则
包括一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
- 一致性：分布式系统中的所有数据备份在同一时刻是否同样的值。值为最新的数据副本，所有节点访问同一份最新的数据副本；
- 可用性：保证每个请求都有响应，不论成功或失败；
- 分区容忍性： 信息会丢失，系统中分区容忍性保证这不影响系统的继续运作。
但是三个要素最多只能同时实现两点，不能三者兼顾。
更多推荐
springcloud 核心组件
发布评论