作者: Ryan S. Brown
原文: Interview: Lambda As A Proxy With Spreaker
译者: 孙薇
本周将有来自Marco的消息:Spreaker会采用API Gateway作为第三方服务代理。代理其他服务会让API更稳定,并有可能在不需更新客户端的情况下切换供应商。Spreaker使用API Gateway、Node.js还有Lambda为其安卓应用提供音频广告。
以下为专访内容
说些与Spreaker相关的内容吧,在托管播客方面你们遇到过什么类型的挑战?目前是尝试为想要托管播客的人提供一站式服务,还是有特定的重点呢?
Spreaker是一个播客平台,用户可以在上面创建、发布、衡量并收听音频节目,包括现场与点播的。我们在2010年推出了Spreaker,随着时间推移,改进良多。如今Spreaker是一个托管与分发播客与广播节目的全面解决方案。
Spreaker的哪一部分将被移到Lambda中?是很小的部分,还是与用户体验攸关的重要部分呢?
Spreaker的商业模式是基于付费订阅的。播客主可以在Spreaker上免费托管自己的播客,不过如果想要获得更多功能或者更大的音频存储空间,就需要付费(起始套餐每月只需少量费用)更新到PRO帐号。
最近我们与Triton签署了协议,刚刚开始在安卓应用上发送音频广告。安卓应用是我们尝试新功能的第一个地方,之后我们会尝试将该功能移植到网络端和iOS端。
音频广告服务是由一系列AWS Lambda函数进行管理的,可通过AWS API Gateway所提供的HTTPS接口访问:基本上是智能代理,为Triton还有我们后续将增加的其他广告代理商提供服务。
我们使用了代理所有音频广告请求,而不是直接调用第三方广告商服务,其中有着充分的理由。引入代理,我们可以在服务器端编写一些逻辑,因此就能在不影响移动应用的情况下进行修改,并可以通过HTTPS发送所有流量。不幸的是,很多广告服务器仍旧只对HTTP提供支持。
除了Lambda之外,你还用到了其他什么技术?包括前端、移动端和数据库,有什么要与我们分享的吗?
我们使用了一堆技术。Spreaker有着非常复杂的基础架构,每天所发送的请求多达数千万个。要想保持结构简单,网络应用(网站与API)要回归PHP、Node.js、PostgreSQL、Redis、RabbitMQ与Sphinx。我们还运行着一个多区域的实时音频数据流应用,基于优秀的Netty框架以Java进行内部开发。我们拥有iOS与安卓应用,各自以相应的原生语言编写,还有一大堆微服务来运行异步任务。
是基于现有产品重写的吗?如果是这样,为什么想要在客户端替换现有的解决方案呢?如果不是这样,怎么决定要使用Lambda的?
广告代理是从头开始编写的。我们对Node.js和AWS Lambda与API Gateway很感兴趣,这让我们得以用Node进行开发,而无需担心部署与扩展问题。
这个项目的团队有多少人?他们有人/每个人在Lambda上有经验吗,或者都是来自其他领域的专家?
Spreaker现在有4个工程师。我自己编写的广告服务器代理,我们没有人有AWS Lambda方面的经验,不过在AWS和Node.js上我们都有若干年的开发经验了,因此转到Lambda并不困难。
在开发该应用上你花了多长时间?是否比你在其他框架中进行编写速度更快?(Express、Rails或者其他什么你们擅长的)
开发用了数周时间。使用AWS Lambda + API Gateway进行开发,就抛弃了从服务器设置到HA设置等管理与维护部署的复杂性。让我们更能关注业务逻辑本身,用AWS完成其他工作:将应用从1个请求扩展到数百个。
如何部署应用?
该应用是基于以Grunt的2个插件进行部署:用grunt-aws-lambda部署Lambda函数,用grunt-aws-apigateway部署API Gateway路径与映射。后者是由我部署的。
你们使用持续整合/持续交付(CI/CD)服务了吗?Lambda是怎样与这一渠道相匹配的?
应用经过了充分测试,包括单元测试与功能测试。我们使用了mocha和chai来执行测试,并用
mock-http-server
来模拟外部服务(也就是Triton广告服务器)。我们确实有Jenkins设置,不过这个具体的应用尚未加入我们的CI工作流。
你们用什么进行监测?有什么你们想要监控,但尚未/无法执行的?
我们使用CloudWatch日志与自定义指标来监控应用。
在发布到生产上之前,如何测试变更?有测试/stage环境吗?
我们构建的每个应用,包括广告服务器代理在内,都运行在三个不同的环境中。
- 本地开发环境
- stage环境
- 生产环境
大多手动测试都是在stage环境中执行的。
从应用推出后,在流量方面有什么变化?能跟我们分享一下PV/API点击吗?是否做过负载测试来查看应用的极限?
大略来讲,Spreaker播客广播应用的安装量超过50万。考虑到每次音频播放前都会发送广告请求,很容易得出大致数字。
在整个过程中,有什么让你们感到惊讶的事情吗?有没有什么任务要比你们预期的更简单/更困难?
使用AWS Lambda执行一切工作都很顺利,不过我们发现安装设置API Gateway有一些烦人。如果使用网络接口,需要进行几百次点击,容易出错,而且文档也不够明确。这也是我编写grunt插件grunt-aws-apigateway来自动部署API Gateway的主要原因。
总结
感谢Marco接受采访,也感谢他用Grunt制作了很棒的API Gateway终端部署工作流。如果在node项目中使用到了Grunt,可以下载grunt-aws-apigateway,将你的代码连接到托管API终端上。
(责编/钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,交流探讨可加微信qshuguang2008,备注姓名+公司+职位)
「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguang2008入群,备注姓名+公司+职位。