Spreaker采用Lambda构建代理的实践

作者： 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入群，备注姓名+公司+职位。