您的位置:首页 > 其它

服务的可靠性设计

2017-04-03 07:45 190 查看
相比于传统的本地Java API调用,分布式服务面临的风险更高

1)网络类故障:链路闪段,读写超时等

2)序列化和反序列化失败

3)畸形码流

4)服务端流控和拥塞保护导致的服务调用失败

对于应用而言,分布式服务框架需要具备足够的健壮性,在平台底层能够拦截并向上屏蔽故障,业务只需要配置容错策略,即可实现高可用性

服务状态监测:

1)基于服务注册中心的状态监测

通常会使用服务注册中心进行状态监测,当监测到有服务不可用时,会将故障的服务信息广播到集群所有节点,消费者接收到故障通知消息之后进行故障节点隔离

2)链路有效性状态检测机制:消费者和服务者之间默认通过长连接,双方通过双向心跳来检测链路的可用性

在一些特殊的场景中,可能会出现消费和和注册中心之间,服务提供者和消息中心之间网络可达,但是消费者和服务提供者之间消息不可达的情况,注册中心并不能检测到这种服务异常,但是如果消费者仍然向服务提供者仿效西,此时的写操作会失败

为了解决该问题,常使用服务注册中心检测+服务提供者和消费者之间的链路检测的双重建策来保障服务的可靠性,消费者通过心跳检测到服务异常之后主动释放链接,清除地址信息

服务健康检测:在集群环境中由于硬件性能差异,服务提供者的负载不均等原因,若采用随机路由分发,会导致负载较重的服务提供者不堪重负被压垮

利用服务的健康检测,可以对集群的所有实例进行体检,根据体检的结果来调配路由权重,通常根据下边的指标:1)服务调用延时  2)服务QPS  3)服务调用成功率  4)基础资源使用情况,如 堆内存,CPU使用率等

服务故障隔离:

1)进程级隔离

主要通过将服务部署到不同的进程池来实现故障隔离,eg 将订单、购物车等核心服务独立部署到一个进程池,与其它非核心服务进行隔离,而其它非核心服务可以合设共享同一个线程池,防止服务署过多导致线程资源紧张服务发布的时候可以指定服务发布到哪个线程池,若未指定线程池,则投递到默认线程池  

这种隔离可以实现服务的故障隔离,但是并不充分,假如某个服务发生了内存泄漏,会导致整个进程不可用,即实现资源调度层的隔离仍然无法保证其它服务不受影响          

2)VM级隔离

通过将基础设施虚拟化、服务化,将应用部署到不同的VM中,利用VM对资源层的隔离可以实现更高

3)物理机故障隔离

服务器宕机时要能够实现与位置无关的自动切换,保证容错

4)机房故障隔离

两个机房对等部署

5)服务注册中心,对等集群设计,一台宕机,自动切换

6)监控中心 集群宕机之后,只丢失部分采样数据,依赖性能KPI采样数据的服务健康度检测功能不能正常使用服务提供者和消费者仍然可以正常使用,业务不会中断
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: