小程序、容器、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、直播加速…最全面的云端架构技术揭秘(下)》

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏前沿技墅

一个前端工程师的基本修养

1693
来自专栏用户2442861的专栏

腾讯微信技术总监周颢:一亿用户增长背后的架构秘密

http://www.csdn.net/article/2012-05-15/2805581

482
来自专栏大数据挖掘DT机器学习

大数据架构和模式(三)——理解大数据解决方案的架构层

作者:Divakar Mysore等 来源:DeveloperWorks 摘要:大数据解决方案的逻辑层可以帮助定义和分类各个必要的组件,大数据解决方案需要使用...

3344
来自专栏JAVA技术zhai

架构的演进,阿里资深Java工程师表述架构的腐化之谜

新技术层出不穷。过去十年时间里,我们经历了许多激动人心的新技术,包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境,缩短了产品...

46112
来自专栏Java架构

架构的演进, 阿里资深Java工程师表述架构的腐化之谜

1765
来自专栏腾讯大讲堂的专栏

以“工匠”的精神对待每一个版本

工匠们喜欢不断雕琢自己的产品,不断改善自己的工艺,享受着产品在双手中升华的过程。工匠们对细节有很高要求,追求完美和极致,对精品有着执着的坚持和追求,把品质从99...

18210
来自专栏云加新鲜事儿

技术栈管理:云时代的研发环境

如何实现这样一个研发技术栈管理的平台?我们的观点是,这样一个平台应该集中管理组织中的技术栈,允许基于一个技术栈创建开发测试PaaS和生产PaaS的两个PaaS服...

7450
来自专栏大数据文摘

微信技术总监周颢:一亿用户背后的架构秘密

1284
来自专栏Java架构

架构的演进,阿里资深Java工程师表述架构的腐化之谜

新技术层出不穷。过去十年时间里,我们经历了许多激动人心的新技术,包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境,缩短了产品...

40510
来自专栏韩伟的专栏

互联网开发模式三:持续集成与DevOps

持续集成的意义和实践 不管是敏捷开发的快速迭代,还是重构系统,我们都将频繁的编译代码、部署、测试,也就是所谓的集成。如果我们的系统集成效率太低,那么快速的迭代可...

3476

扫码关注云+社区