携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第2天，点击查看活动详情
服务注册中心
🦅 .Eureka 注册中心,跟zk一样 Eureka Client：负责将这个服务的信息注册到Eureka Server中 Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号 AP 分布式算法 🦅 zk cp算法 C 一致性 牺牲掉A 可用性 ZK 可能会有一个短时间内 集群不可用 此时需要重写选举一个leader 在做数据同步 保证数据一致性在开发让你来读 🦅 Nocos 也是基于 raft 算法的 CP 模型 同事也支持配置类似 Eureka的AP 包含了雪崩保护 自动注销 监听支持 多数据中心 跨注册中心同步 分布式配置中心 这些都支持 功能最完善 🦅 Consul 也是基于raft 算法的CP 模型 远程调用组件
🦅 Feign 直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。人家Feign Client会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起靕求、获取响应、解析响应，等等。 Feign的一个关键机制就是使用了动态代理 首先,如果你对某个接口定义了@FeignClient注解,Feign就会针对这个接口创建一个动态代理 你要是需要调用哪个接口,本质就是调用Feign创建的动态代理 Feign的动态代理会根据你在接口上的@RequestMaping等注解,用来动态构造出你要请求的服务的地址 最后针对这个地址没发起请求,解析响应 负载均衡组件
🦅Ribbon 如果说部署了多台服务器,feign是怎么知道往哪个服务器上请求呢? Ribbon就能解决这个问题,他的作用就是负载均衡,他会把每个请求按照一定的机制分发到每个服务器,默认使用的负载均衡是轮训,还 有权重啊,随机啊(这里区别于nginx 他会有一个一致性hash) Ribbon是和Feign以及Eureka紧密协作，完成工作的,步骤: 1.Ribbon回仓eureka cilent那里知道了对应的服务器列表,也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。 2.然后Ribbon就可以使用对应的轮训机制，从中选择一台机器 3.Feign就会针对这台机器，构造并发起请求
熔断限流组件 🦅hystrix 断路器,也就是起到了熔断降级的作用 设想一个场景,就是微服务架构中,假如订单服务需要调用积分服务的时候,如果说积分服务出问题了,那么所有订单服务调用积分服务的请求就会一值卡在那,久了过后就会出现服务雪崩,导致订单服务也无法工作,因为一直在等积分服务的反馈,这时候hystrix就有他的作用了,就可以直接走熔断,也就是直接熔断积分服务,5分钟内积分服务的请求就直接返回了, 而降级就是说当直接返回的时候 就可以砸数据库中插入一条记录,因为积分服务挂了,导致积分服务的积分没有增加成功,就可以根据数据库中的记录手动去增加积分,这就是降级的过程 相当于你挂了 我有个备用方案 你直接降级走我这里
🦅Sentinel
轻量级，核心库无多余依赖，性能损耗小。 方便接入，开源生态广泛。Sentinel 对 Dubbo、Spring Cloud、Web Servlet、gRPC 等常用框架提供适配模块，只需引入相应依赖并简单配置即可快速接入；同时针对自定义的场景 Sentinel 还提供低侵入性的注解资源定义方式，方便自定义接入。 丰富的流量控制场景。Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，流控维度包括流控指标、流控效果（塑形）、调用关系、热点、集群等各种维度，针对系统维度也提供自适应的保护机制。 易用的控制台，提供实时监控、机器发现、规则管理等能力。 完善的扩展性设计，提供多样化的 SPI 接口，方便用户根据需求给 Sentinel 添加自定义的逻
服务组件网关 🦅.zuul 网关 主要作用是用来做路由的,假如说你后端有几百个服务,这时候前端需要调用其中一个服务,你还需要他记住这个服务的名字吗?而且就算记住了 后端还有那么多接口的名字,不可能记住的,所以这时候就需要zuul网关了,所有的请求都统一走网关,然后网关再去分发这些请求 网关还有一些别的作用,比如做一些统一的降级,限流,认证鉴权,安全等等(前置拦截,后置拦截) zuul仅支持同步
使用的是阻塞式的 ，不支持长连接，比如 websockets。
底层是servlet，Zuul处理的是http请求
没有提供异步支持，流控等均由hystrix
依赖包spring-cloud-starter-netflix-zuul
🦅 Gateway
网关 主要作用是用来做路由的,假如说你后端有几百个服务,这时候前端需要调用其中一个服务,你还需要他记住这个服务的名字吗?而且就算记住了 后端还有那么多接口的名字,不可能记住的,所以这时候就需要zuul网关了,所有的请求都统一走网关,然后网关再去分发这些请求 网关还有一些别的作用,比如做一些统一的降级,限流,认证鉴权,安全等等(前置拦截,后置拦截)
Spring Boot和Spring Webflux提供的Netty底层环境，不能和传统的Servlet容器一起使用，也不能打包成一个WAR包。
依赖spring-boot-starter-webflux和/ spring-cloud-starter-gateway
提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。
gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件 zuul 则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。
日志监控组件 🦅 cat ：由大众点评开源，基于Java开发的实时应用监控平台，包括实时应用监控，业务监控 。 集成 方案是通过代码埋点的方式来实现监控，比如： 拦截器，过滤器等。 对代码的侵入性很大，集成
成本较高。风险较大。
🦅zipkin ：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微 服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。该产品结合spring-cloud-sleuth
使用较为简单， 集成很方便， 但是功能较简单。
🦅pinpoint： Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点 是支持多种插件，UI功能强大，接入端无代码侵入。
🦅skywalking：SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多 种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。
🦅Sleuth SpringCloud 提供的分布式系统中链路追踪解决方案。
分布式配置 🦅Apollo Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰
度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料
也写的很详细。
🦅Disconf Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效
的。
🦅SpringCloud Config 这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成，使用起来非常方便，并且它的配
置存储支持Git。不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。
🦅Nacos 这是SpingCloud alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也
集成了服务配置的功能，我们可以直接使用它作为服务配置中心。
🦅 Nacos Config 使用 使用nacos作为配置中心，其实就是将nacos当做一个服务端，将各个微服务看成是客户端，将各个微服务的配置文件统一存放在nacos上，然后各个微服务从nacos上拉取配置即可。
组件总结 Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表从而知道其他服务在哪里(心跳包)
🦅 Nacos : 也是基于 raft 算法的 CP 模型 同事也支持配置类似 Eureka的AP 包含了雪崩保护 自动注销 监听支持 多数据中心 跨注册中心同步 分布式配置中心 这些都支持 功能最完善
🦅 重要 Ribbon服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台 🦅 重要 Feign基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求 Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
🦅 重要 Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，流控维度包括流控指标、流控效果（塑形）、调用关系、热点、集群等各种维度，针对系统维度也提供自适应的保护机制
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
🦅 重要 Gateway 如何前端 移动端要调用后端系统 统一从gateway 网关进入 由 gateway 网关 转发请求给对应的服务 动态路由 灰度发布基于现成开源插件来开发 授权认证
🦅 日志链路打标 Zipkin+Sleuth整合 +mq 数据最好建议配置 ELK
🦅 Nacos Config 使用 使用nacos作为配置中心，其实就是将nacos当做一个服务端，将各个微服务看成是客户端，将各个微服务的配置文件统一存放在nacos上，然后各个微服务从nacos上拉取配置即可。
