SoundCloud從SOA轉換到微服務後加速了交付進度

banq發表於2018-03-16
Cloud微服務
流媒體平臺SoundCloud在2014年從SOA切換到微服務架構以後，幾年經驗證明其軟體開發交付速度和生產力都有所提高。

遙想當初2014年，流行音樂和播客的流媒體平臺SoundCloud變成自己成功的受害者。當時，使用者每分鐘都會上傳12小時的音樂，每天有成千上萬的遊客從平臺上消費各種音訊。SoundCloud不僅面臨著軟體的擴充套件性問題，而且還面臨新功能交付實施的效率低下。

這些問題的根源可以追溯到90年代中期，當時面向服務的架構（SOA） - 一種讓各種應用程式元件在網路上共享服務的架構風格 - 成為程式設計領域的熱門趨勢。這種設計風格是基於網路服務，從而使跨部門和跨公司的技術整合變成可能。

然而，自從鼎盛時期以來的數十年裡，對這種設計風格的批評卻不斷上升，SOA的使用率也開始下降 - 其主要缺點是開銷成本可能很高並且效能低下。由此，程式設計師越來越多地將 “微服務” 作為替代的架構方案。其思路是：將服務分解成更小的元件，將應用程式拆分成更容易分發和複製的元件。關鍵的是，微服務架構能夠實現更快速的持續交付和部署，因為較小的元件能夠更容易、更頻繁地更新。

新時代的新架構
SoundCloud於2014年開始轉向微服務，其開發人員在這裡精心記錄瞭如何將單體架構轉換為新架構的勞動密集型過程。

“當時，我們公司的前端團隊致力於提供面向使用者的功能，而後端團隊則注重提供資料和API，”SoundCloud的高階首席工程師Sean Treadway說。“前端團隊可能會等待後端團隊一個月,後端團隊拖後腿了，主要開銷花在對新功能的支援和實施上，這會增加很多工作管理量並拖延最後的交付進度。”

Treadway說，轉向微服務架構導致了端到端交付團隊的建立。除此之外，“他還介紹了一種類似於Netflix釋出的API閘道器方法，稱為BFFs [Backends for Frontends]，”他解釋說。“提供為每個前端桌面網站、移動應用程式或嵌入式小部件的API​​閘道器，工程師能夠實現針對每個應用程式量身定製的資料API，避免了多個團隊之間的無需協調。”

Treadway表示，這種切換已被證明是該平臺的成功，“特別是對於基本功能和API閘道器的更新。”

Treadway說：微服務顯著增加了運營的複雜性，擁有DevOps思維能夠讓一個小團隊管理好複雜性。

SoundCloud工程方法是“根植于敏捷方法論”，他指出，微服務能很好地融入了DevOps思想。 “我們的文化和人員配備團隊既具備開發和運營技能，又能提供更高質量的服務和更短的事件響應時間，”他說。

重組的成本和挑戰
雖然實踐已經證明切換到微服務是適用SoundCloud的，但這一過程本身並非易事。

“我們預計到了轉向微服務架構需要通用的約定和工具，”Treadway說道，“但我們低估了在建立新的或維護現有服務時需要花費多少努力來保持工程師的生產力。我們還了解到，運營服務還需要滿足一系列非功能性需求。“

一致性和安全性是微服務的額外挑戰。Treadway表示，網路API很容易編寫，但很難保持一致。

“我們的每個服務將API對映到HTTP的方式都略有不同，從而產生了處理這些細微差別的API客戶端庫，，”他解釋說。“連結到共享的API客戶端庫卻導致了依賴的傳遞衝突，這打破了獨立服務部署的目的。”

儘管如此，結果證明這些額外的工作還是值得的，他說：“工程師在通用工具諸如監視、日誌記錄、跟蹤、部署、配置驗證和連線池等產品化掌控方面的能力提高了，工作效率顯著提高。”

那麼，Treadway會推薦大家都切換到微服務嗎？不，他認為微服務在合適的情況下才能得到回報。“我認為，當一小隊工程師維護少量服務時，SOA服務架構是最有效的，”他建議道。

SoundCloud's Shift to Microservices Sped Delivery

相關文章