撰稿 | 杰承
51CTO讀者成長計(jì)劃社群招募，咨詢小助手（微信號(hào)：CTOjishuzhan）
眾所周知，身為全球“云計(jì)算一哥”，亞馬遜向來是微服務(wù)和無服務(wù)器架構(gòu)的追捧者。長期以來，亞馬遜也在眾多場合表示過對這種“現(xiàn)代化”應(yīng)用程序最佳構(gòu)建方式的支持。
然而作為亞馬遜旗下元老級(jí)別的流媒體平臺(tái)，Prime Video卻在近期發(fā)表的一篇博客中否認(rèn)了老大的這一觀點(diǎn)，并提出了“從分布式微服務(wù)架構(gòu)到單體應(yīng)用的轉(zhuǎn)變，更有助于實(shí)現(xiàn)高規(guī)模、彈性和降低成本。”
Prime Video的這翻言論，其實(shí)都源于其技術(shù)團(tuán)隊(duì)近期所進(jìn)行的一項(xiàng)實(shí)踐——當(dāng)團(tuán)隊(duì)將Prime Video從微服務(wù)轉(zhuǎn)向整體應(yīng)用后，不僅提升了其擴(kuò)展能力，還成功節(jié)省了90%的基礎(chǔ)設(shè)施成本。
1、選擇微服務(wù)的初衷
作為一個(gè)流媒體平臺(tái)，Prime Video每天都會(huì)向客戶提供成千上萬的直播流。為了確保客戶無縫接收內(nèi)容，Prime Video需要構(gòu)建一個(gè)監(jiān)控工具來識(shí)別客戶所查看的每個(gè)流中的質(zhì)量問題，這提出了極高的可擴(kuò)展性要求。
對此，Prime Video團(tuán)隊(duì)優(yōu)先考慮了微服務(wù)架構(gòu)所能帶來的便利。由于微服務(wù)能夠?qū)误w應(yīng)用分解為多個(gè)模塊，這不僅能解決工具獨(dú)立開發(fā)和部署的問題，還能為應(yīng)用提供更高的可用性、可靠性以及技術(shù)多樣性。
在經(jīng)歷了上下的一致認(rèn)可后，Prime Video選擇創(chuàng)建了一個(gè)由AWS Step Functions編排的分布式組件的解決方案，這是一個(gè)基于狀態(tài)機(jī)和任務(wù)的無服務(wù)器編排服務(wù)，理論上，這將允許團(tuán)隊(duì)獨(dú)立擴(kuò)展每個(gè)服務(wù)組件。
在完成一系列遷移工作后，Prime Video的服務(wù)最終由三個(gè)部分組成，媒體轉(zhuǎn)換器將音視頻流發(fā)送到檢測器的音視頻緩沖區(qū)；缺陷檢測器執(zhí)行算法，并在發(fā)現(xiàn)缺陷時(shí)發(fā)送實(shí)時(shí)通知；第三個(gè)組件則提供控制服務(wù)流程的編排。
2、難以承受的系統(tǒng)開銷
但很快，Prime Video便意識(shí)到了分布式方法在特定用例中并沒有帶來很好的效果。最初的解決方案設(shè)計(jì)使用了無服務(wù)器組件的分布式系統(tǒng)，這在理論上而言是快速構(gòu)建服務(wù)的最好選擇。
然而當(dāng)更多流加入到服務(wù)中時(shí)，擴(kuò)展受限和成本過高兩項(xiàng)問題開始逐漸顯現(xiàn)。該架構(gòu)中的主要擴(kuò)展瓶頸是使用AWS Step Functions實(shí)現(xiàn)的編排管理，由于服務(wù)每秒都會(huì)在流中執(zhí)行多次狀態(tài)轉(zhuǎn)換，這使服務(wù)很快達(dá)到了賬戶限制。
除此之外，由于AWS Step按照函數(shù)狀態(tài)轉(zhuǎn)換向用戶收費(fèi)，當(dāng)需要處理大量流的時(shí)候，大規(guī)模運(yùn)行基礎(chǔ)設(shè)施的開銷會(huì)變得非常昂貴，所有構(gòu)建模塊的總成本過高，導(dǎo)致Prime Video團(tuán)隊(duì)無法大規(guī)模接受最初的解決方案。
基于開銷問題，Prime Video為了減少昂貴視頻的轉(zhuǎn)換工作而建立了一個(gè)新的微服務(wù)，以將視頻分成幀并將圖像臨時(shí)上傳到亞馬遜簡單存儲(chǔ)服務(wù)（S3 Bucket），并使用AWS Lambda并行處理。然而對S3 Bucket的大量一級(jí)調(diào)用同樣需要支付巨額費(fèi)用。
3、從微服務(wù)遷移到單體架構(gòu)
無奈之下，Prime Video開始考慮單體的解決方案以降低成本和增加應(yīng)用的擴(kuò)展能力，在經(jīng)歷了反復(fù)試驗(yàn)后，團(tuán)隊(duì)最終決定重建Prime Video的整個(gè)基礎(chǔ)設(shè)施。
當(dāng)意識(shí)到分布式方法在特定用例中無法帶來更多好處時(shí)，Prime Video選擇將應(yīng)用中的所有組件打包到一個(gè)流程中，這成功消除了S3 Bucket作為視頻幀中間存儲(chǔ)的需求。在此基礎(chǔ)上，團(tuán)隊(duì)還實(shí)現(xiàn)了在單個(gè)實(shí)例中控制組件編排。
從概念上講，在保持頂層架構(gòu)不變的前提下，Prime Video仍然擁有與初始設(shè)計(jì)完全相同的組件，包括媒體轉(zhuǎn)換器、缺陷檢測器及編排。這允許Prime Video團(tuán)隊(duì)重用大量代碼，并快速遷移到新的架構(gòu)。
當(dāng)然，轉(zhuǎn)換為單體架構(gòu)也給Prime Video提出了新的挑戰(zhàn)。在最初的設(shè)計(jì)中，由于每個(gè)檢測器都能作為獨(dú)立的微服務(wù)運(yùn)行，Prime Video能夠水平擴(kuò)展多個(gè)檢測器。然而在單體架構(gòu)中，檢測器只能在同一實(shí)例中運(yùn)行。
為克服這個(gè)問題，Prime Video對服務(wù)進(jìn)行了多次克隆，利用不同的檢測器子集對每個(gè)副本進(jìn)行參數(shù)化，并實(shí)現(xiàn)了在單個(gè)實(shí)例中控制組件的編排，該解決方案運(yùn)行在EC2(彈性計(jì)算云)和ECS(彈性容器服務(wù))上，且具有一個(gè)輕量級(jí)編排層來分發(fā)客戶請求。
最終，將全部服務(wù)遷移到整體平臺(tái)后，Prime Video的基礎(chǔ)設(shè)施成本降低了90%，并擁有了更強(qiáng)的擴(kuò)展能力。如今，Prime Video不僅能夠同時(shí)處理成千上萬的音視頻流，且仍有能力進(jìn)行更多的服務(wù)擴(kuò)展。
4、被過度營銷的微服務(wù)
微服務(wù)被過度營銷可能是許多問題的根源，medium作者Adrian（前亞馬遜云科技可持續(xù)發(fā)展架構(gòu)副總裁、前云架構(gòu)戰(zhàn)略副總裁）發(fā)文認(rèn)為，這可能是因?yàn)楣?yīng)商想通過簡單的營銷信息來銷售Kubernetes，即企業(yè)需要通過使用Kubernete為一切提供云原生微服務(wù)來實(shí)現(xiàn)現(xiàn)代化。
事實(shí)上，我們看到的是對這種信息的實(shí)踐上的強(qiáng)烈反差。具有諷刺意味的是，許多企業(yè)工作負(fù)載是間歇性的、小規(guī)模的，非常適合使用Step Functions和Lambda的無服務(wù)器優(yōu)先方法。但如果大型團(tuán)隊(duì)則不然，大規(guī)模運(yùn)行的成本是高昂的，僅Kubernetes的復(fù)雜性就會(huì)讓人倍感頭疼。
摘自Serverless First（無服務(wù)器優(yōu)先）2019年發(fā)布
Prime Video團(tuán)隊(duì)的做法被adrian稱之為Serverless First的路徑，即，構(gòu)建東西的第一次嘗試是與Step Function和Lambda調(diào)用結(jié)合在一起。重點(diǎn)在于，當(dāng)你在探索如何構(gòu)建東西時(shí)，在幾天或幾周內(nèi)快速構(gòu)建一個(gè)原型是一個(gè)很好的方法。然后，他們試圖對其進(jìn)行擴(kuò)展，以應(yīng)對高流量，并發(fā)現(xiàn)他們的步驟函數(shù)中的一些狀態(tài)轉(zhuǎn)換過于頻繁，并且他們在AWS lambda函數(shù)和S3之間進(jìn)行了一些過多的調(diào)用。他們能夠重用大部分工作代碼，將其組合成一個(gè)長期運(yùn)行的微服務(wù)，該微服務(wù)使用ECS進(jìn)行水平擴(kuò)展，并通過lambda函數(shù)調(diào)用。這只是構(gòu)成Prime Video應(yīng)用程序的眾多微服務(wù)之一。
問題是，他們將這種做法稱為微服務(wù)到單體的轉(zhuǎn)變，而這顯然，只不過是微服務(wù)重構(gòu)的一步。
5、微服務(wù)不應(yīng)該是默認(rèn)選擇
這篇博客確實(shí)證實(shí)了一些開發(fā)者的懷疑，微服務(wù)相對于整體應(yīng)用的優(yōu)勢經(jīng)常被夸大；微服務(wù)的解決方案也并非在所有情況下都是最具成本效益的，因?yàn)樗鼈兛偸菚?huì)涉及使用多種昂貴的服務(wù)。
在Hacker News中，Ruby on Rails之父Hansson給出了這樣的評(píng)價(jià)，“這篇文章理論上總結(jié)了一段時(shí)間以來席卷科技行業(yè)的微服務(wù)熱潮，現(xiàn)在，所有這些理論的實(shí)踐結(jié)果終于出現(xiàn)了。很明顯在具體情況下，微服務(wù)是可能導(dǎo)致你系統(tǒng)復(fù)雜化的最大誘因。”
按照Hansson的說法，“在一個(gè)單一的、一致的團(tuán)隊(duì)和應(yīng)用程序中，使用網(wǎng)絡(luò)調(diào)用和微服務(wù)劃分代替方法調(diào)用和模塊分離，在幾乎所有情況下都是非常瘋狂且沒有意義的，而無服務(wù)器會(huì)讓情況變得更糟?！?/p>
《構(gòu)建微服務(wù)》一書的作者微服務(wù)大師Sam Newman也在Twitter總結(jié)了以下的觀點(diǎn)，“這篇文章更多的是在談?wù)摴δ芏▋r(jià)模型與長期運(yùn)行虛擬機(jī)的定價(jià)模型，這是完全合乎邏輯的架構(gòu)驅(qū)動(dòng)因素。雖然這個(gè)案例所提供的經(jīng)驗(yàn)并沒有太廣泛的適用范圍，但當(dāng)情況發(fā)生時(shí)，改變想法的確是非常明智的?！?/p>
總而言之，即使是作為單個(gè)進(jìn)程或整體部署的應(yīng)用程序，在設(shè)計(jì)上也是可以進(jìn)行模塊化的，不同的團(tuán)隊(duì)在每個(gè)模塊工作。實(shí)現(xiàn)了這一點(diǎn)，許多組織使用模塊化整體架構(gòu)的效果將比微服務(wù)更好。微服務(wù)不應(yīng)當(dāng)成為組織的默認(rèn)選擇，而應(yīng)當(dāng)是最后手段。
6、寫在最后
歸根結(jié)底，無論是微服務(wù)還是單體架構(gòu)，都有著自身的優(yōu)勢與缺陷。但在過去幾年中，太多的開發(fā)者被微服務(wù)的好處所說服并輕易對其進(jìn)行了采用。這也導(dǎo)致了許多系統(tǒng)體量或是團(tuán)隊(duì)成員不足的組織的失敗。換句話來說，當(dāng)你沒有明確看到當(dāng)前系統(tǒng)的瓶頸時(shí)，先做所有簡單的事情。
Prime Video的這篇博客對于許多支持分布式微服務(wù)的云巨頭而言并不一定是一個(gè)壞消息。雖然在一方面，它違背了云巨頭所傾向的最佳實(shí)踐；但在另一方面，它提供了一條令人耳目一新的道路，以及一個(gè)非常成功的遷移案例。與許多我們所熟知的促銷方式不同，這個(gè)案例可能對這些云巨頭的客戶而言將更有意義。
