当前位置: 首页 > 科技观察

一篇读懂分布式开发中服务治理的文章

时间:2023-03-19 10:11:04 科技观察

我们在分布式开发中经常听到的一个词就是“服务治理”。在理解“服务治理”的概念之前,让我们先了解什么是分布式系统,分布式系统之间如何通过RPC(RemoteProcedureCall,远程过程调用)进行通信,以及如何解决RPC框架中存在的问题,这样我们才能真正理解服务治理的核心思想。分布式系统分布式系统是指多台计算机通过网络连接协作解决单台计算机无法解决的计算、存储等问题,多台计算机通过RPC进行通信。在使用分布式系统之前,首先要解决的问题就是如何拆解当前的问题。通过使用多台计算机分布式解决问题,分布式系统中的每台机器负责解决原始问题的一个子集。通常,可以使用水平或垂直拆分来拆分复杂系统。横向拆分:在无状态系统中多部署若干个实例,通过负载均衡协调每个实例加载的计算量。垂直拆分:将一个大应用拆分成多个小应用(比如将系统拆分成用户、产品、订单服务),每个小应用负责处理一部分业务。但是,虽然通过拆分解决了计算或者存储的问题,但是使用分布式技术进行开发会带来比单体应用更多的问题,比如网络异常、数据一致性、分布式系统性能等。因此,在使用分布式架构开发系统之前,有必要对分布式系统的概念和可能出现的异常情况有深入的了解。1、分布式系统常见异常服务器宕机:服务器宕机是分布式架构中最常见的异常之一。任何服务器都可能出现故障,故障的类型和次数也不尽相同。因此,分布式系统一般允许部分服务器发生故障,但要求部分服务器发生故障时不影响整个系统的正常使用。网络异常:服务器通过网络与服务器通信。如果在通信过程中消息丢失,两个节点之间将无法通信,会出现网络分裂、消息乱序等网络问题。分布式系统的三种状态:如果一个节点向另一个节点发起RPC请求,例如节点A向节点B发送消息,节点B根据收到的消息完成一些操作,并将操作结果返回给节点A、那么这个RPC请求的执行结果可能有三种状态:成功、失败、超时(未知)。我们将这三种状态称为分布式系统的三态。在设计架构时,需要考虑成功、失败、超时(未知)三种状态的处理方式。存储数据丢失:对于有状态节点,数据丢失意味着状态丢失。通常,存储数据的状态只能从其他节点读取和恢复。2、分布式系统中副本的分类分布式系统中的副本是指为分布式系统中的数据或服务提供的冗余。副本分为服务副本和数据副本两种。服务副本:多个节点提供相同的服务。该服务不依赖于本地节点的存储状态,是一种无状态服务。数据拷贝:在不同节点上持久化相同的数据。当某个节点存储的数据丢失时,可以从其他副本中读取数据。数据多副本是分布式系统解决数据异常丢失的唯一途径。由于数据分散或复制到不同的机器上,如何保证主机间的数据一致性成为难点。对于分布式系统,服务副本非常容易控制。由于服务本身的无状态特性,运维人员可以在不影响服务接口返回数据正确性的情况下动态增减服务副本数。数据副本分布在不同的计算机上。从技术角度来看,数据一致性面临着巨大的挑战。数据副本的一致性通常有以下几个条件。强一致性:任何用户或节点都可以随时读取上次成功更新的副本数据。这是所需的最高一致性,也是实践中最难实现的。弱一致性:系统不保证进程或线程在访问数据时随时返回最新更新的值。数据写入成功后,系统不承诺立即读取最新写入的值,也不承诺需要多长时间才能最终读取到最新值。最终一致性:一旦数据更新成功,每个副本上的数据最终都会达到完全一致的状态,但这需要一定的时间。然而,分布式系统也具有一些复杂的特性,如分布式系统的三态、异构、透明、并发和可扩展性等。我们在应用分布式系统的过程中需要仔细考虑这些特性的优点和副作用。3、分布式系统的设计原则异构性:由于分布式系统基于不同的网络、操作系统、计算机硬件和编程语言,因此需要考虑采用通用的网络通信协议来屏蔽异构系统之间的差异。开发者一般会选择中间件来屏蔽这些差异。透明性:分布式系统中任何组件的故障以及主机的升级或迁移对用户都是透明的。并发性:应用分布式系统的目的是为了更好地共享资源,所以系统中的每一个资源在并发环境下都必须是安全的。可扩展性:随着业务量的增加,系统必须具有可扩展性,以应对因业务量增长而增加的外部流量。故障独立性:任何计算机都可能发生故障,并且每台计算机在不同类型和不同时间发生故障。因此,分布式系统一般允许局部故障而不影响整个系统的正常使用。数据一致性:由于数据分散或复制到不同的机器上,因此需要保证服务器之间的数据一致性。负载均衡:由于分布式系统是一个多机协同系统,为了提高系统的整体效率和吞吐量,需要考虑最大限度地发挥每个节点的作用,最大限度地利用资源,避免某个节点过载或者浪费资源。4.分布式系统的指标系统的性能:系统每秒处理事务的能力,通常用TPS(TransactionsPerSecond)来衡量。系统可用性:系统在各种异常情况下正确提供服务的能力。该指标可以通过系统关闭时间与正常服务时间的比值来衡量,也可以通过某项功能的失败次数与成功次数的比值来衡量。系统可用性是分布式系统的重要指标,也是系统容错能力的体现。系统可扩展性:分布式系统通过扩展集群机器的规模来提高系统性能(提高接口吞吐量、降低接口延迟、提高接口并发度)、存储容量和计算能力。RPC框架RPC(RemoteProcedureCall,远程过程调用)是一种进程间通信方式,一种技术思想。使用RPC技术时,允许本地程序通过网络调用另一台服务器上的函数或方法。具体调用过程一般由RPC框架实现,无需编码。即无论是调用本地函数还是调用远程函数,我们写的调用代码在本质上是基本一致的。1.RPC框架的工作原理RPC框架需要屏蔽服务调用者和服务提供者各种复杂的操作,如负载均衡、序列化和反序列化、网络重试、超时等,主要由客户端、服务端和注册中心由三个角色组成,整体结构如图3-1所示。客户端(Client):调用远程服务的服务消费者。客户端调用远程服务就像调用本地函数一样。客户端负责序列化、反序列化、连接池管理、负载均衡、故障转移、超时管理、异步管理等。服务器(Server):暴露服务的服务提供者。服务器端像实现本地功能一样实现远程服务提供。服务器端需要做发送和接收数据包队列、I/O线程、工作线程、序列化和反序列化等任务。注册中心:服务注册和发现的注册中心。2.RPC调用说明一个RPC调用过程主要由五个部分组成,即客户端、客户端存根、服务器存根、服务提供者和网络传输。调用流程如图3-2所示。客户:服务调用者。客户端存根:用于存储服务器的地址信息,将客户端的请求参数等信息打包成网络报文,通过网络传输发送给服务器。Server-sidestub:接收并解包客户端发送的请求报文,然后调用本地服务进行处理。服务提供者:服务的真正提供者。网络传输:底层数据传输,可以是TCP,也可以是HTTP。服务治理业务一开始是单体应用。随着用户和访问量的增加,架构层面会发生变化,逐渐从单体应用开发向分布式应用开发转变。比如将Each模块按照特定的方法拆分成一组独立的服务,通过HTTP或RPC调用服务。随着业务量的逐渐增加,服务的数量也逐渐增加。这时候维护服务的URL地址就变得很麻烦,所以需要设计一个系统来统一管理各个服务对应的URL地址。这个系统叫做注册中心。当存在多个服务时,消费者需要按照规则调用相关服务,实现软负载均衡,实现资源利用率最大化。因此,服务注册、服务发现、负载均衡、流量调峰、版本兼容、服务熔断、服务降级、服务限流等问题都是服务拆分带来的一系列问题。如何解决这些问题,让服务运行的更稳定,就叫服务治理。一般来说,服务治理是指企业为确保事情顺利完成而实施的措施,包括最佳实践、架构原则、治理程序、法律和其他决定性因素。下面分别介绍服务治理流程中的各个环节。(1)服务:是分布式架构下的基本单元,包括一个或一组软件功能,其目的是让不同的客户端通过网络获取相应的数据,而无需关注底层实现的具体细节。以用户服务为例,当客户端调用用户服务的注册函数时,会将注册信息写入数据库,缓存起来,并发送消息通知其他与注册事件相关的系统,但调用者并不知道服务的具体处理逻辑。(2)注册中心:是微服务架构中的“通讯录”,记录了服务与服务地址的映射关系,主要涉及服务提供者、服务注册中心和服务消费者。数据流中,服务提供者启动服务后向注册中心注册服务;服务消费者(或称服务消费者)在启动服务时会从注册中心拉取相关配置放入缓存中。注册中心的好处是解耦了服务提供者和服务消费者的关系,支持弹性伸缩。当一个服务需要扩展时,只需要再部署一个服务即可。当服务启动成功后,会自动注册到注册中心并推送给消费者。(3)服务注册和发布:服务实例在启动时加载到容器中,在注册中心注册服务本身的相关信息,如接口名称、接口版本、IP地址、端口等,并通过心跳机制定期刷新注册表中当前服务的状态,以确认服务状态正常,并在服务终止时将其从注册表中删除。服务注册包括两种模式:自助注册模式和第三方注册模式。◎自注册模式:服务实例负责在服务注册中心注册和注销服务实例,服务实例必须发送心跳以保证注册信息不过期。优点是比较简单,不需要其他系统功能的支持;缺点是服务实例需要链接服务注册中心,注册代码必须在各个编程语言和框架内实现。◎第三方注册方式:服务实例由另一个类似的服务管理器注册,服务管理器通过查询部署环境或订阅事件来跟踪运行服务的变化。当管理器发现可用的新服务时,它会向注册表注册该服务,服务管理器负责注销已终止的服务实例。第三方注册模型的主要优点是服务与服务注册中心分离,不需要为每一种编程语言和架构完成服务注册逻辑。相应地,服务实例通过一个集中管理的服务进行管理;缺点是需要高可用的系统来支持。(4)服务发现:使用一个注册中心记录分布式系统中所有服务的信息,以便其他服务可以快速找到这些已注册的服务。目前有两种模式:客户端发现模式和服务端发现模式。客户端发现模式:客户端从服务注册服务中查询所有可用服务实例的地址,使用负载均衡算法从多个服务实例中选择一个,然后发送请求。它的优点是客户端知道可用服务注册中心的信息,因此可以定义多种负载均衡算法,将负载均衡的压力集中在客户端。服务器端发现模式:客户端通过负载均衡器向服务发出请求,负载均衡器从服务注册服务中查询所有可用服务实例的地址,并将每个请求转发给一个可用的服务实例。与客户端发现一样,服务实例在服务注册表中注册或注销。我们可以将HTTP服务和Nginx负载均衡器理解为服务端发现模式。优点是客户端不需要关注发现的细节,可以减少客户端框架需要完成的服务发现逻辑;客户端只需要简单地向负载均衡器发送请求。缺点是需要在服务器端配置一个高可用的负载均衡器。(5)流量削峰:利用一些技术手段削弱瞬时峰值请求,使系统吞吐量控制在峰值请求之下,也可以用来消除毛刺,使服务器资源的利用更加均衡并且足够了。常见的调峰策略包括排队、限频、分级过滤和多级缓存。(6)版本兼容性:在版本升级的过程中,需要考虑版本升级后新的数据结构是否能够理解和解析旧数据,新的协议是否能够理解旧的协议并进行适当的处??理正如预期的那样。这就需要在服务设计过程中做好版本兼容工作。(7)业务保险丝:其作用类似于家用保险丝。当服务不可用或响应超时时,已经达到系统设定的阈值。为了防止整个系统雪崩,会暂时停止对服务的调用。(8)服务降级:当服务器压力急剧增加时,根据当前业务情况和流量,对部分服务和页面进行策略性降级,以释放服务器资源,保证核心任务的正常运行。降级时,往往会指定不同的级别,面对不同的异常级别进行不同的处理。(9)服务节流:服务节流可以被认为是一种服务降级。它通过限制系统的输入输出流量来达到保护系统的目的。一般来说,系统的吞吐量是可以衡量的。为了保证系统的稳定运行,一旦达到阈值,就需要进行流量限制。限制措施包括延迟处理、拒绝处理或部分拒绝处理。(10)负载均衡策略:是用来解决一台机器不能处理所有请求的算法。当集群中的一台或多台服务器无法响应请求时,负载均衡策略会合理分配流量,让更多的服务器均衡处理流量请求,不会造成单台服务器的CPU或内存去急剧上升。