BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Sharon 关注 1 他的粉丝 , 江柳 关注 2 他的粉丝 发布于 2017年11月29日. 估计阅读时间: 27 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

在刚刚闭幕不久的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中,并在后续再次汇总进行后续处理。

这个过程中用到的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秒之内就可以完成,平台的运行效率提高了。

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

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)。那么,kafka系统是怎么如此高的吞吐量呢?以下是kafka的架构图:

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

面向IOT的腾讯MQ技术分析

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

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

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

腾讯云X-P2P直播加速方案

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

P2P技术的发展史

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

  • 2005年,香港科技大学研究出了基于网状无结构网络拓扑的Goo1Streaming,通过定期交换缓冲映射表和邻居列表,实现每个节点与邻居共享媒体数据。这项技术的优点是实现了节点之间随机获取,让各个peer之间达到负载平衡。但同样有硬伤:两个距离很远连接很差的节点也可能被调度为邻居,大大影响系统的服务质量;
  • 2006,华中科技大学基于树状结构研发了一款叫AnySee的直播技术,其实现原理是根据IP邻近原则构建IP多播。这种结构使节点的邻居质量变高,相对更容易达到更高的P2P分享率。劣势是树的父节点离开造成波动大,极易导致中低层节点与顶层节点播放时差大;
  • 2008年,清华大学采用推送数据模型构建了GridMedia,达到低延迟的效果,这个系统经历过春晚和奥运会直播的洗礼,延迟更低、连接速度更快,用户越多的情况下播放越流畅,与之相对应的,当用户少的时候,观看体验就不尽如人意了。

腾讯云X-P2P直播方案及其优化之路

腾讯云根据自身的业务场景在直播技术上做了系列优化,下图为腾讯云基于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%以上。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT