投诉网站制作,互站网怎么样,自创网站的软件下载,科技公司网页设计素材文章目录 什么是微服务架构为什么要使用微服务单体架构如何转向微服务架构服务治理服务治理治的是什么服务注册与发现服务熔断降级服务网关服务调用服务负载均衡服务配置中心 微服务解决方案SpringCloud体系EurekaHystrixGatewayOpenFeignRibbonConfig SpringCloud Alibaba体系… 文章目录 什么是微服务架构为什么要使用微服务单体架构如何转向微服务架构服务治理服务治理治的是什么服务注册与发现服务熔断降级服务网关服务调用服务负载均衡服务配置中心 微服务解决方案SpringCloud体系EurekaHystrixGatewayOpenFeignRibbonConfig SpringCloud Alibaba体系NacosSentinelSeataSkywalking Dubbo体系DubboZooKeeper 参考文章 什么是微服务架构 In short the microservice architectural style is an approach to developing a single application as a suite of small serviceseach running in its own process and communicating with lightweight mechanisms often an HTTP resource API。 These services are built around business capabilities and independently deployable by fully automated deployment machinery。 There is a bare minimum of centralized management of these services which may be written in different programming languages and use different data storage technologies。 ——James Lewis and Martin Fowler (2014) 大意简而言之微服务体系结构风格是一种将单个应用程序开发为一套小型服务的方法每个服务运行在自己的进程中并与轻量级机制(通常是HTTP资源API)通信。这些服务是围绕业务功能构建的可以通过全自动部署机制进行独立部署。对这些服务的集中管理是最低限度的这些服务可能用不同的编程语言编写并使用不同的数据存储技术。
微服务是一种架构风格将服务围绕业务功能拆分一个应用拆分为一组小型服务每个服务运行在自己的进程内也就是可独立部署和升级服务之间使用轻量级HTTP交互可以由全自动部署机制独立部署去中心化服务自治。服务可以使用不同的语言、不同的存储技术。
为什么要使用微服务
说起微服务就不得不说微服务之前的单体应用有对比才能看的出微服务对比之前的单体应用到底强在哪为什么我们要抛弃单体应用
单体应用往往所有的功能打包在一个包里包含了 DO/DAOServiceUI等所有逻辑如果要修改一部分代码就需要全部重新部署所以改动影响大风险高。微服务模式弥补了这个缺陷它将应用合理的拆分实现敏捷开发和快速部署。单体应用只能通过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展如果想要扩展特定的程序显然是不行的则需要使用到微服务模式实现。因为单体应用所有的功能全部都达到一个包里面所以耦合性比较强对于程序员来说代码维护会收到影响出现了什么问题也不太方便进行排查。如果没有正确的设计单体应用的一部分失败可能会级联并导致整个系统崩溃。而这种情况可以使用微服务的熔断、降级的思想来解决。
微服务虽然好处多多但是缺点就是服务众多不好管理这也就是为什么要治理微服务治理成本高不利于维护系统项目成本会升高所以项目架构设计时应综合考量。
建议设计的原则是业务驱动、设计保障、演进式迭代、保守治疗的方式。搞不清楚有争议的地方先尽量不要拆如果确实要拆要经过业务分析后慎重设计把真正相对独立的部分拆分出来可以借鉴 DDD 的方式。拆了以后要观察微服务的接口是否稳定针对业务需求的变更微服务的模块是否可以保持相对稳定是否可以独立演进。 DDD: Domain-driven design的简称译为领域驱动设计是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。 核心思想DDD其实是面向对象方法论的一个升华。无外乎是通过划分领域聚合根、实体、值对象、领域行为封装到领域对象充血模式、内外交互封装到防腐层、职责封装到对应的模块和分层从而实现了高内聚低耦合。 单体架构如何转向微服务架构
从单体架构迁移到微服务架构时避免大规模重写代码重写代码听起来很好但风险较大如果大规模重写代码可能会导致程序出现各种各样的bug。(当你承担重建一套全新基于微服务的应用程序不需要使用时候可以采用重写这种方法)
逐步迁移单体应用的功能独立出来形成新的微服务同时需要与旧的单体应用集成这可以保证系统的正常运行单体式应用在整个架构中比例逐渐下降直到消失或者成为微服务架构一部分。
虽然在逐步的迁移功能但是也会有源源不断的需求需要开发此时该停止让单体式应用继续变大也就是说当开发新功能时不应该为旧单体应用添加新代码应该是将新功能开发成独立微服务
一个巨大的复杂单体应用由成十上百个模块构成每个都是被抽取对象。决定第一个被抽取模块一般都是挑战一般最好是从最容易抽取的模块开始这会让开发者积累足够经验这些经验可以为后续模块化工作带来巨大好处。
转换模块成为微服务一般很耗费时间一般可以根据获益程度来排序一般从经常变化模块开始会获益最大。一旦转换一个模块为微服务就可以将其开发部署成独立模块从而加速开发进程。比如抽取一些消耗内存资源较大的代码将其弄成一个服务然后可以将其部署在大内存主机上。同样的将对计算资源很敏感的算法应用抽取出来也是非常有益的这种服务可以被部署在有很多 CPU 的主机上。有三种策略可以考虑将新功能以微服务方式实现将表现层与业务数据访问层分离将现存模块抽取变成微服务。
首先要将抽离的相关功能封装成相关几个方法、几个类、几个包中定义好模块和单体应用之间的几个大概的接口从程序内部开始调用一旦完成相关的接口也就将此模块转换成独立微服务。为了实现必须写代码使得单体应用和微服务之间通过使用进程间通信机制的API来交换信息服务和单体应用整合的API代码就成为了容灾层。
然后将抽离的功能转化为独立的服务进行部署将其整合成一个微服务基础框架。每抽取一个服务就朝着微服务方向前进一步随着时间推移单体应用将会越来越简单用户就可以增加更多独立的微服务。
服务治理
服务治理是指在分布式系统、微服务架构中通过技术和策略管理、监控、优化各个服务之间的交互来确保整个系统的高效、稳定和可靠运行。它不仅包括技术实现还涉及设计规范和策略目的是为了解决服务调用、资源分配和故障处理等关键问题。
服务治理治的是什么
拿城市交通规划举例在进行城市交通规划之前首先要做的第一个事情是收集信息要能够知道这个城市发生了什么所以在各个路口需要安装采集探头记录车来车往的信息。有了信息以后就需要对信息进行分析了那么就需要可视化的图形界面能够一眼就看出什么地方出了问题通往哪个工厂的路坏了。发现了问题就要解决问题了限制一下拥堵路段的流量把去往一个公园的车辆导向到另外一个类似的公园。最后如果把城市作为一个国家来考虑那么每个进入这个城市的车辆都需要进行检查看看有没有携带违禁品最后给这些不熟悉道路的外地车规划路线。通过上面这个思考的过程我们发现要对一个城市进行治理的时候第一要采集信息然后要能够对采集的信息进行监控和分析最后根据分析的结果采取对应的治理策略。另外从整体安全的角度考虑还需要一个守门人。
用同样的思路来思考服务治理网关就是整个整体的守门人日志采集追踪工具服务注册发现都是用来采集信息的然后需要监控平台来展现这些采集的信息并进行监控和分析。最后根据分析的结果采取治理策略有的服务快撑不住了要限流有的服务坏了要熔断并且还能够及时的调整这些服务的配置。 服务注册与发现
服务注册与发现是微服务架构中的核心概念。在微服务架构中服务数量众多服务间通信变得尤为重要。为了实现动态的服务间通信每个服务都需要将自己的信息注册到注册中心以便其他服务能够发现并调用。
服务注册服务提供者在启动时将自己的信息如IP地址、端口号等注册到注册中心。服务发现服务消费者从注册中心查询所需服务的地址信息实现动态调用。
当服务器启动的时候会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方消费者服务提供者以该别名的方式去注册中心上获取到实际的服务通讯地址然后再实现本地RPC调用。RPC远程调用框架核心设计思想在于注册中心因为使用注册中心管理每个服务与服务之间的一个依赖关系。在任何RPC远程框架中都会有一个注册中心存放服务地址相关信息。
服务熔断降级
由于分布式架构中应用程序依赖关系可能非常多每个依赖关系在某些时候将不可避免地失败针对服务调用失败为了缩小调用失败的影响引入了服务熔断降级的思想。
多个微服务之间调用的时候假设微服务A调用微服务B和微服务C微服务B和微服务C又调用其它的微服务这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用对微服务A的调用就会占用越来越多的系统资源进而引起系统崩溃所谓的“雪崩效应”。
服务熔断熔断机制是应对雪崩效应的一种微服务链路保护机制当链路的某个微服务不可用或者响应时间太长时将快速的返回设置好的提示信息。服务降级服务降级一般是指在服务器压力剧增的时候根据实际业务使用情况以及流量对一些服务和页面有策略的不处理或者用一种简单的方式进行处理从而释放服务器资源的资源以保证核心业务的正常高效运行。
服务熔断是应对系统服务雪崩的一种保险措施给出的一种特殊降级措施。而服务降级则是更加宽泛的概念主要是对系统整体资源的合理分配以应对压力。服务熔断可看作特殊降级。
服务网关
微服务背景下一个系统被拆分为多个服务但是像安全认证、流量控制、日志、监控等功能是每个服务都需要的没有网关的话我们就需要在每个服务中单独实现这使得我们做了很多重复的事情并且没有一个全局的视图来统一管理这些功能。 网关是作为一个用来保护、增强和控制对API服务访问的角色。网关是一个处于应用程序或服务之前的系统用来管理授权、访问控制和流量限制等这样 REST API 接口服务就被网关保护起来对所有的调用者透明。因此隐藏在网关后面的业务系统就可以专注于创建和管理服务而不用去处理这些策略性的基础设施。
服务调用
服务调用可以说是微服务中最关键的如果没有服务调用不会出现熔断降级、也不会出现服务负载、服务注册分布式的服务治理可以说是围绕服务调用展开的。
常见的服务之间的调用方式有两种
RPC远程过程调用定义数据式基于原生TCP通信速度快效率高。早期的WedService现在热门的Dubbo都是RPC的典型代表Http调用Http是一种网络传输协议基于TCP规定了数据传输的格式。现在客户端浏览器与服务器端通信基本都是采用HTTP协议也可以用来进行远程服务调用。缺点是消息封装臃肿优势是对服务的提供和调用方没有任何技术限定自由灵活更符合为服务理念
现在热门的Rest风格就可以通过HTTP协议来实现如果公司全部采用Java技术栈那么使用Dubbo作为微服务框架是一个不错的选择如果公司的技术栈多样化而且你更青睐Spring家族那么SpringCloud搭建微服务是不二之选。
服务负载均衡
负载均衡英文名称为Load Balance其含义就是指将工作任务进行平衡、分摊到多个操作单元上进行运行例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等从而协同完成工作任务。
当前服务与服务之间进行相互调用时在分布式架构下应用都是集群部署所以这个时候就需要进行服务负载即将收到的请求分摊到对应的服务器上从而达到系统的高可用。
常见负载均衡算法
随机分配随机选择一台服务器来分配任务。它保证了请求的分散性达到了均衡的目的。同时它是没有状态的不需要维持上次的选择状态和均衡因子。但是随着任务量的增大它的效果趋向轮询后也会具有轮询算法的部分缺点轮询分配将任务分配给此时具有最小连接数的节点因此它是动态负载均衡算法。一个节点收到一个任务后连接数就会加1当节点故障时就将节点权值设置为0不再给节点分配任务最小连接分配将任务分配给此时具有最小连接数的节点因此它是动态负载均衡算法。一个节点收到一个任务后连接数就会加1当节点故障时就将节点权值设置为0不再给节点分配任务hash分配对请求中的关键信息进行hash计算hash值相同的请求分配到同一台服务器具体原理可查看HashMap分配原理根据性能分配根据服务器的响应时间来进行任务分配优先将新任务分配给响应最快的服务器
服务配置中心
在分布式微服务意味着要将单体应用中的业务拆分成一个个子服务每个服务的粒度相对较小因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行所以一套集中式的、动态的配置管理设施是必不可少的。
配置中心应运而生。配置中心顾名思义就是来统一管理项目中所有配置的系统。对于单机版称之为配置文件而对于分布式集群系统称之为配置中心。它的作用是负责统一管理不同环境和集群的配置解耦应用与配置同时支持版本发布与管理。
微服务解决方案
随着微服务模式的使用服务之间的调用带来的问题有很多如数据一致性、网络波动、缓存、事务等问题。根据服务治理的思想并针对这一系列的问题目前主流一站式微服务解决方案有SpringCloud、SpringCloud Alibaba及以Dubbo构成的体系。
功能模块Spring CloudDubboSpring Cloud Alibaba服务注册与发现Eureka、Consul、ZookeeperZookeeper、NacosNacos熔断与限流Resilience4j、Hystrix已停更逐步替换无需外部集成Sentinel限流、熔断、降级负载均衡Ribbon、Spring Cloud LoadBalancer、FeignDubboNacos、Spring Cloud LoadBalancer配置管理Spring Cloud Config、Consul无可与 Nacos、Apollo 集成NacosAPI 网关Spring Cloud Gateway、Zuul已停更无需外部集成Spring Cloud Gateway分布式追踪Spring Cloud Sleuth Zipkin / JaegerSkywalking、ZipkinSpring Cloud Sleuth Zipkin / Skywalking服务调用Feign、RestTemplateDubboFeign、RestTemplate、Dubbo分布式事务Seata、TCC-Transaction、SAGATCC、XA 等协议Seata支持 AT、TCC、SAGA 模式通信协议HTTP/REST、gRPC需扩展支持Dubbo 协议基于高效 RPC 调用HTTP/REST、Dubbo 协议适用场景面向全栈微服务治理适合通用微服务架构高性能 RPC 调用适合低延迟、高并发场景增强版 Spring Cloud适合国内复杂分布式场景生态成熟度完善社区活跃成熟广泛应用于国内企业活跃逐渐成为国内微服务治理首选
SpringCloud体系
SpringCloud它并不是一个框架而是很多个框架。它是分布式微服务架构的一站式解决方案是多种微服务架构落地技术的集合体俗称微服务全家桶。 Eureka Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers。 We call this service the Eureka Server。 Eureka also comes with a Java-based client componentthe Eureka Client which makes interactions with the service much easier。 The client also has a built-in load balancer that does basic round-robin load balancing。 —https://github.com/Netflix/eureka 大意Eureka是一个REST (Representational State Transfer)服务它主要用于AWS云用于定位服务以实现中间层服务器的负载平衡和故障转移我们称此服务为Eureka服务器。Eureka也有一个基于java的客户端组件Eureka客户端这使得与服务的交互更加容易同时客户端也有一个内置的负载平衡器它执行基本的循环负载均衡。
Eureka采用了Client / Server 的设计架构提供了完整的服务注册和服务发现可以和 SpringCloud 无缝集成。Eureka Sever作为服务注册功能的服务器它是服务注册中心。而系统中的其他微服务使用Eureka的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。 Eureka Server 提供服务注册服务各个微服务节点通过配置启动后会在EurekaServer中进行注册这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息服务节点的信息可以在界面中直观看到。Eureka Client 通过注册中心进行访问它是一个Java客户端用于简化Eureka Server的交互客户端同时也具备一个内置的使用轮询负载算法的负载均衡器。在应用启动后将会向Eureka Server发送心跳默认周期为30秒。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳Eureka Server将会从服务注册表中把这个服务节点移除默认90秒。 Service Provider服务提供方将自身服务注册到Eureka从而使服务消费方能够找到Service Consumer服务消费方从Eureka获取注册服务列表从而能够消费服务
默认使用下Eureka有一个自我保护机制如果Eureka Server在一定时间内默认90秒没有接收到某个微服务实例的心跳Eureka Server将会移除该实例。但是当网络分区故障发生时微服务与Eureka Server之间无法正常通信而微服务本身是正常运行的此时不应该移除这个微服务所以引入了自我保护机制。
自我保护模式正是一种针对网络异常波动的安全保护措施使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。如果在15分钟内超过85%的客户端节点都没有正常的心跳那么Eureka就认为客户端与注册中心出现了网络故障Eureka Server自动进入自我保护机制
Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务Eureka Server仍然能够接受新服务的注册和查询请求但是不会被同步到其它节点上保证当前节点依然可用当网络稳定时当前Eureka Server新的注册信息会被同步到其它节点中
简而言之某时刻某一个微服务不可用了Eureka不会立刻清理依旧会对该微服务的信息进行保存。所以Eureka属于AP。
Hystrix
当微服务系统的一个服务出现故障时故障会沿着服务的调用链路在系统中疯狂蔓延最终导致整个微服务系统的瘫痪这就是“雪崩效应”。为了防止此类事件的发生微服务架构引入了“断路器”的一系列服务容错和保护机制。
断路器”本身是一种开关装置当某个服务单元发生故障之后通过断路器的故障监控类似熔断保险丝)向调用方返回一个符合预期的、可处理的备选响应FallBack)而不是长时间的等待或者抛出调用方无法处理的异常这样就保证了服务调用方的线程不会被长时间、不必要地占用从而避免了故障在分布式系统中的蔓延乃至雪崩。
SpringCloud Hystrix 是基于 Netflix 公司的开源组件 Hystrix 实现的它提供了熔断器功能能够有效地阻止分布式微服务系统中出现联动故障以提高微服务系统的弹性。SpringCloud Hystrix 具有服务降级、服务熔断、线程隔离、请求缓存、请求合并以及实时故障监控等强大功能。
熔断机制是为了应对雪崩效应而出现的一种微服务链路保护机制。当微服务系统中的某个微服务不可用或响应时间太长时为了保护系统的整体可用性熔断器会暂时切断请求对该服务的调用并快速返回一个友好的错误响应。这种熔断状态不是永久的在经历了一定的时间后熔断器会再次检测该微服务是否恢复正常若服务恢复正常则恢复其调用链路。 在熔断机制中涉及了三种熔断状态
熔断打开请求不再进行调用当前服务内部定时一般为MTTR(平均故障处理时间)当打开时长达到所设的时长则进入半熔断状态熔断半开部分请求根据规则调用当前服务如果请求成功且符合规则则认为当前服务恢复正常关闭熔断熔断关闭熔断关闭不会对服务进行熔断
Hystrix 实现服务熔断的步骤如下
当服务的调用出错率达到或超过 Hystix 规定的比率默认为 50%后熔断器进入熔断开启状态。熔断器进入熔断开启状态后Hystrix 会启动一个休眠时间窗在这个时间窗内该服务的降级逻辑会临时充当业务主逻辑而原来的业务主逻辑不可用。当有请求再次调用该服务时会直接调用降级逻辑快速地返回失败响应以避免系统雪崩。当休眠时间窗到期后Hystrix 会进入半熔断转态允许部分请求对服务原来的主业务逻辑进行调用并监控其调用成功率。如果调用成功率达到预期则说明服务已恢复正常Hystrix 进入熔断关闭状态服务原来的主业务逻辑恢复否则 Hystrix 重新进入熔断开启状态休眠时间窗口重新计时继续重复第 2 到第 5 步。
Hystrix工作流程 创建HystrixCommand或HystrixObserableCommand对象。命令执行: 其中HystrixCommand实现了下面前两种执行方式: execute同步执行从依赖的服务返回一个单一的结果对象或是在发生错误的时候抛出异常。queue异步执行直接返回一个Future对象其中包含了服务执行结束时要返回的单一结果对象。 HystrixObservableCommand实现了后两种执行方式 obseve()返回Observable对象它代表了操作的多个结果它是一个Hot Observable不论“事件源”是否有“订阅者”都会在创建后对事件进行发布所以对于Hot Observable的每一个“订阅者”都有可能是从“事件源”的中途开始的并可能只是看到了整个操作的局部过程。toObservable()同样会返回Observable对象也代表了操作的多个结果但它返回的是一个Cold Observable没有“订间者”的时候并不会发布事件而是进行等待直到有“订阅者之后才发布事件所以对于Cold Observable 的订阅者它可以保证从一开始看到整个操作的全部过程。 判断当前命令的请求缓存功能是被启用的并且该命令缓存命中那么缓存的结果会立即以Observable对象的形式返回。检查断路器是否为打开状态。如果断路器是打开的那么Hystrix不会执行命令而是转接到fallback处理逻辑(第8步)如果断路器是关闭的检查是否有可用资源来执行命令(第5步)。判断线程池/请求队列信号量是否占满。如果命令依赖服务的专有线程地和请求队列或者信号量已经被占满那么Hystrix也不会执行命令而是转接到fallback处理理辑(第8步) 。Hystrix会根据我们编写的方法来决定采取什么样的方式去请求依赖服务: HystrixCommand.run()返回一个单一的结果或者抛出异常。HystrixObservableCommand.construct()返回一个Observable对象来发射多个结果或通过onError发送错误通知。 Hystrix会将“成功”、“失败”、“拒绝”、“超时” 等信息报告给断路器而断路器会维护一组计数器来统计这些数据。断路器会使用这些统计数据来决定是否要将断路器打开来对某个依赖服务的请求进行熔断/短路。当命令执行失败的时候Hystrix会进入fallback尝试回退处理我们通常也称波操作为“服务降级”。而能够引起服务降级处理的情况有下面几种 第4步∶当前命令处于“熔断/短路”状态断路器是打开的时候。第5步∶当前命令的线程池、请求队列或者信号量被占满的时候。第6步∶HystrixObsevableCommand.construct()或HytrixCommand.run()抛出异常的时候。 当Hystrix命令执行成功之后它会将处理结果直接返回或是以Observable的形式返回给调用方。
Gateway
SpringCloud Gateway 属于 SpringCloud 生态系统中的网关其诞生的目标是为了替代老牌网关 Zuul。准确点来说应该是 Zuul 1.x。SpringCloud Gateway 起步要比 Zuul 2.x 更早。为了提升网关的性能SpringCloud Gateway 基于 Spring WebFlux 。Spring WebFlux 使用 Reactor 库来实现响应式编程模型底层基于 Netty 实现同步非阻塞的 I/O。 Gateway 核心组件
Route路由是构建网关的基本模块它由ID目标URI一系列的断言和过滤器组成如断言为true则匹配该路由Predicate断言参考的是Java8的java.util.function。Predicate开发人员可以匹配HTTP请求中的所有内容例如请求头或请求参数如果请求与断言相匹配则进行路由Filter过滤指的是Spring框架中GatewayFilter的实例使用过滤器可以在请求被路由前或者之后对请求进行修改
工作流程 路由判断客户端的请求到达网关后先经过 Gateway Handler Mapping 处理这里面会做断言Predicate判断看下符合哪个路由规则这个路由映射后端的某个服务。请求过滤然后请求到达 Gateway Web Handler这里面有很多过滤器组成过滤器链Filter Chain这些过滤器可以对请求进行拦截和修改比如添加请求头、参数校验等等有点像净化污水。然后将请求转发到实际的后端服务。这些过滤器逻辑上可以称作 Pre-FiltersPre 可以理解为“在…之前”。服务处理后端服务会对请求进行处理。响应过滤后端处理完结果后返回给 Gateway 的过滤器再次做处理逻辑上可以称作 Post-FiltersPost 可以理解为“在…之后”。响应返回响应经过过滤处理后返回给客户端。
客户端的请求先通过匹配规则找到合适的路由映射到具体的服务然后请求经过过滤器处理后转发给具体的服务服务处理后再次经过过滤器处理最后返回给客户端。
对于公司业务以 Java 为主要开发语言的情况下SpringCloud Gateway 通常是个不错的选择其优点有简单易用、成熟稳定、与 SpringCloud 生态系统兼容、Spring 社区成熟等等。不过SpringCloud Gateway 也有一些局限性和不足之处 一般还需要结合其他网关一起使用比如 OpenResty。并且其性能相比较于 Kong 和 APISIX还是差一些。如果对性能要求比较高的话SpringCloud Gateway 不是一个好的选择。
OpenFeign Feign is a declarative web service client。 It makes writing web service clients easier。 To use Feign create an interface and annotate it。 It has pluggable annotation support including Feign annotations and JAX-RS annotations。 Feign also supports pluggable encoders and decoders。 Spring Cloud adds support for Spring MVC annotations and for using the same HttpMessageConverters used by default in Spring Web。 Spring Cloud integrates Ribbon and Eureka as well as Spring Cloud LoadBalancer to provide a load-balanced http client when using Feign。 大意Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单。它的使用方法是定义一个服务接口然后在上面添加注解。Feign也支持可拔插式的编码器和解码器。SpringCloud对Feign进行了封装使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。
Feign与OpenFeign:
Feign是SpringCloud组件中的一个轻量级RESTful的HTTP服务客户端Feign内置了Ribbon用来做客户端负载均衡去调用服务注册中心的服务。Feign的使用方式是使用Feign的注解定义接口调用这个接口就可以调用服务注册中心的服务OpenFeign是SpringCloud在Feign的基础上支持了SpringMVC的注解如RequesMapping等等。OpenFeign的Feignclient可以解析SpringMVc的RequestMapping注解下的接口并通过动态代理的方式产生实现类实现类中做负载均衡并调用其他服务
通过使用OpenFeign可以使代码变得更加简洁减轻程序员负担 // 伪代码Component// 括号中为在注册中心注册的服务名称FeignClient(CLOUD-PAYMENT-SERVICE)public interface PaymentFeignService {GetMapping(/payment/get/{id})CommonResultPayment getPayment(PathVariable(id) Long id);PostMapping(/payment/timeout)String feignTimeoutTest();}OpenFeign工作原理 使用注解FeignClient注册FactoryBean到IOC容器 最终产生了一个虚假的实现类代理使用Feign调用接口的地方最终拿到的都是一个假的代理实现类所有发生在代理实现类上的调用都被转交给Feign框架翻译成HTTP的形式发送出去并得到返回结果再翻译回接口定义的返回值形式
Ribbon
SpringCloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具是一个内置软件负载平衡器的进程间通信远程过程调用库。主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon客户端组件提供一系列完善的配置项如连接超时、重试等。
本地负载与服务端负载
Nginx是服务器负载均衡客户端所有请求都会交给Nginx然后由Nginx实现转发请求。即负载均衡是由服务端实现的Ribbon是本地负载均衡在调用微服务接口时候会在注册中心上获取注册信息服务列表之后缓存到JVM本地从而在本地实现RPC远程服务调用技术
Ribbon其实是一个软负载均衡的客户端组件它可以和其他所需请求的客户端结合使用例如与Eureka结合 消费方和服务方在注册中心注册服务当消费方发起请求时Ribbon会去注册中心寻找请求的服务名即服务方集群Ribbon默认负载算法会根据接口第几次请求 % 服务器集群总数量算出实际消费方服务器的位置每次服务重启动后rest接口计数从1开始。
模拟Ribbon默认负载均衡算法
public interface ILoadBalance {ServiceInstance instance(ListServiceInstance instances);
}Component
public class MyLoadBalance implements ILoadBalance{/*** 轮询索引*/private final AtomicInteger index new AtomicInteger(0);/*** 负载均衡算法rest接口第几次请求数 % 服务器集群总数量 实际调用服务器位置下标每次服务重启动后rest接口计数从1开始。* param instances 服务器集群数量* return 实际服务器的下标*/Overridepublic ServiceInstance instance(ListServiceInstance instances) {return instances.get(incrementAndGet() % instances.size());}public final int incrementAndGet() {int current 0;int next 0;do {current index.get();// 当最大数量超过 Integer。MAX_VALUE 归0next current 2147483647 ? 0 : current 1;}while (!index.compareAndSet(current, next));return next;}
}Resourceprivate RestTemplate restTemplate;Resourceprivate DiscoveryClient discoveryClient;Resourceprivate ILoadBalance iLoadBalance;GetMapping(/myLoadBalance)public String myLoadBalanceTest() {ListServiceInstance instances discoveryClient.getInstances(CLOUD-PAYMENT-SERVICE);ServiceInstance instance iLoadBalance.instance(instances);URI uri instance.getUri();String finalUri String.format(%s/%s,uri, PaymentConstant.PAYMENT_GETPORT_API);log.info(自定义负载均衡请求地址{}, finalUri);return restTemplate.getForObject(finalUri, String.class);}Config
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。 SpringCloud Config是配置中心的一种它分为服务端和客户端两部分
服务端也称为分布式配置中心它是一个独立的微服务应用用来连接配置服务器并为客户端提供获取配置信息加密/解密信息等访问接口Config-Server端集中式存储/管理配置文件并对外提供接口方便Config-Client访问接口使用HTTP的方式对外提供访问客户端则是通过指定的配置中心来管理应用资源以及与业务相关的配置内容并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息这样就有助于对环境配置进行版本管理并且可以通过git客户端工具来方便的管理和访问配置内容
使用SpringCloud Config非常简单需要在服务端和客户端分别进行改造
引入依赖就不说了首先将分布式中系统中的配置放到git或svn上在服务端配置文件里配置好git或svn用户名密码、配置文件所在的分支及配置文件的目录再将服务端启动类加上EnableConfigServer注解就大功告成了放在git或svn上的配置文件名称要符合规则才能通过配置中心访问得到该文件。一些常用的配置文件规则其中label分支、profiles环境(dev/test/prod)、application服务名 ## http://127.0.0.1:3344/master/config-dev.yml1. /{label}/{application}-{profile}.yml## http://127.0.0.1:3344/config-dev.yml2. /{application}-{profile}.yml## http://127.0.0.1:3344/config/dev/master3. /{application}/{profile}[/{label}]在客户端也要引入依赖和进行相关配置配置中心地址、分支名称、配置文件名称、环境。需要注意的是要将客户端模块下的application.yml文件改为bootstrap.yml再将主启动类加上EnableEurekaClient注解 当配置客户端启动时它绑定到配置服务器(通过spring.cloud.config.uri引导配置属性)并使用远程属性源初始化Spring Environment。 这种行为的最终结果是所有想要使用Config Server的客户端应用程序都需要bootstrap.yml或一个环境变量 applicaiton.yml是用户级的资源配置项而bootstrap.yml是系统级的优先级更加高在加载配置时优先加载bootstrap.yml
当将SpringCloud Config客户端服务端都配置好之后修改配置时会发现修改的配置文件不能实时生效。针对这个问题可以将服务重启或者调用actuator的刷新接口使其生效使用之前需要引入actuator的依赖
# 使用SpringCloud Config修改完配置后调用刷新接口使客户端配置生效
curl -X POST http://localhost:3355/actuator/refresh为了避免手动的调用刷新接口可以使用SpringCloud Bus配合SpringCloud Config实现配置的动态刷新。
SpringCloud Alibaba体系
Spring Cloud Alibaba 是一个为 SpringCloud 提供的增强解决方案专注于微服务架构的构建和治理特别是在中国市场的使用场景。此项目包含开发分布式应用服务的必需组件方便开发者通过 SpringCloud 编程模型轻松使用这些组件来开发分布式应用服务。
Nacos
Nacos 是一个由阿里巴巴开源的动态服务发现、配置管理和服务治理平台专为微服务架构设计。它提供服务注册与发现功能允许服务实例自动注册并被其他服务发现从而简化微服务之间的通信。Nacos 还支持动态配置管理应用的配置可以实时更新无需重启应用提升了系统的灵活性。Nacos 提供健康检查机制监控服务的可用性并支持多数据源存储选项以满足不同的业务需求。它与 Spring Cloud Alibaba 深度集成形成了一整套高效的微服务治理解决方案广泛应用于云原生和分布式系统中。
Nacos 服务注册流程
当服务提供者服务实例启动时它会初始化 Nacos 客户端服务提供者通过 Nacos 客户端发送注册请求包括以下信息服务名称、服务实例的 IP 地址、端口号、权重可选、元数据可选Nacos 接收到注册请求后执行以下操作 将服务实例信息存储在内存中。根据配置将服务实例信息持久化存储到数据库如 MySQL、PostgreSQL 等。 Nacos 定期对注册的服务实例进行健康检查保证服务的可用性。健康检查可以使用HTTP 健康检查、TCP 健康检查、GRPC 健康检查。如果某个实例被标记为不可用Nacos 会在一定时间内将其状态更新为“下线”并在一段时间后将其从注册表中剔除。
Nacos 服务发现流程
服务消费者需要调用服务的应用在启动时也会初始化 Nacos 客户端服务消费者通过 Nacos 客户端向 Nacos 发送请求查询指定服务名称的可用实例信息Nacos 查询到可用的服务实例后将其信息以 JSON 格式返回给服务消费者信息包括服务实例的 IP 地址、端口号、权重、元数据如果有服务消费者收到服务实例信息后使用负载均衡算法如轮询、随机等选择一个实例进行调用服务消费者通过 HTTP、gRPC 等协议调用选定的服务实例实现业务逻辑
使用Nacos作为配置中心步骤 下载安装Nacos启动Nacos并创建配置 server:port: 8001config:info: config info for dev from nacos config center集成Nacos客户端在SpringBoot项目中添加相关依赖在application.yml配置中配置Nacos地址 dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-config/artifactId
/dependencyspring:cloud:nacos:config:server-addr: localhost:8848file-extension: yaml # 或 json根据配置格式选择在应用中使用Value或ConfigurationProperties注解来获取Nacos中的配置使用RefreshScope注解标记需要动态刷新的Bean RestController
RefreshScope
public class ValueAnnotationExample {Value(${config.info})private String configInfo;GetMapping(/config/info)public String getConfigInfo() {return configInfo;}}修改 Nacos 控制台中的配置观察 SpringBoot 应用是否能够动态刷新配置
Sentinel
Sentinel 是阿里巴巴开源的一款流量防护和熔断工具专为分布式系统设计提供了限流、熔断降级、系统保护和实时监控等功能适用于高并发、高可用的分布式微服务架构。
Sentinel 具有以下特征:
丰富的应用场景 Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景例如秒杀即突发流量控制在系统容量可以承受的范围、消息削峰填谷、实时熔断下游不可用应用等。完备的实时监控 Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据甚至 500 台以下规模的集群的汇总运行情况。广泛的开源生态 Sentinel 提供开箱即用的与其它开源框架/库的整合模块例如与 SpringCloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。完善的 SPI 扩展点 Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点快速的定制逻辑。例如定制规则管理、适配数据源等。
Sentinel 的熔断机制通过实时监控接口的异常情况如请求失败率、响应时间来判断是否触发熔断以避免系统雪崩。主要工作原理如下
监控数据对每个接口的请求量、错误率、响应时间等数据进行统计基于滑动窗口收集短时间内的请求情况。熔断触发根据配置的熔断规则如错误比例、响应时间等当统计数据超过预设的阈值时触发熔断。熔断期间该接口会拒绝请求直接返回错误响应。进入半开状态经过一段时间后系统进入“半开”状态允许部分请求通过。若恢复正常解除熔断若依然异常继续熔断。恢复正常在半开状态下请求正常时熔断器关闭接口恢复服务来保证服务逐步回归稳定。
假设有一个电商系统中的“下单”接口为了保证系统稳定性我们配置了以下熔断规则当“下单”接口的错误率超过 50%并且在 10 秒内调用量超过 100 时触发熔断熔断持续时间为 5 秒。Sentinel执行流程如下
正常监控系统正常运行时Sentinel 监控每次“下单”请求的成功与失败统计错误率。熔断触发某个时段内由于后端数据库延迟“下单”接口的错误率在 10 秒内达到了 60%超过了配置的 50%且调用量也超过 100。此时Sentinel 自动触发熔断拒绝所有“下单”请求并直接返回错误信息给客户端。进入半开状态5 秒后Sentinel 进入“半开”状态。此时允许一部分请求通过如果这些请求成功率较高系统恢复正常。恢复或继续熔断 如果在半开状态下的请求依旧失败较多错误率较高则熔断器重新进入熔断状态拒绝请求并持续监控。若通过请求的错误率明显下降则熔断器关闭接口完全恢复正常服务。
Seata
Seata是一款分布式事务解决方案专为微服务架构而设计主要用于解决分布式环境下的数据一致性问题。Seata 由阿里巴巴开源具备高性能、易于扩展的特点在微服务环境下提供简单可靠的分布式事务控制。
Seata的设计目标其一是对业务零侵入因此从业务无侵入的2PC入手在传统方案2PC的基础上演进并解决2PC方案面临的问题。Seata把一个分布式的事务理解为一个包含了若干分支事务的全局事务它通过对本地关系型数据库的分支事务的协调来驱动完成全局事务是工作在应用层的中间件。全局事务的职责是协调其下管辖的分支事务达成一致要么一起成功提交事务要么一起回滚失败。此外通常分支事务本身就是一个关系型数据库的本地事务。主要优点是性能较好且不长时间占用连接资源它以高效并对业务0入侵的方式解决微服务场景下面临的分布式事务问题目前提供AT模式即2PC和TCC模式的分布式事务解决方案。 与传统2PC的模型类似Seata定义了3个组件来协调分布式事务的处理过程
TMTransaction Manager事务管理器需要嵌入jar包应用程序中工作负责开启一个全局事务并最终向TC发起全局提交或全局回滚的指令。RMResource Manager资源管理器控制分支事务负责分支事务注册状态回报并接收事务调节器的指令驱动分支事务的提交和回滚。TCTransaction Coordinator事务协调器它是独立的中间件需要独立运行部署它维护全局事务的运行状态接收TM指令发起全局事务的提交与回滚负责与RM通信协调各个分支事务的提交回滚。
以新用户注册送积分举例
具体执行流程
用户服务器的事务管理器向事务协调器申请开启一个全局事务全局事务的创建成功并生成一个全局唯一XID。用户服务器的资源管理器向事务协调器注册分支事务该分支事务在用户服务执行新增用户逻辑并将其纳入XID对应全局事务的管辖。 在执行注册分支事务的时候这里事务已经提交了提交后可以释放资源从而提升程序性能。 用户服务器执行分支事务向用户表插入一条记录。逻辑执行到远程分布式调用积分服务时XID在微服务调用链路的上下文中传播。积分服务的资源管理器向事务协调器注册了分支事务该分支事务执行增加积分的逻辑并将其纳入XID对应的全局事务的管辖。积分服务执行分支事务向积分记录表插入一条记录执行完毕后返回用户服务。用户服务分支事务执行完毕。事务管理器向事务协调器针对XID的全局提交或者回滚决策。事务协调器调度XID下管辖的全部分支事务完成提交或回滚的请求。
Seata实现2PC与传统2PC的差别
架构方面传统2PC方案的RM实际上是在数据库层RM本质上就是数据库自身通过XA协议实现而Seata的RM则是以jar包的形式作为中间件层部署在应用程序这一侧的。两阶段提交方面传统2PC无论第二阶段的决策是commit还是rollback事务性资源的锁都要保持到第二阶段才释放。而Seata的做法是在第一阶段就将本地事务提交这样可以省去第二阶段持有锁的时间提高整体效率。
Seata两阶段提交协议的演变 一阶段Seata会拦截解析SQL语义找到SQL要更新的数据在业务员数据更新前将其保存为before image随后执行业务SQL。在业务数据更新后将其保存为after image插入UNDO LOG回滚日志提交前向TC注册分支并生成行锁。 随后本地事务提交将本地事务提交的结果上报给TC由TC协调。 二阶段-提交执行提交操作说明SQL执行顺利因业务SQL在一阶段已经提交至数据库所以Seata框架只需将一阶段保存的快照数据和行锁删掉完成数据清理即可。 二阶段-回滚要执行回滚操作说明SQL执行不顺利Seata需要回滚一阶段已经执行的业务SQL还原数据。回滚方式是用before image还原数据但是在还原前还要校验脏写对比数据库当前业务数据和after image。对比数据库当前业务数据和after image。
Skywalking
SkyWalking 是一款开源的应用性能监控APM工具专注于微服务、云原生应用和分布式系统的监控与管理。它能够通过链路追踪、指标收集和分析帮助开发者定位和解决分布式系统中的性能瓶颈和故障。
SkyWalking 适用于各类分布式系统尤其是微服务架构的应用。它能够帮助开发和运维人员更好地监控和优化服务性能并在故障发生时快速定位问题源头适用于电商、金融等对系统可靠性要求较高的领域。核心功能如下
分布式追踪SkyWalking 能够在微服务调用链路中记录请求的路径包括请求的起点、经过的服务节点和终点等帮助定位问题节点。应用监控收集系统的各项性能指标如 CPU、内存、请求量、延迟等直观呈现应用的健康状况。报警与告警支持阈值告警和自定义告警当性能指标异常时自动触发报警及时提醒运维人员。服务依赖分析绘制服务间的调用关系图展示微服务架构下的服务依赖方便分析服务拓扑。
SkyWalking 分布式追踪的核心原理
链路追踪的基本概念 Trace追踪一个请求的全生命周期它跨越多个服务节点可以包含多个 span。Span描述链路中的一次操作或请求通常是一个服务的处理过程。一个 trace 由多个 span 组成且 span 之间有顺序关系表示请求流转的路径。 追踪数据的采集 每当一个请求被发送到一个微服务时SkyWalking 会在请求头中插入唯一标识符如 Trace ID 和 Span ID。这些标识符会随着请求在微服务间传递保持请求的链路关系。通过在服务端应用中安装 SkyWalking 的代理探针Agent或 SDKSkyWalking 会自动捕获请求的相关信息包括调用时间、请求的服务、处理的操作等。 追踪数据的传播 在分布式系统中每个微服务的处理请求都会携带 Trace ID 和 Span ID 信息。当请求从一个服务调用到另一个服务时后续服务会继续传递这些 ID 信息从而形成一个完整的调用链。SkyWalking 支持通过 HTTP、gRPC 等协议传递追踪信息通常是通过 HTTP 请求头如 X-B3-TraceId, X-B3-SpanId来传递。 数据的收集与聚合 每个微服务中的 SkyWalking Agent 会对本地的每个请求生成一个 Span并在 Span 完成时将其发送到 SkyWalking 后端。后端会对收集到的 Span 数据进行聚合将它们组合成完整的 Trace。Trace 包含了所有跨服务的调用信息并可以形成一个服务间的调用链。
注意事项
数据存储优化SkyWalking 生成大量追踪数据建议使用性能较好的存储方案如 Elasticsearch。对于高流量系统存储方案的性能至关重要否则会造成数据处理瓶颈。网络开销SkyWalking 的探针会收集大量追踪数据并发送至后端网络延迟可能影响监控的实时性。性能开销SkyWalking 的探针会增加一定的系统开销尽管通常开销不大但在高并发服务中需关注探针对服务响应时间的影响合理配置采样率。告警规则的合理配置设置适合系统的告警阈值避免频繁告警导致“告警疲劳”。建议针对关键性能指标如响应时间、错误率等制定精确告警规则。采样率在高流量场景下可以适当降低链路追踪的采样率以平衡系统监控的全面性和性能。
Dubbo体系
Dubbo 是一个高性能分布式服务框架致力于解决微服务架构中的服务调用、服务治理和服务注册发现问题。Dubbo 体系由多个关键组件组成包括 Dubbo 本身、服务注册中心如 Zookeeper、Nacos等共同构成完整的服务治理解决方案。
Dubbo
Dubbo是一个高性能的Java RPC框架主要用于构建和管理分布式服务广泛应用于微服务架构中。它提供高效的远程过程调用功能支持多协议如Dubbo、HTTP等和多注册中心如Zookeeper、Nacos等实现服务的自动发现和治理。Dubbo具备负载均衡、容错、动态服务发现以及扩展能力等特性提升了服务之间的可用性和可靠性。与其他框架如Spring Cloud相比Dubbo在性能上更具优势尤其在高并发和低延迟的环境中表现突出。它适用于大规模分布式系统尤其在电商平台、金融系统等需要高吞吐量和低延迟的场景中发挥着重要作用。而对于较小的项目可能需要权衡其复杂性与功能的匹配程度。
Dubbo的核心组件包括以下几个方面
服务注册与发现这个组件负责将服务提供者的服务信息注册到注册中心并让服务消费者能够发现并调用这些服务。通过注册中心服务可以在运行时动态管理。常用的注册中心有Zookeeper、Nacos等。注册与发现为分布式系统中的服务管理提供了灵活性和扩展性。协议层协议层负责定义服务之间的通信方式。Dubbo默认使用自己的Dubbo协议同时也支持HTTP、Hessian等协议。协议层通过底层的网络通信机制确保服务间的数据传输高效且稳定。序列化层序列化层将Java对象转换为字节流以便在网络中传输在接收端再反序列化回Java对象。Dubbo支持多种序列化方式包括Java原生序列化、Hessian、JSON、Protobuf等。开发者可以根据实际需求选择不同的序列化方式优化数据传输的效率和兼容性。负载均衡层负载均衡层将请求均匀地分配给多个服务实例。Dubbo支持多种负载均衡策略比如随机、轮询和加权轮询等。通过合理的负载分配系统能够更好地利用资源避免某个服务节点过载。容错层容错层负责处理服务调用时可能出现的异常。它通过重试、失败切换等策略减少系统异常带来的影响。容错机制有助于提高系统的可靠性保持系统的稳定运行。服务治理层服务治理层包括服务限流、熔断和动态配置等功能。限流可以防止系统过载熔断可以在服务不可用时迅速切断请求而动态配置则能在不重启服务的情况下调整配置增强了系统的灵活性和稳定性。监控与管理层监控与管理层通过收集服务的性能指标如调用次数、响应时间、错误率等帮助开发者实时了解服务的健康状态。通过这些数据开发者能够快速发现潜在问题并进行优化。过滤器层过滤器层让开发者可以在服务调用过程中插入自定义逻辑比如日志记录、权限校验、数据加密等。它为Dubbo提供了灵活的扩展点能根据业务需求增强框架的功能。异步调用层异步调用层允许服务的调用不阻塞当前线程提升系统的响应速度和并发处理能力。尤其在高并发场景中异步调用可以显著提高系统的吞吐量。API层API层定义了服务的接口服务提供者根据接口提供服务消费者通过调用接口访问服务。API层支持版本控制可以在服务升级时平滑过渡避免因为接口变动而导致的兼容性问题。扩展层Dubbo提供了高度的可扩展性开发者可以根据需要自定义协议、负载均衡策略、序列化方式等。通过扩展层Dubbo可以在不同的业务场景中进行灵活调整和优化。
Dubbo RPC调用原理主要包括服务的注册、发现、请求和响应的处理过程涉及客户端与服务器之间的远程调用。整个过程大致可以分为以下几个步骤
服务提供者启动服务提供者启动时会将自己提供的服务接口和实现类注册到注册中心。服务暴露时会将服务的接口、方法、调用地址、协议、版本等信息通过注册中心如Zookeeper发布出去。这使得服务消费者能够发现并调用该服务。服务消费者发现服务消费者在调用服务时首先会通过注册中心获取服务提供者的信息。消费者会查询注册中心获取到服务提供者的地址、协议、负载均衡策略等信息从而决定如何与提供者进行远程调用。代理创建在消费者端Dubbo框架会为每个远程服务接口生成一个动态代理。代理对象通过反射机制将方法调用委托给Dubbo客户端的调用框架而不是直接执行方法体。这个代理对象主要用于将消费者的请求封装为远程调用请求并将结果进行解封装。请求封装与发送消费者端调用服务方法时代理对象会把调用信息方法名、参数、超时时间等封装成一个RPC请求对象。请求对象会通过指定的协议如Dubbo协议进行序列化然后通过网络传输一般通过TCP/IP发送到服务提供者的服务端。服务端处理请求在服务端Dubbo框架接收到请求后会通过反序列化将请求数据还原为Java对象然后查找对应的服务实现通过反射机制。服务端调用相应的方法处理请求执行业务逻辑并将执行结果封装成RPC响应对象。响应返回服务端将调用结果通过网络返回给消费者。响应数据会进行序列化通过Dubbo协议传输回消费者。消费者接收到响应后会对数据进行反序列化恢复成Java对象最终将结果返回给调用者。负载均衡和容错Dubbo在RPC调用过程中会根据配置的负载均衡策略选择服务提供者。如果有多个服务提供者Dubbo会使用如随机、轮询、加权等策略来进行负载均衡。若某个服务提供者不可用Dubbo会根据容错机制进行重试或者快速失败确保服务调用的高可用性。
ZooKeeper
ZooKeeper 是一个开源的分布式协调服务主要用于在分布式系统中管理和协调大量分布式应用之间的配置和同步问题。它为分布式系统提供了高效的协调机制帮助处理分布式锁、配置管理、命名服务、集群管理等问题。ZooKeeper 的核心功能包括数据的分布式一致性、实时通知机制和高可靠性。它通过类似文件系统的节点结构来组织数据并允许客户端对这些节点进行读取、写入和监听操作。
ZooKeeper的核心组件包括以下几个部分
ZooKeeperZooKeeper 集群由多个 ZooKeeper 服务端组成通常会部署为一个主备集群。服务端负责处理客户端的请求、同步数据、保证数据一致性。ZooKeeper 使用了一个“Leader-Follower”模型其中一个节点充当主节点处理所有写请求其他节点作为从节点同步数据并处理读请求。ZNodeZooKeeper 中的数据以节点的形式存储。每个ZNode可以包含数据以及一组子节点ZNode 支持两种类型持久节点和临时节点。持久节点会一直存在直到显式删除而临时节点在客户端会话结束时自动删除。ZNode 的层次结构类似于文件系统的目录结构通过路径来标识每个节点。客户端客户端是与 ZooKeeper 服务端交互的组件客户端可以向服务端发送请求来读取数据、修改数据、监控节点变动等。客户端通过会话与 ZooKeeper 服务器保持连接会话有超时机制超过一定时间未与服务器通信ZooKeeper 会认为客户端失效进而删除客户端注册的临时节点。WatcherWatcher 是 ZooKeeper 提供的事件监听机制。客户端可以通过设置 Watcher 来监控 ZNode 的变化如数据更新、节点创建、节点删除等事件。当监控的 ZNode 发生变化时ZooKeeper 会通知客户端。Watchers 仅在首次触发事件时通知客户端需要重新设置 Watcher 来持续监控。Leader选举与写请求处理ZooKeeper 在集群中使用 Leader-Follower 模型。所有的写请求都由 Leader 节点处理Follower 节点主要负责处理读请求。Leader 节点负责协调集群中各个节点的数据同步保证集群内的数据一致性。当 Leader 节点失效时ZooKeeper 会通过选举机制选择一个新的 Leader 节点。QuorumZooKeeper 集群通过 Quorum来保证数据的一致性。集群中只有超过半数的节点同意的操作才会被提交这样在集群中的节点出现故障时仍然能够保持系统的可用性和一致性。
ZooKeeper的服务注册与发现原理主要依赖于分布式协调机制通过使用 ZooKeeper 的节点和数据来实现服务的注册、发现以及健康检查。以下是详细的注册发现流程
服务注册服务启动时客户端将自己的信息如服务地址、端口等注册到 ZooKeeper 上。通常是通过在某个指定的根路径如 /services/下创建一个临时节点例如 /services/serviceA/instance1。该临时节点包含服务的元数据如 IP 地址和端口等信息。这些临时节点在服务关闭或宕机时会被自动删除保证了系统的健康性和一致性。服务发现服务消费者通过 ZooKeeper 获取服务的注册信息。消费者通过读取 ZooKeeper 中指定路径的数据如 /services/serviceA/获取服务实例的信息。ZooKeeper 会返回所有在该路径下注册的服务实例。由于这些节点是临时的当服务实例出现故障或关闭时节点会自动删除从而保证消费者只获取到可用的服务实例。
参考文章
https://www.jianshu.com/p/cb7fa0aa47a8https://www.springcloud.cc/spring-cloud-config.htmlhttps://cloud.spring.io/spring-cloud-static/spring-cloud-confighttps://martinfowler.com/bliki/CircuitBreaker.htmlhttps://cn.dubbo.apache.org/zh-cn/https://www.cnblogs.com/jack1995/p/10920994.htmlhttps://blog.csdn.net/qq_31960623/article/details/119840131
