转载

向微服务迁移？来听听Phil Calcado在SoundCloud的经验教训

在 QCon London 2015会议上， Phil Calcado 分享了 SoundCloud 由单块应用转向微服务架构的一些经验教训，他认为构建微服务平台的核心需求包括三点，快速构建研发环境的能力、基本的监控能力以及快速的应用部署能力。

Calcado是SoundCloud核心工程部的总监，他首先分享了SoundCloud从2011年到现在的快速增长阶段的一些细节，平台每月活动用户数从300万增长到接近3亿。SoundCloud已经是世界上最大的在线音频库，平均每分钟都会有11小时的用户音频上传到平台，客户能够通过移动设备、桌面电脑等各类终端去使用这些音频内容。SoundCloud起初是一个Ruby On Rail的单块应用，直到2011年SoundCloud决定去拥抱微服务的架构风格。

过去的一年里，网上关于微服务的文章很多，包括Martin Flowler的那篇“ 微服务的先决条件 ”。Calcado说，当他读到这篇文章时感到有些不安，虽然一开始并不十分确定原因。在2011年，SoundCloud团队决定为微服务架构而准备开发底层平台。他们很担心可能会产生“微服务爆炸”的情况，担心新开发的微服务数目之多可能会变得无法管理，尤其是从运维的角度去看。

Calcado讨论说，SoundCloud应用平台天生就是云化的，从一开始大量的运算工作就是在Amazon的AWS平台上运行的，包括所有的音频及转码工作。但SoundCloud的应用系统是在Amsterdam的多个私有的数据中心中运行的。Calcado说，从2010年到2011年间， Heroku 是最受欢迎的公共应用部署平台之一，也因此对SoundCloud的微服务规划设计有所启发。SoundCloud团队认同Heroku遵从的 12factor.net 开发指南，Heroku就是基于这些指导意见去构建基于Paas的应用的。SoundCloud使用了 LXC 去实现部署机制，使用 Doozer 进行平台协同。

尽管SoundCloud起初的架构比同期他们研发平台内其他应用的架构都要好，Calcado还是提出了一些存在的问题，最主要的就是数据中心内的应用干扰问题(noisy neighbours)。这个问题是由于SouldCloud使用的LXC技术并未对资源使用进行限制（也就是说没有 cgroups ），同时调度策略也过于简单。

在SoundCloud研发他们新平台的时候，开源社区也在开发类似的方案，包括 Mesos 、 Docker 以及 Kubernetes 等。其中的一些产品有着诸如Twitter、AirBnB和Google这样的公司支持，意味着这些产品研发的进展会很迅猛。SoundCloud一开始倾向于改变平台并使用这些产品，但最终还是决定在迁移之前还是先去简化他们当前的方案（也是在等待业内基于容器的各种方案能够更加稳定）。

Calcado谈到监控时提出，在2011年到2012年期间，业内的自动化检测工具还不是很成熟。SoundCloud一开始选择使用 StatsD 、 Graphite 、 Nagios 以及 Pagerduty 构建监控系统。这个方案虽然可行，但Graphite是整个链条中最弱的一环，因为它仅提供有限的查询语言支持，不仅运行缓慢，而且还耗费大量的磁盘空间。

SoundCloud的团队中，有些成员来公司之前有过大型系统的工作经历，他们并不喜欢既有的推模式监控方案。最终使得SoundCloud去构建他们自己的监控系统 Prometheus ，并已经开源发布到社区。Prometheus使用拉模式去收集监控数据，数据被送到 Icinga 和Pagerduty以进行后续的监控和告警。

Calcado说，与单块应用相比，在微服务架构下很难判断哪里出了问题。他们的核心经验是需要标准化各类监控的仪表盘。如今，在SoundCloud架构下，应用仪表盘配置都包含在代码库中指定的JSON文件中，这样使得微服务的开发团队有责任为了满足监控需要而实现统一的仪表盘。

在SoundCloud平台中，应用的运维相关功能必须以标准的易于访问的方式暴露出来，从而使得外界可以关停应用或者让下游应用交易调用的断路器生效。诸如 twitter-server 之类一些应用平台提供了以HTTP接口的方式暴露功能的示例。Calcado认为，除了要提供标准的运维功能，生产事故的解决方案必须包含升级策略使得管理层知晓事故，这会鼓励管理层优先考虑采取措施避免生产系统要一次次的救火。

谈到最初提及的三个话题中的最后一个，Calcado认为，对于微服务的持续交付来讲，建立一个可靠的构建流水线是至关重要的。不同服务的构建和部署过程也必须是标准化的。尽管并不是所有的SoundCloud服务都通过LXC运行，但使用容器技术确实会带来好处，它使得程序员能够在开发机上构建一个迷你SoundCloud，从而化解开发时服务依赖的问题，这对于程序员来讲是非常有利的。

在演讲总结的时候，Calcado回答了演讲之初提出的第一个问题，为什么他对于Martin Fowler的那篇“微服务的先决条件”提及的一些细节感到那么不安。

那是我第一次意识到我们搞砸了，原来有简单渐进的方式能够解决研发环境快速构建、基本的监控以及应用快速部署的问题，而且完全没必要构建自己的系统。

Adrian Cockcroft 是Netflix在实现微服务架构时的云架构师，Calcado最近与他进行了一次谈话后感到很欣慰。SoundCloud团队十分想知道他们为什么不能在第一次尝试时就构建出完美的系统。Calcado讲述了Cockcroft当时的回应：

嗯？你认为Netflix一开始就做对了？[...]在找到方法绕过问题之前，我们也是一团糟。我们对外公布的往往都是些好的事情。

Calcado在结束时表示，SoundCloud实现的微服务平台有很多好的产出。尤其是Prometheus监控系统，已经成为了大型系统诊断生产问题的关键工具；诸如12factor.net应用开发指南，满足了微服务应用开发指南（“而非规则”）的需要；诸如Twitter提供的 Finagle 应用开发平台，满足了微服务对坚实基础设施的需要。

在QCon London 2015日程安排网页上能够找到Phil Calcado的“ 确实没有免费的午餐：SoundCloud的微服务三年实践 ”演讲幻灯片。

查看英文原文： Phil Calcado on Lessons Learnt During SoundCloud's Microservice Migration

感谢夏雪对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

正文到此结束