大丰专业做网站的公司,工信部备案号查询平台,上海猎头公司哪家好,企业网站意思1、Eureka 简介
Eureka是Spring Cloud Netflix 微服务套件中的一个服务发现组件#xff0c;本质上是一个基于REST的服务#xff0c;主要用于AWS云来定位服务以实现中间层服务的负载均衡和故障转移,它的设计理念就是“注册中心”。 你可以认为它是一个存储服务地址信息的大本…1、Eureka 简介
Eureka是Spring Cloud Netflix 微服务套件中的一个服务发现组件本质上是一个基于REST的服务主要用于AWS云来定位服务以实现中间层服务的负载均衡和故障转移,它的设计理念就是“注册中心”。 你可以认为它是一个存储服务地址信息的大本营微服务启动时会把自己的信息告诉Eureka这个过程叫做注册。 当别的服务想要调用这些服务时就会去问Eureka需要的服务地址在哪里这个过程叫做发现。
1.1 Eureka 组件 Eureka由两个组件组成Eureka Server和Eureka Client。
1.1.1 Eureka Server Eureka的服务端提供服务注册和发现的功能。服务实例启动后会向Eureka Server注册自己的信息比如主机名、端口号等。然后Eureka Server会保存这些信息供其他服务查询使用。
EnableEurekaServer // 启用Eureka Server
SpringBootApplication
public class EurekaServerApplication {public static void main(String[] args) {SpringApplication.run(EurekaServerApplication.class, args);}
}1.1.2 Eureka Client Eureka的客户端它是一个Java客户端用于简化与服务端的交流可以很轻松地集成到Spring Cloud应用之中。
EnableEurekaClient // 启用Eureka Client
SpringBootApplication
public class EurekaClientApplication {public static void main(String[] args) {SpringApplication.run(EurekaClientApplication.class, args);}
}2、Eureka 和 Zookeeper 对比
在微服务架构中服务发现是一个核心的问题。服务发现让服务消费者能够找到网络中运行的服务提供者的实例。 Eureka和Zookeeper都是流行的服务发现解决方案但它们的设计理念和实现细节有所不同。
2.1 什么是 CAP 定理 CAP定理是分布式计算领域的一个重要概念由加州大学伯克利分校的Eric Brewer教授提出。它指出一个分布式系统不可能同时满足以下三点
Consistency一致性在分布式系统中的所有数据副本在同一时间内是否具有相同的值。Availability可用性保证每个请求不管成功或者失败都有响应。Partition tolerance分区容错性系统中任意信息的丢失或失败不会影响系统的继续运作。
在实际的分布式环境中网络分区是不可避免的因此分区容错性是必须要实现的这就意味着在CAP的三个特性中我们只能在一致性和可用性之间进行权衡。
2.2 基于 CAP 定理比对 Eureka 和 Zookeeper 根据CAP定理我们来看看Eureka和Zookeeper是如何做权衡的。 Zookeeper Zookeeper是一个中心化的服务协调系统广泛用于名称服务、配置管理、节点同步等。它保证了强一致性Consistency和分区容错性Partition tolerance但不保证可用性Availability。这意味着如果Zookeeper集群中的过半节点不可用整个Zookeeper服务就不可用了。这样做可以保证所有读取操作返回的都是最新的数据。 在Zookeeper中领导选举算法保证了服务的一致性。举个例子如果在Zookeeper集群中出现网络分区那么集群将会分裂成多个部分每一部分都会尝试进行新的领导选举。只有当某一部分节点数量超过半数时它才能选出新的领导并继续对外提供服务。 Eureka 与此相反Eureka则是设计成高可用性Availability优先。Eureka可以很好地处理网络分区问题它的设计哲学是即便在服务之间出现严重的网络故障每个服务实例仍然能够被客户端发现并使用。Eureka的自我保护模式使得在网络分区问题发生时不会立即注销服务列表中的节点而是等待一段时间直到网络稳定。这样做虽然能增加可用性但却可能因为没有及时剔除失效的服务实例而返回过时的信息。 一个具体的例子是如果Eureka Server与Eureka Client通信出现问题如网络延迟Server不会立即从注册表中移除这个Client而是等待Client恢复并发送心跳。这样做的好处是即使有少量的服务器或客户端无法进行通信整个系统仍然是可用的。
出Zookeeper保证的是CP而Eureka则是AP。在选择使用Zookeeper还是Eureka时需要根据实际业务需求和架构特点做出决策。如果你的服务对一致性要求极高而且可以接受因网络分区导致的服务不可用那么Zookeeper可能是更好的选择。如果你需要的是高可用的服务发现机制并且可以容忍服务状态的短暂不一致那么Eureka是更合适的选项。
3、搭建 Eureka 注册中心 Eureka Server作为服务发现的关键组件负责存储服务信息和处理服务注册与发现。下面我们将详细介绍如何从零开始搭建Eureka Server。
3.1 POM 文件 首先需要创建一个Spring Boot工程并在pom.xml文件中添加Eureka Server的依赖。你可以使用Spring Initializr来快速生成项目结构。
dependencies!-- Eureka Server --dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-netflix-eureka-server/artifactId/dependency!-- Spring Boot Starter Web用于搭建基于Web的应用 --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency!-- 测试依赖可以根据需要选择添加 --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactIdscopetest/scope/dependency
/dependencies此外你还需要在pom.xml中指定Spring Cloud的版本通过spring-cloud-dependencies来保证各个组件版本的兼容性
dependencyManagementdependenciesdependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-dependencies/artifactIdversion${spring-cloud.version}/versiontypepom/typescopeimport/scope/dependency/dependencies
/dependencyManagementpropertiesspring-cloud.versionGreenwich.SR1/spring-cloud.version
/properties这里${spring-cloud.version}要替换为当前稳定的Spring Cloud版本号。
3.2 配置文件 application.yml 在src/main/resources/目录下创建或编辑application.yml配置文件添加Eureka Server的基础配置
server:port: 8761 # Eureka服务端口eureka:client:registerWithEureka: false # 表示不向注册中心注册自己fetchRegistry: false # 表示自己就是注册中心我的职责就是维护服务实例不需要去检索服务service-url:defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ # 设置与Eureka Server交互的地址instance:hostname: localhost # 可以是其他的域名或者IP3.3 启动类 在你的Spring Boot应用中创建一个主类使用EnableEurekaServer注解来启动一个服务注册中心。
package com.example.eurekaserver;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;SpringBootApplication
EnableEurekaServer // 启用Eureka Server功能
public class EurekaServerApplication {public static void main(String[] args) {SpringApplication.run(EurekaServerApplication.class, args);}
}这段代码会启用一个Eureka Server实例允许其他服务向它注册。
3.4 访问 Eureka Server WEB 服务管理平台 一旦启动了Eureka Server你可以在浏览器中输入http://localhost:8761来访问Eureka的管理界面。在这个界面你能看到所有注册的服务实例以及它们的状态信息。
Eureka的Web界面提供了实时的服务注册监控你可以看到哪些服务已经注册进来以及它们的健康状态。
以上步骤是搭建一个单节点的Eureka Server的基本过程。 在生产环境中为了确保高可用性通常会搭建Eureka Server集群我们会在后续的小节中讨论如何搭建和配置Eureka Server集群。
接下来我们将深入了解Eureka Server的服务管理平台以及如何通过它来监控服务实例的状态。
4、Eureka 服务管理平台介绍 Eureka服务管理平台是Eureka Server自带的一个Web界面它提供了实时的服务注册情况和服务健康状况的监控。
4.1 Eureka Server 服务管理平台访问预览 一旦Eureka Server启动你可以通过在浏览器地址栏输入http://localhost:8761这里的地址和端口根据你实际的配置决定来访问Eureka服务管理平台。这个界面简洁直观提供了关于当前Eureka实例所有必要信息的概览。
由于我这里不能直接上传图片你可以通过项目运行后自行查看界面或者在网络上搜索Eureka Server界面的相关截图这将有助于你获得一个直观的感受。
4.2 System Status 在管理平台的主页上你可以看到System Status区域这通常位于页面的顶部。这里会显示Eureka自身的状态包括
Current time服务器的当前时间。Uptime服务器运行时间。Environment服务器环境信息如配置的profile。Number of CPUs服务器的CPU数量。Total memory服务器的总内存。General runtime info包括JVM版本等运行时信息。
4.3 DS Replicas 如果你配置了Eureka Server集群DS Replicas部分将会显示所有的Eureka Server节点。这些副本节点之间会相互注册保证服务注册信息在整个Eureka集群中是一致的。在这个区域你可以看到其它Eureka Server节点的状态这对于确保高可用性是非常关键的。
4.4 Instances currently registered with Eureka 这个区域显示了所有已注册到Eureka的服务实例以及它们的状态。每个服务下面会列出所有的注册实例包括它们的应用名、IP地址、端口号、运行状态等信息。点击具体的实例你还可以看到更多的细节例如服务的metadata、租约信息等。
4.5 General Info 在General Info部分你可以找到Eureka Server自身的一些信息包括
Eureka version显示Eureka Server的版本号。Started atEureka Server启动的时间。
4.6 Instance Info Eureka Server Dashboard还有Instance Info部分这里提供了每个注册服务实例的详细信息。这些信息有助于管理员了解服务实例的健康状况以及进行问题排查。
Eureka服务管理平台提供了丰富的信息和操作界面管理员可以利用这些信息来监控服务的健康状态确保系统的稳定运行。 在实际的生产环境中还可以结合额外的监控工具比如Spring Boot Admin等来更全面地监控系统状态。
5、搭建高可用集群 在实际生产环境中为了保证Eureka服务的稳定性和可用性通常会部署Eureka Server集群。这样即使某个Eureka Server节点故障其他节点仍能提供服务注册和发现的功能从而实现高可用。
5.1 在 Eureka 应用中定义多环境配置 为了构建Eureka集群需要为每个Eureka Server节点指定一个独立的配置文件。
5.1.1 application-eureka1.yml 定义第一个Eureka Server实例的配置文件。例如
server:port: 8761eureka:instance:hostname: eureka1.feiz.comclient:service-url:defaultZone: http://eureka2.feiz.com:8762/eureka/fetch-registry: trueregister-with-eureka: true5.1.2 application-eureka2.yml 定义第二个Eureka Server实例的配置文件。例如
server:port: 8762eureka:instance:hostname: eureka2.feiz.comclient:service-url:defaultZone: http://eureka1.feiz.com:8761/eureka/fetch-registry: trueregister-with-eureka: true这两个配置文件中的defaultZone属性指向了对方的服务注册中心从而形成一个互相注册的关系。
5.2 打包工程 我们需要将Eureka Server项目打包成jar包以便可以在服务器上运行。
5.2.1 POM 依赖 在pom.xml文件中Spring Boot已经帮我们定义好了打包的插件所以一般不需要额外定义。
5.2.2 打包 在项目根目录下运行Maven命令进行打包
mvn clean package5.2.3 打包结果 打包完成后在target目录下会生成对应的jar文件例如eureka-server-0.0.1-SNAPSHOT.jar。
5.3 上传打包后的 jar 文件到 Linux 系统 使用FTP或SCP等工具将打包好的jar文件上传到两台Linux服务器上。
5.4 设置 Linux 主机域名 在/etc/hosts文件中为两台Linux服务器设置域名解析方便通过域名访问
# Example /etc/hosts entries
192.168.1.10 eureka1.feiz.com
192.168.1.11 eureka2.feiz.com5.5 启动 Eureka 有了jar文件和配置文件我们就可以在服务器上启动Eureka Server的实例了。
5.5.1 使用 java 命令启动 在Linux服务器上通过指定配置文件的方式启动Eureka Server实例
java -jar eureka-server-0.0.1-SNAPSHOT.jar --spring.profiles.activeeureka1
java -jar eureka-server-0.0.1-SNAPSHOT.jar --spring.profiles.activeeureka2这里的--spring.profiles.active参数用来指定活动的配置文件。
5.5.2 脚本启动 为了方便管理我们可以编写启动脚本来控制Eureka Server的启动、关闭等操作。例如创建一个start-eureka-server.sh的脚本内容如下
#!/bin/bash
nohup java -jar eureka-server-0.0.1-SNAPSHOT.jar --spring.profiles.active$1 eureka-server.log 21 然后就可以用这个脚本来启动Eureka Server
./start-eureka-server.sh eureka1
./start-eureka-server.sh eureka2搭建Eureka高可用集群的步骤就是这样的有了Eureka集群即使某个节点宕机其他节点还能继续提供服务从而确保了整个微服务架构的高可用性。
接下来我们可以通过在客户端配置这些Eureka Server地址将客户端注册到集群这样客户端就能享受到高可用服务发现的好处了。
推荐几个 Spring Cloud 学习的文章
01、Feign的核心概念及入门案例02、Feign原生注解03、Spring Cloud 2020.x 集成Open Feign04、集成OkHttp及连接池配置详解05、集成Ribbion实现客户端负载均衡06、Ribbion配置类源码分析07、Ribbion负载均衡策略源码分析08、Feign超时配置详解及源码分析09、Fegin 开启日志打印、Gzip压缩10、Feign 、Ribbon 重试机制源码分析…
6、集群原理
6.1 服务注册 当一个微服务实例启动时它会向Eureka Server注册自己的信息比如IP地址、端口号、健康指标等。这些信息会存储在Eureka Server的内存中。
6.2 服务同步 在集群环境下每个Eureka Server节点都会存有一份服务实例的注册信息。为了保持这些信息的一致性Eureka Server节点之间会相互复制replicate这些信息
当一个服务实例在Eureka Server A上注册时Server A会将这个信息同步给其他的Eureka Server节点比如Server B。这个同步过程是通过复制一个注册操作的请求到集群中的其它节点来完成的。通过这样的方式每个节点都有机会获取最新的注册信息保证了服务注册的一致性。
6.3 心跳检测 服务实例会定期向Eureka Server发送“心跳”即续约默认情况下每30秒一次以告知Eureka Server它还活着。
如果Eureka Server在一定时间内没有接收到某个服务实例的心跳它会在其注册表中将这个实例剔除。但在自我保护模式下为了应对因网络问题导致的心跳失败Eureka Server不会立即剔除实例会有一个宽限期。
6.4 自我保护模式 Eureka Server能够进入自我保护模式。在这种模式下Eureka Server会保护注册表中的信息不会删除未发送心跳的服务实例
这种做法可以在网络分区故障发生时阻止Eureka Server错误地剔除大量服务实例。当网络稳定时Eureka Server会自动退出自我保护模式。
6.5 故障转移 当一个Eureka Server节点宕机后由于服务注册信息已经同步到了其他节点微服务实例可以自动将注册请求转移到其他健康的Eureka Server节点上
这实现了故障转移和服务的高可用。客户端通常会有一个Eureka Server的地址列表当尝试与一个节点通信失败时它会尝试联系列表中的下一个节点。
当然可以。针对第四点6.6 读写操作的分离的内容我们可以展开解释使其更加详尽和容易理解
6.6 读写操作的分离
在Eureka Server集群中读写分离的概念对于维护整个系统的高性能和高可用性至关重要。这里的“读”主要指客户端从Eureka获取注册服务列表的操作而“写”则指服务实例注册和续约的操作。 写操作对于注册和续约这样的写操作它们必须在集群中的每个节点上进行复制。当一个服务实例向Eureka Server注册时这个注册信息会被同步到集群中的所有其他节点。这种复制确保了即使某个节点发生故障服务实例的注册信息仍然可以在其他节点上被访问到从而保持系统的一致性。 读操作相比之下读操作则可以从任何一个Eureka Server节点获取无需跨节点复制。这意味着任何时候当客户端需要获取服务列表时它都可以快速地从任一可用的节点获得数据而不需要等待跨节点之间的信息同步。这减少了单个节点的负担并显著提高了系统的响应速度。
重要性
性能提升读写分离可以显著减少因写操作复制而产生的网络负载因此提升了整个集群的性能。减少瓶颈通过允许读操作在任一节点上执行它避免了所有请求都集中在单个节点上这样可以有效分散流量减少了单点瓶颈的风险。弹性扩展读写分离使得Eureka Server集群能够更加弹性地扩展。根据读写负载的变化可以灵活地增加或减少节点数量以实现最优的资源利用。
注意事项
数据一致性虽然读操作可以从任一节点获得但Eureka Server会通过复制机制确保每个节点的数据最终一致。故障转移策略集群中的节点必须要有故障转移机制确保当一个节点不可用时其它节点能够接管它的职责保持服务的连续性。
通过上面这些机制Eureka集群确保了即使在某个Eureka Server节点出现故障的情况下整个服务发现框架也能够继续正常工作不会影响到微服务的正常运行。 这就是为什么即使在分布式系统中常常出现的网络分区、通信故障、服务故障等问题发生时Eureka仍然能够提供稳定的服务发现功能。
7、Eureka 优雅停服 在微服务架构中服务的可用性至关重要。但有时候也需要对服务进行升级或者维护这时候如果能够优雅地停止服务就可以避免对用户造成过多的影响同时也能保护服务不受损害。
7.1 自我保护模式 Eureka Server的自我保护模式是为了应对网络不稳定的情况。在网络状况不佳时Eureka Client可能无法及时地向Server发送心跳。如果Eureka Server在这种情况下仍按常规流程剔除没有发送心跳的Client那么可能会导致大量服务实例被错误移除造成“脑裂”问题。 所以在自我保护模式下Eureka Server宁可保留所有服务实例也不去主动剔除任何一个即使它们已经很长时间没有发送心跳了。
7.2 为什么要自我保护 这个模式能保证在网络不稳定导致Eureka Client和Server之间的通信出现问题时服务注册信息不会被轻易丢掉。这样就可以防止因为临时的网络问题而导致整个微服务架构不稳定。自我保护模式保证了在不可靠的网络环境下服务注册表的稳定性和可靠性。
7.3 关闭自我保护 有些情况下我们可能希望关闭自我保护模式特别是在测试环境中以确保当一个服务实例真的宕机时它能够被及时从注册表中移除。 要关闭自我保护模式可以在Eureka Server的配置文件中设置:
eureka:server:enable-self-preservation: false关闭自我保护模式后如果Eureka Client在配置的时间内没有向Server发送心跳那么这个实例将会被Server从注册列表中剔除。这确实会提高注册表的准确性但同时也增加了在网络不稳定时误剔除服务实例的风险。
优雅停服是微服务管理中的一个重要环节它能确保服务的升级和维护对用户的影响降到最低。 在实际应用自我保护模式时我们需要根据具体的业务需求和网络环境来权衡是否开启此模式。 通常在生产环境下建议开启自我保护模式以提高微服务架构的稳定性和健壮性。而在开发和测试环境中可以考虑关闭它以便更快地发现并处理服务实例的故障。 我们继续深入讲讲如何进行Eureka的优雅停服以及在整个过程中可能遇到的一些注意事项。 7.4 优雅停服的流程 优雅停服意味着服务在停止之前会完成当前处理的请求并且不再接受新的请求。具体到Eureka Client需要做到以下几点
7.4.1 停止流量转发 在停服之前首先要确保不再有新的流量进入该服务实例。这可以通过在负载均衡器中摘除实例来实现。
7.4.2 服务下线 然后服务实例需要主动向Eureka Server发送下线请求告知注册中心自己将停止服务。
7.4.3 等待处理请求完成 在服务实际停止之前需要等待服务实例完成当前正在处理的所有请求。
7.4.4 停止服务实例 最后当所有请求都处理完成后可以安全地停止服务实例。
在Spring Cloud中可以通过Spring Boot的Actuator来实现优雅停服。Actuator暴露了一个/actuator/shutdown端点可以通过调用这个端点来优雅地关闭服务。为了能够使用这个特性需要在application.yml或application.properties文件中添加以下配置
management:endpoints:web:exposure:include: shutdownendpoint:shutdown:enabled: true在应用程序准备停止时可以发出一个HTTP POST请求到/actuator/shutdown端点。这将触发上述流程优雅地关闭服务实例。
7.5 处理停服时遇到的问题 在进行优雅停服时可能会遇到一些问题例如
服务调用链中断如果服务实例在处理请求时依赖于其他服务需要确保这些依赖服务在停服过程中仍然可用。超时设置停服过程中需要合理设置超时时间以确保服务实例有足够的时间完成正在处理的请求。数据一致性如果服务实例在处理事务请求需要确保事务能够正确提交或回滚避免数据不一致。
在实际操作中通常需要先在测试环境中模拟停服流程确保各个环节都能够正确执行然后再在生产环境中实施。这样做可以最大限度地减少停服给用户带来的影响并确保服务的稳定性和数据的一致性。
在微服务架构中优雅停服是一项重要的技能。正确地执行优雅停服不仅能够保护正在运行的业务流程也是保障服务质量和用户体验的关键。 实践中需要结合具体的业务特点和技术环境来制定详细的停服策略以确保服务平稳过渡到新的状态。
7.6 服务恢复策略
搞定优雅停机之后咱们看看停机后的服务恢复策略以及在服务停机期间如何保持业务连续性,这个是挺重要的毕竟服务总得起来业务也不能停。
当服务需要重新上线时有以下几个步骤可以确保服务的平稳恢复
7.6.1 服务实例重启 将服务实例重新启动并确保所有的配置项都是最新的。
7.6.2 注册到Eureka 启动时服务实例会自动注册到Eureka Server。确保服务实例的健康检查是通过的服务实例能够正常提供服务。
7.6.3 服务同步 Eureka Client会定期从Server拉取服务注册列表确保本地的信息是最新的。
7.6.4 流量逐步切换 在确保服务实例稳定运行后可以通过负载均衡器逐步将流量切换到新的服务实例上避免流量突增对新实例造成冲击。
7.7 业务连续性策略 在服务停机期间为了保持业务的连续性可以采取以下措施
7.7.1 服务降级 在服务无法正常提供时可以启用服务降级策略比如返回一个默认值或者从缓存中获取数据。
7.7.2 流量切换 如果是计划内的停机可以提前将流量切换到其他地理位置的服务实例或者是切换到备份服务上。
7.7.3 用户通知 对于长时间的停机合理的用户通知也是很必要的。提前通知用户减少用户的困扰。
7.7.4 监控和报警 确保有监控系统持续监控服务的状态一旦服务恢复或出现异常及时报告。 推荐几个 Spring Cloud 学习的文章
01、Feign的核心概念及入门案例02、Feign原生注解03、Spring Cloud 2020.x 集成Open Feign04、集成OkHttp及连接池配置详解05、集成Ribbion实现客户端负载均衡06、Ribbion配置类源码分析07、Ribbion负载均衡策略源码分析08、Feign超时配置详解及源码分析09、Fegin 开启日志打印、Gzip压缩10、Feign 、Ribbon 重试机制源码分析…
搞定了这些就算服务需要停机升级或者维护对用户的影响也能降到最低。重点是不管停不停机服务质量和用户体验始终是咱们要维护的。
最后说一句(求关注求赞别白嫖我)
最近无意间获得一份阿里大佬写的刷题笔记和面经一下子打通了我的任督二脉进大厂原来没那么难。
这是大佬写的 7701页的阿里大佬写的刷题笔记让我offer拿到手软
本文已收录于我的技术网站 小郑说编程有大厂完整面经工作技术架构师成长之路等经验分享
求一键三连点赞、分享、收藏
点赞对我真的非常重要在线求赞加个关注我会非常感激小郑说编程
