20多岁的QQ，把近20万台服务器上云，过程之艰难，堪比“把大象搬到云端”。如果你熟悉腾讯的开发工具，就会发现他家框架超级多。以至于在腾讯内部论坛上，经常有新人问，这么多开发框架，到底该用哪一个？腾讯内部也流传着这样一个故事，一个从腾讯互娱BG转岗到微信BG的程序员，竟然发现他需要重新熟悉开发框架。此外，“930调整”之前，腾讯很多基础框架，也没有进行内部开源，很多部门间的代码，都是相互封闭的。因此，“930调整”后，腾讯启动开源协同和自研业务上云两大业务方向。过去一年，不仅是对内开源，即便是对外开源，腾讯也堪称“疯狂”。而在自研业务上云方面，腾讯拿自家元老级产品QQ试水，其决心可见一斑。QQ成功上云后，工程师们发现，业务研发效率更高了，从前开发一个产品需要很久，现在哪怕是从0到1开发一个新产品，也只需要短短一周。其次就是，工程师的自我价值得到了更大体现，当看到自己开发的组件，上传到云上成为一种被很多人使用的服务，那种自豪感油然而生！更重要的是，QQ上云让腾讯云积累很多宝贵经验，这些经验对整个云计算行业，都大有裨益。那么，QQ上云过程中，就遇到过哪些困难？又是怎样克服的？1月13日，CSDN采访了腾讯云云服务器副总经理李力，力图为你揭晓QQ上云的那些事儿、以及腾讯云背后的技术。以下为经过整理后的部分采访实录。
关于QQ上云
CSDN：QQ本身有二十多年历史，它是有一定历史技术包袱的，技术架构和云架构的适配难度也更大。那么，QQ上云的过程中，遇到最大的困难是什么？腾讯云云服务器副总经理李力：遇到的问题主要是，QQ对性能和成本的要求，在某些场景下对云会有一个冲击。QQ业务的特点，在于它是海量用户互相访问的过程，这个过程既不可预测，很难做一个良好规划。腾讯云云服务器副总经理李力：回到云本身的基础架构来说，如果要简单区隔云和物理机房，就得尽可能通过软件定义，这样才能让云具备更好的灵活性。在具体内网的通过性上面，我们对所有的网络流量和网络关系，进行了软件建模。所以我们给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的带宽专线。CSDN：有报道称，腾讯云分布式调度系统VStation，可以把成千上万台服务器的管理，做到像管理一台服务器那么简单，这个过程是怎么实现的？腾讯云云服务器副总经理李力：腾讯的技术理念跟QQ和微信是一脉相承的，也就是说我们想要解决的是海量高并发的业务场景。如果只去看管理成千上万台物理机这么一件事，它跟管理一台物理机，其实没有太大差别。所以，我们一开始思考这个问题时，主要思考的是如何通过一个自研系统，去调度整个云机房内的物理机，让它能够生产和调度虚拟机。而腾讯的VStation，跟其他系统不一样的地方，在于我们特别强调可扩展性和高可用性。比如，原来调度一台机器，现在要调度一百台、一千台，这看起来是无限可扩展的，似乎只需要把这个脚本在一台机器上执行、或者到一千台机器上执行就可以。但这里面最大的问题在于，我们想要做到让它像一台机器一样，它就一定要快。可是在大规模集群里，一个很大的问题在于它很难快起来。云的系统比较复杂，它包括计算网络存储、监控、安全、周边的管理系统和机房的DCS系统（Distributed Control System，分布式控制系统）。所以，整个云计算系统看起来只是在做一些运维调度，但是要牵涉到上百个模块的协同，然后还会牵涉到几千上万台物理机的分布式通信。所以我们在可扩展上面临的挑战，就是很有可能在一台机器上执行的操作，会在机器规模提高之后变成线性的时间增长。而如果我们无法接受线性时间增长，它就不能像机器的简单扩容一样把这个系统做好。这里面还有一点在于，假如我现在要创建一台虚拟机，我应该选择哪一台物理机来作为它的溯源机？这个过程非常复杂，如果只考虑单次的调用是很简单的，我只需要拿到全部信息，然后想办法在一个单点计算一下就可以。但是我们的场景，很有可能同时迎来很多请求。因此，我们做了很多技术优化，目的就是尽可能地有更多的执行体，并让每一个执行体都有更多调度输入。而每一次调度时，因为全部信息随时在变，我拿到的是随时在变的全部信息。然后，我们会在这些信息里，挑选出足够多的、并且打分也比较高的资源池，然后再做一个随机排序，再加上一些哈希算法，从而避免服务器之间的碰撞。另外，当模块数量特别多的时候，所有主业之间的通信都会面临问题。比如，开源系统规模越来越大时，它会面临一个典型问题：即一旦它的消息发出去之后，一旦中断或者处理异常，就会加大运维过程的难度。因此，我们在一开始设计微原生云系统时，所秉持一个核心思想，就是把通信和业务割裂开。但是我们不用Service Mesh（服务网格），而是把整个业务按照简单的原子接口方式去实现，然后通过Search Flow（搜索流）的概念，把它组合成一个有效而完整的DAG（Database Availability Group，数据库可用性组）。再在通信框架和后台框架里，把这个有效而完整的图做优化，从而让它尽量并行，最后在有效完整图里做一个回顾。也就是说，我在某一个地方吃饭，这个地方会自动按照图的逆序回过来，并能把原来做的章数清理掉。这样就实现了大型分布式系统里面的事务概念，最终实现集群规模的增加。有了这样的能力后，我们在QQ上云的过程中，主要面临的问题就是性能调优。可以说，腾讯云的整个调动框架，已经接受过腾讯超大的业务考验，所以现在的集群规模在实验室环境下，已经拥有管理上百万台物理服务器的能力。
2018年腾讯“930调整”，曾在业界引起巨大反响。如今回头来看，改革的结果非常成功。如果说这次调整，有哪些代表作，QQ上云一定是其中之一。今天的你我，都在享受QQ上云后的好处，它或许不像点击一个App按钮那样直接，但是正如西方经典所讲：“所见的是暂时的，所不见的是永远的。”☞集五福，我用Python
☞搜狐员工迟到一次罚 500 元，张朝阳回应“资本家就得剥削员工”
☞如何打通“鱼塘” ？腾讯启动“SaaS技术联盟” 共建技术中台