向微服务迁移？来听听 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 ）关注我们，并与我们的编辑和其他读者朋友交流。