我之前编译的一篇文章《公司拆成自主管理的小团队，马云专程去北欧学来的管理结构》，说的就是北欧公司Hudl如何模仿Spotify“自主运营小组”的管理模式。具体这篇文章是Spotify官方博客里的内容，相比Hudl所说的，算是第一手的经验。

Spotify是北欧的技术公司，一直热衷于在内部建立大量的“自主运营小组”（squad），由小组自我完成工作，而不需要自上而下的管理。这很类似于凯文凯利在《失控》中的观点，在企业内部组织运行中的实现。

今天的文章，说的是Spotify一方面在企业组织形式上建立“自主运营小组”，一方面又在技术后台的系统架构上，为适应这种企业组织形式，而进行了相应的调整。

从文章隐含的意思来看，Spotify一直认为，公司内部运行效率低下的重要原因是：各个团队之间需要互相协作，一旦某个团队工作进度慢了，其他所有团队都要等着，于是造成工期延误。所以，要提高公司的整体效率，就要让各个工作团队之间，互相不依赖；任何一个团队的工作不影响另外一个团队。

为了实现这样的效果，公司产品层面应该把各个功能模块都隔绝开，某个功能出现问题，不影响其他功能的正常使用，也就是说，开发这个功能的小组掉链子了，其他小组开发的功能还仍然照旧运行。

为了实现这样的效果，公司的系统架构上也要调整。数据库、存储等技术性资源支持方面的工作，也不需要公司内部来组织某个职能部门来协调，否则职能部门的工作效率将会影响到资源的调配效率。所以Spotify建立来一个类似云服务的平台，让小组自己去配置。

这篇文章有一些细节内容偏技术，所以我翻译不出来，错误肯定会不少。大家如果侧重技术，还是去看原文吧。原谅我，我本专业只是个律师。

为什么明明读不懂技术名词，还要硬着头皮看这篇文章呢？

因为，即使是说了很多偏技术的东西，但是基本的思路我还是非常理解和认同。或者说，这种技术后台的系统架构，其实就是一种企业生产流程。即使是非技术型的企业，也可以建立一种这样的企业运营体制，在这个体制之上建立各个接口，让各个独立的工作小组，可以接入这体制、进行运转，而不受其他环节的束缚。

这是我想将来尝试的企业组织和管理结构。

其实，经济学家科斯说过类似的观点。为什么企业会产生？企业的各个部门，之前本来都是独立的，大家通过市场上的自由合作来实现协作。如果什么时候觉得自由合作效率不高，那大家就合并起来，组成一个企业，由企业进行自上而下的计划经济模式的指挥管理。现在，Spotify这种模式的出现，实际上把企业产生之前的市场自由合作，又搬回来企业内部，在企业内部建立一个自由协作的市场机制。

我想，原因可能是，在科斯时代及之前，信息在市场上的传导速度太慢，导致自由合作的效率低，而合并为一个企业后，在企业内部组织生产，信息传导的速度就起来了。但是现在，有来IT信息技术，即使是在企业外部，信息也可以迅速传导，那么就不需要企业来组织生产来，通过一个信息架构平台，就可以实现企业本身的信息传递、生产组织等职能。

比如，Uber、滴滴打车、Airbnb、饿了么，实际上都是在用技术平台，扮演之前“企业”的角色。司机不再需要从属于出租车公司来调度，滴滴打车的技术平台就是出租车调度公司。

信息技术，正在取代企业组织形式。

在这篇文章里我要大致介绍一下Spotify的后台架构。我们的后台架构一种处在不断改进的过程中，有的模块已经用了很久了，有多么模块才刚刚开始开发出来。

要理解为什么Spotify要建立这样的后台架构，最好先了解一下Spotify的团队组织结构和协作模式。Spotify目前有300名工程师，而且还在快速增加中。

一、背景

1. 增长：

Spotify的所有指标都在不停地增长，而且规模越来越庞大。比如，日常用户的数量、后端节点的数量、客户端所运行的硬件平台数量，产品开发团队的数量，在Spotify平台上运行的外部应用程序的数量，Spotify上歌曲的数量，都在一股脑迅速增长。

2.速度：

正是因为Spotify的增长速度太快，我们不得不一遍又一遍地仔细分析，在Spotify有什么东西会妨碍这样的发展速度，并且不断地消除这样的因素。所以，我们付出了不少努力，一方面，尽可能降低内部各个团队之间的互相依赖关系；另一方面，如果我们的架构中存在某些会让工作复杂化的东西，而这些东西又是可有可无的话，我们就会干净利落地淘汰掉这些毫无意义的复杂玩意。

在Spotify我们建立了很多自行运营的小组（squad）。Spotify内部，最重要的一个观念就是，团队必须能自行运营。每个开发团队（或者说“小组”），其工作和运营，都应当是能独立于其他小组的。

即使有时候两个小组之间存在一定的互相依赖关系，但大部分时候各个小组之间还应当是独立前进的。如果某个小组的工作能否取得进展，依赖于另一个小组的工作进展，那么我们会采取这样的策略：在内部各个团队之间实行代码透明化的模式（ transparent code model），并建立自助服务架构（ self service infrastructure）。

3. 代码透明化模式：

Spotify内部的每个开发团队都可以看到Spotify的所有代码。这意味着，Spotify的所有开发人员，都可以看到Spotify客户端、Spotify后台和Spotify架构的所有代码，并且也可以修改这些代码。如果某个小组迟迟不能完成工作，导致另外一个小组没有办法开展下一步工作，那么后面这个小组完全可以跳开前面那个小组，自己去完全前面小组应该完成的工作、直接更新所需要的代码。

在实践中，Spotify的代码透明模式，是通过所有团队共享同一台git服务器（git server）来实现的。每个git存储器（ git repo）都会指定一名系统所有者，负责维护代码，确保代码不会rot。代码透明模式让每个人的工作都可以向前推进，每个人都可以获得其他所有人的代码。这种方式让Spotify可以随时向前推进，并保持一种积极和开放工作环境。

4. 自助服务架构：

所有的架构都应当是可以自助服务的（ self service entity）。通过这种方式，任何一个团队要向前推进工作，都想不需要等另外一个团队帮他们获得硬件支持、设置存储集群（ storage cluster）或更改配置（ configuration change）。Spotify的后端架构建立来好几个层次的硬件和软件，从物理设备（ physical machines ）到信息传输（ messaging）与存储解决方案（storage solutions）。

5. 开源：

我们一直在尽可能用开源的工具。在Spotify 的后端所使用的软件中，我们会选择对Spotify最关键的一些软件，努力提高其可伸缩性。Spotify 也在积极参与为许多开源项目，比如Apache Cassandra和ZMQ。我们几乎没有自己的专用软件，因为我们不认为我们有能力开发出能适应Spotify飞速发展需求的软件。

6. 文化：

在Spotify我们坚信应当给个人充分的授权。这反映在我们的企业组织结构中建立了自主运营团队。这样工程师就有足够机会在Spotify内部参与和尝试其他领域的工作，从而让每个人对工作都能保持热情。我们还会定期组织骇客日（hackday），让每个人尝试实现他们的任何想法。

二、基本架构

只要是需要处理大量用户的系统架构，Spotify都会进行分区。Spotify架构有多种分区的方式。最主要的是通过功能进行分区。我们可以先采用非常非常简化的方式来描述这种分区。

比如，Spotify客户端中所有页面中涉及物理屏幕的部分，由某个小组负责，Spotify中所有的功能性部分由另一个小组负责。每个小组负责的功能都是跨平台的，比如，既包括在IOS设备上、也包括在浏览器上通过Spotify的后端即时响应请求。（翻译不出来了，不太懂技术啊）

即使某个功能没能实现出来，Spotify客户端上的其他功能仍然不受影响，并会独立地继续工作。如果两个功能之间确实存在某种些微的依赖关系，有时候一个功能没有实现，只会导致另一个功能不能完全发挥出来，但不会导致整个Spotify无法提供服务。

由于并不是每个用户都会用到Spotify的所有功能，某些功能出现问题只会涉及到很小一部分用户。

并且，因为某个功能所涉及的技术，都由某一个小组集中掌握的，所以很容易在这个小组内部进行A/B测试，也很容易对收集到到数据进行分析，并由直接涉及的小组来负责考虑如何对这个功能进行决策。

功能分区工作更具有可伸缩性、更可靠、也更高效，从而使团队的工作更专注。

三、后端架构

Spotify先是把产品架构按功能进行分区，并建立了技术水平高超的跨功能小组来进行工作任务的维护。在解决这些问题之后，Spotify面临的问题是：Spotify的后端架构能否确保各个小组独立自主运营。

让每个小组都可以快速地开发出产品功能，而不会受到其他小组的拖累，这是我们的架构所需要解决的问题。而Spotify的解决方案，还应当可以扩展到全球。我已经说过，我们建立了代码透明模式来解决这个问题，让某个团队可以直接跳过其他配合团队的工作，直接向前推进。但是，除了众多的功能开发小组之外，Spotify还有其他团队需要以合适的方式组织起来。

在许多企业的组织体系里，都会有一个数据库管理员，负责数据库及其架构的维护。你需要通过运营部门区申请从数据中心分配硬件，或者诸如此类的工作。

如果自主运营的产品开发小组有100个以上时，这种组织工作就会成为小组开发工作的瓶颈，因为运营部门实在无法应付众多的小组同时提出需求。

为了解决这个问题，我们开发出了一个后端的架构，提供完全自助化的服务，不再需要运营部门来做这样的配合工作。完全自助服务意味着，任何小组都可以在现场自行进行开发和迭代，而不需要其他团队或部门的配合。

1. 配置：

如果某个小组开发新的功能，往往需要在多个地方同时部署。我们正在开发的一个后端架构，运行开发小组自行决定是在Spotify的数据中心部署，还是在外部的公有云部署。Spotify的系统架构，正在尽可能让Spotify内部的数据中心和外部的公有云之间不存在太大的差别，这样方便开发小组选择和使用。简而言之，Spotify内部的数据中心迟延问题处理的最好，也最稳定。外部公有云硬件条件更好更快，而且动态扩展性更好。开发小组可以根据自己的需要灵活选择。

2. 存储：

大多数功能都需要某种形式的存储，比如“播放列表”功能或者“关注”功能。对于一个有数百万人使用的功能来说，建立一个合适的存储解决方案并不是一件容易的事情，有很多因素都需要考虑到：访问模式、站点之间的故障转移、工作容量、一致性、备份、降级等。很难找到一个通用的方法完全解决所有的问题。所以，Spotify的后端架构中提供了不同的存储方案：Cassandra, PostgreSQL 和 memcached。

3. 信息传输：

Spotify的客户端和后端服务之间的信息沟通，通过这种模式来实现：请求-应答（ request-reply），信息传输（ messaging），发布订阅（pubsub）。我们自己建立一套低迟延、低额外开销（overhead）的信息传输层，并准备将其扩展到高投递保障（ delivery guarantees）、故障转移路由（ failover routing）和更灵活的负载平衡（load-balancing）。

4. 容量规划：

Spotify的快速增长使Spotify的后端发生了大量的流量。每个小组都需要确保他们的功能可以扩展到本地负载。各个小组可以手动监控其流量，发现和解决遇到的瓶颈，并根据需要扩容。我们也建立了一个后端架构，让各个小组都可以自动扩展其服务的负载。因为只有在你已经发现遇到瓶颈了才会扩展自动负载，所以需要开发小组自己进行一定程度的人工监控。我们的后端架构可以很容易的创建出负载情况的图标，并在需要时发出警报。

5. 功能或服务互相隔离：

小组开发出来的新功能或服务之间应当与现有的功能保持一定的隔离。这非常重要，因为这样就能让开发小组毫无顾忌地以最快的速度开发产品，同时把负面影响控制在最小。为了实现这样的需求，我们对信息传输层的速率做了限制，并且通过许可机制进行控制。速度限制有一个默认的阈值，从而运行开发小组可以在一定范围之内调用其他服务。如果预计到可能发生流量拥堵，开发小组之间需要进行协调，以共同处理这个问题。不同小组开发的不同功能，分别独立地在不同的服务器或虚拟主机上运行，以避免某个服务影响到另外一个服务。

四、总结

正如我一开始所说的，我们的这种架构还处于完善过程中，还会遇到很多有意思的挑战。我所说的，只是我们目前的观点。因为我们一直在不断改进，所以我的观点也会不断修正和改变。

原文标题：Backend infrastructure at Spotify

原文链接：https://labs.spotify.com/2013/03/15/backend-infrastructure-at-spotify