腾讯云运维干货沙龙-海量运维实践大曝光 (二)

作者丨魏旸:腾讯高级工程师,具有15年运维经验的专家。负责QQ空间、微云、QQ空间相册等的运维工作。

12月16日,首期沙龙“海量运维实践大曝光”在腾讯大厦圆满举行。沙龙出品人腾讯运维技术总监、复旦大学客座讲师、DevOps专家梁定安,讲师腾讯手机QQ运维负责人郭智文,腾讯高级工程师魏旸,腾讯SNG资深运维专家周小军出席沙龙,并带来精彩的技术分享。为了便于大家学习,特将本次沙龙讲师的演讲内容进行了整理。您也可以在腾讯织云公众号下载本次演讲PPT。

背景

腾讯社交业务包括QQ、QQ空间、QQ相册等核心业务。核心业务按深圳、天津和上海三地分布,各支撑华南、华中、华东、华北、西北、西南等大区的用户访问。

大家都知道核心业务多地部署物理容灾,名字服务、负载均衡等手段架构容灾。但是当机房、网络等大范围故障真正发生时,我们要怎么做才能保证业务持续可用?拿前一段时间腾讯深圳某个机房光纤被挖断的案例来讲,业务碰到的问题:

  1. 机房爆炸了,会影响多少用户?
  2. 是否需要调度?
  3. 怎么调度?
  4. 天津机房覆盖范围的用户调度到哪里?调多少?
  5. 怎么调度?

带着这些问题,我简单介绍一下空间SET化分布异地多活方案。

为什么要做SET?

提升质量,提升速度,提升效率,节约成本。

业务通过SET化部署在多个物理机房,当某个机房故障时,我们可以快速切换服务到其他机房,可以做到物理容灾。同时,多地部署也提供了用户就近接入的能力,提升用户体验。再者,业务关联的服务部署在同一个城市或者机房,能够极大减少业务之间的机房穿越带宽,降低成本。最后,SET的复制结合织云的快速部署能力,我们能够快速复制并在不同地域部署多个业务SET。

SET的属性

简单来说,SET是一个包含了多个标准化模块的集合,同时包含了更多的业务属性,比如业务形态,核心指标,柔性策略,地域,调度策略等等。

怎么分SET?

横向分布与条带化的思维  海量用户按不同比例被分流到不同的专区访问。比如用户接入维度,我们划分了PC、移动端SET,同时在移动端我们又可以细分为安卓和苹果用户。比如运营商,比如地域分布。每一个SET都需要有可度量的指标,空间业务主要根据SET内模块负载、可支撑的用户量、和实时交易量等维度来评估一个SET。

SET模型

在有了可度量的SET标准后,我们就可以基于自己的业务形态来创建SET模型了。以空间为例,用户登录进空间首先会看到自己发表的历史说说,相册,好友动态等等信息,我们把这一类的业务场景划分为读数据SET。用户会在空间上发说说,上传照片或视频,我们把这一类的业务场景划分为写数据SET。同时深圳的PC或者移动端用户更新了空间,数据需要同步到其他地域的后端存储上,空间有一套专用的同步中心架构来保证数据同步。

我们基于空间的业务场景制定的一个大致的模型就是这样:根据接入层区分用户,单点写,多点读,数据同步模块保证多点读的数据一致性。

命名规范:

初步模型制定好以后,我们需要针对不同的架构和业务场景来划分不同的SET。比如空间首屏,主要由空间的信息中心模块来负责数据拉取展现,我们把信息中心相关联的业务模块都统一划分为I类SET。再根据不同的

我们还根据不同数字代表不同的地域信息和SET顺序。

1) 名称分为2段,用“_”分割;第1段固定为SET,表示专区;

2) 第二段分为4节,每节占一位,前3位与目前规则一致:

3) SET类型,简写为A、D 、B、I,分别代表接入、数据SET、基础数据,信息中心等;

4) 地域信息,分别有深圳,上海、西安等,用0、1、2分别按序增加,最多到16进制等

5) SET数序号,从1、2、3开始,最多到16进制的F;

6) 业务产品信息,即Qzone为各业务搭建的SET,用一个字母代替,如P、G、U分别代表如PENGYOU、3G、UGC等

同步中心

同步中心是空间业务SET化能力的一个重要组件,业务数据的同步都依赖同步中心。简单介绍一下同步中心的架构:单写多度的业务讲数据接入同步中心后,同步中心通过多种技术手段保证数据同步到多地的读SET。同步中心架构较复杂,这里主要介绍一下同步中心的有序转发:

许多业务对用户请求处理的先后顺序有很严格的要求,为了实现用户请求的有序转发,同步中心做了三个功能:

  1. 接入机转发请求到存储机使用有状态l5,确保同一个号码的请求流水落到同一台机器上。
  2. 固定进程读取固定号段,平均分配每个进程处理的号段,并且确保同一个号码的请求由同一个进程处理。
  3. 使用半异步方式进行转发,批量读取流水,对不同号码的请求流水并发转发,对相同号码的流水进行串行转发。

空间实际的SET展示

SET链路

SET内部和不同SET的业务模块都是通过名字服务来相互访问的

用户层GSLB->STGW=TGW+Nginx,Nginx自动获取vip

接入->逻辑:L5,vip->l5名字服务。负载均衡的时候有过载保护

逻辑->存储:L5。Stgw和L5都是腾讯自研的路由、名字服务组件。调度都是基于名字

服务来实施。L5有SET化的标签,可以让SET的服务配置文件保持一致的情况下,服务只在SET内调度。可以极大提升SET的部署效率。

SET容量管理:

指定好的SET,需要通过压测来找出SET内业务模块资源的最优配比。我们会通过调度现网用户来对SET做压测,通过压测找出SET内某个模块的短板并及时调整资源配比。同时,随着SET内模块服务的升级,服务性能也在变化,我们会定期做调度演习来压测SET的完整链路,及时更新SET内模块的资源配比,可支撑用户数等SET核心指标。

SET的部署和扩容

在制定好SET模型,明确了每个SET可以支撑多少用户量,对应的业务场景,包含了多少个模块,可以支撑多少用户后,就可以开始着手SET部署了。每个SET建立一个模板,录入SET内包含的模块,模块内服务、权限、文件等信息保持一致,不同SET的配置不同

SET的复制根据SET模板快速部署。这些信息最后会同步到织云,由织云来快速部署服务。一个SET内几十个模块,几百台服务器可在10分钟内完成自动化部署上线 。

SET的监控

针对SET内不同的业务架构,业务形态,我们也开发了配套的监控工具。

SET的调度

前面主要说了为什么要做SET,怎么做,以及怎么维护和监控,回到深圳机房光纤被挖断的问题上来,我们是怎么做的?

每个SET都有可衡量的指标,模块设备的平均负载都在40%左右。

如果网络故障影响到了用户接入W01 SET,我们会调整stgw将用户转移到部署在另一个机房的W02 SET。如果W01 访问I01故障,我们可以把W01的访问切换到W02。如果整个深圳机房都不可访问,我们则会把请求切换到上海、天津的SET中。

柔性策略:

重大活动期间,用户量可能会突增几倍甚至十几倍,靠堆设备不现实。我们针对这类场景制定了柔性策略,当SET容量达到一定的标准时,比如CPU负载达到70%,我们就会开启业务的柔性策略,牺牲用户部分非核心功能体验来保证业务整体可持续可用。柔性策略有分级,SET容量没达到一个标准就会自动启用不同的柔性策略。

相关文章

腾讯云运维干货沙龙-海量运维实践大曝光 (一)

腾讯云运维干货沙龙-海量运维实践大曝光 (三)

沙龙PPT下载地址:

https://share.weiyun.com/5c406a57164ed4cf7e248160aebf74c3

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏PPV课数据科学社区

大数据分析需要把hbase、mysql等数据导入hive吗?

看做什么,如果不需要对数据进行实时处理,那么大部分情况下都需要把数据从hbase/mysql(数据库)“导入”到hive(数据仓库)中进行分析。“导入”的过程中...

3565
来自专栏数据和云

时移世易:遵从既往经验致 1.5PB 数据删除,Google SRE是如何应对的?

本文出自《SRE:Google运维解密》,由Google资深SRE 孙宇聪 担任译者,首次深度剖析Google SRE。 Google Music——2012 ...

33012
来自专栏后端技术探索

淘宝高并发订单的数据库方案

周末参加了@淘宝技术嘉年华 主办的技术沙龙, 感觉收获颇丰,非常感谢淘宝人的分享。这里我把淘宝下单高并发解决方案的个人理解分享一下。我不是淘宝技术人员,本文只是...

1172
来自专栏EAWorld

服务都微了,编排怎么整?

目录: 1. 编制、编排傻傻分不清楚 2. “编排”的关键在于流程+适配 3. “编排”中的分布式事务应满足最终一致性 4. “编排”需要更友好的运维工具支撑...

4916
来自专栏大数据和云计算技术

超融合方案分析系列(8)SmartX超融合方案分析

引 言 作者是国内研究超融合相当早的专家,有非常强的理论基础和实战经验。上几篇分析文章,对nutanix/VSAN/深信服/H3C/EMC等厂家的深入分析,引起...

5366
来自专栏包子铺里聊IT

[包子分享] 构架模式: Microservices Architecture

http://baozitraining.org ---- ? 微服务构架是近年来比较流行的服务端应用构架,由其非常好的可伸缩性,稳定性以及灵活的协同开发模...

2836
来自专栏Hadoop实操

大数据凉了?No,流式计算浪潮才刚刚开始!

AI 前线导读:本文重点讨论了大数据系统发展的历史轨迹,行文轻松活泼,内容通俗易懂,是一篇茶余饭后用来作为大数据谈资的不严肃说明文。本文翻译自《Streami...

1706
来自专栏祝威廉

数据天生就是流式的

部门目前核心其实就是流式计算,从根部开始(一个超大的Kafka集群)开始,延伸出一个超级庞大的树形结构。整个过程都是数据自我驱动进行流转,没有使用类似Azkab...

674
来自专栏最新技术

大数据架构的未来

大家应该都清楚,数据正在以巨幅的速度增长。如果能够有效地利用这些数据,可以发现非常有价值的内容,然而传统技术(许多早在40年前设计的,比如RDBMS这样的技术)...

57512
来自专栏腾讯技术工程官方号的专栏

腾讯基于全时态数据库技术的数据闪回

作者简介:李海翔,网名“那海蓝蓝”,腾讯金融云数据库技术专家。中国人民大学信息学院工程硕士企业导师。著有《数据库事务处理的艺术:事务管理和并发访问控制》、《数据...

10.6K3

扫码关注云+社区