2012, 在微信红包种一棵 "树"
"微信红包是什么? 相当于天天秒杀"
腾讯内部有这样一个传统, 一些快速成长的业务或遇到一些突发事件, 公司内会快速集结一直技术团队来支援, 这样的队伍被称为 "特种部队".
2014 年冬天, Eric 就加入了微信红包 "特种部队".2011 年, 微信上线, 2014 年, 微信红包横空出世, 那一年除夕夜, 微信红包摇一摇总次数达到 110 亿次, 峰值 1400 万次 / 秒. 如何扛住海量数据, 高并发的挑战?
在 Eric 看来, 微信红包这个场景挺有意思,"电商有一个秒杀, 微信红包是什么? 相当于天天秒杀."
单一的支付场景其实挑战不大, 发一个红包到一个一两百人的群, 可能几秒钟就被抢完, 整个业务链完成后需要调用的数据库, 存储, 除了高并发下的平均延时要求是非常高, 也需要非常低的尾延时. 支付背后的金融属性又需要被严肃对待, 一分钱都不能错.
在这个阶段, 腾讯引入了一致性协议, 广义事务 (包括单机事务, 多地多中心分布) 等技术方案, 保障了数据的可用性和一致性.
2012 年是中国互联网的分水岭, 手机 QQ 的消息数第一次超过了 QQ, 大多数用户的主要时间开始花在手机上.
2012 年之前, 腾讯几乎所有人都在做 PC 互联网, 无线应用部门负责把公司所有的产品无线化. 当用户都开始往手机上转移, 各部门也纷纷醒悟过来. 2012 年, 腾讯完成了大的组织变革和转型, 开始全 BU 的无线化.
移动互联网对于技术的要求与 PC 互联网并不一样: 首先, PC 互联网是基于几乎全球唯一的 Windows 平台, 移动互联网则要面对 iOS,Android,WP, 黑莓等多种系统平台, 各类应用需要开发适配不同 OS 版本; 其次, 移动互联网的地盘面积是三到六寸大的移动终端屏幕, 手机, 平板电脑等算力较差, 硬盘, 内存, CPU 型号等参差不齐, 服务器就需要体现多样性.
微信的出现, 帮助腾讯获得了第一张移动互联网时代的 "船票", 同时也提出了新的挑战 -- 比如需要在用户基数庞大的情况下处理高并发问题; 社交关系链对数据库, 存储调用的安全性和稳定性要求极高; 每次微信版本更新都需要适配不同手机型号, 不同操作系统.
为此, 工程师们决定在数据库上种上一棵 "树", 也就是在 NoSQL 数据库上实现关系数据库才有的树结构.
换句话说, 整个数据库结构不再是一个统一的二机制数据了, 而是一个关系型数据库的树枝状结构, 这棵树分一, 二, 三, 四级的分级, 设置父节点, 子节点, 生枝节点, 整个关系就出来了, 当其中某一个枝节需要修改时, 只需要改那个枝节, 数据量就会减少很多.
"种树" 还有一个好处, 查询效率很高. 例如抢红包这个场景, 用户需要回去查询朋友圈抢红包的记录, 按照以前的做法, 需要把用户所有抢红包记录全都拉出来, 数据量就很大了. 而在 "树" 的结构中, 当你发起一个查询时, 只需要查一个节点就行, 不需要把整个数据拉出来再往里面塞.
2009 年至 2012 年, QQ 的体量从 1000 万在线发展到 1 亿在线; 2012 年及随后的 6 年间, 微信日活跃用户数从 1 亿发展到 10 亿. 在姚星看来, 腾讯贡献的最大价值其实是从 1998 年开始, 经历 QQ,QQ 空间, 微信积累的技术方法论: 动态运营, 云中成长, 有损服务.
2012 年还有一个重要节点 -- 虚拟化技术的成熟. 虚拟化的过程, 是把物理机变成虚拟机的过程, 这意味着在超大规模数据中心和高速互联网络的基础上提供云服务成为了可能, 腾讯云主机管控平台 Vstation 做到了每分钟交付千台虚拟机的能力, 使得一个中等规模公司的计算需求可以快速得到满足.
虚拟化是云计算区别于传统计算模式的核心特点, 也见证着下一个时代的到来.
云潮涌来
"腾讯走向云的时代, 是长期以来技术发展, 演进的必然."
为了支撑起 QQ 农场的正常运行, 腾讯曾在短短一个月内额外采购与上架了几千台服务器到机房. 这也让腾讯意识到,"流量到来前, 如何设计一个高可用的 IT 架构","流量激增时, 如何快速补充服务器资源","流量下降后, 如何不浪费闲置服务器资源" 是业界普遍存在的难题. 而这正是腾讯多年服务海量用户所积累的能力. 因此, 腾讯要把这种能力通过腾讯云开放给合作伙伴.
许多人还记得 2014 年滴滴和快的之战. 那个冬天, 为了抢占市场, 大量补贴像雪花般投放给用户, 滴滴的订单量从十万快速增加到百万级别, 每到早晚高峰, 系统和程序员们不堪重负:
交易表庞大且订单量暴增, MySQL 性能已跟不上; 司机在线量上不去, 管理在线的 pushserver(司机在线系统)是用 java 编写的, LBS(周边检索系统)使用 MongoDB, 稳定性和性能没人能搞定.
当滴滴创始人程维愁眉不展时, 腾讯连夜调集了一支 "精锐部队" 前去支援.
正月的北京乍暖还凉, 时任腾讯架构平台部负责人谢明博士赶到北京时, 团队已连续救火多天. 谢明和团队盘算了一下, 随即做了这样几件事:
用腾讯自身的框架和协议重写了 pushserver 和 LBS, 替换了原有的 java 和 PHP+MongoDB 实现, 解决了接入上限的问题; 与滴滴团队一起在打车业务逻辑中增加了几个关键的柔性降级开关, 比如说超过警戒容量之后的订单丢弃和安抚通知.
因机房条件艰苦, 中间同机房其他公司的产品发生疑似攻击的情况, 把带宽打满了, 一点小小的流量就可能将整个系统弄垮. 于是, 双方联合团队做出了一个艰难的决定 -- 将滴滴的整个系统, 平迁到腾讯内部机房.
几个月后的腾讯战略大会, 邀请创业伙伴现场分享. 程维分享滴滴打车经历多少次的九死一生时, 眼圈红红的, 最后特别提到了那一夜: 2014 年 2 月 23 日凌晨, 滴滴打车的服务, 成功的从滴滴自运营机房, 迁移到腾讯深圳机房, 几天几夜的不眠抢修, 这一刻终于绽开笑颜.
现任腾讯 TEG 云架构平台部总经理的谢明 2006 年加入腾讯, 主要负责操作系统和芯片相关的计算, CDN 和雾计算相关的接入, 对象 / 块 / 数据库相关的存储技术研发和运营工作.
滴滴不是腾讯云的第一个客户, 但是表明了腾讯做云的一个出发点. 谢明说:"确实有很多创业公司没有精力或技术放在基础设施和业务发展上, 有云的话情况会好很多."
从 2010 年开始, QQ 空间, 相册, 腾讯视频等一系列自研业务的打磨, 帮助腾讯在视频, 直播等领域积累了强大的整套解决方案和能力. 于是在 2015 年, 腾讯云顺利抓住了直播的风口, 迎来了第一波大爆发.
对于直播而言, 平时有明显的波峰, 波谷效应, 没有直播的时候流量不高, 一旦有直播的时候有很大突发. 今年 S9, 腾讯云为全网 90% 流量护航, 直播流量承载将再创新高, 考验的是云厂商智能调度 CDN 的能力, 弹性伸缩的计算能力, 支撑海量高并发的数据库能力, 技术保障和护航的能力.
腾讯云过去使用的是第三方 CDN 厂商的服务, 随着体量不断增长, 许多技术需求, 带宽压力以及成本问题都不是一家供应商能够解决的. 因此, 腾讯云走上了 CDN 的自研道路.
云时代面临许多新的场景, 对技术体系构成了新的挑战. 2015 年前后, 腾讯内部已经明显感觉到了这一变化, 于是在网络设备, 服务器等技术领域, 腾讯加快了自研的脚步.
例如在存储上, 云时代考虑的是如何利用好 10G 乃至 100G 网络, 使得这一台的每一个服务器的计算和存储能力都能得到释放, 于是腾讯研发了下一代存储系统, 真正做到了按需扩容, 利用率整体上可以达到 90% 以上, 单集群可以管理百万级别节点, 同时大幅降低了人工的运维成本.
数据库上, 腾讯通过开源托管, 商业合作, 自研三线齐发, 提供超过 20 种数据库产品, 以及数据备份, SQL 审计, 数据管理, 数据迁移等服务等生态工具, 让用户获取最佳的上云体验.
网络方面, 腾讯基于自研设备和 SDN 来构建第四代网络架构. 比如, 在自研设备上, 腾讯自研交换机 TCS83 支持单芯片 100G 端口, 自研光网络设备 OPC-4, 单通道转发能力达到业界顶级 600G 水平. 通过自研, 网络设备 TCO 下降 20% .
产业互联网时代, 各行各业对云计算有更高性能和稳定性诉求, 腾讯通过 DPDK, 智能网卡等软硬件方案, 将网络, 存储等 IO 消耗卸载到硬件上, 实现了虚拟机零损耗和虚拟机之间的零干扰. 同时, 在国内率先推出 FPGA 服务器, 高性能 GPU 服务器等异构计算, 满足各行业用户的不同需求.
来源: https://www.cnblogs.com/ccloud/p/12143673.html