更新时间:2023-11-07 GMT+08:00
服务治理概述
服务治理是一个非常宽泛的概念,一般指独立于业务逻辑之外,给系统提供一些可靠运行的系统保障措施。针对微服务场景下的常用故障模式,提供的保障措施包括:
- 负载均衡管理:提供多实例情况下的负载均衡策略管理,比如采用轮询的方式保障流量在不同实例均衡。当一个实例发生故障的时候,能够暂时隔离这个实例,防止访问这个实例造成请求超时等。
- 限流:流控的主要目的是提供负载保护,防止外部流量超过系统处理能力,导致系统崩溃。流控还被用于平滑请求,让请求以均匀分布的方式到达服务,防止突发的流量对系统造成冲击。
- 重试:重试的主要目的是保障随机失败对业务造成影响。随机失败在微服务系统经常发生,产生随机失败的原因非常多。以Java微服务应用为例,造成请求超时这种随机失败的原因包括:网络波动和软硬件升级,可能造成随机的几秒中断;JVM垃圾回收、线程调度导致的时延增加;流量并不是均匀的,同时到来的1000个请求和1秒内到来的1000个请求平均分布对系统的冲击是不同的,前者更容易导致超时;应用程序、系统、网络的综合影响,一个应用程序突然的大流量可能会对带宽产生影响,从而影响到其他应用程序运行;其他应用程序相关的场景,比如SSL需要获取操作系统熵,如果熵值过低,会有几秒钟的延迟。 系统不可避免地面临随机故障,必须具备一定的随机故障保护能力。
- 隔离仓:隔离仓通常针对系统资源占用比较多的业务进行保护。比如一个业务非常耗时,如果这个业务和其他业务共享线程池,当这个业务被大量突发访问时,其他业务都会等待,造成整个系统性能下降。隔离仓通过给资源占用比较多的业务分配独立的资源池(一般通过信号量或者线程池实现),避免对其他业务造成影响。
- 降级:降级治理是在业务高峰期时,需要临时减少对于目标服务的访问,达到降低目标服务负载;或者屏蔽对于非关键服务的访问,保持本服务的核心处理能力的治理措施。
服务治理的复杂性在于没有任何治理措施是适用于所有场景的。对于一个应用场景工作良好的治理手段,在另外一个场景可能成为问题。在业务运行周期,根据业务运行状态和指标,动态的更新治理策略非常重要。
在业务系统中使用服务治理,通常包括下面几个步骤:
- 开发业务。这个过程一般比较少关注服务治理的内容,以交付业务功能为重心。微服务开发框架针对常用的系统故障,一般都默认提供了保障措施,选择合适的微服务开发框架,可以节省DFx的时间。
- 性能测试和故障演练。这个过程中会发现非常多的系统不稳定问题,服务治理的策略会在解决这些问题的过程中应用,并写入配置文件作为应用程序缺省值。
- 业务上线运行。上线运行的过程中碰到未考虑的场景,需要采用配置中心动态调整治理参数,以保障业务平稳运行。
上面的3个步骤在整个软件生命周期会不断迭代完善。描述如何使用所有的治理能力是复杂的,ServiceComb引擎针对不同的微服务开发框架,提供了一个统一的基于流量特征的服务治理能力。如果使用微服务框架开发应用,在应用托管后启动应用,微服务会自动注册到对应的ServiceComb引擎,您可以到微服务引擎控制台进行服务治理的相关操作请参考治理微服务。
本章节重点介绍如何使用基于流量特征的服务治理能力。
父主题: 使用服务治理