映客高级技术总监黄继:7天从开发到上线,云上高效运维实践与探索-阿里云开发者社区

开发者社区> 弹性计算-百晓生> 正文

映客高级技术总监黄继:7天从开发到上线,云上高效运维实践与探索

简介: 2021云栖大会上,映客高级技术总监黄继为大家阐述映客团队如何在较短时间内快速完成业务的开发,同时还要保障业务上线后的稳定运行、快速扩展、访问质量和数据化运营等方面的经验。
+关注继续查看

2021年10月22日,在云栖大会的《云上运维最佳实践》分论坛,映客高级技术总监黄继发表了主题为“7天从开发到上线,云上高效运维实践与探索”的演讲,为大家阐述映客团队如何在较短时间内快速完成业务的开发,同时还要保障业务上线后的稳定运行、快速扩展、访问质量和数据化运营等经验。


本文根据他的演讲整理而成,主要分为三个部分:

一、映客业务的效率问题与挑战

二、应对思路与实践探索

三、未来方向与规划


image001.png

图:映客高级技术总监黄继


映客业务的效率问题与挑战


说到映客,在大部分人理解或认识里,映客就是一个直播的平台。但实际上,映客是有一系列泛娱乐化的各种APP,比如有在线相亲、香港地区的电商直播、陌生人的音视频社交等。截止到目前为止,映客大约有40个业务在线运营。


在映客内部,我们非常鼓励去做新赛道探索和内部创业。所以,我们每年都还会有十多个新的业务被立项、开发和投入上线。在这个大的背景下,时间和效率对我们来说至关重要


image003.png


在时间短这个前提下,对我们主要造成的问题或者一些挑战就来自于这三个方面:


1. 业务需快速做功能迭代。尤其在APP上线初期,有大量的业务需求和功能去完善,我们需要一个比较完善的工具平台和智能化体系。


2. 验证周期短。在数据运营方面,大部分产品在上线之初就设计好了付费、盈利的模式。所以产品会在非常短的时间周期内进行验证。只要验证可行,就会马上转入流量推广和增长获客的阶段。


3. 服务质量。因为我们业务验证周期很短,在这个周期之内,很可能会遇到突发的用户新增。所以我们希望所有的用户,都有比较好的用户体验。这就要求在业务刚上线的初期,在稳定、访问速度等方面,要达到成熟业务的标准。


image005.png


在刚开始的时候,我们大部分产品的必要功能就很多,比如支付、审核、用户触达等。这些功能在初期就是必备功能,涉及到很多团队,需要多方去沟通和对接;其次,内部的流程有时候也会影响工作效率;在服务质量方面和数据运营方面,初期没有什么投入,大家的精力基本都在功能上。  


如果说把这些问题都拉到一个比较长的周期来看,其实不是太大的问题。但在我们的场景里,我们希望在业务上线的时候就已经解决了这些问题,或者能够尽快解决这些问题。


image007.png


我们的解决思路大致分为四个维度:

1. 敏捷,努力完善我运维体系和服务治理体系,从而加快内部的迭代效率;

2. 解耦,通过解耦让业务更加的纯粹,只需要关心自己的业务逻辑;

3. 复用,这么多业务中有一些功能是相同的,把这些功能作为公共服务提供;

4. 场景化,比如说用户注册之后,会涉及到风控、审核、数据可视化和用户触达等。我们把部分能力做了整合,让它在快速获得这些能力。


image009.png


我们给自己定了一些目标和口号,比如我们的目标是“711”,口号是“让业务更专注业务”。“711”意思是7个双端的研发可以在1周时间开发上线1个APP。具体实践的过程是:

首先,提前做统一的资源管理;

其次,在内部所有的业务之间统一服务架构;

第三,做标准的公共服务组件;

最后,沉淀我们自己的业务场景和闭环。


image011.png


应对思路与实践探索


下图是我们应对思路与实践探索示意图,底层主要是统一资源的管理,上面两层是为服务端和客户端提供的开发框架的服务组件,横向部分是将第三方服务和我们自己内部的服务去做一些场景提炼和沉淀。


image013.png


最早,我们先从统一资源管理开始做,其中公有云也提供了一些管控的能力。但为什么我们还要考虑自己来做呢?


image015.png


1.多云支持。这里最早是为了解决服务质量,在发生故障时方便做热备切换。

2.去差异化。如果云扩展了,相互之间会有不同和差异。对于业务层,我们需要把这些差异做到屏蔽,让他们觉得平滑和透明。

3.自有体系。在这个基础上更容易建立自己的自有体系,包括运维自动化的体系和服务管理的体系。

4.成本管理。因为我们需要在很早阶段就做更精细的成本管控,所以我们需要看APP的维度,去看大家的费用消耗或者资源使用情况。


image017.png


上图是当前所有的运维工具和平台的体系。右边最下面是CloudAPI层,我们把所有公有云提供的资源,只要能支持API接口的都做了接入。在这个基础之上,按资源的分类去做相对应的管理工具和平台,包括安全组,因为它的变更频率非常高,所以我们对安全组做了抽象和重新设计,还有一个对应的管理平台。这些资源一旦被开通和投入线上使用,都会和我们自己的服务树做关联绑定。


这棵服务树就是右边黑色的图,在这个树上按照产品、子系统、功能模块进行业务拆分。因为这个树上记录了每个业务和资源的对应关系,所以服务树和内部其他的系统进行关联和联动。


比如与监控系统联动,可以实现监控自动地添加和删除。这棵树不但是运维管理的基础视角,还是内部其他系统数据源。所以它的信息需要准确及时,不能是静态或者手动回复。那么我们如何动态维护和管理这棵树呢?我们通过和上层服务治理结合的方式实现。


image019.png


先介绍一下自动化运维里三个基本的概念。

首先是Service Tag,即微服务模块。当它横向排列展开时就是如图的字符串。在这个字符串里包含了子系统的信息、服务系统的信息、模块的名字。如果把它竖向排列,就和服务树一样,它很多时候可以通过这个Tag生成服务树。

再往上是service Name,包含服务名字、子系统。这两个有相似性,本质是一个东西,只是一长一短。长的这一块更偏向资源和运维管理,短的这个更偏向服务应用。

再往上就是Appid,即业务的标识。Appid下关联了很多业务属性,比如业务的负责人,相关的业务属性等。

这三个基础的概念,底层有一个关联的逻辑关系,可以梳理业务下面的服务,服务所关联的资源。这三个是一一对应的关系。我们所有的自动化运维体系围绕这三个来展开的。


image021.png


具体运行的模式,这里简单跟大家介绍一下。如果创建了一个新的业务。它首先在映客云平台上立项添加;然后生成和业务对应的属性;其次,通过一些接口或者生成工单的形式通知运维平台做基础资源的准备。


同时,研发可以开展代码开发的工作。在代码开发的同时,它需要先到KAE平台创建和生成serviceName和serviceTag的字符串。当这个业务在平台发布线上之后,业务和资源的对应关系会自动生成关联到树上。基于服务树,我们进一步做自动监控,基于KAE平台进一步做远程配置、流量录制。同时业务还会生成一些源数据给大数据做计算分析。生产数据也利用service和Appid信息去决定生产到什么样的队列,去做一些隔离和优先级划分等等,最后落地到大数据。


业务在最初创建时,会和我们的数据平台去做关联。当源数据生成之后,对应的数据就能可视化,和APP相关的数据都会和映客云做一个关联。


image023.png


为了让所有业务都能遵守这样的机制,我们提供了统一的一套开发框架。这套框架提供了一些能力,包括日志、监控上报等基础功能。围绕这个框架,我们也做了周边的脚手架,以便快速生成一个项目。对于整个框架依赖的公共资源,我们抽取出来进行集中的统一管理和运维。


image025.png


下一阶段做一些通用公共服务组件的提炼,包括短信、推送、加解密、埋点等服务。这些都变成公共服务,并且尽可能让它实现自助对接。我们在客户端也同样做了类似的事情,比如热修复、网络优选、通用埋点。我们都提供一个公共的能力。


image027.png


包括对于一些第三方,我们也做了一些提炼。这个设计图底层就是音视频SDK所提供的能力,在高阶应用接口这一层,我们按照房间操作和使用角度去提供接口。通过这样的方式,我们去实现底层SDK接口快速切换,来做到对业务层更加透明


image029.png


在业务场景化这一块,我们内部主要在使用的是用户、金融、IM这三块。比如用户,我们对基本的注册/登录,风控、推广投放和数据可视化能力进行了整合。


image031.png


这些整合过的能力,我们尽可能让它自助配置,自助的对接。我们现在设计的一个目标就是每个组件可以在30分钟内完成接入,达到可连调的条件。


image033.png


经过上面几个阶段的发展之后,们主要的变化和收益在研发人员这边

一是他们可以跨业务的灵活迁移。比如说这个项目要去做了,它可以快速从其他产品里抽调人手。如果不做了,这些人可以快速分散到其他业务里;

二是他们更多时间是聚焦在业务逻辑上,所以可以降低一些经验要求在业务端,我们对业务可以减少开发的工作量;很多组件可以快速对接,我们目前大部分都可以做到30分钟-1小时完成;

三是底层服务升级更加透明,而且这些服务有专人维护,更加成熟稳定,避免业务之间重复踩坑。最后是一些默认的功能整合。


image035.png


我们整套体系从最初100%基于公有云来去搭建和建设,某种程度上也符合最近比较流行的云原生理念。在上图,左边是初期已经开始在用的一些服务,右边是随着现在公有云产品越来越丰富和完善,我们也陆续用了更多的一些能力。大家在准备上云,或者在云上运维里,不可避免都会遇到类似这样的问题,比如说云的定位是什么?云上产品越来越丰富,到底直接使用还是考虑自研?云需不需要去做混合云,或者做多云架构?我觉得这个需要根据业务和场景来做具体的分析和决策。


image037.png


我个人认为这些问题在可控性、迁移性和低投入,这三个角度去寻找平衡。而这三个角度某种程度上点像一个不太严谨的CAP理论。只能占有两个,牺牲掉一个或者放弃掉其中一个。在映客最初的定位里,我们更多侧重在可控性和可迁移性上。


image039.png


未来方向与规划


针对未来,我们要做的一些事情。


首先持续建设多云热备架构,以及迁移能力的加强,这方面主要考虑是服务质量。随着公有云本身的稳定性和可用区域越来越多。这件事情变成一个重要,但不紧急的事情。但是对于一些大面积故障,或者区域性故障,我们仍然是不可接受的。


其次中台化相关的能力,主要针对海外。因为我们越来越多的业务开始去探索海外市场。这一块我们的积累沉淀还很少。


最后更多的场景化。让业务可以更简单,比如客服或者智能投放的能力。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【开发课堂】支付宝小程序如何提交审核与快速上线
    小程序开发完成后,便是要上线。     支付宝小程序上线,需要经过提交审核→灰度→上架,三个操作。     具体操作流程,见官网介绍:小程序提审、发布与修改     接下来,我们来看看如何能够提交审核后快速上线。
1435 0
抢先报名丨2021云上架构与运维峰会12月10日线上开启,五大精彩看点不容错过
本次峰会,希望通过分享云上架构与运维的最佳实践,促进业内DevOps与IaC理念的落地,帮助企业“用好云管好云”,释放云的技术红利。
1483 0
在家运维不用慌 | 盘点那些远程运维中的云上利器
远程办公期间,降低非必要的协作成本和本地操作,来提升开发和运维效率,显得尤为重要。此外,大量的在线教育、在线医疗等行业的客户在疫情期,遇到了流量激增的情况,那么是否有在不影响现有架构的情况下,通过一些工具型产品,就能提升业务的可用性呢? 本文将介绍几款阿里云的开发和运维工具,优势是降低计算资源成本、提升开发运维效率、优化协作成本。
3161 0
如何查看自己的appid是已上线,开发中,接口功能是否添加
第一步:查看appid应用是否已上线     1.登陆开发者管理中心:[url]https://openhome.alipay.com/platform/appManage.htm[/url],查看每一个应用的状态    第二步:查看自己需要的功能是否已经添加:   1.
364 0
十分钟上线-基于函数计算开发 Restful web api & asp.net core web app
.NET Core是一个开源通用的开发框架,支持跨平台, 阿里云函数计算推出了 dotnetcore2.1 runtime, 使用 C# 编写 serverless 函数, 除了很好地支持通常意义上的函数外, 还可以基于函数计算开发 asp.
4548 0
阿里云发布无服务器应用平台,运维效率从未如此高效
近年来,随着越来越多的企业基于微服务架构构建自身核心业务平台后,微服务已获得越来越多技术人员的肯定,同时,微服务也承载着企业数字化转型的重任。但微服务架构的落地给企业的运维团队带来了不少的挑战,原有的运维方式和工具已无法满足微服务架构的需求。
4410 0
云上运维最佳实践一览|阿里云产品内容精选(三十九)
本文内容取自阿里云开发者社区ECS版块,云计算时代选云、用云指南,洞察前沿技术趋势、分享云上运维实战经验,云计算开发者的家园。
104 0
免费 | 开发部署效率提升 12 倍,这款应用托管服务让云上运维更简单
应用托管服务,顾名思义,就是一个用来构建和部署应用的全托管式平台,简化部署和运维过程。 在使用应用托管服务之前,上线一款简单的应用,需要经历: 购买 ECS; 配置 VPC; 配置 RDS; 配置 SLB; 前前后后可能有12个步骤,而借助阿里云Web应用托管服务,可省去云端资源的申购与编排、软件运行时环境的安装与配置、应用程序的启停与维护、部署环境模板的分发与重放等多个环节,一步便能实现赢得上线。
2314 0
开发者云《Serverless函数计算初体验》火热上线。体验函数计算场景领取定制版马克杯
火遍全网的体验挑战第二弹抢鲜首发,体验函数计算相关场景并通过答题挑战即可获得印有阿里云第一行代码的定制版马克杯 活动地址:https://developer.aliyun.com/adc/series/fc/
26309 0
阿里云栖开发者沙龙PHP技术专场-直面PHP微服务架构挑战
在4月20日的阿里云栖开发者沙龙PHP技术专场上,云智慧Technical VP高驰涛为大家介绍了微服务的前世今生,分享了微服务架构实践中所面对的诸多挑战以及相应的应对策略。 以下内容根据演讲视频以及PPT整理而成。
5173 0
+关注
弹性计算-百晓生
做技术领先、性能优异、稳如磐石的弹性计算!
94
文章
0
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载