小程序、容器、SCF、直播加速…最全面的云端架构技术揭秘（上）

在刚刚闭幕不久的2017腾讯全球合作伙伴大会上，腾讯首次发布其AI开放全景图，并围绕AI主线进行腾讯全产品线开放布局。无论在AI方面的战略计划，还是机器学习、计算机视觉、语音识别等AI技术的开放和落地，其背后都离不开云的支撑，这就好比AI是火箭，云计算是助推器。

在火爆的云计算市场，腾讯云一直以来都比较低调，但这并不妨碍他深耕自己的技术，并把技术优势发扬光大。近期腾讯云与极客邦科技共同在北京举办了一场题为“解码腾讯云软件架构与应用”的技术沙龙，来自腾讯云和知乎的六位技术专家，详细介绍腾讯云在小程序、视频业务、无服务器云函数、中间件等领域的技术储备，也分享他们的洞察。本文整理了部分精彩干货内容，感兴趣的同学可以点击阅读原文下载完整版演讲PPT。

实时音视频爆款APP背后的技术支撑

腾讯云视频业务产品总监黄斌进行了开场演讲，他的演讲主题是《如何快速打造基于实时音视频能力的爆款APP》。对于网络直播、音视频应用，大家肯定都不陌生，无论是2016年的千播大战，还是以商业直播为依托的视频+，都让网络直播、视频从娱乐化走向垂直领域。

不过实时音视频对技术的要求其实很高，要从基础和架构角度去做推流；要做基础平台；要进行音视频编解码；要进行各种格式的终端适配；要做多协议支持；要做美拍、美颜动效、打赏等等功能；另外，现在的用户打开一个主播的房间，或者进入一个电商的房间，已经不接受延迟了，秒开才是业界的标准。

对此黄斌表示：“腾讯已经做了十多年的音视频，我们的团队就是基于QQ进行的延展，现在我们在做腾讯云的音视频业务，我们把这个业务逐步开放出来，提供完整的解决方案。”

在视频直播、短视频方面，腾讯云通过各种SDK接口，把能力开放出来。在这方面腾讯云提供两套解决方案，第一套方案是标准化的，将主播端/源站、流媒体处理、CDN、观看端打通。

还有一个解决方案是QQ音视频以前提供的多方视频通话能力，实际上这是一个非标准的解决方案，它其实是基于RTP协议改造的腾讯私有协议，这个私有协议经过腾讯验证，它的延迟性、稳定性、双向互动保证的百秒延迟性能，比标准流媒体协议要好；而且它在部署上面跟QQ全球化的部署共用很多资源，所以在资源保障上有优势，它最显著的特点是支持互动连麦。

从应用角度，黄斌也进行了详解。移动直播分为轻量或者快速集成小直播，以及随心播两种；实时游戏音视频（TMG）在腾讯叫做移动游戏，但实际上主要的功能是做实时音视频；短视频也需要非常多的能力，比如掐头去尾、添加动效、做滤镜、动态美颜、添加音效字幕、快速分享，后台要做非常多的优化。当然短视频还有旅行、社交等不同场景，每个场景提供的技术支持上的侧重点也不同。

对于直播的安全来说，要通过AI能力去做图像、声音的识别，完成直播鉴黄、大屏监看等工作，在这方面，腾讯的优图引擎对几千上万个房间实时去做智能鉴黄，能够完成90%识别工作，百万级并发的检索时间小于150ms。对此黄斌补充，通过将AI引入直播，绿幕技术、基于背景预学习的分割技术、基于VGG Net的人体识别网络都能轻松实现了。

在直播向垂直领域渗透方面，无论电商、金融、在线教育，还是娱乐，实时的音视频能力在不同场景下都可以找到落地的应用，这也呼应了黄斌演讲一开始的观点。

此外，H5 双向音视频(T-H5)也是腾讯云基于 QQ 十多年来在音视频通话技术上积累，结合腾讯浏览服务 TBS WebRTC 能力与腾讯实时音视频 SDK ，为客户提供多平台互通高品质视频通话能力的一款产品，终端用户只需要在手机 QQ/微信/QQ 浏览器和其它所有接入了 TBS 的 APP 中，通过 H5 页面发起视频请求，就可以轻松接入企业的实时视频服务。

演讲最后，黄斌演示了一个小程序与实时音视频技术整合的一个业务场景，可以在小程序能力里面去做双向甚至多方的实时音视频。以车险理赔为例，打开定损小程序，通过实时音视频就可以在线完成查勘定损。

无服务器云函数产品SCF详解

serverless架构在今年引起广泛关注，腾讯云也推出了无服务器云函数产品SCF，腾讯云 SCF 无服务器云函数产品经理黄文俊进行了《用云函数结合消息服务实现数据的流式分析》的主题分享。

黄文俊的分享从反爬虫场景引入，这是一个很常见的场景，围绕的是UA检测、IP检测、代理IP识别和封禁，这也是爬虫发展的几个历程。在第三个历程中，如果用户用代理IP，我们该怎么办？这个时候我们不可能一一找出IP，这就要借助代码的力量找出IP进行相应封锁了。怎么找出IP？最常见的就是大家传统用到的先存储再进行分析的方式，有没有更有时效性的方式？黄文俊介绍，腾讯云提供了一种流式的方式来进行分析。

流式数据分析的特点，是需要分析的数据来源很多，例如物联网终端汇报采集的数据，手机上报自身地理位置，股市的行情变化，用户对网站链接的点击等等，同时这些数据都是在持续不断的产生。在这些数据里，其实持续上报的，都是很小的单条记录，但是在大量源存在的情况下，很小的单条记录也会形成超高的并发。之所以要采用流式分析，就是要加快分析速度，对一定时间内的数据立即进行分析，否则过期的数据其意义价值就不是那么大了。

我们要怎么用流式分析解决需求呢？我们把存储和分析做一个并行，或者只要分析过程不要存储过程，这个存储还是做一个汇总，这个汇总可能只是一个缓存，用缓存来做最近的采集和收集，采集之后立刻分析，得出输出结果。这就可以使用腾讯云上的消息服务和云函数来实现，实际上这两个产品都可以称之为无服务器架构。

无服务器是今年火起来的一个概念，从结构上来看分为两个部分，一个是后端即服务，是很多人在使用的对象存储、CDB云数据库或者消息队列产品；另外就是函数即服务，也就是腾讯云推出的SCF无服务器云函数产品。

为什么称它为无服务架构？就是开通就能使用，开通创建配置后，就可以通过API或者SDK进行连接使用，不需要再去配置服务器，这些都交给云来进行运维和管理。对于开发者来说最关心的只是代码，用代码实现核心业务就可以；而无服务器架构另外一个特点，就是事件驱动型，由事件触发。

具体到SCF无服务器云函数产品，目标就是托管计算，用户不需要关心后台的计算资源有多少，应该配多少的CPU、多大的内存，而仅仅关心上传代码、把代码托管到平台上来、配置好触发器就完成运行。

针对日志分析demo，黄文俊表示：我们可以使用这种架构来完成流式分析。将日志汇总到kafka中的同一个topic中，然后使用kafka触发云函数分析。这里使用的是消息拉取方法，一次拉取一批，分析后的结果可以仍然缓存进入kafka的另外topic中，并在后续再次汇总进行后续处理。

消息服务就是腾讯云现在提供的服务，目前分为三种，包括CMQ消息队列——提供队列模式和主题模式；Ckakfa——兼容开源Kafka，提供队列模式；MQ for IOT——支持mqqt接入，提供主题订阅模式。

SCF的使用方式或者工作原理，就是用户在最初只要在平台上创建一个函数，把代码或者代码包、库上传上来，同时配置一个触发器。如果你的事件够多，所有的函数都是以并行实例的方式在运行，而这个扩缩容其实也在平台自动完成，而不需要用户关心我究竟要取多少实例，配置多大的资源来控制这些实例。

对此黄文俊举例：“前面也说了SCF是要求无状态的，那么分析的结果怎么进行处理、怎么进行汇总呢？实际上就是用了Redis来进行缓存，同时进行计数。我又用了一个函数，再用一个定时触发器，比如每隔5分钟去访问一下Redis，看一下列表中哪些IP已经超阈值了，比如这5分钟它访问了2千次了，我认为它是爬虫，我就把这些抽出来，去生成一个封禁列表。”

更进一步，黄文俊还给出了一个Demo，也是一个流式的处理过程，偏向于IoT设备采集，用IoT MQ产品，去接收所有IoT设备传来的消息。其中创建两个函数，分别做不同事情，第一个订阅的是日志，每个礼拜二上传的日志，接收这个日志再做一个汇总，放到Kafka中去，或者直接放到Topic，以文件方式记录下来；另外一种方式，订阅不同的主题，它是一个告警，某一个设备发生了告警，就会触发下面的运行，比如发邮件或者短信出去，就使用这个函数来进行处理。 实际上云函数这款产品的关键点就在于触发器，云函数本身是一个连接的作用，要连接这些云产品、打通各个云产品，形成一些完整解决方案。黄文俊介绍：“目前云函数处于公测期，是免费的，后续正式运营之后的每一个帐号也有免费额度。”

知乎容器化之路的三大关键阶段

接下来一个演讲嘉宾是一位腾讯云的用户，他就是知乎容器平台高级工程师王路，他带来的是《知乎容器化之路》的分享。

据介绍，知乎大概从2015年开始全面容器化，到目前为止99%的业务都在容器上，基础的组件也在容器上。提及为什么要容器化，王路表示：“当时知乎用的是纯物理机，成本比较高，资源利用率比较低。我们选的虚拟化方案，第一个就是虚拟机，就是OpenStack，但人力维护成本还是比较高；另外虚拟机的的扩容效率也比较低。之后推出微服务，微服务和容器几乎是一脉相承的，所以我们最终确定了使用容器的方案。项目命名为bay，就是海湾的意思。”

“当时我们面临三个选择，分别是：mesos、k8s和swarm，当时选的是mesos，这是我们第一阶段的整体架构，就是一个PaaS架构，以下是架构图，物理机就是腾讯云提供的物理机。这一阶段只有业务的物理机是进行容器化的，基础组件没有。”

第一阶段初代平台完成之后，主要支持以下几个功能：滚动升级、金丝雀发布、CI/CD完整集成、支撑几乎全部业务（万级容器器）、秒级自动扩容 （10->100 35s）。

如果说第一阶段解决了业务容器化的问题，那么第二阶段就是在这个过程中又遇到了基础组件的问题，这个问题是Kafka集群管理的问题。一开始的Kafka管理的是一个大的单集群，当时出了两个比较典型的问题，一个是topic的流量突然增加，引发整个集群的故障；第二个就是负载不均衡。这一情况下如果由维护一套Kafka集群转成两套，成本非常高，最少的集群也需要三台机器。知乎的解决办法就是对它进行容器化，定义更细粒度的调度单位、更高效的集群管理工具，知乎最终做出的选择是对Kafka broker进行容器化，高效的集群管理工具是kubernetes，对于本地磁盘使用的是kubernetes的本地组件，磁盘化到这个容器里去。理想状态就是在三台机器上跑三个Kafka集群，每一个Kafka的broker都是单独占用一个磁盘，构成三个集群。

随着业务的发展，有一些容器组越来越大，有的容器组可以包含1千多个容器，上线一次可能就会非常慢。bay最终只能用一个口，它的速度是有上限的；第二个就是无法快速回滚；第三就是缺乏好用的运维工具；最后一点，mesos的社区活跃度比较低。

根据这些不足，知乎考虑重建bay系统，目标就是提高部署速度。首先就是如何解决快速部署回滚的问题，第一个方法就是区分部署与发布；至于回滚，业务在部署新的代码之后，旧的代码是不销毁的，容器是实际存在的，但不对外提供服务。

第三阶段整体架构是，新的bay系统也是放在kubernetes上，相当于两套系统并存。新的bay系统的framework是怎么实现发布和部署的？据王路介绍，知乎通过新bay系统的API去发请求。目前知乎大概1/3业务已经迁移到新的bay系统上了，快速部署在3秒之内就可以完成，平台的运行效率提高了。

演讲最后王路表示，系统后续的开发工作中，涉及到腾讯公有云的扩容问题，在资源实在不够的情况下知乎打算把容器分发集群，通过腾讯公共云提供的虚拟机，扩容到公有云上，做一个一级备份。

MQ在大数据与IOT等领域的最佳实践

消息中间件具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，因此已经成为分布式系统异步RPC通信的核心手段。当今市面上有很多主流的消息中间件，如老牌的RabbitMQ，炙手可热的Kafka等。腾讯消息中间件针对公司金融业务打造了基于raft算法的高可靠强一致的分布式消息中间件CMQ，并经过多次春节微信红包、微众银行等海量消息检验。

腾讯云中间件架构师黄钰现场结合具体应用场景，从技术角度分享了腾讯消息中间件如何做到高可靠、高弹性、高性能、强一致，及其在不同应用领域的最佳实践。

大数据MQ-Ckafka技术实践

据黄钰介绍，MQ面向大数据的应用场景主要包括日志收集、日志分析、Spark streaming特征抽取与EMR四个方面。腾讯云在大数据的日志收集上做了系列优化实践：

• 最原始日志收集的方法是采用日志+ES+COS bucket的存储方式，这种方法有一个问题，即ES抓取的日志信息存放到COS系统的过程中，任何存储系统都是一个路径，在这种情况下对内存消耗极大，难以支撑大量用户的访问日志区分存储。
• 针对这个问题，腾讯云的优化方案是先将所有的消息存储在消息中间件当中，如Kafka系统，通过Kafka进行消息解耦，然后将日志信息分别发送给COS bucket和ES系统，缓解资源池的压力。下图是腾讯云大数据日志收集原有方案和改进方案的对比：

在这里，Kafka除了消冲填补和解耦之外，还起到一个数据分发和聚合作用，如数据需要进行多平台的分析时，可以通过Kafka将解耦后的消息分发到不同的平台做日志分析；反之，基于Kafka的使用方式，也可以将不同平台的同种数据聚合在一个服务器上做Spark streaming特征抽取，这些都是典型的大数据应用的场景。

基于Kafka的典型应用，腾讯云根据自身的业务需求开发了一款CKafka（Cloud Kafka）架构，与开源Kafka系统相比，CKafka拥有分布式、高可扩展、高吞吐等性能，同时，它能100%兼容Apache Kafka API（0.9及0.10），开发者无需部署即可直接使用Kafka所有功能，据了解，当同时有四个Partition时，Ckafka的小包性能是开源性能的5倍（750MB/s VS158MB/s）。那么，Ckafka系统是怎么如此高的吞吐量呢？以下是Ckafka的架构图：

首先在单机的方面，Ckafka放弃了java的机制，采用操作系统级的页进行缓存；其次，它采用了一个优化的系统机制（如上图），用以提升了IO的特性；同时在水平方面，Ckafka它采用了一个类似于乘法的规则，将多个消息进行分片，并对每个分片消息进行同步处理。这样，Ckafka系统对于海量消息的处理速度基本上是成倍增长的状态。

面向IOT的腾讯MQ技术分析

除了在大数据上面的应用，MQ在IoT上也有丰富的应用，如MQTT是当前物联网以及移动互联网领域的主流协议，在车联网、智能家居、直播互动、金融支付、IM即时通讯等多个场景均有广泛应用，特别是在需要低功耗、网络吞吐有限、网络质量差的IOT场景下，具有独特的优势。

腾讯云根据自身的应用特点，在MQTT的基础上开发出了一款兼容MQTT协议的IOT MQ产品。下图是IoT MQ 应用架构，设备端将消息发布到腾讯云的Topic，然后再转到消息的接收方。这个有什么系统作用呢？举个例子，比如用户使用了电、水或者任何家居设备，服务商开发一个相关的微信小程序，用户就可以在你手机上很方便的看到使用的电量或者水量。

据黄钰透露，除了兼容 MQTT 3.1.1协议、及任何支持该协议的SDK之外，IoT MQ基于腾讯自研 CMQ 架构，可根据业务规模弹性伸缩，对上层透明，与此同时，CMQ-MQTT 提供腾讯云平台的整套运维服务，包括资源申请、消息查询、监控告警等各项运维服务，实现统一运维，节省大量的运维成本。

接下篇《小程序、容器、SCF、直播加速…最全面的云端架构技术揭秘（下）》