Consul 是HashiCorp公司推出的开源工具，用于实现分布式系统的服务发现与配置共享。对比其他分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框架、分布–致性协议实现(Raft算法)、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具(比如ZooKeeper等)。Consul用Golang 实现，因此具有天然可移植性(支持Linux、Windows和Mac OS X);安装包仅包含-一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合。
在注册中心的选择方面，可以针对自身业务的特点，选择一款合适的注册中心，如果团队原有框架基于Dubbo，那么ZooKeeper会更合适一些;如果团队整体使用Spring Cloud, 那么Eureka的优势就会更大- - 些;如果团队对于容器化的要求比较高，那么etcd和Consul都是不错的选择。由于我们的整体构建所需，我们选择的是Spring Cloud中的Eureka。
Eureka 介绍
=========
Eureka的一些概念如下。
Register: 服务注册
当Eureka客户端向Eureka Server 注册时，它提供自身的元数据，比如IP地址、端口、运行状况指示符URL、主页等。
Renew: 服务续约
Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。正常情况下，如果Eureka Server在90秒后没有收到Eureka客户的续约，则它会将实例从其注册表中删除。建议不要更改续约间隔。
Fetch Registries：获取注册列表信息
Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期(每30秒)更新一次。每次返回的注册列表信息可能与Eureka客户端的缓存信息不同，Eureka客户端会自动处理。如果由于某种原因导致注册列表信息不能及时匹配，则Eureka客户端会重新获取整个注册表信息。Eureka服务器缓存注册列表信息，整个注册表及每个应用程序的信息都进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka服务器可以使用JSON/XML格式进行通信。在默认的情况下，Eureka客户端使用压缩JSON格式来获取注册列表的信息。
Cancel: 服务下线Eureka客户端在程序关闭时向Eureka服务器发送取消请求。发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容:
DiscoveryManager . getInstance () . shutdownComponent () ;
Eviction：服务剔除
在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约(即心跳)时，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。
Eureka由多个instance ( 服务实例)组成，这些服务实例可以分为两种: Eureka Server 和Eureka Client。
Eureka Client再分为Service Provider和Service Consumer。
Eureka Server：服务的注册中心，负责维护注册的服务列表。
Service Provider：服务提供方，作为一个Eureka Client，向Eureka Server 进行服务注册、续约和下线等操作，注册的主要数据包括服务名、机器IP、端口号、域名等。
Service Consumer：服务消费方，作为一个Eureka Client,向Eureka Server获取Service Provider的注册信息，并通过远程调用与Service Provider进行通信。
Service Provider 和Service Consumer 不是严格的概念，Service Consumer 也可以随时向Eureka Server注册，来让自己变成一个Service Provider。
Eureka程序构成如下。
-
纯正的Servlet应用，需构建成war包部署。
-
使用了Jersey 框架实现自身的RESTful HTTP接口。
-
peer 之间的同步与服务的注册全部通过HTTP协议实现。
-
定时任务(发送心跳、定时清理过期服务、节点同步等)通过JDK自带的Timer实现。
-
内存缓存使用Google的guava包实现。
服务发现
====
在现在的软件开发中，如果对性能要求不是非常高，则一般使用REST API来开放服务的接口。
服务发现有如下两种模式。
客户端服务发现(Client-Side Discovery)如下图所示。
服务实例启动时会向服务注册中心进行注册，服务的注册中心能够看到所有注册的实例。客户端需要调用服务时，先到注册中心摘取可用的服务列表的地址，然后根据负载均衡算法， 去获取一个可用的实例的地址来响应这次请求。
一个服务实例被启动，它的网络地址会被写到注册中心，当服务实例终止，会从注册表中删除。这个服务实例的注册表通过心跳机制动态刷新。
服务端服务发现(Server-Side Discovery)如下图所示。
客户端通过负载均衡器向某个服务提出请求，负载均衡器向注册中心发出请求，将每个请求转发至可用的服务实例。和客户端发现一样，服务实例启动时在注册中心注册，当服务实例销毁时，会从服务注册表中进行删除。
使用服务器端服务现，客户端无须关注发现的细节，只需要简单地向负载均衡器发送请求即可，实际上减少了编程语言框架需要完成的服务发现逻辑。缺点是除非部署环境能够提供负载均衡，否则负载均衡器是另外一个需要配置管理的高可用系统功能。目前比较流行的方式是使用Nginx来进行服务器端的负载均衡。
负载均衡
====
负载均衡是云计算的基础组件，是网络流量的入口，其重要性不言而喻。
什么是负载均衡呢?用户输入的流量通过负载均衡器按照某种负载均衡算法把流量均匀地分散到后端的多个服务器上,接收到请求的服务器可以独立地响应请求，达到负载分担的目的。从应用场景上来说，常见的负载均衡模型有全局负载均衡和集群内负载均衡。
服务端负载均衡
负载均衡是处理高并发、缓解网络压力和进行服务端扩容的重要手段之-一，但是一般情况下我们所说的负载均衡通常都是指服务端负载均衡，服务端负载均衡又分为两种，一种是硬件负载均衡，另一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备实现，常见的设备如F5。
软件负载均衡则主要通过在服务器上安装一些 具有负载均衡功能的软件来完成请求分发进而实现负载均衡，常见的就是Nginx。
无论是硬件负载均衡还是软件负载均衡，它的工作原理均如下图所示。
无论是硬件负载均衡还是软件负载均衡，都会维护一个可用的服务端清单，然后通过心跳机制来删除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端的请求到达负载均衡服务器时，负载均衡服务器按照某种配置好的规则从可用服务端清单中选出一台服务器去处理客户端的请求，这就是服务端负载均衡。
负载均衡策略：
-
简单轮询负载均衡;
-
加权响应时间负载均衡;
-
区域感知轮询负载均衡;
-
随机负载均衡。
Feign
=====
在Spring Cloud Netlix中，各个微服务都是以HTTP接口的形式暴露自身服务的，因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JDK原生的URLConnection、Apache的Http Client、Netty 的异步HTTP Client,以及Spring的RestTemplate。但是，用起来最方便、最优雅的还是Feign。
Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign,我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。
微服务容错
=====
在大中型分布式系统中，通常系统有很多依赖。在并发量很小的时候，通常不会造成很严重的后果，但是当并发量激增，这些依赖的稳定性就有可能造成整个系统的瘫痪，这也就是我们经常说的雪崩。
雪崩的形成
=====
服务雪崩效应是一种因服务提供者的不可用而导致服务调用者的不可用的现象，并将不可用逐渐放大的过程。举例来说，我们使用链式设计模式构建的微服务，当其他的服务出现问题时，就会出现连锁支应，导致整个服务链条不可用。
造成服务不可用的原因包括:
-
硬件故障;
-
网络连接缓慢;
-
程序Bug;
-
缓存击穿，一般发生在缓存应用重启，所有缓存被清空时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端，造成服务提供者超负荷运行，引起服务不可用;
-
用户大量请求。
那么出现雪崩应该如何应对呢?
应对雪崩一般有以下几种办法。
- 流量控制
一般是使用Nginx进行流量控制，对流量大的应用采用分流和限制，这个功能也可以使用网关来完成。
- 服务自动扩容
取决于硬件的限制，也可以使用第三方的云服务以达到扩容的效果。如果微服务构建得比较成熟，则可以通过容器的动态扩容来完成服务的扩容。
- 降级和资源隔离
资源隔离主要是对调用服务的线程池进行隔离，监控一般要细致到线程级别，当发现某个线程占用资源过高时，进行有效的处理来解决性能瓶颈。
我们根据具体业务将依赖服务分为强依赖和弱依赖。强依赖服务不可用会导致当前业务中止，而弱依赖服务的不可用不会导致当前业务的中止。
不可用服务的调用快速失败一般通过超时机制、熔断器和熔断后的降级方法来实现。
- 降级
在网络访问中，为了优化用户体验，遇到超时的情况，可以直接放弃本次请求，不等待结果的返回，直接返回用户默认数据，也可以降级为从另一个服务或者使用缓存中设置的默认数据。
熔断
熔断是指错误达到某个设定的阈值，或者请求量超过阈值后，系统自动(或手动)阻止代码或服务的执行调用，从而达到系统整体保护的效果。当检测到系统可用时，需要恢复访问。
熔断器模式
熔断器模式定义了熔断器开关相互转换的逻辑。
正常运行 (Closed)
当一个系统运行平稳时，成功状态计数器用于测量弹性系统的稳定性，而故障表用于跟踪任何故障。该设计确保当达到故障的阆值时，断路器断开电路，以防止进一步的资源请求。
失败状态 (Open)
在这个时刻，每-一个依赖调用是短路的，并抛出HystrixRuntimeException 异常，伴随SHORTCIRCUIT失败类型，给出异常明确的原因。一旦等待时间过后，Hystrix 断路器移到半开放状态。
半开放状态在这种状态下，由Hystrix负责发送第一一个请求， 检查系统的可用性，让其他的请求快速失败，直到得到依赖的响应。如果调用是成功的，则断路器被重置为Closed状态;如果发生故障，则系统返回Open状态，并且整个过程继续循环。
断路器是Hystrix库默认提供的一个功能。断路器的功能可以概括如下:
熔断器对所有调用状态进行验证;如果是closed状态，则允许请求通过;如果是open状态，则失败所有的请求;如果是half-open状态，则允许-一个请求通过，并在成功或者失败时，转换成closed或open状态。
Hystrix
=======
Hystrix：通过服务熔断、降级、限流、异步RPC等手段控制依赖服务的延迟与失败。通过命令模式封装调用来实现弹性保护，继承HytrixCommand并且实现run方法，就完成了最简单的封装。可以为分布式服务提供弹性保护。
Hystrix的设计原则包括:资源隔离、熔断器、命令模式。
断路器机制
断路器很好理解，当Hystrix Command请求后端服务失败数量超过一定 比例，默认为50%，断路器会切换到开路状态(open)， 这时所有请求会直接失败而不会发送到后端服务。断路器保持在开路状态一段时间后， 默认为5秒，自动切换到半开路状态(half-open), 这时会判断下一次请求的返回情况。如果请求成功，则断路器切回闭路状态(closed)，否则重新切换到开路状态(open)。Hystrix 的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链,避免发送大量无效请求影响系统吞吐量，并且断路器有自我检测并恢复的能力。
fallback
fallback相当于降级操作。对于查询操作，我们可以实现一个fallback 方法，当请求后端服务出现异常时，可以使用fallbak方法返回的值。fllback 方法的返回值一般是设置的默认值或者来自缓存。
资源隔离
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）
最后
由于篇幅限制，小编在此截出几张知识讲解的图解
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
lt=“img” style=“zoom: 33%;” />
最后
由于篇幅限制，小编在此截出几张知识讲解的图解
[外链图片转存中…(img-qxls6Vyd-1713419487928)]
[外链图片转存中…(img-a3QcdyK9-1713419487928)]
[外链图片转存中…(img-5f9zHk30-1713419487929)]
[外链图片转存中…(img-cec4q5SC-1713419487929)]
[外链图片转存中…(img-x9OZD6wk-1713419487929)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
1584
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
