中间件技术及双十一实践·稳定性平台篇

标签: 产品和系列专题 | 发表时间:2014-03-10 10:40 | 作者:jm
出处:http://jm-blog.aliapp.com

稳定性平台——系统稳定运行的保障者

综述

大多数互联网公司都会根据业务对自身系统做一些拆分,大变小,1变n,系统的复杂度也n倍上升。当面对几十甚至几百个应用的时候,再熟悉系统的架构师也显得无能为力。稳定性平台从2011年就开始了依赖治理方面的探索,目前实现了应用级别和接口级别的依赖自动化治理。在2013的双11稳定性准备中,为共享交易链路的依赖验证和天猫破坏性测试都提供了支持,大幅度减小了依赖治理的成本和时间。另一方面,线上容量规划的一面是稳定性,另一面是成本。在稳定性和成本上找到一个最佳的交汇点是线上容量规划的目的所在。通过容量规划来进行各个系统的机器资源分配,在保证系统正常运行的前提下,避免对机器资源的过度浪费。

7.1、依赖治理实践

依赖治理的一些基础概念

依赖模型分为关系、流量、强弱,实际的使用场景有:

  • 依赖关系:线上故障根源查找、系统降级、依赖容量、依赖告警、代码影响范围、系统发布顺序、循环依赖等。
  • 依赖流量:分配流量比、优化调用量、保护大流量。
  • 依赖强弱:线上开关演练,系统改造评估。

关系数据可以通过人工梳理、代码扫描、线上端口扫描的方式获取。流量数据可以通过分析调用日志的方式获取。强弱数据则必须通过故障模拟才能拿到。故障模拟分为调用屏蔽和调用延迟两种情况,分别代表服务不可用和服务响应慢的情况。依赖的级别分为应用级依赖和接口方法级依赖,两个级别的故障模拟手段完全不同,下面分开来描述。

应用级别强弱依赖检测

应用级别故障模拟比较做法有几种,即:修改代码,写开关,远程调试,填错服务的配置项。这几种方式对配置人要求相对较高,并且对应用代码有一定的侵入性,所以没有被我们采用。Linux有一些原生的命令(如iptables、tc)默认就有流量流控功能,我们就是通过控制linux命令来达到模拟故障的效果。命令举例:

iptables -A INPUT -s xxx.xxx.xxx.111 -j DROP

上面的命令表示:当前主机屏蔽掉来自xxx.xxx.xxx.11的网络包。

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 6000ms
tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dst xxx.xxx.xxx.111/32 flowid 1:1

命令表示:在网卡eth0上面设置规则,对xxx.xxx.xxx.111的网络包进行延迟,延迟的时间是6000ms。

接口级别强弱依赖检测
理想情况下,我们希望确定任意一次远程方法调用的强弱,确定到接口方法级别的强弱数据。要想达到这个目的,就只能在通信框架和一些基础设施上面做文章。基于这个思路,我们设计了接口级别强弱依赖检测的方案。方案如下:

过滤规则配置组件(服务器端)
过滤规则配置组件提供一个web界面给用户,接受用户配置的屏蔽指令和测试机器IP信息,并把配置信息更新到配置中心组件中去。
配置的规则举例:

client|throw|xxx.ItemReadService:1.0.0.daily@queryItemById~lQA|java.lang.Exception
client|wait|xxx.ItemReadService:1.0.0.daily@queryItemById~lQA|4000

上面的规则分别表示在客户端发起对远程接口xxx.ItemReadService:1.0.0.daily的queryItemById~lQA调用时,在客户端模拟一次异常或延迟4000毫秒后调用。

配置中心组件

配置中心组件的主要作用是接受客户端(过滤规则配置组件)发来的配置信息,持久化配置信息到存储介质中,并实时把配置信息实时推送到配置中心的所有客户端(即每一个故障模拟组件)。此部分功能通过中间件开源产品Diamond实现。

分布式服务调用组件

发生RPC调用时,会传递一些调用信息,如:RPC发起者的IP、当前的方法名称、下一级调用的方法名称。

故障模拟组件

故障模拟组件是一个插件,可以被服务调用组件(HSF)加载。插件可以接受配置中心推送的配置信息,在服务调用组件发生调用前都比对一下据配置信息的内容,当RPC发起者的IP、调用方法都合条件的时候,发生故障模拟行为,从而达到故障模拟的效果。

7.2、容量规划实践

线上容量规划最重要的一个步骤为线上压力测试,通过线上压力测试来得知系统的服务能力,同时暴露一些在高压力场景下才能出现的隐藏系统问题。我们搭建了自己的线上自动压测平台来完成这一工作,线上自动压测归纳起来主要包含4种模式:模拟请求、复制请求、请求引流转发以及修改负载均衡权重。

模拟请求

完全的假请求,可以通过代码或者采用工具进行模拟,常用到的工具有http_load、webbench、apache ab、jmeter、siege等。模拟请求有一个很明显的问题,即如何处理“写请求”?一方面由于“写请求”的场景不大好模拟(一般需要登录),另一方面“写请求”将要面临如何处理一致性场景和脏数据等。模拟请求方式的压测结果准确性我们认为是最低的。

复制请求

可以看成是半真实的假请求。说它半真实,因为它是由复制真实请求而产生。说它是假请求,因为即使复制的真实请求,它的响应是需要被特殊处理的,不能再返回给调用方(自从它被复制的那一刻,它就已经走上了不真实的轨道)。复制请求同样可以通过代码实现(比如我们有通过btrace去复制对服务的调用), 此外也有一些比较好用的工具:比如tcpcopy等。如果想在nginx上做请求复制,可以通过nginx的nginx post_action来实现。“复制请求”模式被压测的那台机器是不能提供服务的,这将是一个额外的成本,此外复制请求模式的压测结果准确性也会由于它的半真实而打上折扣。

请求引流转发

完全真实的压测模型,常用于集群式部署的web环境当中。我们对于apache和nginx的系统基本上都采取这种方式来做线上压力测试。用到的方式主要通过:apache 的mod_jk和 mod_proxy模块;nginx的proxy以及upstream等。这种方式压测的结果准确性高,唯一的不足是这种方式依赖系统流量,如果系统流量很低,就算是将所有的流量引到一台机器上面,仍不足以达到压测目的。请求引流转发模式的压测结果准确性高。

修改负载均衡权重

同样为完全真实的压测模型,可以用于集群部署的web环境中,也可用于集群部署的服务类系统。在web环境中我们通过修改F5或者LVS的机器负载均衡权重来使得流量更多的倾斜到其中的某一台后者某几台机器上;对于服务类系统,我们通过修改服务注册中心的机器负载均衡权重来使得服务的调用更多分配到某一台或者某几台机器上。修改负载均衡权重式的压测结果准确性高。

系统的服务能力我们定义为“系统能力”。在系统机器配置都差不多的情况下,系统能力等于线上压力测试获取的单台服务能力乘以机器数。在得知了系统能力之后,接下来我们需要知道自己的系统跑在怎么样的一个容量水位下,从而指导我们做一些决策,是该加机器了?还是该下掉一些多余的机器?通常系统的调用都有相关日志记录,通过分析系统的日志等方式获取系统一天当中最大的调用频率(以分钟为单位),我们定义为系统负荷;当前一分钟的调用频率我们定义为当前负荷。计算系统负荷可以先把相关日志传到hdfs,通过离线hadoop任务分析;计算当前负荷我们采用storm的流式计算框架来进行实时的统计。

水位公式

系统水位 = 系统负荷 / 系统能力;当前水位 = 当前负荷 / 系统能力。

水位标准

单机房(70%);双机放(40%);三机房(60%)。
单机房一般都是不太重要的系统,我们可以压榨下性能;
双机房需要保障在一个机房完全挂掉的情况下另一个机房能够撑得住挂掉机房的流量;
三机房同样需要考虑挂掉一个机房的场景后剩下两个机房能够撑得住挂掉机房的流量。

机器公式

理论机器数 = (实际机器数 * 系统负荷 * 系统水位)/ (系统能力 * 水位标准)
机器增减 = 理论机器数 – 实际机器数

7.3、稳定性平台双11准备与优化

强弱依赖检测面临的最大挑战就是如何使用户使用方便,接入成本最小,主要需要解决下面两件事情:

  • 如何复用现有的测试用例?
    我们开发一个注解包,里面封装与CSP的交互协议。服务器端完成测试环境的管理,测试用例端专注应用系统的验证。这是一种测试平台无关的方式,不需要修改现有的测试代码,只需要配置注解的方式就使测试用例支持了强弱依赖验证的功能。
  • 如何解决故障模拟组件覆盖不全导致的验证局限?
    依赖调用一定存在client和server端,很有可能出现一端没有安装故障模拟组件的情况。为此,我们改造了故障描述协议,增加了client和server两种模式,只要client或server有一方安装了故障模拟组件就可以完成强弱依赖校验。

小结

稳定性平台通过依赖治理、容量规划、降级管理、实时监控等手段,对阿里各系统稳定性的治理给予了支持。未来我们将继续深挖稳定性这个领域,汇总各种数据,真正做到稳定性的智能化、自动化。

系列文章:

中间件技术及双十一实践之中间件总体介绍http://jm-blog.aliapp.com/?p=3359

中间件技术及双十一实践之软负载篇http://jm-blog.aliapp.com/?p=3450

中间件技术及双十一实践·服务框架篇http://jm-blog.aliapp.com/?p=3462

中间件技术及双十一实践·EagleEye篇http://jm-blog.aliapp.com/?p=3465

《中间件技术及双十一实践·消息中间件篇》http://jm-blog.aliapp.com/?p=3483

《中间件技术及双十一实践·数据篇》http://jm-blog.aliapp.com/?p=3490

《中间件技术及双十一实践·应用服务器篇》http://jm-blog.aliapp.com/?p=3495

 

如果觉得内容还行,请分享给更多的人…

转发:中间件技术及双十一实践之中间件总体介绍

转发:中间件技术及双十一实践之软负载篇

转发:中间件技术及双十一实践·服务框架篇

转发:中间件技术及双十一实践·EagleEye篇

转发:中间件技术及双十一实践·消息中间件篇

相关 [中间件 技术 双十一] 推荐:

中间件技术及双十一实践·中间件总体介绍

- - 阿里中间件团队博客
本文发表在《程序员》2014年1月刊:11.11背后的技术 http://www.csdn.net/article/2013-12-23/2817882. 阿里巴巴中间件与稳定性平台团队,是一个给业务应用团队以提供低成本,高可用,可扩展的弹性互联网系统解决方案为己任的技术团队,前身是成立于7年之前的淘宝平台架构部,而后随着业务领域,尤其是针对性能和稳定性技术领域的成功探索与突破,目前已经发展为一个涵盖消息通信,数据处理,性能优化和稳定性等各类技术的互联网架构服务平台.

中间件技术及双十一实践·消息中间件篇

- - 阿里中间件团队博客
消息中间件——分布式消息的广播员. 消息中间件是一种由消息传送机制或消息队列模式组成的最典型的中间件技术. 通过消息中间件,应用程序或组件之间可以进行可靠的异步通讯来降低系统之间的耦合度,从而提高整个系统的可扩展性和可用性. Notify是淘宝自主研发的一套消息服务引擎,是支撑双11最为核心的系统之一,在淘宝和支付宝的核心交易场景中都有大量使用.

中间件技术及双十一实践·数据篇

- - 阿里中间件团队博客
数据层——分布式数据存储的桥梁. 大型互联网架构中,数据存储会面临读写容量瓶颈问题,像淘宝双十一活动,核心数据存储集群读写日访问量可以达到100亿以上,在这种场景下,单机数据库方式必定面临极大挑战,类似的场景也在一些传统使用IOE的企业中成为一种制约业务发展的致命要素. 而在阿里集团内,TDDL体系就是解决此种场景的利器, 这个体系是基于廉价pc和开源mysql、以客户端依赖方式、分库分表为主要手段、集中化数据库配置等几个关键要素构建起来, 成为阿里集团接入mysql的标准,提供整个集团上千个应用的数据库访问.

中间件技术及双十一实践·稳定性平台篇

- - 阿里中间件团队博客
稳定性平台——系统稳定运行的保障者. 大多数互联网公司都会根据业务对自身系统做一些拆分,大变小,1变n,系统的复杂度也n倍上升. 当面对几十甚至几百个应用的时候,再熟悉系统的架构师也显得无能为力. 稳定性平台从2011年就开始了依赖治理方面的探索,目前实现了应用级别和接口级别的依赖自动化治理. 在2013的双11稳定性准备中,为共享交易链路的依赖验证和天猫破坏性测试都提供了支持,大幅度减小了依赖治理的成本和时间.

中间件技术及双十一实践·应用服务器篇

- - 阿里中间件团队博客
应用服务器——系统运行的托管员. 阿里巴巴集团有国内最大规模的Java系统,几万台的应用服务器规模也空前庞大,目前主要使用的应用服务器有Tomcat,JBoss和Jetty三种. 阿里巴巴自从2004年开始转向Java技术平台后,先后经历了从WebLogic到Jboss和Tomcat迁移. 到了2008年,随着更为轻量级的Tomcat和Jetty容器的迅速发展,越来越多的应用系统开始尝试使用Tomcat或Jetty作为底层应用服务器.

阿里双十一数据库技术

- - Hello Database
真的很抱歉,我的博客已经很久没有更新了,因为花了太多的时间在微博和微信上,当然最主要的原因还是工作实在太忙了,仅剩的那点业余时间都用来陪娃了. 从2012年开始,工作重心转移到了淘宝和天猫,我的技术方向也发生了改变,2012年和2013年,经历了两次双十一,在这个过程中学到了很多东西. 尤其是2013年的双十一,系统准备的非常充分,技术上有很多创新,团队也得到了成长.

女人们,这些技术男真的被“双十一”逼“疯”了!

- - 博客园_新闻
每到“双十一”都是女人购物狂欢日,你家女人是不是都守到电脑前、手机上抢到手抖. 可是你有没有想过,这里面支撑这么多人疯狂购物的技术系统码农们都是怎么过的. 前些日子遇到了淘宝的一个技术小二庄卓然(南天),听他嘚啵嘚啵他那些被“双十一”逼疯的事,很有感触起来. 他和他的技术小二团队,是马云主动求合照的怪咖;是在辣妹热舞面前,也要忙着秒单的“死技术男”;婚礼当晚不是洞房,是赶回杭州加班“双十一”;在“双十一”让老婆怀上了孩子,还抽烟、喝红牛⋯⋯;因为一个系统错误,差点被逼得跳下 23 楼.

消息中间件的技术选型心得-RabbitMQ、ActiveMQ和ZeroMQ

- - haohtml's blog
RabbitMQ、ActiveMQ和ZeroMQ都是极好的消息中间件,但是我们在项目中该选择哪个更适合呢. 下面我会对这三个消息中间件做一个比较,看了后你们就心中有数了. RabbitMQ是AMQP协议领先的一个实现,它实现了代理(Broker)架构,意味着消息在发送到客户端之前可以在中央节点上排队.

mycat 数据库中间件

- - Oracle - 数据库 - ITeye博客
出处:http://blog.csdn.net/nxw_tsp/article/details/56277430. 实习的时候,在一个项目当中,项目经理要求把原先的MySQL数据连接基于mycat来进行改造. 当时就在想MyCat是什么东西. MyCat是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里.

淘宝双十一架构优化及应急预案

- - InfoQ cn
 每年的双十一,在整体架构上最依仗的是过去几年持续建设的稳定的服务化技术体系和去IOE带来整体的扩展性和成本的控制能力. 今年在架构上做的比较大的优化有三点:. 第一是导购系统的静态化改造. 今年淘宝和天猫都分别根据自身的业务特性进行了Detail页面的静态化改造,但核心的思路都是通过CDN+nginx+JBoss+缓存的架构,将页面信息进行静态化缓存.