LBS检索容灾架构研究.docVIP

LBS检索容灾架构研究 　　摘要：文章结合LBS检索场景提出了一个稳定性容灾架构，通过过载保护、容灾环境、负载调度、分级发布等几部分相互配合，为在线检索服务提供了一个离线、在线相互配合的沙盒环境。该容灾架构能在任一个检索服务容量不足时快速地做出响应并将流量引导到安全环境下，保证对用户的影响降到最低，为服务的快速发布提供更多的保障。 　　关键词：容灾系统；过载保护；容灾cache；负载均衡；分级发布 　　随着移动互联网技术的不断发展，互联网开发模式采用持续迭代的方式来持续驱动服务的不断升级，并采用分级/灰度发布的方式实现在线迭代产品特性。互联网开发模式在快速改变着互联网研发生态的同时也引入了更多的稳定性风险，而服务的持续稳定是至关重要的，引入更快的迭代开发可能带来服务质量的下降，降低稳定性风险是研究互联网开发模式的重点。本文结合LBS检索业务场景，引入容灾体系架构，为快速迭代开发的业务构建稳定性的容灾环境，解决服务稳定性等问题。并设计一种主动容灾系统，其结合影响在线服务稳定性的若干因素，使其一旦发生异常时尽可能减少对用户的影响。 　　1在线服务稳定性综述 　　1.1影响在线服务稳定性的若干因素 　　影响在线服务稳定性的服务级因素因服务变更带来更大的稳定性风险。服务级的故障包括3个方面，其中用户请求包括突发流量和异常流量，突发流量可能导致服务上限被打破，异常流量可能导致整个服务的崩溃。变更包括服务变更、程序升级、基础数据的实时更新等。系统因素可以定义为服务所在的宿主节点的网络等突发故障或被争抢带来服务异常表现的一些因素。这类问题的触发本身是不可抗力的，但可以通过服务级的调度快速发现并隔离这些异常节点。 　　1.2主动容灾系统设计 　　主动容灾系统设计的主要目标是通过实时诊断监测可能的异常行为并立即进行补救处理，将对用户的影响降到最低甚至无影响。整体架构如图1所示。 　　整体架构包括4个部分：过载保护主要通过活跃线程状态指标快速判定服务当前是否处于过载状态，一旦过载就会立即拒绝无法及时处理的请求并向上汇报过载状态，主要通过检测活跃线程的状态趋势对服务状态作出可能的判断。容灾环境提供了保证服务稳定输出的在线环境，它由容灾cache和延迟环境2个部分组成。负载调度是面向服务的顶层节点进行调度，通过对顶层节点作过载判断或异常隔离来对顶层节点进行实时流量调度与负载均衡，当项层节点容量不足或不可用的时候，会实时将流量引到容灾系统。分级发布主要包括服务和数据的发布，通过分级发布实现数据或服务的灰度上线。 　　2在线稳定性系统设计 　　2.1过载保护 　　容量和性能对于在线服务是非常重要的，一般情况下通过扩容或性能优化不断地提升服务容量，满足更多的用户访问需求，通过不断的优化性保证用户的访问体验。对于在线服务而言，服务不可用是灾难性的。常规的容灾手段多数属于事后容灾，因此如何通过服务行为的变化快速诊断出可能的系统异常十分重要。 　　从容量的角度来讲，可以分为2个方面：一是极端情况下的服务宕机，会导致拒绝及服务容量的突然下降，服务宕机通过心跳或连接状态等都能比较快地发现；一种则是服务异常或流量突增导致系统临时容量不足，服务宕机进一步规约宕机也可认为是容量不足。 　　容量不足不等于系统完全不可用，需要极力规避服务容量不足时的雪崩效应以保证容量不足时的最大化输出，但处理不当就会导致整个系统的瘫痪，在这种情况下，一个稳定、可靠的拥塞预判检测机制就显得尤为重要。常见的拥塞判定方式包括：通过队列状态判断和根据QPS判断。 　　以上2个指标在系统的负载状态上都有一定缺陷。对于检索服务而言，磁盘读写、网络I/O消耗相对比较低，基于此观测每个线程的任务调度状态，如图2所示，其中绿色块表示被调度的任务。 　　结合图2，正常情况下在一个时间切片下活跃任务数比较小，在CPU利用率较低的时候工作线程大部分时段空闲，在线程数换I/0的模型下任务活跃代表占用了CPU时间，因为使用I/0消耗在总时间中的比例等比例放大工作线程个数，因此本文使用工作线程活跃状态表征系统负载。 　　在线程数换I/0模型下，工作线程数的设置一般会结合计算、I0的消耗去设定，如果在计算密集型服务下一般和CPU核数保持一致就可以，在I/0消耗的服务下可以根据I/0消耗占比调大工作线程数，使用I/0换计算。在检索线程模型下，设置合理的工作线程数代表了服务满载时的计算能力，因此当前服务CPU利用率的计算方法如下： 　　其中C代表线程计数，分子为活跃线程计数，分母为总的工作线程数，P则为CPU利用率。 　　对于在线服务来说，为保证服务的稳定高性能输出、多机房互备的资源储备，CPU利用率一般不希望超过40%，在这种情况下应当结合服务的计算、I/0消耗的比例，所能承载的