Spotify工程师讲述如何使用“无聊”技术完成服务发掘和数据库服务

Björn Edström是互联网音乐服务Spotify的工程师,在Spotify的官方博客中,他讲述了Spotify为什么要使用一些“无聊”技术的原因。

Björn指出:

在Spotify的后端服务和架构中,我们使用了这些成熟和经过验证的技术,我会说明如何实现,以及这样做的原因。此外,我们还会试图说明Spotify何时不会使用某些经过验证的技术,背后的原因以及它们的问题。

如今,更多时候,完成工作的合适工具,最好是使用已经存在了一段时间的软件,而且是有成功案例的。举个后端服务的例子,用Java或是Python,而不是Go或者Node.js。另一个例子,数据存储,用MySQL或PostgreSQL,而不是MongoDB或是Riak。

对于“成熟”的定义,Björn这样理解:

一项成熟技术的原则之一,就是对于你特定的使用案例,它在多大程度上能作为黑盒使用。如果你不时就得去捣腾下它的代码,就可以说这个项目对你来说还不够成熟,否则你就基本上不用,或者很少需要去给软件打补丁。

这很重要,因为“完成工作的正确工具”有成本方面和临时性的效应。比如,考虑到配置和调优,一种存储解决方案对于你目前的负载和资源是有意义的,如果用户量和负载上来了,另一种方案就更有意义。

接下来,Björn先介绍了他们的DNS和绑定解决方案。

Spotify大量使用DNS,他们将其用作分布式的复制数据库,可处理大量读负载。在具体用途上,他们用DNS解决服务发现问题。而且,他们使用的SRV记录。DNS SRV记录是一种规范化名称,形式为:name.protocal.site,映射到一个主机名列表上,带有权重、优先级和端口号。

举个例子,当Spotify的客户端连接到接入点AP(就是客户端到Spotify后端的连接)时,它会寻找SRV记录 spotify-client.tcp.spotify.com。接入点为要发送请求的每个后台服务做如下事情:

$ dig +short _spotify-client._tcp.spotify.com SRV

10 12 4070 A1.spotify.com.

10 12 4070 A2.spotify.com.

10 12 4070 A3.spotify.com.

10 12 4070 A4.spotify.com.

上面的字段按顺序为:优先级、权重、端口号和主机。服务的一个用户可以根据权重比和优先级选择服务器。只有当所有服务器都宕机时,请求才能发送到低优先级的服务器上。上例中,所有四个主机名都有同样优先级(10)和同样权重(12),因此,在正确配置的环境中,它们会各自处理25%的流量。

支持Spotify的所有后端服务,都可以通过询问正确的SRV记录发现,服务之间也是这样彼此发现的。对于不适用DNS的,比如外部可见的web服务,他们在DNS前开发了HTTP外观。比如,某些客户端会发送HTTP请求,找出应该连接哪个接入点。

在某些情况下,Spotify使用CNAME和PTR记录来补充SRV记录,这主要针对某个服务器有特定目的的情况。

他们开发了一些工具,比如让SRV查找变得更简单的命令行工具,作为DNS缓存的 web服务等等,其中包括反向查找(将主机名映射到服务名)等特别功能。

他们还用DNS存储服务配置数据,比如在TXT记录中存储DHT环信息,并以此信息作为定位多个复制数据库的辅助。

在基础设施和系统管理方面,为了支持DNS,他们使用了一些有特色的开源项目,比如dnspython、dnsjava和c-ares,这些分别是用Python、Java和C开发的DNS解析器。

Spotify的DNS服务器上运行Bind,很多后端服务运行Unbound,这也是DNS服务器,用来改善性能,并降低主DNS服务器的负载。他们在自己的git库中维护DNS区域文件,并在DNS主服务器上运行一个小Makefile文件,从git库中部署变更,推送到不同数据中心的DNS从服务器上。

从2007年启动beta版本开始,这种方案就基本上没有变过,而且扩展性特别好,处理了数千台服务器、几十个服务器和几千万用户。

不过最近,他们在考虑逐步放弃DNS,原因有:

  • 部署新硬件时,管理DNS区域文件的开销过高。
  • DNS提供对于世界的静态视角(“这些是应该正在运行的服务器”),当服务器越来越多时,动态视角变得越来越重要和有用(“这些是目前真正在运行的服务器”)

截止2013年1月,他们尚未开始执行替代方案,但是已经开始调研Zookeeper。

在数据库方面,Spotify是PostgreSQL的重度用户。后端第一个版本就是用它。

Björn认为:

PostgreSQL是高度成熟技术的上佳例子。除非用得太多,它“非常到位”,不用去折腾、甚至不用理解源码。PostgreSQL手册也是世界上开源项目中的最佳文档之一。

在Spotify的开始阶段,负载较低时,PostgreSQL绝对是“完成工作的正确工具”。

他们开始用PostgreSQL 8,并使用其中的复制特性。PostgreSQL 9出来后,他们在存储用户身份验证信息的集群中使用了9,一台主数据库服务器负责写,多台热备份服务器处理所有的读。

他们还开发了与基础设施相关的库,以相对智能方式判定使用哪个从数据库,基础设施库中跟踪节点健康状况,会从DNS中选取新节点,并停止向DNS记录中已经删除记录的服务器(或健康程度过低的服务器)发送请求。

选择成熟的技术还有一个好处,相关技术也相对成熟。Spotify大量使用Python的psycopg2库,他们曾有一些服务使用sqlalchemy和类似项目,但很快开始编写自己的SQL到psycopg2中,这样可以深入控制和了解他们的环境。

为了降低到PostgreSQL服务器的连接数,他们最近开始使用pgbouncer——这是一个连接池调度器。PostgreSQL的架构决定了PostgreSQL会为每个连接启动新进程,有连接池调度器有助于降低服务器资源使用率。

不过到了2009年,Spotify不断发展,服务器负载成为越来越大的问题。后来,他们选择了Cassandra:

这不是因为Cassandra是热门的新技术,而是因为它对我们来说是正确的工具,从经济角度和短期策略角度都是如此。

他们有一个专人的人,全天候扑在Cassandra上面,因为它不像PostgreSQL那么成熟,也不完全是个黑盒子。他们从中得到的收获,是一种特定设置,对于特定情形很有用,这对于他们部署到更多数据中心和服务器上十分重要。

  • 正确管理的Cassandra集群有更好的复制特性(特别是针对写操作)。
  • 正确管理的Cassandra集群可以更好地应对网络问题和失败,比如分区或是间歇性小故障。
  • 总得来说,从运维角度看,Cassandra在特定的失败情况下表现很好,比如服务器宕机、网络中断等,比PostgreSQL好。

不过要注意,对Spotify来说这些是相对较新的问题,其中很多在几年前还没有。如果当时就用Cassandra,那就不是“完成工作的正确工具”了。

你可能感兴趣的:(Spotify工程师讲述如何使用“无聊”技术完成服务发掘和数据库服务)