在刚刚闭幕不久的 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 中,并在后续再次汇总进行后续处理。
消息服务就是腾讯云现在提供的服务,目前分为三种,包括 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 秒之内就可以完成,平台的运行效率提高了。
演讲最后王路表示,系统后续的开发工作中,涉及到腾讯公有云的扩容问题,在资源实在不够的情况下知乎打算把容器分发集群,通过腾讯公共云提供的虚拟机,扩容到公有云上,做一个一级备份。
消息中间件具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,因此已经成为分布式系统异步 RPC 通信的核心手段。当今市面上有很多主流的消息中间件,如老牌的 RabbitMQ,炙手可热的 Kafka 等。腾讯消息中间件针对公司金融业务打造了基于 raft 算法的高可靠强一致的分布式消息中间件 CMQ,并经过多次春节微信红包、微众银行等海量消息检验。
腾讯云中间件架构师黄钰现场结合具体应用场景,从技术角度分享了腾讯消息中间件如何做到高可靠、高弹性、高性能、强一致,及其在不同应用领域的最佳实践。
据黄钰介绍,MQ 面向大数据的应用场景主要包括日志收集、日志分析、Spark streaming 特征抽取与 EMR 四个方面。腾讯云在大数据的日志收集上做了系列优化实践:
在这里,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 系统对于海量消息的处理速度基本上是成倍增长的状态。
除了在大数据上面的应用,MQ 在 IoT 上也有丰富的应用,如 MQTT 是当前物联网以及移动互联网领域的主流协议,在车联网、智能家居、直播互动、金融支付、IM 即时通讯等多个场景均有广泛应用,特别是在需要低功耗、网络吞吐有限、网络质量差的 IOT 场景下,具有独特的优势。
腾讯云根据自身的应用特点,在 MQTT 的基础上开发出了一款兼容 MQTT 协议的 IOT MQ 产品。下图是 IoT MQ 应用架构,设备端将消息发布到腾讯云的 Topic,然后再转到消息的接收方。这个有什么系统作用呢?举个例子,比如用户使用了电、水或者任何家居设备,服务商开发一个相关的微信小程序,用户就可以在你手机上很方便的看到使用的电量或者水量。
据黄钰透露,除了兼容 MQTT 3.1.1 协议、及任何支持该协议的 SDK 之外,IoT MQ 基于腾讯自研 CMQ 架构,可根据业务规模弹性伸缩,对上层透明,与此同时,CMQ-MQTT 提供腾讯云平台的整套运维服务,包括资源申请、消息查询、监控告警等各项运维服务,实现统一运维,节省大量的运维成本。
接下篇 《小程序、容器、SCF、直播加速… 最全面的云端架构技术揭秘(下)》
来源: https://www.qcloud.com/community/article/995589