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

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

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

腾讯云视频业务产品总监黄斌进行了开场演讲，他的演讲主题是《如何快速打造基于实时音视频能力的爆款 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 页面发起视频请求，就可以轻松接入企业的实时视频服务。

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

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

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

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

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

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

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

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

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

这个过程中用到的 ckafka，就是腾讯云提供的消息服务中的一种。目前腾讯云提供的消息服务分为三种，包括 CMQ 消息队列—高可靠消息队列，提供队列模式和主题模式；Ckakfa——兼容开源 Kafka，高性能消息队列，提供队列模式；MQ for IOT——支持 mqqt 接入，面向 IoT，提供主题订阅模式。

SCF 的使用方式，就是用户只要在平台上创建一个函数，把代码或者代码包、库上传上来，同时配置一个触发器。在触发器中发生事件时，会自动完成函数的触发运行，进行事件处理。如果有多个事件同时触发，函数能以并行实例的方式运行，分别进行事件处理，而这个扩缩容其实也在平台自动完成，而不需要用户关心我究竟要启动多少实例，配置多大的资源来给到实例。

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

更进一步，黄文俊还给出了一个 Demo，也是一个流式的处理过程，偏向于 IoT 设备采集，用 IoT MQ 产品，去接收所有 IoT 设备传来的消息。其中创建两个函数，分别做不同事情，第一个函数订阅的是日志主题，每个设备上传的日志，使用云函数来接收日志后再做一个汇总，放到 Kafka 中去，或者直接放到 cos 对象存储中，以文件方式记录下来；另外一个函数，订阅告警主题，在某一个设备发生了告警，就会触发函数的运行进行告警，比如发邮件或者短信出去。

实际上云函数这款产品的关键点就在于触发器，云函数本身是一个连接的作用，要连接这些云产品、打通各个云产品，形成一些完整解决方案。黄文俊介绍：“目前云函数处于公测期，用户可以免费试用，后续正式运营之后，每个帐号也有每月的免费额度可供试用。”

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

据介绍，知乎大概从 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 秒之内就可以完成，平台的运行效率提高了。

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

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

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

据黄钰介绍，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）。那么，kafka 系统是怎么如此高的吞吐量呢？以下是 kafka 的架构图：

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

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

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

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

腾讯云 X-P2P 是业内领先成熟的 P2P 产品，从 2014 年开始，到现在历时 2 年多，其中多个产品线均已成熟，包括不同平台、不同延迟场景下的 P2P 直播、点播 P2P 等，现已推广到斗鱼、熊　猫等直播平台使用，经受住了大流量阅兵活动直播、赛事直播的考验。腾讯云 X-P2P 直播加速技术负责人张鹏，就 P2P 的发展历史、X-P2P 方案架构以及腾讯云在 X-P2P 的探索与优化等内容作了详细分享。

P2P 概念最早出现在 1969 年被 RFC 1 所收录，2000 年 Guntella 网络诞生，紧接着 BT 协议发布，在这段期间，人们一度以为 P2P 仅适用于文件分享。2004 年底随着 PPLive 的发布，开发者才逐渐意识到这项技术同样适用于流媒体直播，从 05 年开始，P2P 在直播领域大行其道，具体发展技术路线如下：

• 2005 年，香港科技大学研究出了基于网状无结构网络拓扑的 Goo1Streaming，通过定期交换缓冲映射表和邻居列表，实现每个节点与邻居共享媒体数据。这项技术的优点是实现了节点之间随机获取，让各个 peer 之间达到负载平衡。但同样有硬伤：两个距离很远连接很差的节点也可能被调度为邻居，大大影响系统的服务质量；

• 2006，华中科技大学基于树状结构研发了一款叫 AnySee 的直播技术，其实现原理是根据 IP 邻近原则构建 IP 多播。这种结构使节点的邻居质量变高，相对更容易达到更高的 P2P 分享率。劣势是树的父节点离开造成波动大，极易导致中低层节点与顶层节点播放时差大；

• 2008 年，清华大学采用推送数据模型构建了 GridMedia，达到低延迟的效果，这个系统经历过春晚和奥运会直播的洗礼，延迟更低、连接速度更快，用户越多的情况下播放越流畅，与之相对应的，当用户少的时候，观看体验就不尽如人意了。

腾讯云根据自身的业务场景在直播技术上做了系列优化，下图为腾讯云基于 Segment 的直播 P2P 架构，整个直播流程分为两大部分：首先主播将媒体源推到服务器上，P2P 技术将它们进行切片，切成时长 1S 的 Segment ，集成到 CTN 上，然后 CTN 对其进行回源；接下来就是客户端的行为，客户端会先请求一个 conf 服务，这里包含着该频道的穿透服务器、日志服务器、及最新的切片信息，然后开始请求播放，手机获取由公网址来提供端口，种子服务器获取同一个频道的端口后发起连接，P2P 数据就开始产生了。

在直播体验优化上，张鹏现场介绍了腾讯云的内部传输控制、精准播控以及大房间高并发三大解决方案：

• 内部传输控制：当多人共用同一网络时，资源抢占时有发生，X-P2P 方案节点之间采用优胜劣汰，自动演进，不与 TCP 抢占资源、不突发发包，避免造成网络拥塞，节点替换波动亦不会影响到播放质量；

• 精准播控：秒播是直播的一个必备的元素，X-P2P 系统针对不同的播放器，设置快速写数据，使其播放视频秒起画面，同时，为满足低延迟需求，启动播放时快进，消除 GOP 延迟；

• 大房间高并发：大房间高并发是所有直播供应商最为头疼的一个问题，腾讯云采取的手段是主动分裂大房间，在每个分裂的房间里配置一台服务器，将用户分流。

说到 X-P2P 现在面临的挑战，张鹏最后表示，以前的视频码率低，现在的视频清晰度已有 4k、10M 码率，远超过带宽的增速，P2P 流量跨省跨运营商流动，易造成运营商不满，都是 X-P2P 需要考虑的问题。在未来，P4P 是解决这些问题的一剂良药。

关于微信小程序，相信大家都并不陌生。本次沙龙的最后一位讲师黄荣奎就小程序实现的的具体原理、 如何开发一个简单的小程序等实战内容作了精彩的分享和诠释。黄荣奎首先给出了小程序的定义：小程序是一种新的开放能力，开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验。

下图为小程序核心框架，分为三个大块，一块是视图层，也就是在整个页面的展示；一块是逻辑层，功能是什么，或者和后台的逻辑，都是在这层来做；最重要的一部分就是它底层提供的功能，就是点击、扫描二维码，或者调取一下它的硬件相关的一些接口，或者发起网络请求，这些都是在 native 这层做的。

了解小程序的核心框架之后，黄荣奎着重讲解了各个模块之间的通信过程。首先，用户进行操作如点击登录的操作，点击了之后会调取后台的逻辑。具体的交互过程如下：

• 首先，通过 View 展现，结合第一步，message 到 JSBridge，JSBridge 会通过 Webview，再结合 Native 方法，把事件成列到 Native 里面；

• 随后，信息流通过 Native 再通过 JSCore 传递到 JSBridge，然后再通过 JSBridge 传递给 service，这样业务就会搜到消息；

• Service 接受了消息之后会进行处理，通知给 View，View 接受了消息处理完了之后会发出一个消息，给 JSBridge，然后再通过 JSCore，到 Native；

• 最后再通过 native 到 View，把 view 展示的结果通过 JSBridge 去告诉到 View，然后 View 会做界面展示的更改。

上图为各模块之间的通信视图，简而言之，当用户进行一个点击操作，进入到组件，里面指 View，再到 JSBridge 到 view 和 Native，然后再到 service，然后在一步一步传到组件里面这样一个过程。

小程序联合微信联合做了一个相对比较完整的解决方案。下图是一个后台的部署窗口，在右上角可以看到有一个腾讯的标识，在这里可以完成一些更加快捷方便的操作。一键自动配置可运行后台的环境。第二个是后台代码编写。第三是一键上传代码自动部署，第四远程调试。具体部署过程在此就不加以详述，感兴趣的读者可以下载讲师 PPT 查看完整信息。

值得一提的是，在云上，小程序还提供了一些分装的比较高级的实用接口，其中包括 Websocket 服务，图片鉴黄、语音识别，还有视频还有直播相关的一些东西，在这里都可以找到解决方案的。另外，一些比较高级的应用，比如图像识别 OCR，也可以提升到 SDK 里面去。据黄荣奎介绍，目前的腾讯 AI 图像识别已经在很多的业务中使用到了，准确率达到 99% 以上。