亚洲av永久无码精品成人-亚洲av永久无码精品放毛片-亚洲av永久无码精品古装片-亚洲av永久无码精品国产精品-亚洲av永久无码精品漫画-亚洲av永久无码精品秋霞电影秋

我之前編譯的一篇文章《公司拆成自主管理的小團隊，馬云專程去北歐學來的管理結構》，說的就是北歐公司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