查看原文
其他

20 万台 QQ 服务器全面上云!

程序人生 2020-02-17

The following article comes from CSDN Author CSDN App

作者 | 胡巍巍
出品 | CSDN(ID:CSDNnews)
是的,你现在正在用的QQ,已经是“云上QQ”!
截至目前,QQ已经把所有业务,都搬到了腾讯云上。
20多岁的QQ,把近20万台服务器上云,过程之艰难,堪比“把大象搬到云端”。
这么难的事儿,腾讯为啥要做?
事情要从2018年腾讯“930调整”说起。
如果你熟悉腾讯的开发工具,就会发现他家框架超级多。
以至于在腾讯内部论坛上,经常有新人问,这么多开发框架,到底该用哪一个?
腾讯内部也流传着这样一个故事,一个从腾讯互娱BG转岗到微信BG的程序员,竟然发现他需要重新熟悉开发框架。
此外,“930调整”之前,腾讯很多基础框架,也没有进行内部开源,很多部门间的代码,都是相互封闭的。
因此,“930调整”后,腾讯启动开源协同和自研业务上云两大业务方向。
过去一年,不仅是对内开源,即便是对外开源,腾讯也堪称“疯狂”
而在自研业务上云方面,腾讯拿自家元老级产品QQ试水,其决心可见一斑。
QQ成功上云后,工程师们发现,业务研发效率更高了,从前开发一个产品需要很久,现在哪怕是从0到1开发一个新产品,也只需要短短一周。
其次就是,工程师的自我价值得到了更大体现,当看到自己开发的组件,上传到云上成为一种被很多人使用的服务,那种自豪感油然而生!
更重要的是,QQ上云让腾讯云积累很多宝贵经验,这些经验对整个云计算行业,都大有裨益。
那么,QQ上云过程中,就遇到过哪些困难?又是怎样克服的?
1月13日,CSDN采访了腾讯云云服务器副总经理李力,力图为你揭晓QQ上云的那些事儿、以及腾讯云背后的技术。以下为经过整理后的部分采访实录。

关于QQ上云


CSDN:QQ本身有二十多年历史,它是有一定历史技术包袱的,技术架构和云架构的适配难度也更大。那么,QQ上云的过程中,遇到最大的困难是什么?
腾讯云云服务器副总经理李力:遇到的问题主要是,QQ对性能和成本的要求,在某些场景下对云会有一个冲击。QQ业务的特点,在于它是海量用户互相访问的过程,这个过程既不可预测,很难做一个良好规划。
CSDN:那么是怎么克服困难的?
腾讯云云服务器副总经理李力:回到云本身的基础架构来说,如果要简单区隔云和物理机房,就得尽可能通过软件定义,这样才能让云具备更好的灵活性。
在具体内网的通过性上面,我们对所有的网络流量和网络关系,进行了软件建模。所以我们给QQ的每一个连接和每一个包,都做了软件层面的转发。
这种情况下,虽然UDP(用户数据报协议,User Datagram Protocol)没有连接,但是在软件定义里面,有一个虚拟连接。并且,我们也会把建立连接的过程变成可控的,建立好之后,数据包就会不断发送从而形成数据。
早期我们更倾向优化数据的性能,因为大部分情况下,都是数据包建立好之后,工程师们再去进行数据传输。但在QQ里面,并不完全是这样。
由于QQ通讯里面,会建立大量临时的UDP访问,而这也变成QQ上云之后的性能瓶颈。而这个非常小的性能瓶颈,可能会导致成本急剧增加。
那么,如何解决?在早期面对QQ场景时,我们会先把资源做补充,但是这样就会失去成本优势。后来,我们的研发团队和虚拟化团队花了很长时间,在具体细节方面做了很多工作,最后终于以一个非常合理的资源和成本,满足了QQ群的业务要求。
以应对依赖和容灾问题为例,大家都知道,上云需要进行灰度迁移,而迁移时不可避免地会造成自研机房和云机房的带宽穿越,为此,工程师们需要提前评估自研机房到云机房所需的带宽。
假如使用城市方案,专线带宽应该跟现有的三地部署方案对齐(CSDN注:QQ服务器分布在天津、上海和深圳三地)。那么,QQ核心系统大概需要几十G的带宽。
假如采用IDC(Internet Data Center,互联网数据中心)方案,QQ里面有很多业务,使用的是有状态的寻址方式,因此得把同城内的机房全部打散访问(类似一致性哈希)。
为此,工程师们评估了自研到云机房的带宽,评估之后发现支持QQ几大核心系统(接入、消息、状态、资料、关系链、登录)所需要的带宽为N。
而所有QQ基础功能都迁移到云上,则至少需要2N的带宽。考虑到容灾问题,工程师们实际上拉了两条专线互备(防止专线被挖断形成孤岛),即为QQ上云专门搭建了4N的带宽专线。

关于VStation对于QQ上云的加持

CSDN:有报道称,腾讯云分布式调度系统VStation,可以把成千上万台服务器的管理,做到像管理一台服务器那么简单,这个过程是怎么实现的?
腾讯云云服务器副总经理李力:腾讯的技术理念跟QQ和微信是一脉相承的,也就是说我们想要解决的是海量高并发的业务场景。如果只去看管理成千上万台物理机这么一件事,它跟管理一台物理机,其实没有太大差别。
所以,我们一开始思考这个问题时,主要思考的是如何通过一个自研系统,去调度整个云机房内的物理机,让它能够生产和调度虚拟机。
而腾讯的VStation,跟其他系统不一样的地方,在于我们特别强调可扩展性和高可用性。比如,原来调度一台机器,现在要调度一百台、一千台,这看起来是无限可扩展的,似乎只需要把这个脚本在一台机器上执行、或者到一千台机器上执行就可以。
但这里面最大的问题在于,我们想要做到让它像一台机器一样,它就一定要快。可是在大规模集群里,一个很大的问题在于它很难快起来。
云的系统比较复杂,它包括计算网络存储、监控、安全、周边的管理系统和机房的DCS系统(Distributed Control System,分布式控制系统)。
所以,整个云计算系统看起来只是在做一些运维调度,但是要牵涉到上百个模块的协同,然后还会牵涉到几千上万台物理机的分布式通信。
所以我们在可扩展上面临的挑战,就是很有可能在一台机器上执行的操作,会在机器规模提高之后变成线性的时间增长。
而如果我们无法接受线性时间增长,它就不能像机器的简单扩容一样把这个系统做好。这里面还有一点在于,假如我现在要创建一台虚拟机,我应该选择哪一台物理机来作为它的溯源机?
这个过程非常复杂,如果只考虑单次的调用是很简单的,我只需要拿到全部信息,然后想办法在一个单点计算一下就可以。但是我们的场景,很有可能同时迎来很多请求。
因此,我们做了很多技术优化,目的就是尽可能地有更多的执行体,并让每一个执行体都有更多调度输入。
而每一次调度时,因为全部信息随时在变,我拿到的是随时在变的全部信息。然后,我们会在这些信息里,挑选出足够多的、并且打分也比较高的资源池,然后再做一个随机排序,再加上一些哈希算法,从而避免服务器之间的碰撞。
另外,当模块数量特别多的时候,所有主业之间的通信都会面临问题。比如,开源系统规模越来越大时,它会面临一个典型问题:即一旦它的消息发出去之后,一旦中断或者处理异常,就会加大运维过程的难度。
因此,我们在一开始设计微原生云系统时,所秉持一个核心思想,就是把通信和业务割裂开。
但是我们不用Service Mesh(服务网格),而是把整个业务按照简单的原子接口方式去实现,然后通过Search Flow(搜索流)的概念,把它组合成一个有效而完整的DAG(Database Availability Group,数据库可用性组)。
再在通信框架和后台框架里,把这个有效而完整的图做优化,从而让它尽量并行,最后在有效完整图里做一个回顾。
也就是说,我在某一个地方吃饭,这个地方会自动按照图的逆序回过来,并能把原来做的章数清理掉。这样就实现了大型分布式系统里面的事务概念,最终实现集群规模的增加。
有了这样的能力后,我们在QQ上云的过程中,主要面临的问题就是性能调优。可以说,腾讯云的整个调动框架,已经接受过腾讯超大的业务考验,所以现在的集群规模在实验室环境下,已经拥有管理上百万台物理服务器的能力。

采访手记


伟人曾言:“不破不立。
2018年腾讯“930调整”,曾在业界引起巨大反响。如今回头来看,改革的结果非常成功。
如果说这次调整,有哪些代表作,QQ上云一定是其中之一。
今天的你我,都在享受QQ上云后的好处,它或许不像点击一个App按钮那样直接,但是正如西方经典所讲:“所见的是暂时的,所不见的是永远的。
芸芸众生里,一个工程师名字和容貌,很难被记住。
但他们的产品,能被很多人使用,也是一种记住。

热 文 推 荐 

悲痛!临近年关,一位 IT 创业者自杀,曾卖房给员工发工资☞斯坦福首位华人女院长,“人造皮肤”赋予机器和残疾人触觉我国自主开发的编程语言“木兰”是又一个披着“洋”皮的红芯浏览器吗?

回家的票抢上了吗?聊聊12306为什么时不时要崩一下

☞小网站的容器化(上)

区块链第一,情商上榜,2020找工作需要哪些技能?

你点的每个“在看”,我都认真当成了喜欢

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存