营销网站建设品牌企业济南市扬尘治理官网

营销网站建设品牌企业,济南市扬尘治理官网,保定网站建设公司排名,房产网站电商怎么做Spring Cloud常规八股关于微服务你是怎么理解的微服务的核心思想是 单一职责原则#xff0c;即每个服务专注于完成一个特定的任务#xff0c;确保服务的高内聚性和低耦合性。可以针对不同服务可以进行不同技术或者语言选型#xff0c;这会使得开发、部署、维护更…Spring Cloud常规八股关于微服务你是怎么理解的微服务的核心思想是 单一职责原则即每个服务专注于完成一个特定的任务确保服务的高内聚性和低耦合性。可以针对不同服务可以进行不同技术或者语言选型这会使得开发、部署、维护更加灵活和高效。服务之间的通信一般使用 RPC远程调用相比单体应用会带来网络的开销。它的特点是独立部署减少了系统整体部署的复杂度不同的微服务可以使用不同的技术栈可以灵活扩展并且容错性高。如何对微服务集群做监控和报警的1Prometheus: Prometheus 是一个开源的监控系统其数据模型较为灵活且内置了数据查询语言 PromQLPrometheus Query Language提供了对时间序列数据丰富的查询聚合以及逻辑运算能力的支持。使用时可以实时选择和汇总时间序列数据然后它还可以通过 Http 协议定期拉取微服务的指标数据并且提供了可扩展的存储以及查询功能。2Grafana Gfafana 是一个开源的可视化仪表板工具可以与 Prometheus 结合使用创建实时和历史数据的仪表盘。并且 Grafana 提供了丰富的图表和可视化选择可以帮助用户更好地查看当前微服务集群的性能和状态。也可以利用 ELFK 套件来实现监控Elasticsearch用于存储和检索日志信息。Logstash/Fluentd采集日志数据发往 es。Kibana可视化分析工具展示查询数据。ElasticSearchElasticSearch 是一个分布式搜索和分析引擎可以存储和索引大量的数据日志他提供了快速的搜索和聚合功能实现大规模的日志数据高效处理。LogstashLogstash 是一个用于采集、过滤和转发日志数据的工具。它可以从文件、消息队列、网络等多种渠道实现日志数据的采集并对数据进行处理以及转换最后发到 ElasticSearch 进行存储和索引。KibanaKibana 是一个日志数据可视化以及分析的工具它提供了丰富的图表以及仪表盘工具可以帮助用户实现日志数据的实时监控和分析。SOA、单体应用、微服务架构有什么区别单体应用其对外是一个整体所有的功能都打包在同一个应用上这种架构风格方便测试和容易部署容易发生单体故障所以灵活性和可维护性并不是很高。SOA它是一种面向服务的架构风格将系统划分为多个独立的服务。这些服务可以通过网络调用并且可以实现跨平台、跨语言进行交互。微服务它是在 SOA 的基础上演变而来的微服务架构进一步将系统为多个小型、独立的服务每个服务都是一个单独的应用程序可以采用独立部署的方式运行和扩展。缺点是开发与运维成本增加基础设施成本增加。相较于单体应用复杂性增加同时性能监控与故障排除都会更加困难因为涉及到很多个服务。微服务的通讯方式有哪些最常见的就是远程调用即 RPC 调用它通过将方法封装成通用网络数据包实现不同进程间的传输从而实现不同服务之间的调用。RPC 调用其实又包含了基于 TCP 自定义协议的调用和 HTTP 调用比如 Spring Cloud OpenFegin 用的就是 HTTP 调用而 Dubbo 默认用的就是自定义的 dubbo 协议调用。其他的通讯方式常见的还有消息队列一个服务往 Broker 发送消息另一个服务只要订阅这个主题就能从 Broker 获取这个消息。还有就是直接通过 HTTP 调用了直接利用 HttpClient 填入对方的网址进行调用。分布式和微服务有什么区别分布式系统它是由多台计算机或多节点组成的系统各阶段之间通过网络进行通信和协作共同完成一个或多个共享的任务分布式的各个节点其实目标是一致的。微服务架构它是一种服务的架构风格主要是为了把一个大而全的服务拆分成多个独立、松耦合的服务单元为了让这些服务单元可以独立部署、运行和管理。微服务架构是如何运行的客户端这个主要是来自不同设备的不同用户请求。身份提供商这个是验证用户身份的工具即鉴权一般客户端在访问 API 网关之前都需要实现这一步通过用户提供商获取安全令牌。API 网关主要用于处理客户端的请求并把请求路由转发到对应的微服务。静态服务指容纳系统的所有内容。管理指微服务的配置、监控、运维等服务治理。服务发现准确来说是服务的注册与发现用于服务间的通信及查找。远程服务即驻留在 IT 设备网络上的远程访问信息。Spring Cloud Config 是什么Spring Cloud Config 是 Spring Cloud 生态系统中的一个关键组件它的主要作用是为分布式系统提供集中化的外部配置管理通过使用它开发者能够在不同的环境中对应用程序的配置进行集中管理和动态更新而不需要在每个服务实例中单独维护配置文件。集中化配置将所有微服务的配置文件统一存放在一个中心位置如 Git 仓库方便进行管理和维护。环境隔离支持为不同的环境如开发、测试、生产提供不同的配置并且能够根据环境自动切换配置。动态刷新在运行时可以动态刷新配置无需重启服务保证系统的高可用性。版本控制由于配置文件存储在版本控制系统如 git) 中因此可以跟踪配置的变更历史便于进行回滚操作。Config Server: 这是配置中心的核心它负责从配置仓库如 Git、SVN 或本地文件系统中获取配置信息并以 HTTP 接口的形式将这些配置提供给客户端。它是一个独立的 Spring Boot 应用需要添加spring-cloud-config-server依赖支持多种后端存储包括 Git、SVN、本地文件系统等可以通过配置spring.cloud.config.server.uri指定 git 仓库的地址。Config Client这是各个微服务客户端它们在启动时会从 Config Server 获取配置信息并将其注入到应用程序的环境中。微服务客户端需要添加spring-cloud-config-client依赖通过配置spring.cloud.config.uri指定 Config Server 的地址客户端会根据应用名称spring.application.name) 和环境spring.profiles.active) 来获取对应的配置。配置规则在 Git 仓库中配置文件遵循特定的命名规则。{application}-{profile}.properties(或.yml): 例如user-service-dev.properties表示user-service服务在开发环境下的配置。{application}.properties(或.yml): 这是默认配置会被特定环境的配置覆盖。application-{profile}.properties或.yml)这是全局配置会应用到所有服务。动态刷新配置要实现配置的动态刷新需要配合 Spring Cloud Bus 或 Actuator添加spring-boot-starter-actuator依赖并启用refresh端点。在需要动态刷新的 Bean 上添加RefreshScope注解当配置发生变更并且客户端接收到刷新事件时标注了RefreshScope的 Bean 会重新加载最新的配置。当配置发生变更时通过 POST 请求触发/actuator/refresh端点客户端会重新加载配置。高可用性部署多个 Config Server 实例并使用负载均衡器如 Nginx、Spring Cloud Gateway进行负载均衡。对于 Git 仓库可以使用高可用的 Git 服务如 Github、GitLab 或自建 Git 服务器集群。// Config Server 配置 dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-config-server/artifactId /dependency spring: cloud: config: server: git: uri: https//github.com/example/config-repo search-paths: config username: your-username password: your-password server: port: 8888 ​ // 主应用类 SpringBootApplication EnableConfigServer public class ConfigServerApplication { SpringApplication.run(ConfigServerApplication.class, args); } ​ ​ dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-config-client/artifactId /dependency // bootstrap.yml注意是 bootstrap.yml, 不是 application.yml spring: application: name: user-service cloud: config: uri: http://localhost:8888 profile: dev label: masterSpring Cloud 有哪些注册中心CAP 原则在分布式系统中CAP 原则Consistency AvailablityPartition tolerance指出一个系统不可能同时完全满足一致性、可用性和分区容错性通常需要在三者之间进行权衡。一致性Consistency所有节点在同一时间看到的数据一致。可用性Avaliability系统在任意时间都能提供服务。分区容错性Partition tolerance系统能够应对网络分区的发生。CP一致性、分区容忍性Consul、Zookeeper、EtcdAP可用性、分区容忍性EurekaCP/AP 都有Nacos 两者都有默认情况下是 APEureka通过EnableEurekaServer 和 EnableEurekaClient注解可以轻松实现服务注册中心或服务客户端。开源的服务注册与发现框架属于 Spring Cloud 生态的一部分。支持服务注册、心跳检测、服务下线和服务剔除拥有自我保护机制在网络出现短暂问题时不立即剔除服务可以提升系统的容错性。采用AP 原则即强调系统的可用性和分区容忍性允许短暂的一致性延迟。使用的内存较少适合中小规模的服务注册中心部署。基于客户端的心跳续约机制服务实例需要定期向 Eureka Server 发送心跳心跳的默认时间间隔是 30 s如果 Server 在 90 s 内未收到心跳Eureka Server 根据心跳的情况决定是否剔除服务实例。自我保护机制当 Eureka Server 在短时间内检测到大量服务实例不可用时它会启动自我保护机制暂时停止剔除失效的实例以防止因为网络问题或短暂的系统波动导致大量服务下线。当网络恢复正常Eureka Server 接收到的心跳数恢复到期望值后自我保护机制会自动关闭恢复正常的服务剔除逻辑。当 Eureka Server 接收到的心跳数低于期望值心跳率的 85%时自我保护机制会自动开启在此期间Eureka Server 仍然会接收新的服务注册和查询但不会移除失效实例。优点是提高系统容错能力避免数据丢失。缺点是短时间内可能提供错误的服务列表。自我保护机制在网络恢复正常后会自动关闭但这个过程中可能会延长不可用实例。Consul它支持多数据中心并且自带KV 存储和健康检查功能。可以定期检测服务的状态并自动剔除失效实例包括HTTP、TCP、脚本检测等。拥有内置的健康检查功能可以定期检查服务状态并剔除失败的实例。提供DNS和HTTP API两种服务发现方式便于服务的注册和查询。支持CP 模型即更注重数据一致性使用Raft 协议来保证注册数据的一致性。Consul 的 Server 节点使用Raft 共识算法来确保集群中的数据一致性并使用Gossip 协议进行节点间的状态传播和故障检测Gossip 协议是一种去中心化的通信协议可以在节点之间的传播健康检查状态、服务列表等信息。LAN Gossip:用于同一个数据节点中心内的节点间通信确保各个节点状态的同步。WAN Gossip: 用于不同数据中心之间的节点状态传播实现跨数据中心的服务状态同步。AgentClient Agent: 部署在每个服务节点上负责向 Consul Server 发送服务注册和健康检查信息Client Agent 是无状态的所有请求会被转发给 Server 节点。Server Agent: 是 Consul 集群的核心负责存储集群的状态信息并对外提供服务注册健康检查和配置管理等功能。它们之间 使用Raft 协议来保证数据一致性。Zookeeper适用于需要元数据管理和一致性协调的系统如 Hadoop 集群、HBase 集群中的元数据管理。由于其强一致特点适合对一致性要求严格的场景如分布式消息队列Kafka、分布式锁、分布式数据库等。它的一致性保障机制使得其性能在高并发场景下可能受到影响特别是在进行大量写操作时。建议使用奇数个节点来保证数据的可靠性。采用临时节点ephemeral nodes来实现健康检查当客户端与 Zookeeper 的连接断开时临时节点会被删除从而标记服务失效。Nacos支持AP 和 CP模型的切换用户可以根据业务场景选择不同的模型。支持 DNS-F 和 HTTP 的服务发现方式适合不同类型的微服务架构。提供强大的配置管理能力可以与服务发现功能配合使用实现配置的动态更新。通过 Nacos 集群部署来应对高并发的服务注册需求支持多种注册数据的持久化方式如嵌入数据库、MySQL。支持主动健康检查和被动检测两种方式通过 API 可以灵活配置服务的健康检测策略。Etcd它是Kubernetes的默认注册中心并且是一个高可用的键值存储数据库最初是由CoreOS开发的主要用于分布式系统的协调和服务发现它是Kubernetes的默认注册中心。基于CP模型使用Raft 协议保证数据的一致性。适合对一致性要求高的分布式系统和容器编排系统。提供强大的键值存储功能可以用于配置管理、分布式锁、服务注册等多种场景。Spring Cloud 如何实现服务注册SpringCloud 服务注册和发现需要依赖其他注册中心。项目在启动时会自动将本身服务的服务名、IP、端口信息通过引入的注册中心依赖注册到服务注册中心的服务端。服务自动注册SpringCloud 提供的服务自动注册规范其实就是三个接口只要注册中心实现这些接口就能够在服务启动时自动注册到注册中心。Registration 是 SpringCloud 提供的一个接口继承了 ServiceInstance 接口public interface Registration extends ServiceInstance { } ​ public interface ServiceInstance { default String getInstanceId() { return null; } String getServiceId(); String getHost(); int getPort(); }从 ServiceInstance 的接口定义可以看出这是一个服务实例数据的封装比如这个服务的 ip 是多少端口号是多少。所以 Registration 就是当前服务实例数据封装封装了当前服务的所在的机器 ip 和端口号等信息。public class NacosRegistration implements Registration, ServiceInstance { public static final String MANAGEMENT_PORT management.port public static final String MANAGEMENT_CONTEXT_PATH management.context-path }服务注册--ServiceRegistry这个接口的作用就是把上面封装的当前服务的数据 Registration 注册通过register方法注册到中心中。public interface ServiceRegistryR extends Registration { void registere(R registration); void deregister(R registration); } ​ public class NacosServiceRegistry implements ServiceRegistryRegistration { private static final String STAUS_UP UP; private static final String STATUS_DOWN DOWN; private static final Logger log LoggerFactory.getLogger(NacosServiceRegistry.class); private final NacosDiscoveryProperties nacosDiscoveryProperties; } ​ Override public void register(Registration registration) { if (StringUtils.isEmpty(registration.getServiceId())) {...} NamingService namingService namingService(); String serviceId registrartion.getServiceId(); String group nacosDiscoveryProperties.getGroup(); Instance instance getNacosInstanceFromRegistration(registration); try { namingService.registerInstance(serviceId, group, instance); log.info(nacos registry, {} {} {}:{} register finished, group, serviceId, instance.getIp(), instance.getPort()); } catch (Exception e) { log.error(nacos registry, {} register failed...{},, serviceId, registration.toString(), e); // rethrow a RuntimeException if the registration is failed rethrowRuntimeException(e); } }服务自动注册--AutoServiceRegistrationpublic interface AutoServiceRegistration { }除了 Nacos 是这么实现的常见的比如 Eureka、Zookeeper 等注册中心在整合 SpringCloud 都是实现上面的三板斧。应用架构演进流程单体多模块模型架构多服务器单应用模型架构我们将原先的 1 个 server 的服务进行了拆分拆出了用户服务订单服务商品服务等等。每个服务里用 4 台机器来实例化并且每个服务还相互关联和调用使得维护成本比之前困难了很多。每个实例服务在启动时都根据自身的名称向服务注册中心写入自己的实例信息如名称、IP、端口。用户服务可以根据订单服务注册的名称从注册中心获取订单服务的详细信息然后根据负载均衡策略选择一个 IP 调用即可都不用自己做选择。微服务网关你了解多少呢服务网关可以通过路由转发的方式将请求分发到不同的服务实例上也可以结合注册中心实现负载均衡与流量控制。在之前单体架构时我们实现安全鉴权这个操作放在拦截器中。但是在微服务中我们可以考虑将鉴权功能放在网关进行比如身份认证、授权、加密等功能。网关其实是可以通过缓存一些信息的方式来加快访问速度以及提高性能的即通过缓存一些静态资源来降低响应时间提高访问速度。在网关层可以通过 HTTP 协议转换为 RPC 协议或者 HTTPS 协议因为网关可以统一管理服务的出口以及入口调用因此可以很方便的进行日志监控以及请求统计方便开发者了解服务的使用以及性能状况。常见的 API 网关1Spring Cloud Gateway: 其基于非阻塞的 WebFlux 响应式编程框架充分发挥了响应式编程的优势及特性并且提供了流量染色、路由转发、流量控制、服务熔断等并且与其他微服务组件结合的较好实现服务的注册发现、远程调用等功能。2Nginx它是前后端分离的常用网关其提供了负载均衡、路由转发的功能性能较高不过其修改配置之后需要 Reload 才能使得配置生效跟不上云原生架构的发展。3Zuul: 这个是 Spring Cloud 早期默认的 API 网关它可以实现路由、过滤、负载均衡等功能不过自 2020 年 12 月起Zuul 就已经停止维护了在逐渐被 Spring Cloud Gateway 所取代。4Envoy其底层使用的是 C 语言二次开发的难度大其是 CNCF 云原生基金会的毕业项目比较适合服务网格场景以及多语言架构的部署。Zuul主要用于提供动态路由、监控、弹性和安全等边缘服务功能它本质上是一个基于 JVM 的路由器和服务器端负载均衡器。为什么选择 Gateway 作为网关以前用的比较多的是官方开源的 Zuul后面哪些都差不多停止维护了而官方自己又研发了 Spring Cloud Gateway 所以相比 ZuulGateway 是一个更好的选择。与 Spirng 生态兼容好集成了 Spring Cloud 相关组件如 Eureka、Nacos、Consul 等实现服务的注册与发现。内置限流模块集成 Hystrix 断路器功能实现服务熔断可以对路由指定断言Predicate和过滤器实现动态路由。它可以根据配置条件如 URL、请求方法等实现动态配置。Dubbo 和 Spring Cloud Gateway 的区别是什么呢SpringCloud 的优缺点SpringCloud 是 spring 家族中的一员能够得到更多的原生支持。对一些常见的微服务模式做了抽象如服务发现、动态配置、一步消息等同时包含一些批处理任务、定时任务、持久化数据访问等领域也有涉猎。基于 HTTP 的通信模式加上相对比较完善的入门文档和演示 demo 和 starters。很多微服务实践场景的问题需要用户独自解决比如优雅停机、启动预热、服务测试、再比如双注册、双订阅、延迟注册、服务按分组隔离、集群容错等。当集群规模增长后就会遇到地址推送效率、内存占用等各种瓶颈问题但此时迁移到其他体系却很难实现。欠缺服务治理能力尤其是流量管控方面如负载均衡、流量路由方面能力都比较弱。Dubbo 的优点它是一个 RPC远程过程调用框架主要用于服务之间的通信。它提供高性能的 RPC 调用、负载均衡、服务发现、服务注册、服务治理等功能。提供 Java 外的多语言实现使得构建多语言异构的微服务体系成为可能。在通信协议和编码上选择更加灵活包括 RPC 通信层协议如 HTTP、HTTP/2(Triple、gRPC)、TCP 二进制协议、rest 等序列化编码协议 Protobuf、JSON、Hessian2 等支持单端口多协议。是在超大规模微服务集群实践场景下开发的框架可以做到百万实例规模的集群水平。从设计上突出服务治理能力如权重动态调整、标签路由、条件路由等支持 Proxyless 等多种模式接入 Service Mesh 体系高性能的 RPC 协议编码与实现。完全支持 Spring Spring Boot 开发模式同时在服务发现、动态配置等基础模式上提供与 Spring Cloud 对等的能力。Dubbo 考虑到了企业微服务实践中会遇到的各种问题如优雅上下线、多注册中心、流量管理等。关于令牌桶算法你了解多少呢它是一种流量控制算法用于限制系统的访问频率。该算法允许以固定的速率向 桶 中加入令牌处理请求时消耗桶中的令牌当桶中的令牌耗尽时后续请求会被拒绝或延迟处理。在 Java 中可以使用基于 Guava 的RateLimiter实现令牌算法可以有效控制单用户的访问频率。import com.google.common.util.concurrent.RateLimiter; ​ ​ public class RateLimitExample { // 创建一个 RateLimiter设置每秒生成 5 个令牌 private static final RateLimiter rateLimiter RateLimiter.create(5.0); public stataic void main(String[] args) { // 模拟请求处理 for (int i 0; i 10; i) { // 请求获取令牌 rateLimiter.acquire(); // 处理请求 System.out.println(Request i processed); } } }令牌桶算法工作原理1令牌生成系统以固定的速率生成令牌令牌被放入桶中。生成的速率可以根据需求进行配置例如每秒生成一定数量的令牌。2令牌存储桶中可以存储一定数量的令牌这个数量被称为 桶容量 或 最大容量。当桶满时多余的令牌将会被丢弃。3请求处理每当一个请求到达系统时需要从桶中取出一个令牌。如果桶中有足够的令牌允许请求通过如果没有足够的令牌请求会被拒绝或者等待令牌的生成。4速率控制由于令牌是以固定速率生成的因此系统能够控制请求的速率。例如如果每秒生成 10 个令牌并且桶的容量为 100那么系统每秒最多允许处理 10 个请求但如果有更多的请求到达可以在桶中缓存令牌。通过调整令牌的生成速率和桶的大小可以灵活地控制流量速率和突发流量的处理能力。注意事项如果桶的容量设置过小可能会导致无法处理正常的突发流量如果设置过大则可能会积累过多的流量超出系统的处理能力。 令牌生成速率直接影响系统的处理能力如果速率设置过低可能无法满足用户的请求如果速率设置过高可能会导致系统负担过重。 在分布式系统中时间同步问题可能影响令牌的精确生成导致限流效果不稳定。对于配置中心你了解过吗介绍一下它实现了配置的统一管理和动态刷新当配置信息发生变化时配置中心可以自动通知服务实例进行配置更新这样就可以实例无需重启即可应用最新的配置。常见的配置中心Spring Cloud Config: Spring 提供的分布式配置管理工具支持从 Git、SVN 等版本控制系统加载配置。没有原生的推送机制需要借助消息队列等外部系统实现。Nacos: 阿里巴巴的配置管理和服务发现工具既支持配置中心功能又能作为注册中心使用。1.x 版本为长轮询2.x 版本基于 gRPC (HTTP/2) 实现的长连接。Zookeeper: Zookeeper 是一个开源的分布式协调服务和 Nacos 一样其既可以作为注册中心又可以作为配置中心。它是基于 TCP 协议的长连接。Zookeeper 和 Etcd 更偏向于分布式协调服务支持配置管理但在易用性和界面操作上不如 Nacos 友好。Nacos 提供了更好的 API 和管理页面易于上手。配置中心如何实现动态更新长连接它是一种基于 TCP 或 WebSocket 协议的连接方式在建立连接后客户端和服务器之间可以持续进行数据的双向传输而无需每次都重新建立连接。长连接的典型实现是 WebSocket 或 gRPC能够实现实时的推送。当客户端与服务器建立一个持久的连接该连接保持打开状态。当服务器检测到配置变化时立即通过这个连接向客户端推送变更信息客户端即时接收和处理更新。连接会一直保持直到手动关闭或由于网络中断等因素断开。优点是实时性强服务器可以即时推送更新无需频繁建立连接减少了连接开销。缺点长连接需要消耗更多的系统资源并且对网络环境的要求较高断线重连和连接管理需要额外的处理。长轮询它是一种模拟服务器推送的机制客户端主动向服务器发起请求并保持连接比如保持 30s直到服务器有更新或超时为止。如果有更新服务器会返回新的数据客户端在接收到数据后再次发起新一轮的请求如果等待超时也再次发起新的请求。客户端发送 HTTP 请求给服务器询问是否有配置更新。服务器保持这个请求打开直到检测到配置发生变更或者达到超时时间。如果配置有更新服务器返回更新的配置数据客户端处理并再次发起新请求如果没有更新连接会超时客户端也会重新发起请求。模拟推送的效果但本质上是客户端的连续请求。优点实现相对简单兼容性好适用于大多数网络环境。缺点即便没有配置变化也需要不断发起请求造成资源浪费响应数据取决于轮询频率不够实时。Nacos 配置中心的实现原理你了解多少呢企业内 Nacos 一般会使用数据库如 MySQL来存储配置数据库配置数据库是以键值对的形式存储的每个配置项对应一个数据 IDData Id)并且支持通过 Namespace命名空间、Group组来进行配置的隔离与分类。通过多副本的数据持久化保证配置的高可用性和可靠性。Nacos 客户端维护一个本地缓存客户端接收到配置更新后会自动刷新本地缓存的配置。当与 Nacos 服务器的连接出现异常或服务器不可用时可以从本地缓存中读取配置保证系统的基本运行不受影响。Nacos 配置中心使用gRPC 长连接来实现配置的实时推送Nacos 服务器可以通过这个长连接实时向客户端推送配置更新。客户端在启动时会向 Nacos 注册监听器Listener并维持与服务器的长连接当 Nacos 检测到配置变更时会通知所有相关客户端进行配置刷新。Nacos 的配置管理模型1Namespace用于环境隔离如 dev、test、prod..2Group在同一 Namespace 下进一步对配置进行分组管理方便针对业务模块进行分类。3Data ID每个具体的配置项的唯一标识通过这个 ID 可以精确定位到某个配置可以认为是文件名。Nacos 配置中心的集群高可用Nacos 集群至少需要 3 个节点以确保在某些节点失效时系统仍然可以正常工作。Nacos 采用了Raft 协议来实现节点之间的数据一致性确保配置数据在集群中的一致性。多副本存储Nacos 支持配置的多副本存储通过在集群内多节点存储配置数据的方式避免单节点故障问题提升了服务的可用性。断线重连机制客户端在与 Nacos 服务器的连接断开时会自动尝试重新连接并在连接恢复后同步最新的配置数据保证配置更新不会因网络问题而丢失。Nacos 2.x 的改进gRPC 协议Nacos 2.x 版本相较于 1.x做出了显著的优化将通信机制从 HTTP 长轮询切换为 gRPC。gRPC 基于 HTTP/2 协议支持更高效的双向流通信带来了以下优势。RPC 能够实现真正的长连接支持实时推送减少了 HTTP 轮询带来的延迟和带宽消耗。HTTP/2 支持多路复用客户端与服务器之间可以通过一个 gRPC 连接传输多路数据流降低了连接开销。gRPC 支持数据压缩和流式传输使得在规模配置更新时的传输更为高效。配置灰度发布与版本管理Nacos 提供了灰度发布的能力可以将配置的更新仅应用到部分客户端以降低风险。通常情况下可以先发布到某个 Group 或使用标签Tag指定的客户端确保新配置在小范围内运行稳定后再逐步扩展到所有客户端。当配置发生变更时会生成新的版本旧版本也会保。版本管理可以确保在配置更新出现问题时能够快速回退到之前的版本减少对生产环境的影响。配置的权限管理RBAC基于角色的访问控制Nacos 支持基于角色的权限控制管理员可以为不同的用户分配相应的权限例如读取、写入、删除配置的权限。每个用户只能访问自己权限范围内的配置数据。身份认证Nacos 通过 Token 或 OAuth2 等方式进行用户身份认证确保只有经过认证的用户才能访问配置数据增强了配置的安全性。审计日志Nacos 记录了所有配置操作的审计日志包括配置的创建、修改和删除操作。管理员可以通过日志监控配置变更保证系统的合规性。关于分布式事务你了解多少呢防悬挂防悬挂是指在分布式事务的第一阶段防止在没有对应的 Try 操作的情况下出现 Confirm 或 Cancel 操作这是为了保证事务的正确性和一致性。TCCTry-Confirm-Cancel模式在 TCC 模型中事务分为三个步骤。Try: 资源的预留操作Confirm: 确认操作完成业务逻辑。Cancel取消操作回滚预留资源。如果 Confirm 操作在没有执行过 Try 操作的情况才被调用可能会导致数据不一致。类似地如果 Cancel 操作在没有 Try 操作的情况下被调用也会破坏数据的一致性。为了防止这种情况需要通过某些机制来检测和防止悬挂。Confirm 和 Cancel 操作应该具备幂等性避免多次调用引发问题。在执行 Confirm 或 Cancel 之前可以先检查是否有对应的 Try 操作成功过如果没有则拒绝执行 Confrim 或 Cancel 操作。空回滚它是指在没有执行成功的 Try 操作时Cancel 操作仍然被调用了。Cancel 操作实际上就是 Try 操作的回滚操作如果 Try 操作根本没有成功则 Cancel 操作实际不会对任何资源产生影响这就是空回滚了。它一般发生在分布式系统中的异常情况下比如Try 操作还没执行成功网络就超时了分布式事务协调器可能误认为 Try 操作失败因此会调用 Cancle。Try 操作请求未到达相应的服务端客户端误认为 Try 操作已经失败并发起 Cancel。为了支持空回滚即使 Cancel 操作被多次调用它的效果也只能是执行一次不会对系统产生额外影响。Cancel 操作在发现没有 Try 操作执行成功时不做任何修改直接返回成功状态。防悬挂的目标是防止 Confirm 或 Cancel 操作在没有执行 Try 操作的情况下被调用防止系统出现异常。空回滚则是在没有 Try 操作成功的情况下Cancel 操作被调用了而 Cancel 操作正确处理这种情况并不产生副作用。XA 模式的回滚机制XA 模式基于标准的 XA 协议实现回滚在第一阶段中事务协调器TC向各个资源管理器RM发送预备指令。所有参与的资源在执行操作后暂时不提交而是等待 TC 的最终决策。如果 TC 选择回滚事务它会通知各个 RM 执行ROLLBACK操作。RM 根据数据库内置的 XA 支持来回滚数据确保所有资源恢复到未提交之前的状态。AT 模式的回滚机制在 AT 模式中Seata 的回滚机制依赖于数据库中的undo_log表每当执行数据操作如INSERT、UPDATE、DELETE) 时Seata 的 RM 会在数据库中记录操作前的数据快照并存储在undo_log中这个过程在业务操作的本地事务提交前完成。如果全局事务中任一分支事务失败或者 TM 向 TC 发起了全局回滚请求TC 会通知所有相关的 RM 执行回滚操作。在接收到回滚请求后RM 从undo_log中读取数据的原始状态并将数据恢复到操作前的状态。即使数据库中已经进行了UPDATE或DELETE操作RM 也能根据undo_log中的快照还原原始数据。TCC 模式的回滚机制在 TCC 模式下事务回滚是通过业务实现的Cancel方法来完成的。开发者需要在业务代码中定义Try预留资源、Confirm确认操作、Cancel取消操作三个阶段。当全局事务需要回滚时Seata 会调用对应的Cancel方法来撤销Try阶段中预留的资源。Cancel操作的逻辑由业务代码实现通常是对Try操作的逆过程。SAGA 模式的回滚机制SAGA 模式通过定义每个业务操作的补偿操作来实现回滚每个子事务都有一个对应的补偿操作用于在子事务失败时撤销之前的操作。如果某个子事务执行失败SAGA 模式会按相反的顺序调用之前已完成的子事务的补偿算法从而将整个业务流程回滚到初始状态Seata 分布式事务详解AT模式AT 模式是 Seata 创新的一种非侵入式的分布式事务解决方案Seata 在内部做了对数据库操作的代理层我们使用 Seata AT 模式时实际上用的是 Seata 自带的数据源代理 DataSourceProxySeata 在这层代理中加入了很多逻辑比如插入回滚 undo_log 日志检查全局锁等。第一阶段 Seata 会拦截 SQL在数据更新前记录修改之前的数据。第二阶段负责业务的回滚或提交如果一阶段本地事务提交失败则全局回滚反之全局提交。回滚时用到的就是一阶段的修改之前的数据生成反向 SQL 回滚数据。GlobalTransactional public void purchase(String userId, String commdityCode, int count, int money) { jdbcTemplateA.update(update stock_tb1 set count count - ? where commodity_code ?, new Object[] {count, commodityCode}); jdbcTemplateB.update(update account_tb1 set money money - ? where user_id , new Object[] {money, userId}); }写隔离一阶段本地事务提交前需要确保先拿到全局锁拿不到全局锁不能提交本地事务。拿全局锁的尝试被限制在一定范围内超出范围将放弃并回滚本地事务释放本地锁。两个全局事务 tx1 和 tx2分别对 a 表的 m 字段进行更新操作m 的初始值 1000。tx1 先开始开启本地事务拿到本地锁更新操作 m 1000 - 100 900。本地事务提交前先拿到该记录的全局锁本地提交释放本地锁。tx2 后开始开启本地事务拿到本地锁更新操作 m 900 - 100 800。本地事务提交前尝试拿到该记录的全局锁 tx1 全局提交前该记录的全局锁被 tx1 持有 tx2 需要重试等待全局锁。tx1 二阶段全局提交释放全局锁tx2 拿到全局锁提交本地事务。如果 tx1 的二阶段全局回滚则 tx1 需要重新获取该数据的本地锁进行反向补偿的更新操作实现分支的回滚。此时如果 tx2 仍然等待该数据的全局锁同时持有本地锁则 tx1 的分支回滚会失败分支的回滚一直重试直到 tx2 的全局锁等锁超时放弃全局锁并回滚本地事务释放本地锁tx1 的分支回滚最终成功。因为整个过程全局锁在 tx1 结束前一直是被 tx1 持有的所以不会发生脏写的问题。读隔离在数据库本地事务隔离级别读已提交Read Committed或以上的基础上SeataAT 模式的默认全局隔离级别是读未提交Read Uncommitted)。如果应用在特定场景下必须要全局的读已提交目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的处理。SELECT FOR UPDATE 语句的执行会申请全局锁如果全局锁被其他事务持有则释放本地锁回滚 SELECT FOR UPDATE 语句的本地执行并重试。这个过程中查询是被 block 住的直到全局锁拿到即读取的相关数据是已提交的才返回。出于总体性能上的考虑Seata 目前的方案并没有对所有 SELECT 语句都进行代理仅仅针对 FOR UPDATE 的 SELECT 语句。AT 工作机制示例FieldTypeKeyidbigint(20)PRInamevarchar(100)sincevarchar(100)update product set name GTS where name TXC;一阶段1解析 SQL得到 SQL 的类型UPDATE表product条件Where name TXC等相关的信息。2查询前镜像根据解析得到的条件信息生成查询语句定位数据。select id, name, since from product where name TXC;3执行业务 SQL更新这条记录的 name 为 GTS。4查询后镜像根据前镜像的结果通过主键定位数据。select id, name, since from product where id 1;5插入回滚日志把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录插入到UNDO_LOG表中。{ branchId: 641789253, undoItems: [{ afterImage: { rows: [{ fields: [{ name: id, type: 4, value: 1 }, { name: name, type: 12, value: GTS }, { name: since, type: 12, value: 2014 }] }], tableName: product }, beforeImage: { rows: [{ fields: [{ name: id, type: 4, value: 1 }, { name: name, type: 12, value: TXC }, { name: since, type: 12, value: 2014 }] }], tableName: product }, sqlType: UPDATE }], xid: xid:xxx }6提交前向 TC 注册分支申请product表中主键值等于 1 的记录的全局锁。7本地事务提交业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。8将本地事务提交的结果上报给 TC。二阶段二阶段-回滚1收到 TC 的分子回滚请求开启一个本地事务执行如下操作。2通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。3数据校验拿 UNDO LOG 中的后镜与当前数据进行比较如果有不同说明数据被当前全局事务之外的动作做了修改。这种情况需要根据配置策略来做处理。4根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句update product set name TXC where id ;5提交本地事务并把本地事务的执行结果即分支事务回滚的结果上报给 TC。二阶段-提交1收到 TC 的分支提交请求把请求放入一个异步任务的队列中马上返回提交成功的结果给 TC。2异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。TCC模式它是一种侵入式地分布式事务解决方案需要业务系统自行实现 TryConfirmCancel 三个操作对业务系统有着非常大的入侵性设计相对复杂。整体是两阶段提交模型。全局事务是由若干分支事务组成的分支事务要满足两阶段提交的模型要求即需要每个分支事务都具备自己的一阶段 prepare 行为二阶段 commit 或 rollback 行为在两阶段提交协议中资源管理器RMResource Manager需要提供 准备、提交 和 回滚 3 个操作而事务管理器TMTransaction Manager分 2 阶段协调所有资源管理器在第一阶段询问所有资源管理器 准备 是否成功如果所有资源均 准备 成功则在第二阶段执行所有资源的 提交 操作否则在第二阶段执行所有资源的 回滚 操作保证所有资源的最终状态是一致的要么全部提交要么全部回滚。资源管理器有很多实现方式其中 TCCTry-Confirm-Cancel是资源管理器的一种服务化的实现TCC 是一种比较成熟的分布式解决方案可用于解决跨数据库、跨服务业务操作的数据一致性问题TCC 其 Try、Confirm、Cancel 3 个方法均由业务编码实现故 TCC 可以被称为是服务化的资源管理器。TCC 的 Try 操作作为第一阶段负责资源的检查和预留Confirm 操作作为二阶段提交操作执行真正的业务Cancel 是二阶段回滚操作执行预留资源的取消使资源回到初始状态。基本使用区别在于 AT 模式直接使用数据源代理来屏蔽分布式事务细节业务方需要自行定义 TCC 资源的 准备、提交、和 回滚。public interface TccActionOne { TwoPhaseBusinessAction(name DubboTccActionOne, commitMethod commit, rollbackMethod rollback) public boolean prepare(BusinessActionContext actionContext, BusinessActionContextParameter(paramName a) String a); public boolean commit(BusinessActionContext actionContext); public boolean rollback(BusinessActionContext actionContext); }Seata 会把一个 TCC 接口当成一个 Resource也叫 TCC Resource。在业务接口中核心的注解是TwoPhaseBusinessAction, 表示当前方法使用 TCC 模式管理事务提交并标明了 TryConfirmCancel 三个阶段。name 属性给当前事务注册了一个全局唯一的 TCC bean name同时 TCC 模式的三个执行阶段分别是。Try 阶段预定操作资源Prepare这一阶段所以执行的方法便是被TwoPhaseBusinessAction所修饰的方法如示例代码中的prepare方法。Confirm 阶段执行主要业务逻辑Commit这一阶段使用commitMethod属性所指向的方法来执行 Confirm 的工作。Cancel 阶段事务回滚Rollback这一阶段使用rollbackMethod属性所指向的方法来执行 Cancel 的工作。其次可以在 TCC 模式下使用BusinessActionContext在事务上下文中传递查询参数。xid全局事务 idbranchId分支事务 idactionName分支资源 idactionContext业务传递的参数可以通过BusinessActionContextParameter来标注需要传递的参数。注意如果 TCC 参与者是本地 bean非远程 RPC 服务本地 TCC bean 还需要在接口中添加 LocalTCC 注解比如。LocalTCC public interface TccActionTwo { TwoPhaseBusinessAction(name TccActionTwo, commitMethod commit, rollbackMethod rollback) public boolean prepare(BusinessActionContext actionContext, BusinessActionContextParameter(paramName a) String a); public boolean commit(BusinessActionContext actionContext); public boolean rollback(BusinessActionContext actionContext); }SAGA模式它是 SEATA 提供的长事务解决方案在 Saga 模式中业务流程中每个参与者都提交本地事务当出现某一个参与者失败则补偿前面已经成功的参与者一阶段正向服务和二阶段补偿服务都由业务开发实现。Saga 的实现状态机引擎SEATA 提供的 Saga 模式是基于状态机引擎来实现的机制是通过状态图来定义服务调用的流程并生成 json 状态语言定义文件。状态图中一个节点可以是调用一个服务节点可以配置它的补偿节点状态图 JSON 由状态机引擎驱动执行当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚注意异常发生时是否进行补偿也可以由用户自定义决定可以实现服务编码需求支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能。状态机引擎原理1图中的状态图是先执行 stateA再执行 stateB然后执行 stateC2状态 的执行是基于事件驱动的模型stateA 执行完成后会产生路由消息放入 EventQueue事务消费端从 EventQueue 取出消息执行 stateB3在整个状态机启动时会调用 Seata Server 开启分布式事务并生产 xid然后记录 状态机实例 启动事务到本地数据库。4当执行到一个 状态 时会调用 Seata Server 注册分支事务并生产 branchld然后记录 状态实例 开始执行事件到本地数据库。5当一个 状态 执行完成后会记录 状态实例 执行结束事件到本地数据库然后调用 Seata Server 上报分支事务的状态。6当整个状态执行完成会记录 状态机实例 执行完成事件到本地数据库然后调用 Seata Server 提交或回滚分布式事务。状态机引擎设计Eventing 层次实现事件驱动架构可以压入事件并由消费者端消费事件本层不关心事件是什么消费端执行什么由上层实现。ProcessController 层次由于上层的 Eventing 驱动一个 空 流程引擎的执行state 的行为和路由都未实现由上层实现。StateMachineEngine 层次实现状态机引擎每种 state 的行为和路由逻辑提供 API、状态机语言仓库。状态机的高可用设计状态机引擎是无状态的它是内嵌在应用中。当应用正常运行时图中上半部分状态机执行日志存储在业务的数据库中状态机引擎会上报状态到 Seata Server当一台应用实例宕机时图中下半部分状态机引擎收到事务恢复请求后从数据库里装载日志并恢复状态机上下文继续执行。Seata Server 会感知到并发送事务恢复请求到还存活的应用实例。XA模式利用事务资源数据库、消息服务对 XA 协议的支持以 XA 协议的机制来管理分支事务的一种事务模式。可回滚业务 SQL 操作放在 XA 分支中进行由资源对 XA 协议的支持来保证回滚持久化XA 分支完成后执行 XA prepare同样由资源对 XA 协议的支持来保证持久化即之后任何意外都不会造成无法回滚的情况分支提交执行 XA 分支的 commit分支回滚执行 XA 分支的 rollback整体运行机制XA start/XA end/XA prepare SQL 注册分支XA commit/XA rollback数据源代理XA 模式需要 XAConnection获取 XAConnection 两种方式方式一要求开发者配置 XADataSource方式二根据开发者的普通 DataSource 来创建第一种方式给开发者增加了认知负担需要为 XA 模式专门去学习和使用 XA 数据源与 透明化 XA 编程模型的设计目标相违背。第二种方式对开发者比较友好和 AT 模式使用一样开发者完成不必关心 XA 层面的任何问题保持本地编程模型即可。我们优先设计实现第二种方式数据源代理根据普通数据源中获取的普通 JDBC 连接创建出相应的 XAConnection。但是第二种方法有局限无法保证兼容的正确性。实际上这种方法是在数据库驱动程序要做的事情不同的厂商、版本的数据库驱动实现机制是厂商私有的。综合考虑XA 模式的数据源代理设计需要同时支持第一种方式基于 XA 数据源进行代理。分支注册XA start 需要 Xid 参数这个 Xid 需要和 Seata 全局事务的 XID 和 Branchld 关联起来以便由 TC 驱动 XA 分支的提交或回滚。目前 Seata 的 Branchld 是在分支注册过程由 TC 统一生成的所以 XA 模式分支注册的时机需要在 XA start 之前。把分支注册尽量延后类似 AT 模式在本地事务提交之前才注册分支避免分支执行失败情况下没有意义的分支注册。XA 模式的使用样例场景是 Seata 经典的涉及库存、订单、账户 3 个微服务的商品订购业务。上层编程模型与 AT 模式完全相同只需要修改数据源代理即可实现 XA 模式与 AT 模式之间的切换。Bean(dataSource) public DataSource dataSource(DruidDataSource druidDataSource) { // DataSourceProxy for AT mode // return new DataSourceProxy(druidDataSource); // DataSourceProxyXA for XA mode return new DataSourceProxyXA(druidDataSource); }什么是 SeataSeata (Simple Extensible Autonomous Transaction Architecture) 是阿里巴巴开源的一款分布式事务解决方案主要是为了解决分布式系统中全局事务的一致性问题。事务协调器Transaction Coordinator, TC)TC 负责管理全局事务的生命周期记录全局事务和分支事务的状态并协调全局事务的提交和回滚。TC 是 Seata 的中心控制器所有的分布式事务请求都会通过 TC 进行管理。作用TC 保证各个分支事务在全局事务中的状态一致性它记录每个事务分支的状态信息并在发送异常时向相关分支发送回滚命令。事务管理器Transaction Manager, TM) TM 负责定义全局事务的边界即启动、提交、回滚全局事务。TM 通常嵌入在业务服务中用于向 TC 发起全局事务的创建和提交请求。通过GlobalTransactional注解或 APITM 标记某个业务操作为全局事务。TM 在事务的注册、提交、回滚。RM 的核心作用是对本地数据库进行事务操作并将分支事务的状态通知给 TC。资源管理器Resource Manage, RM)RM 负责管理本地资源如数据库以及分支事务的注册、提交、回滚。RM 的核心作用是对本地数据数据库进行事务操作并将分支事务的状态通知给 TC。在分支事务执行时RM 通过数据库代理层来记录数据记录以便在事务回滚时能够还原数据。同时RM 负责向 TC 注册分支事务并在接受到 TC 的命令时执行数据的提交或回滚操作。TM 向 TC 发起全局事务创建TC 返回 XID。TM 调用业务方法 业务方法执行过程中RM 向 TC 注册分支事务。RM 执行数据库操作并生成回滚日志同时提交本地事务。业务方法执行结束后TM 向 TC发送全局提交或回滚操作。TC 收到请求后通知 RM 执行提交或回滚操作。RM 执行提交或回滚并将结果通知 TC。TC 记录事务状态为提交完成或回滚完成。Seata 的事务执行流程全局事务的创建Transaction Start事务管理器通过在业务方法上使用GlobalTransactional注解标识该方法为全局事务。业务方法调用时TM 会向事务协调器TC发起全局事务的创建请求。TC 负责为该全局事务生成一个唯一的全局事务 IDXID)并返回给 TM。XID 是全局事务的唯一标识用于后续跟踪和管理这个事务的所有操作。分支事务的注册Branch Register)分支事务是全局事务的一部分通常对应业务方法中具体的数据库操作如新增、更新删除。业务方法执行时会调用数据库操作ruINSERT、UPDATE)。Seata 的资源管理器RM通过代理数据库操作来记录数据的前后状态并生成回滚日志。在执行数据库操作之前RM会将该数据库操作注册为分支事务并向TC发起分支注册请求。注册信息包括全局事务IDXID资源 ID 数据库表名分支事务的类型如 AT 模式的 SQL 操作数据的锁定信息用于行锁管理。TC 接收到分支事务注册请求后会记录该分支事务的信息并将注册成功的结果返回给 RM。业务方法的执行与本地事务提交Local Transaction Commit分支事务注册成功后RM执行数据库操作更新数据并将修改的状态保存到数据库中。在完成操作后本地事务提交此时本地事务的数据已经写入数据库但全局事务尚未提交。为了支持回滚回滚日志undo_log也会存储在数据库中以记录数据修改前的状态。全局提交流程如果业务逻辑执行过程中发生异常TM 向TC发起全局回滚请求。TC根据 XID 确认所有分支事务状态正常后向所有参与的RM发送分支提交请求。RM接收到分支提交请求后执行数据库操作的最终提交实际上AT 模式下的数据已经在本地事务阶段提交分支提交请求主要是确认无误。TC收到所有分支提交成功的响应后标记全局事务为提交完成并释放全局锁。全局回滚流程如果业务逻辑执行过程中发生异常TM 向TC发起全局回滚请求。TC向所有参与的RM发送分支回滚请求。RM在接收到分支回滚请求后根据undo_log中记录的数据快照将数据库恢复到执行操作之前的状态确保数据的一致性。TC收到所有分支回滚完成的响应后标记全局事务为回滚完成并释放相关的全局锁。全局事务的结束Transaction End无论是全局事务的提交还是回滚当 TC 确认所有分支事务的操作完成后会标记该全局事务的状态为COMMITEED或ROLLED BACK并在事务日志中记录事务的结束状态。事务结束后Seata 会清理 undo_log 表中的数据防止日志占用过多的数据库存储空间。Seate 的实现原理Seata 的数据一致性保证机制回滚日志机制Undo Log)在 AT 模式下Seata 会在本地事务执行前后记录undo_log即数据操作前的快照信息。回滚时Seata 读取undo_log并恢复数据确保事务回滚操作的正确性。全局锁机制Seata 使用全局锁来管理分支事务对数据库行的并发访问确保同一行数据在同一时刻只能被一个全局事务修改通过 TC 管理全局锁可是防止多事务并发修改同一数据行时冲突。两阶段提交2PCSeata 的事务提交过程遵循两阶段提交协议第一阶段RM 提交本地事务同时记录undo_log注册分支事务到 TC。第二阶段TC 根据全局事务的状态决定提交或回滚并通知所有 RM 执行相应什么是服务雪崩服务雪崩是指在微服务架构和分布式系统中由于某个服务不可用或性能下降导致依赖它的其他服务也出现连锁故障最终整个系统或大部分服务不可用的现象。一个服务的不可用或性能下降可能会导致依赖它的多个上游服务响应变慢甚至出现请求堆积。在服务故障或超时情况下重试机制可能会产生更多的请求进一步加剧下游服务的压力导致故障范围扩大。解决办法熔断器Hystrix、Resilience4j能够在检测到某个服务请求的失败率达到一定阈值时自动中断对该服务的进一步调用从而防止服务继续被拖垮。也可以通过限流令牌桶、漏桶算法和隔离如线程池隔离、信号量隔离限制单个服务的请求数量防止流量过大。还可以提供降级方案确保系统在部分功能不可用时仍能为用户提供基本服务。什么是服务降级服务降级是一种在分布式系统和微服务架构中常用的容错机制用于在系统压力过大或部分服务出现故障时暂时减少或关闭某些不必要的功能从而确保核心功能的正常运行避免系统崩溃。当某个服务的调用时间超过了设定的阈值或者服务多次调用失败时可以触发降级机制返回预设的降级响应。当系统的负载过高如 CPU 使用率、内存占用率等时可以主动降级某些非核心功能释放系统资源确保核心业务的正常运行。如果下游依赖服务不可用或者响应时间过长可以通过降级机制返回缓存数据或默认数据避免请求继续传播。解决办法基于Hystrix或Resilience4j系统可以在HystrixCommand注解中指定fallbackMethod当服务调用失败或超时时直接执行降低方法返回预设的响应。或者当服务不可用时直接返回最近一次的缓存数据保证用户体验的稳定性。也可以当系统流量超过某个阈值时对部分非核心请求进行限流或直接拒绝用来保护核心服务的可用性。Sentinel它是阿里巴巴开源的服务限流降级框架提供流量控制、熔断降级、系统自适应保护等功能。与 Spring Cloud Alibaba 生态集成良好适用于国内市场功能丰富易于配置。Hystrix它是 Netflix 开源的熔断器和降级框架通过HystrixCommand主机可以方便地实现服务地降级逻辑适用于 Spring Cloud 的应用中用来服务降级和熔断处理。同时提供实时的仪表盘和可视化的监控界面。Resilience4j它是一个轻量级的容错框架、支持熔断、限流、降级等功能采用函数式编程风格适合与 Spring Boot 2.x 集成它更适合在新的微服务项目中使用。Sentinel 与 Hystrix 的区别是什么呢Sentinel 支持多种流量策略比如基于 QPS、线程数、并发连接数等多种指标。支持通过 API 动态配置流量规则以及熔断规则并且可以根据服务的实际情况进行动态调整。支持粒度更小支持对任意资源比如代码段、url、接口等实现自定义流量控制规则比如熔断、限流、降级等操作。Sentinel 限流的核心组件它的核心限流逻辑是通过Slot Chain来实现的当请求进入时Slot Chain 会根据限流规则检查当前请求是否可以通过如果某个槽位如流控槽检查到请求超过了设定的限流阈值则会触发限流操作。Sentinel 使用 Statistic Node 来记录每个资源的请求统计信息包括通过数、阻塞数、QPS、响应时间等为限流决策提供了数据支持帮助 Flow Slot 在限流时做出精确的判断。Flow Slot 是 Slot Chain 中负责流控的部分它会根据限流规则中的 QPS 阈值或并发数限制判断是否允许请求通过。Sentinel 是怎么实现集群限流的Sentinel 支持对多个 Token Server 进行配置实现多 Token Server 模式从而避免单点故障。多个 Token Server 可以对令牌请求进行负载均衡提高系统的可靠性。当 Token Server 出现故障时可以自动切换到其他可用的 Token Server以保证集群限流的持续性。流程如下当一个服务实例Token Client有请求进来时它会首先向 Token Server 发送一个令牌申求。Token Server根据预设的限流规则判断当前请求是否可以通过并返回结果给Token Client如果请求获得了令牌Token Client 就允许继续处理该请求。如果未获得令牌则根据设定的限流策略如直接拒绝、排队等待等进行相对应处理。关于限流你了解多少呢它是指的是限制到达系统的并发请求数使得系统能够正常的处理部分用户的请求来保证系统的稳定性。它需要在用户体验和系统稳定之间做平衡即我们常说的trade off。计数限流优点简单粗暴单机在 Java 中可用 Atomic 等原子类、分布式就 Redis incr。缺点假设我们允许的阈值是 1 万此时计数器的值为 0当 1 万个请求在前 1 秒内一股脑儿的都涌进来这突发的流量可是顶不住的。固定窗口限流请求次数小于阈值允许访问并且计数器 1请求次数大于阈值拒绝访问这个时间窗口过了之后计数器清零。固定窗口临界问题虽然窗口内的计数没有超过阈值但是全局来看来 0.55s - 1.05s 这 0.5 s 内涌入了 200 个请求这其实对于阈值是 100/s 的系统来说是无法接收的。滑动窗口限流它除了需要引入计数器之外还需要记录时间窗口内每个请求到达的时间点解决了固定窗口临界值的问题可以保证在任意时间窗口内都不会超过阈值但是对内存的占用会比较多。记录每次请求的时间统计每次请求的时间 至 往前推 1 秒这个时间窗口内请求数并且 1 秒前的数据可以删除。统计的请求数小于阈值就记录这个请求的时间并允许通过反之拒绝。滑动窗口和固定窗口都无法解决短时间之内集中流量的突击我们可以设置多条限流规则不仅限制每秒 100 个请求再设置每 10 ms 不超过 2 个。TCP 的滑动窗口是接收方告知发送方自己能接收多少 货然后发送方控制发送速率。漏桶算法请求来了放入桶中桶内请求量满了拒绝请求服务定速从桶内拿请求处理优点宽进严出无论请求多少请求的速率有多大都按照固定的速率流出对应的就是服务按照固定的速率处理请求。缺点在面对突发流量我们希望在系统平稳的同时提升用户体验即能更快的处理请求而不是和正常流量一样循规蹈矩的处理令牌桶算法什么是服务熔断服务熔断指的是当某个服务的调用失败率持续升高时通过中断对该服务的请求防止系统资源被不断消耗进而保护整个系统不受影响。当一个服务在设定的时间窗口内连续多次请求失败如超时、异常、HTTP 5xx 错误等并且失败率超过设定阈值时熔断器会自动触发。或者当服务完全不可访问如网络故障或服务宕机熔断器可以直接切断请求快速返回错误。最后如果一个服务的响应时间长导致调用超时并且这种情况在一定时间内多次发生熔断器也会触发熔断。熔断器的三种状态Closed关闭状态熔断器在正常情况下处于关闭状态所有请求都会正常发往目标服务。当服务调用失败次数或失败率达到阈值时熔断器会从Closed状态变为open状态。Open 打开状态当熔断器处于打开状态时Hystrix 会阻断所有对目标服务的请求直接返回降级结果。经过一段时间后熔断器会自动进入Half-Open状态尝试发送部分请求以判断目标服务是否恢复。Half-Open半开状态在半开状态下部分请求可以尝试发往目标服务。如果这些请求成功率达到设定阈值熔断器会关闭恢复正常调用如果半开状态下的请求失败率仍然很高则熔断器会重新打开。Hystrix 的常见配置项circuitBreaker.requestVolumeThreshold: 熔断器触发的最小请求数量当达到该数量且失败率超过阈值时熔断器才会打开。circuitBreaker.errorThresholdPercentage: 请求失败率的阈值超过该百分比时熔断器打开。circuitBreaker.sleepWindowInMilliseconds: 熔断器打开后的休眠时间休眠结束后进入半开状态。coreSize: 线程池的核心线程数控制并发线程数。maxQueueSize: 线程池的最大队列长度用于控制请求排队等待的数量。queueSizeRejectionThreshold: 队列拒绝阈值当队列中的请求超过该阈值后续请求将被拒绝。execution.isolation.semaphore.maxConcurrentRequests: 信号量隔离的最大并发请求数超出该数量的请求将被拒绝。负载均衡主要用于将网络请求和流量分发到多台服务器或服务实例上从而提高系统的高可用性和性能同它还能确保系统在高并发访问下保持稳定避免单个服务器因负载过高而导致性能下降或宕机同时能够方便地进行横向扩展Scale OUt)。负载均衡算法哈希算法Hash根据请求的某个特定关键字来实现负载均衡比如通过请求的 URL 路径、请求的 IP 地址等来计算哈希值然后根据哈希值选择相应的后端服务器。最小连接算法Least Connection根据后端服务器当前的连接数来决定请求的分配负载均衡器会选择当前连接最少的服务器进行请求分配保证后端服务器的负载均衡。加权随机算法Weight Random在随机的基础上添加权值的概念可以根据服务器的性能设置权值。随机算法Random将请求随机分配后给后端服务器每个后端服务器被选中的概念是一致的不考虑服务器的负载情况。加权轮询算法Weighted Round Robin在轮询算法的基础上添加权重的概念可以从后端服务器的性能设置对应的权重和分配比例。轮询算法Round Robin最简单的负载均衡算法主要就是按照顺序将请求分配给后端服务器。负载均衡的实现方式硬件负载均衡就是用一个硬件一个基础网络设备类似于我们的交换机啊这样的硬件来实现负载均衡常见的硬件有F5、A10优点支持全局负载均衡提供全面的复杂均衡算法支持百万以上并发提供安全功能。例如防火墙防 DDos 攻击等。缺点扩展能力差硬件成本高。软件负载均衡常见的软件有LVS、Nginx、HAProxy四层负载均衡在网络层利用 IP 地址端口进行请求的转发基本上就是起个转发分配的作用。七层负载均衡可以根据访问用户的 HTTP 请求头、URL 信息将请求转发到特定的主机。缺点和硬件负载均衡比性能一般流量很大的企业就用软件负载均衡顶不住没有防火墙或者防 DDos 攻击等安全性功能。DNS 负载均衡这个负载均衡是通过 DNS 来的因为 DNS 解析同一个域名可以返回不同的 IP所以主要是用来实现地理级别的负载均衡。优点就近访问可以减少响应的时间提升访问速度。缺点因为是运营商管理控制的所以扩展能力差。DNS 有缓存而且缓存时间较长当机房迁移等需要修改 DNS 配置的时候用户可能还会访问之前的 IP。什么是 Feign本身并没有负载均衡的能力它负载均衡的能力需要依赖其他框架。比如 Ribbon 或者 loadbalancer。特点声明式的服务客户端通过 Java 接口和注解构建服务客户端简化了 Http 调用的使用过程无需手动构建 HTTP 请求。很好地融入了 SpringCloud 生态可以使用 SpringCloud 负载均衡、服务熔断等能力。我们经常需要调用第三方提供的 Http 接口此时我们就可以使用一些 Http 框架来实现比如 HttpClientpublic class HttpClientDemo { public static void main(String[] args) throws Exception { // 创建一个 HttpClient HttpClient httpClient HttpClientBuilder.create().build(); // 构建一个 get 请求 HttpGet httpGet new HttpGet(http://192.168.100.1:8080/order/1); // 发送请求获取响应 HttpResponse httpResponse httpClient.execute(httpGet); HttpEntity httpEntity httpResponse.getEntity(); // 读出响应值 String response EntityUtils.toString(httpEntity); System.out.println(Response response); } }Feign 是一个声明式的 Http 框架当你需要调用 Http 接口时你需要声明一个接口加一些注解就可以了。而像组装参数、发送 Http 请求等重复性的工作都交给 Feign 来完成。为什么 Feign 第一次调用耗时很长主要是由于 Feign 内置的负载均衡组件 Ribbon 的懒加载机制。主动预热只需要在应用启动的时候进行服务预热先自动执行一次随便的调用提前加载 Ribbon 以及其他相关的服务调用组件。开启 Ribbon 的饥饿加载# application.yml 配置 ribbon: eager-load: enabled: trueribbon.eager-load.enabled: 将其设置为true表示启用 Ribbon 的饥饿加载机制。ribbon.eager-load.clients: 指定需要进行饥饿加载的 Feign 客户端列表用逗号分割。这些客户端的 Ribbon 配置和服务实例信息将在应用启动时预先加载。Ribbon 的客户但缓存机制默认情况下Ribbon 会隔取 30s 刷新一次缓存中的服务实例列表意味着在此期间内客户端获取到的服务实例信息不会变化通过调整ribbon.ServerListRefreshInterval的值可以更频繁或更少地刷新缓存。Spring Cloud LoadBalancer 是 Spring 官方提供的新一代负载均衡旨在替代 Ribbon提供更加简洁和现代化的配置方式。Ribbon 如何得知服务实例的数据需要注册中心主动去适配 Ribbon只要注册中心去适配了 Ribbon那么 Ribbon 自然而然就知道服务实例的数据了。当 Ribbon 通过 ServerList 获取到服务实例数据之后会基于这些数据来做负载均衡的。Nacos 自然而然也实现了 ServerList 接口为 Ribbon 提供 Nacos 注册中心的服务。同样的除了 Nacos 之外Eureka、Zookeeper 等注册中心也都实现了这个接口。对于 loadbalancer 来说其实也是这种模式需要不同的注册中心去适配这样也就可以获取到服务注册中心的服务实例信息了。Feign 和 Dubbo 的区别核心架构协议Feign基于 HTTP 协议如 REST/JSON适用声明式注解如FeignClient定义客户端接口适用于微服务间的轻量级通信。本质上是将 HTTP 请求封装 Java 接口调用依赖外部服务发现如 Eureka和负载均衡如 Ribbon。Dubbo基于自定义二级制协议如 Dubbo 协议适用 RPC 模式支持高效序列化如 Hessian、Kryo。内置服务注册中心、负载均衡、容错等机制提供完整的服务治理能力。优点高性能、低延迟适用于高并发分布式系统但配置相对复杂。通信模型Feign采用同步 HTTP 请求/响应模型每次调用可能涉及 TCP 连接建立和断开开销较大但兼容性强。Dubbo基于长连接和 NIO非阻塞 I/O)支持异步调用减少了网络开销吞吐量更高。服务发现与负载均衡Feign依赖外部组件如 Spring Cloud Eureka实现服务发现负载均衡通过客户端库如 Ribbon完成。Dubbo基于长连接和 NIO非阻塞 I/O)支持异步调用减少网络开销吞吐量更高。适用场景Feign适合 RESTful 微服务架构尤其是 Spring Boot/Cloud 项目需要快速开发 HTTP API 客户端。Dubbo: 适合企业级分布式系统对性能要求高需要服务治理如熔断、监控的场景。性能与扩展FeginHTTP 协议协议通用性强但序列化JSON和网络开销较大适合中小规模微服务。Dubbo二进制协议效率高支持自定义扩展如过滤器、路由更适合大规模高可用系统。Feign 和 OpenFeign 的区别OpenFeign 是 Spring Cloud 在 Feign 的基础上进一步封装的它整合了 Spring Cloud 的特性使得我们可以更加简单地使用 Feign自动配置OpenFeign 利用 Spring Boot 的自动配置机制通过 FeignClient 和 EnableFeignClientsFeign 的本质动态代理 七大核心组件contract这个 Contract 接口会去解析方法上的注解和参数获取 Http 请求需要用到基本参数。SpringCloud 在整合 Feign 的时候为了让 Feign 能够识别 Spring MVC 的注解所以就自己实现了 Contract 接口。EncoderFeign 默认的 Encoder 实现只支持请求体对应的方法参数类型为 String 和字节数组。具体作用就是将请求体对应的方法参数序列化成字节数组。Spring 就实现了 Encoder 接口可以将任意请求体对应的方法参数类型对象序列化成字节数组。DecoderDecoder 其实就是将响应体由字节流反序列化成方法返回值类型的对象和 Encode 的默认情况是一样的只支持反序列化成字节数组或者是 String。所以 Spring 同样实现了 Decoder用来扩展它的功能。Client这其实就是动态代理对象最终用来执行 Http 请求的组件默认实现就是通过 JDK 提供的 HttpURLConnection 来的。如下是 OpenFeign 用来整合 Ribbon 实现复杂均衡的核心实现。InvocationHandlerFactory对于 JDK 动态代理来说InvocationHandler 的 invoke 实现方法就是动态代理走的核心逻辑而 InvocationHandlerFactory 顾明思义其实就是创建 InvocationHandler 的工厂。去看看 InvocationHandler 的实现类 FeignInvocationHandler除了 Object 类的一些方法最终会调用方法对应的 MethodHandler 的 invoke 方法虽然说默认情况下 SpringCloud 使用是默认实现最终使用 FeignInvocationHandler但是当其他框架整合 SpringCloud 生态的时候为了适配 OpenFeign有时会自己实现 InvocationHandler。RequestInterceptorRequestInterceptor 它其实是一个在发送请求前的一个拦截接口通过这个接口在发送 Http 请求之前再对 Http 请求的内容进行修改。比如我们可以设置一些接口需要的公共参数如鉴权 token 之类的。Component public class TokenRequestInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { template.header(token, token值); } }Retryer默认实现如下默认情况下最大重试 5 次在 SpringCloud 下并没有使用上面那个实现而是使用的是下面这个实现。所以 SpringCloud 下默认是不会进行重试。Feign 核心运行原理分析动态代理生成原理public class FeignDemo { public static void main(String[] args) { OrderApiClient orderApiClient Feign.builder().target(OrderApiClient.class, http://localhost:8088); orderApiClient.queryOrder(9527L); } }Feign.builder().target(xx)获取到的动态代理如下最终会调用 ReflectiveFegin 的 newInstance 方法来创建动态代理对象而 ReflectiveFeign 内部设置了前面提到的一些核心组件。接下来我们可以看看 newInstance 方法。首先解析接口构建每个方法对应的 MethodHandlerMethodHandler 在前面讲 InvocationHandlerFactory 特别地提醒过动态代理FeignInvocationHandler最终会调用 MethodHandler 来处理 Feign 地一次 HTTP 调用。然后通过 InvocationHandlerFactory 创建 InvocationHandler 然后再构建出接口的动态代理对象。一次 Feign 的 HTTP 调用执行过程调用接口动态代理的方式时通过 InvocationHandler FeignInvocationHandler最终交给 MethodHandler 的 invoke 方法来执行。MethodHandler 是一个接口最终会走到它的实现类 SynchronousMethodHandler 的 invoke 方法实现。SynchronousMethodHandler 中的属性就是我们前面提到的一些组件。首先说进入 FeignInvocationHandler找到方法对应的 SynchronousMethodHandler调用 invoke 方法实现。之后根据 MethodMetadata 和方法的入参构造出一个 RequestTemplateRequestTemplate 封装了 Http 请求的参数在这个过程中如果有请求体那么会通过 Encoder 序列化然后调用 RequestInterceptor通过 RequestInterceptor 对 RequestTemplate 进行拦截扩展可以对请求数据再进行修改再然后讲 RequestTemplate 转换成 RequestRequest 其实跟 RequestTemplate 差不多也是封装了 Http 请求的参数接下来通过 Client 去根据 Request 中封装的 Http 请求参数发送 Http 请求得到响应 Response最后根据 Decoder将响应体反序列化成方法返回值类型对象返回。扫盲八股Spring Cloud Alibaba 与 Spring Cloud 有什么区别你了解多少呢它是基于 Spring Cloud 构建的一套微服务开发一战式解决方案它额外增加了一些特定于阿里云的解决方案和工具,它集成度高、生态丰富、可扩展性能强、功能全面。它包括服务注册与发现Eureka/Nacos)、负载均衡Ribbon、断路器Hystrix/Resilience4j、API 网关Zuul/Spring Cloud Gateway)、链路追踪Sleuth/Zipkin、Spring Cloud Config 配置管理提供分布式系统中的外部配置支持配置可以动态刷新无需重启应用。Spring Cloud Gateway作为统一网关接收用户请求。在网关层可能会配合 Sentinel 做限流和熔断避免突发流量打爆后端。网关会去 Eureka / Nacos / Consul 查询可用的服务地址。通过 Ribbon / LoadBalancer 实现负载均衡应用之间调用用 openFeign代码更简洁。所有微服务的配置都统一放在Spring Cloud Config / Apollo / Nacos Config配置变化后可以通过Spring Cloud Bus通知集群里的服务动态刷新。如果某个下游服务挂了Sentinel / Resilience4j会做熔断降级返回兜底结果。一些非核心逻辑会丢到Spring Cloud StreamKafaka、RabbitMQ实现解耦和削峰。用Sleuth Zipkin给调用链打日志和 traceId, 方便排查性能问题Spring Boot Admin可以看到各个微服务的运行情况。现在有哪些流行的微服务框架Spring Cloud Netflix它是 Spring Cloud 下面的一个子项目结合了 Netflix 开源的多款组件包括我们所熟知的 Eureka、Hystrix、Zuul 等组件并逐渐进入了维护状态。Spring Cloud Alibaba 这个是目前主流用的比较多的方案它是阿里巴巴开源的一套微服务下的解决方案主要包括了 Nacos、Sentinel、RocketMQ 等多款开源组件。Dubbo 很多人认为其只是一个 RPC 框架其一些服务治理的功能还是依赖于第三方组件实现如 Zookeeper、Apollo 等现在支持 (TCP、HTTP、Redis 等) 和多种序列化方式如 Json、Hessian、Protobuf 等、可以实现按需分配。主要是作为一个 RPC 框架具有较高的性能和可扩展性提供了服务注册与发现、负载均衡、容错、分布式调用等功能。不过近两年其为了适应云原生时代的发展又开始了迭代并推出了 Dubbo 3。在微服务中是怎么使用链路追踪的它可以选择哪些微服务链路追踪方案Spring Cloud Sleuth它是 Spring Cloud 提供的分布式链路追踪库它会在每个请求中自动生成 Trace ID 和 Span ID并将这些 ID 传递到调用链中的所有服务中。Zipkin 是一种分布式追踪系统支持收集和展示 Spring Cloud Sleuth 生成的追踪数据它能够将每个请求的详细路径进行可视化展示。Jaeger它是 CNCF 托管的分布式追踪系统支持高性能的追踪数据收集和存储与 Zipkin 相比它更适合大规模分布式系统。Spring Cloud Sleuth 可以与 Jaeger 集成利用 Jaeger 的强大功能进行请求追踪、分析和展示支持对历史追踪数据的搜索和分析。SkyWalking它是 Apache 开源的应用性能监控和分布式追踪平台支持多种语言和框架。它不仅可以提供链路追踪功能还支持全链路的 APM应用性能管理包括指标监控、告警和服务依赖分析。它可以直接与 Spring Cloud 微服务集成自动采集微服务的调用数据生成调用链路图和依赖关系视图适合对系统性能有较高要求的场景。OpenTelemetry它是一个统一的分布式追踪和指标收集的框架由 OpenTracing 和 OpenCensus 合并而来它提供了跨平台和跨语言的支持是未来分布式追踪领域的重要方向。在 Spring Cloud 中开发者可以使用 OpenTelemetry 与 Spring 集成将追踪数据发送到支持 OpenTelemetry 的后端系统如 Jaeger、Zipkin、Prometheus 等。基本概念Trace ID: 表示整个调用链的唯一标识当一个请求发起时系统会生成一个 Trace ID用于标识该请求在整个系统中的流转路径。Span ID: 每个服务处理请求的一个单元称为一个 Span每个 Span 都有一个唯一的 Span ID。Span 记录了每个微服务在调用链中的处理时间、日志和元数据。Span 关系Span 之间可以有父子关系一个 Trace 可以包含多个 Span用于描述微服务之间的调用关系这些关系构成了调用链树。工作原理数据采集链路追踪工具通过拦截 HTTP 请求、数据库查询、RPC 调用等操作来记录请求的流转过程。它会在每个请求中注入 TraceID 和 SpanID并将这些信息传递给下一个服务。数据传递链路追踪信息Trace ID 和 Span ID通过 HTTP Header 或 RPC 调用头部进行传递确保所有服务都能共享同一个 Trace ID从而实现对同一请求的全程跟踪。数据上报各个微服务将追踪信息发送到集中式的追踪存储系统如 Zipkin、Jaeger。存储系统会汇总和分析这些数据并通过可视化界面展示给开发者。微服务链路追踪的优势首先它能够记录每个请求在各个服务中的处理时间和顺序帮助开发者了解请求在系统中的全貌提升系统的可观测性。然后当系统出现延迟或错误时可以通过追踪请求的调用路径精确定位到性能瓶颈或异常服务帮助开发者分析系统的性能瓶颈优化服务的调用链和接口性能。最后它可以持续监控请求的延迟和错误率生成调用链的拓扑图和统计数据使运维人员可以更好地管理和优化微服务架构。什么是服务网格它是一个专门用于处理服务间通信的基础设施层它通过部署在每个服务旁边的Sidecar 代理拦截服务间的网络流量实现诸如流量管理、故障恢复、服务发现等功能。常见的服务网格解决方案包括Istio、Linked等。它的核心就是通过Sidecar模式将复杂的网络通信逻辑从微服务中分离出来应用开发者只需关注业务逻辑无需处理服务间的通信管理。它是一种新型的架构模式主要的思想就是将服务通信从服务代码中抽象出来并且在应用中实现统一的管理和控制这里可以再看下腾讯云的服务网格架构图。服务网格提供了强大的可观测性工具开发者可以轻松监控服务间的调用情况、响应时间等从而快速定位问题。服务网格的核心组件控制平面Control Plane控制平面负责管理和下发服务网格的配置协调各个代理的行为。它负责流量策略的配置、策略规则的下发、身份认证的管理等。它是服务网格的“大脑”通过配置管理来实现流量控制、安全策略和可观测性功能。常见的比如Pilot、Citadel、Galley等组件。数据平面Data Plane)它由Sidecar 代理组成这些代理部署在每个微服务旁边负责处理服务之间的所有网络流量。它和微服务应用在同一宿主机上运行能够透明地管理进出服务地流量无需修改应用程序代码。什么是灰度发布、金丝雀部署以及蓝绿部署灰度发布它是一种渐进式的发布方式通过将新版本逐步推送给部分用户进行试用逐步扩大使用范围直到新版本完全替换旧版本。目的是通过小范围的用户测试验证新版本的稳定性降低发布新版本的风险。适用于业务逻辑变动较大的场景使用并在影响较小的情况下进行回滚。金丝雀部署它是一种特殊的灰度发布策略通常是指将新版本部署到少量的实例上并仅将部分流量引导至这些实例以验证新版本在实际生产环境中的表现。它可以通过负载均衡器或服务网格将一定比例的流量引导到运行新版本的实例上若新版本稳定再逐步增加其流量占比。它适用于需要在生产环境中验证新功能或配置变更的场景通过金丝雀部署可以提前发现新版本在生产环境中的潜在问题。同时也适用于在实际生产环境下进行性能测试或新版本兼容性测试的场景。蓝绿部署它是一种无缝切换的部署策略当绿色版本新版本准备就绪时通过负载均衡或路由切换将所有流量从蓝色版本当前的生产版本切换到绿色版本。它通常是通过负载均衡器、DNS 切换或 API 网关来切换蓝色版本和绿色版本之间的流量指向。适用于需要快速切换和回滚的场景特别是在对系统稳定性要求高的应用中通过蓝绿部署可以实现无停机升级。HTTP 与 RPC 之间的区别HTTP 是一种应用层的协议主要强调的是网络通信然后 RPC 其实是一种分布式系统之间通信的方式强调的是服务之间的远程调用。有一些 RPC 框架底层使用的是 HTTP 协议实现通信比如 gRPC其底层使用的就是 HTTP/2然后还有 Dubbo其现在也兼容了 gRPC 了并且使用了 HTTP/2 作为传输协议。HTTP 的传输格式啊通常使用文本格式如 JSON、XML传输数据容易被人类阅读和理解由于 HTTP 是基于 TCP 的应用层协议因此它的消息体较大适用于 Web 页面、API 等场景。RPC 的传输格式RPC 传输的数据通常是二进制格式如 Protocol Buffers、Thrift数据量较少效率较高。通常是基于 TCP 进行通信同时也可以直接使用 HTTP。说明IDL 是指接口定义语言如二进制、JSON、Protocol Buffers 等。