Eureka服务端挂了后，微服务还能调通是因为：客户端缓存、Ribbon的负载均衡机制、Hystrix熔断机制。Eureka客户端会在启动时从Eureka服务端获取服务注册信息，并将其缓存到本地。即使Eureka服务端挂了，Eureka客户端仍然可以使用缓存的服务注册信息进行服务调用。Ribbon作为客户端负载均衡器，它会从Eureka客户端获取服务列表并进行负载均衡，即使Eureka服务端挂了，Ribbon也能够使用缓存的数据进行负载均衡。Hystrix作为熔断器，可以在服务调用失败时快速失败并返回默认值，从而提高系统的稳定性。
一、EUREKA客户端缓存
Eureka客户端在启动时，会从Eureka服务端获取服务注册信息，并将其缓存到本地。这个缓存机制使得即使Eureka服务端挂了，客户端也能从本地缓存中获取服务列表进行服务调用。Eureka客户端的缓存是通过定时任务进行更新的，默认情况下每隔30秒刷新一次。因此，即使Eureka服务端宕机，只要客户端本地的缓存没有过期，服务调用仍然可以正常进行。
Eureka客户端缓存的具体实现是通过Eureka客户端的一个内部类实现的，这个类会在初始化时从Eureka服务端获取服务注册信息，并将其存储在本地的一个数据结构中。在每次服务调用时，客户端会首先检查本地缓存，如果缓存中有对应的服务信息，就直接使用缓存中的信息进行服务调用。这样的设计不仅提高了服务调用的性能，还增强了系统的容错能力。
二、RIBBON的负载均衡机制
Ribbon是一个客户端负载均衡器，广泛用于微服务架构中。它与Eureka集成，可以从Eureka客户端获取服务列表并进行负载均衡。即使Eureka服务端挂了，Ribbon也能够使用缓存的数据进行负载均衡。Ribbon会在服务调用时自动选择一个可用的服务实例进行调用，这种机制能够有效地分散请求压力，提高系统的可用性和稳定性。
Ribbon的负载均衡策略是可配置的，常见的策略包括轮询、随机、加权响应时间等。开发者可以根据具体的业务需求选择合适的负载均衡策略。Ribbon还支持自定义负载均衡策略，通过实现ILoadBalancer接口，可以实现更加复杂的负载均衡逻辑。
Ribbon的负载均衡机制不仅提高了系统的性能，还增强了系统的容错能力。当某个服务实例不可用时，Ribbon会自动从服务列表中移除该实例，并将请求转发到其他可用的实例。这种机制使得系统在面对服务实例故障时仍然能够保持高可用性。
三、HYSTRIX熔断机制
Hystrix是一个用于处理分布式系统中延迟和故障的库，它通过熔断机制在服务调用失败时快速失败，并返回默认值，从而提高系统的稳定性。即使Eureka服务端挂了，Hystrix也能够通过熔断机制保护系统不受到影响。Hystrix的熔断机制能够有效地防止雪崩效应，在服务调用失败时，Hystrix会立即返回默认值，而不是让请求一直等待，导致整个系统的响应时间变长。
Hystrix的熔断机制包括三个状态：关闭、打开和半开。当服务调用失败率超过一定阈值时，熔断器会打开，此时所有对该服务的调用都会立即失败，返回默认值。经过一段时间后，熔断器会进入半开状态，允许部分请求通过，如果这些请求成功，熔断器会关闭，恢复正常服务调用。如果这些请求失败，熔断器会继续保持打开状态。
Hystrix还提供了隔离策略，通过线程池或信号量的方式来隔离不同的服务调用，从而防止某个服务的故障影响到其他服务。通过配置不同的隔离策略，可以根据具体的业务需求灵活调整系统的容错能力。
四、服务注册与发现机制
服务注册与发现是微服务架构中的关键组件，Eureka作为一个服务注册与发现的框架，广泛应用于Spring Cloud生态系统中。Eureka服务端负责维护服务注册表，而Eureka客户端负责从服务端获取服务注册信息并进行服务调用。即使Eureka服务端挂了，Eureka客户端仍然可以使用本地缓存的服务注册信息进行服务调用。
服务注册与发现机制通过心跳检测来维护服务实例的健康状态。Eureka客户端会定期向Eureka服务端发送心跳请求，以通知服务端该服务实例仍然存活。如果服务端在一定时间内没有收到某个服务实例的心跳请求，就会将该实例从服务注册表中移除。
服务注册与发现机制不仅提供了服务实例的自动注册和注销功能，还支持服务实例的动态扩展和缩减。通过配置Eureka的相关参数，可以灵活控制服务实例的注册和注销行为，从而提高系统的可用性和灵活性。
五、客户端重试机制
客户端重试机制是在服务调用失败时，自动重试请求的一种机制。通过配置客户端重试机制，可以在服务调用失败时自动重试，增加成功的概率。这种机制在Eureka服务端挂了的情况下尤为重要，通过重试机制可以有效提高服务调用的成功率。
客户端重试机制通常与负载均衡策略结合使用，通过重试不同的服务实例来增加请求成功的概率。重试机制的实现可以通过配置重试次数、重试间隔时间等参数来控制，灵活调整重试策略以适应不同的业务需求。
客户端重试机制虽然能够提高服务调用的成功率，但也会增加系统的负载。因此，在配置重试机制时需要权衡重试次数和系统负载之间的关系，避免因过多的重试而导致系统性能下降。
六、微服务的自我保护机制
自我保护机制是Eureka的一项重要特性，用于在网络异常或服务端压力过大时，保护服务注册表中的服务实例不被过早移除。当Eureka服务端检测到大量服务实例的心跳请求失败时，会进入自我保护状态，此时不会移除任何服务实例，以保证服务调用的高可用性。
自我保护机制的实现是通过调整Eureka服务端的阈值参数来控制的。当服务实例的心跳请求失败率超过一定阈值时，服务端会进入自我保护状态。在自我保护状态下，服务端仍然会接受新的服务注册请求，但不会移除任何现有的服务实例。
自我保护机制提高了Eureka在网络异常或服务端压力过大时的容错能力，但也需要注意配置合理的阈值参数，以避免自我保护状态过长时间维持，影响服务注册表的准确性。
七、服务实例的健康检查机制
健康检查机制用于定期检测服务实例的健康状态，确保服务实例的可用性。Eureka客户端会通过心跳请求通知服务端该实例的健康状态，而服务端会根据心跳请求的结果更新服务注册表中的信息。通过健康检查机制，可以及时发现和移除不可用的服务实例，提高系统的稳定性和可用性。
健康检查机制的实现可以通过多种方式，例如HTTP、TCP或自定义的健康检查脚本。根据具体的业务需求，可以选择合适的健康检查方式，并配置合理的检查频率和超时时间。
健康检查机制不仅用于服务实例的健康状态监控，还可以用于服务实例的自动恢复和重启。在检测到服务实例不可用时，系统可以自动重启该实例，尝试恢复其可用性，从而提高系统的自愈能力。
八、服务调用的超时和重试机制
在微服务架构中，服务调用的超时和重试机制是提高系统可靠性的重要手段。通过配置服务调用的超时时间，可以在服务调用超时后快速失败，避免长时间等待导致的系统性能下降。通过重试机制，可以在服务调用失败时自动重试，增加成功的概率。
服务调用的超时和重试机制通常与负载均衡和熔断机制结合使用，通过合理配置超时时间和重试次数，可以提高系统的容错能力和稳定性。在配置超时和重试机制时，需要根据具体的业务需求和系统性能进行权衡，避免因过多的重试导致系统负载过高。
服务调用的超时和重试机制不仅提高了系统的可靠性，还增强了系统的弹性和扩展性。通过灵活调整超时和重试参数，可以适应不同的业务场景和系统负载，确保系统在高并发和高压力下仍能保持稳定运行。
九、服务依赖的解耦与隔离
服务依赖的解耦与隔离是微服务架构中提高系统稳定性的重要手段。通过将服务之间的依赖关系解耦，可以减少服务之间的耦合度，提高系统的灵活性和可维护性。通过隔离策略，可以防止某个服务的故障影响到其他服务，从而提高系统的容错能力。
服务依赖的解耦可以通过消息队列、事件驱动等方式实现，通过异步通信减少服务之间的直接依赖。隔离策略可以通过线程池、信号量等方式实现，通过隔离不同的服务调用，防止某个服务的故障影响到其他服务。
服务依赖的解耦与隔离不仅提高了系统的稳定性，还增强了系统的扩展性和弹性。通过合理配置解耦和隔离策略，可以灵活调整系统的架构和部署，提高系统在高并发和高压力下的表现。
十、日志与监控系统
日志与监控系统是微服务架构中提高系统可观测性的重要手段。通过日志记录和监控数据的收集，可以及时发现和定位系统中的问题，从而提高系统的稳定性和可维护性。通过配置合理的日志级别和监控指标，可以实时监控系统的运行状态，及时发现和处理异常情况。
日志与监控系统的实现可以通过多种方式，例如ELK（Elasticsearch、Logstash、Kibana）、Prometheus、Grafana等。根据具体的业务需求，可以选择合适的日志和监控方案，并配置合理的日志级别和监控指标。
日志与监控系统不仅提高了系统的可观测性，还增强了系统的运维管理能力。通过实时监控系统的运行状态，可以及时发现和处理系统中的问题，提高系统的稳定性和可靠性。
相关问答FAQs：
1. 为什么即使 Eureka 服务端挂了，微服务仍然可以调通？
Eureka 是 Netflix 开源的一款基于 REST 的服务治理框架，用于实现微服务架构中的服务注册与发现。当 Eureka 服务端挂了，即使注册中心不可用，已经注册到 Eureka 的微服务实例仍然可以相互调用。这是因为 Eureka 采用了客户端-服务端的架构模式，即每个微服务都会周期性地向 Eureka 服务端发送心跳，并将自身的状态注册到 Eureka 服务端。因此，即使 Eureka 服务端挂了，已经注册的微服务实例在本地缓存了服务注册表信息后，仍然可以相互发现并进行通信。
2. 微服务如何在 Eureka 服务端挂了的情况下继续调用其他微服务？
在 Eureka 服务端挂掉后，微服务之间的通信不会受到影响，因为微服务在启动时会从 Eureka 服务端获取服务注册表信息，并在本地进行缓存。当需要调用其他微服务时，微服务会直接从本地缓存的服务注册表中获取目标微服务的地址和端口，然后进行通信。这种方式使得微服务在 Eureka 服务端不可用时仍然能够相互调用，保证了系统的可用性。
3. Eureka 服务端挂了会对微服务架构造成哪些影响？
虽然 Eureka 服务端挂了不会影响已经注册到 Eureka 的微服务之间的通信，但是在 Eureka 服务端不可用的情况下，新的微服务实例无法注册到注册中心，也无法被其他微服务实例发现。这可能会导致服务发现的延迟和不一致性，以及新服务实例的负载均衡问题。因此，为了保证微服务架构的稳定性和可靠性，建议在生产环境中采取高可用性措施，如使用 Eureka Server 集群、结合 Nginx 实现负载均衡等，以避免单点故障带来的影响。
关于 GitLab 的更多内容，可以查看官网文档：
官网地址：
文档地址：
论坛地址：
原创文章，作者：极小狐，如若转载，请注明出处：https://devops.gitlab.cn/archives/38812
