幾年前，我所在的一家傳統(tǒng)行業(yè)的頭部企業(yè)啟動了一系列數(shù)字化轉(zhuǎn)型項(xiàng)目，在配套的 IT 基礎(chǔ)設(shè)施建設(shè)上，“上云”已是大勢所趨。
在此前數(shù)年的工作中，我斷斷續(xù)續(xù)地使用著公有云產(chǎn)品，大多數(shù)情況下，我們只選擇 IaaS 層級的服務(wù)，也就是只使用虛擬實(shí)例，對 PaaS 和云平臺特定的 Serverless 服務(wù)敬而遠(yuǎn)之。作為一名架構(gòu)師，我對公有云的此類產(chǎn)品一直懷有一種“戒備”心理。
一方面，從技術(shù)發(fā)展路線上，不管是個人還是團(tuán)隊(duì)，我們都希望學(xué)習(xí)并使用行業(yè)主流且平臺中立的技術(shù)，這些技術(shù)大多數(shù)都是開源的，有著活躍的社區(qū)和良好的周邊生態(tài)，包括高質(zhì)量的文檔、豐富的技術(shù)專著，以及互聯(lián)網(wǎng)上大量的討論文章等等；另一方面，從公司角度出發(fā)，我們也不希望企業(yè)與某一朵云深度綁定，這似乎總讓人缺少一種“安全感”。
此外，對于還沒有準(zhǔn)備好擁抱云計(jì)算的技術(shù)人員來說，上云會給他們帶來一種危機(jī)感：“既然你都已經(jīng)做得這么好了，那以后還要我做什么呢”？這一感受最初產(chǎn)生于 IT 的基礎(chǔ)設(shè)施團(tuán)隊(duì)，之后系統(tǒng)架構(gòu)師也會有些許同感，這也是很多 PaaS 和 Serverless 服務(wù)“不受歡迎”的原因。但對于云廠商而言，由于這類服務(wù)的利潤率更高，他們會更加熱衷于推薦此類服務(wù)，這會讓本已十分敏感的用戶更加警惕，以至產(chǎn)生抗拒心理。
回到公司的數(shù)字化轉(zhuǎn)型項(xiàng)目，在聽取了多方意見之后，公司決定僅使用虛擬實(shí)例構(gòu)建應(yīng)用系統(tǒng)和數(shù)據(jù)平臺，盡可能避免深度介入平臺特定服務(wù)，甚至連非?；A(chǔ)的對象存儲服務(wù)也沒有采用。我們數(shù)據(jù)團(tuán)隊(duì)負(fù)責(zé)構(gòu)建大數(shù)據(jù)平臺，在一批虛擬實(shí)例上搭建了一個 Hadoop/Spark 集群后，就開始了長期的數(shù)倉建設(shè)工作。
之后，隨著數(shù)據(jù)規(guī)模的不斷上漲，集群也經(jīng)歷過幾次擴(kuò)容，得益于 Hadoop 集群管理工具和自動化運(yùn)維工具的支持，每次擴(kuò)容倒也不算麻煩。當(dāng)時，我們對基礎(chǔ)設(shè)施的總體狀況是滿意的：“你總得維護(hù)一堆機(jī)器，然后定期擴(kuò)容，哪個系統(tǒng)不是這樣呢？”
幾年后，機(jī)緣巧合，我去了一家業(yè)界知名的云計(jì)算公司。所謂“食君之祿、忠君之事”，入職后，我必須廣泛而深入地學(xué)習(xí)這家公司的云產(chǎn)品，這些產(chǎn)品既有基于開源產(chǎn)品封裝的“云化”版本，又有深度定制的 PaaS 和 Serverless 服務(wù)，這些產(chǎn)品都借助云平臺的虛擬化能力，將動態(tài)伸縮與可維護(hù)性做到了極致。
隨著對云平臺和云系統(tǒng)架構(gòu)的深入學(xué)習(xí)和應(yīng)用，我開始越來越清晰地認(rèn)識到，由于過去對云計(jì)算固有的偏見，阻礙了自己正確看待云計(jì)算對系統(tǒng)架構(gòu)和開發(fā)模式帶來的深刻影響，在走訪了大量公有云企業(yè)用戶之后，我真切地感受到了云之所以成功和必將成功的“關(guān)鍵”。
大多數(shù)用戶選擇上云的初衷是希望減輕在 IT 基礎(chǔ)設(shè)施上的負(fù)擔(dān)，避免在機(jī)房建設(shè)，網(wǎng)絡(luò)規(guī)劃和服務(wù)器采購上一次性投入大量資金，并且還將繼續(xù)在后期投入資源去管理和維護(hù)。
隨著對云計(jì)算的深度應(yīng)用，很快我們就會發(fā)現(xiàn)，上云所影響的并不僅僅是基礎(chǔ)設(shè)施，上層應(yīng)用系統(tǒng)的架構(gòu)在基礎(chǔ)設(shè)施“服務(wù)化”的影響下，也慢慢進(jìn)化出了一些云上特有的架構(gòu)模式和最佳實(shí)踐，這些模式和實(shí)踐在自建（on-premises）場景下并不適用，或效果不夠顯著，但是在云上則顯示出了強(qiáng)大的威力。
本文，我想針對數(shù)據(jù)平臺的架構(gòu)設(shè)計(jì)，選擇最具實(shí)質(zhì)意義與深刻影響的幾個方面分享一些個人觀點(diǎn)。
Snowflake 的成功讓業(yè)界看到了“存儲與計(jì)算分離”架構(gòu)的巨大優(yōu)勢，這一架構(gòu)充分利用了云計(jì)算平臺靈活的伸縮能力，幾乎成為了當(dāng)前在云上構(gòu)建數(shù)據(jù)平臺的事實(shí)標(biāo)準(zhǔn)。
過去，硬件資源的最小粒度是服務(wù)器，CPU、內(nèi)存和硬盤之間是緊密耦合的，系統(tǒng)基本是以服務(wù)器為單位進(jìn)行伸縮的，這本是平常不過的事情，但是在云平臺上，當(dāng)基礎(chǔ)設(shè)施被“服務(wù)化”之后，就出現(xiàn)了獨(dú)立的存儲服務(wù)（如 AWS 的 S3 和阿里云的 OSS）和計(jì)算服務(wù)（如 AWS 的 EMR 和阿里云的 EMR），這給數(shù)據(jù)平臺的架構(gòu)設(shè)計(jì)開辟了新的思路，“存儲與計(jì)算分離”就是最重要的一條架構(gòu)準(zhǔn)則。
在存儲與計(jì)算分離架構(gòu)下，所有數(shù)據(jù)將統(tǒng)一存放在對象存儲服務(wù)上，所有計(jì)算服務(wù)與對象存儲服務(wù)無縫打通，可以像讀寫本地磁盤一樣讀寫上面的數(shù)據(jù)。如此一來，計(jì)算資源和存儲資源就可以在各自的維度上自由伸縮，不再受彼此的制約。
存儲與計(jì)算分離之后，衍生出了一系列強(qiáng)大而先進(jìn)的新架構(gòu)，無狀態(tài)集群就是其中最“酷”的一個，這種集群在過去自建（on-premises）模式下是無法想象的，“無狀態(tài)”意為著集群可以“即用即啟，用后釋放”，很多云上的高階用戶已經(jīng)在普遍使用這種模式處理他們的 ETL 作業(yè)了，他們每天會在零時過后的某個時刻拉起一個臨時集群，執(zhí)行所有的 daily 作業(yè)，待全部執(zhí)行完畢之后隨即釋放集群，從而將批處理的計(jì)算成本壓縮到了極致。
這里需要知道一個技術(shù)細(xì)節(jié)：多數(shù)云平臺都支持通過命令行或 API 啟動一個集群，所以創(chuàng)建集群的成本（工作量）幾乎可以忽略不計(jì)（這與本地化搭建一個 Hadoop 集群是完全不同的），研發(fā)團(tuán)隊(duì)可以將命令行或 API 調(diào)用寫入到工作流中，作為批處理的前置任務(wù)，這樣就可以實(shí)現(xiàn)上述做法了。
特別地，數(shù)據(jù)平臺如果要實(shí)現(xiàn)集群“無狀態(tài)”，還需要解決一個問題：即需要將數(shù)據(jù)的表結(jié)構(gòu)等元數(shù)據(jù)以服務(wù)形式開放出來供計(jì)算服務(wù)使用，只有這樣，當(dāng)集群下次重建時才能接續(xù)此前的狀態(tài)繼續(xù)處理。通常，云廠商都會提供與行業(yè)主流元數(shù)據(jù)接口（例如 Hive 的 Metastore）兼容的元數(shù)據(jù)服務(wù)，如 AWS 的 Glue Data Catalog，阿里云的 DLA Meta 等。
一些團(tuán)隊(duì)也會在自建（on-premises）模式下嘗試存儲與計(jì)算分離，通常它們會選擇兼容某種對象存儲標(biāo)準(zhǔn)（如 AWS 的 S3）的硬件設(shè)備作為統(tǒng)一的存儲層，將所有數(shù)據(jù)存放在此類設(shè)備上?？陀^地說，這些嘗試是值得肯定的，但是在非云場景下，其“收益”并不明顯，就是說“看不出好在哪里”。因?yàn)樵谧越ǎ╫n-premises）模式下，頻繁地啟停集群是非常罕見的，也毫無意義，暫停集群后釋放的資源并不能分配給其他系統(tǒng)，除非所有服務(wù)器被 Kubenetes 統(tǒng)一管理，但這就是另一個故事了。
通常，不同的應(yīng)用場景對計(jì)算集群有不同的需求，例如批處理、實(shí)時處理以及 Ad-Hoc/OLAP 查詢所使用的組件和配置都各不相同，此外，不同部門、不同團(tuán)隊(duì)在使用資源時經(jīng)常會發(fā)生沖突，導(dǎo)致作業(yè)阻塞。過去，在單一集群模式下，技術(shù)團(tuán)隊(duì)只能依賴 Yarn 等資源配置工具針對不同應(yīng)用場景、不同用戶制定資源分配策略，由于多場景疊加多租戶，使得資源分配策略異常復(fù)雜，集群資源的整體利用率很難達(dá)到較高水平。
在實(shí)現(xiàn)存儲與計(jì)算分離之后，“多集群”策略可以輕松解決上述問題，也就是面向特定應(yīng)用場景和租戶創(chuàng)建專職集群，針對使用場景進(jìn)行最佳配置，同時，租戶之間也實(shí)現(xiàn)了絕對的資源隔離。由于數(shù)據(jù)與元數(shù)據(jù)是共享的，且如前所述，創(chuàng)建集群可通過命令行一鍵完成，所以創(chuàng)建多集群的成本幾乎可以忽略不計(jì)。
多集群策略可以有效地分解企業(yè)級架構(gòu)上的復(fù)雜性，是應(yīng)對復(fù)雜數(shù)據(jù)生態(tài)的強(qiáng)力措施。
Serverless 服務(wù)是指那些在基礎(chǔ)設(shè)施之上進(jìn)一步將程序運(yùn)行環(huán)境也虛擬化的云產(chǎn)品，使用 Serverless 服務(wù)，用戶既不需要搭建服務(wù)器，也不需要構(gòu)建運(yùn)行應(yīng)用所需的系統(tǒng)環(huán)境，他們只需要做一件事：編寫代碼。
Serverless 是一件美好的事嗎？不同的用戶態(tài)度可能會大相徑庭，這取決于團(tuán)隊(duì)自身的背景和對云計(jì)算的擁抱程度。Serverless 的哲學(xué)在于“把精力用到最核心的問題上”，喜歡 Serverless 的用戶會對其贊不絕口，因?yàn)樗_實(shí)將團(tuán)隊(duì)從基礎(chǔ)設(shè)施和運(yùn)行環(huán)境的維護(hù)上徹底解放了出來，使得團(tuán)隊(duì)可以集中精力交付更多的開發(fā)任務(wù)。但是也有技術(shù)人員會對 Serverless 持一種輕蔑態(tài)度，認(rèn)為這種服務(wù)只適合開發(fā)簡單的應(yīng)用，或者只有技術(shù)實(shí)力不強(qiáng)的團(tuán)隊(duì)才會選擇。
對于后者我們不予置評，但是對“Serverless 服務(wù)只適用于中小規(guī)模開發(fā)”的言論，需要謹(jǐn)慎看待，從我過去接觸到的大量企業(yè)用戶來看，得出該結(jié)論的原因很有可能是對所使用的 Serverless 服務(wù)了解不深造成的。大部分初級用戶是通過 Serverless 服務(wù)的控制臺頁面編寫和調(diào)試程序的，這種圖形化界面使用起來非常簡單，在很短時間內(nèi)就可以有所產(chǎn)出，這也是很多團(tuán)隊(duì)喜歡 Serverless 的原因之一，但是基于圖形化界面進(jìn)行開發(fā)有著無法克服的弊端，包括：代碼缺乏版本控制，無法多人協(xié)作開發(fā)，程序規(guī)模變大后難以維護(hù)等等，這些并不是 Serverless 本身的問題，而是基于 Serverless 的開發(fā)沒有進(jìn)行“工程化”導(dǎo)致的。人們會將這些問題錯誤地歸結(jié)到了 Serverless 上，進(jìn)而得出了“Serverless 服務(wù)不適合大規(guī)模開發(fā)”的結(jié)論。
關(guān)于 Serverless 項(xiàng)目的工程化，我們有過很好的實(shí)踐經(jīng)驗(yàn)，通常 Serverless 服務(wù)都會提供 CLI 與 API 用于部署和運(yùn)行程序，這些 CLI 與 API 與用戶界面上的操作是等價的。一個非常好的做法是基于這些接口將部署和運(yùn)行等操作編寫成自動化腳本，脫離對用戶界面的依賴，然后將這些腳本和程序代碼一起組織成一個工程項(xiàng)目，放到 Git Repository 上，這樣就可以對程序代碼進(jìn)行版本控制了，然后再利用構(gòu)建工具打包，并通過 DevOps 工具自動化部署，這樣一個 Serverless 項(xiàng)目就轉(zhuǎn)換成了一個常規(guī)項(xiàng)目，可以復(fù)用所有常規(guī)項(xiàng)目的開發(fā)流程與規(guī)范，構(gòu)建大規(guī)模 Serverless 項(xiàng)目將不是問題。
我們已經(jīng)說了很多云計(jì)算的“好”，最后回應(yīng)一下對云計(jì)算與開源生態(tài)相左的“擔(dān)憂”，從目前的行業(yè)態(tài)勢來看，主流云廠商其實(shí)早已認(rèn)識到這個問題，并在產(chǎn)品設(shè)計(jì)上努力向開源標(biāo)準(zhǔn)靠攏。只有使用行業(yè)廣泛認(rèn)可的技術(shù)，云計(jì)算才有活力，也才能緩解用戶對云平臺綁定的擔(dān)憂，進(jìn)而吸引更多的用戶向云上遷移。
在數(shù)據(jù)領(lǐng)域，各主流云廠商都有基于 Hadoop、Spark 等主流開源大數(shù)據(jù)產(chǎn)品封裝的“云化”版本，與 Cloudera 的 CDH 類似。同時，很多 Serverless 服務(wù)也大多基于主流開源產(chǎn)品封裝，或者保持一致的編程接口，例如 AWS 的 Glue 就是基于 Spark 的 Serverless 服務(wù)，編程接口與開源 Spark 一致。
總的來說，云計(jì)算與開源生態(tài)不是也不應(yīng)該是對立的，一方面，云廠商有向開源生態(tài)靠攏的商業(yè)驅(qū)動力，另一方面，有能力的云廠商也應(yīng)該積極回饋開源社區(qū)，一起營造更好的雙贏局面。
由于過往的獨(dú)特經(jīng)歷，我先后經(jīng)歷過“半云”、“全云”以及“非云”等多種環(huán)境，真切地體會到了云計(jì)算對數(shù)據(jù)平臺的深刻影響。當(dāng)今的數(shù)據(jù)平臺建設(shè)，“云上”和“云下”已經(jīng)幾乎是兩個賽道了，如果以個人的一點(diǎn)淺見展望一下的話，我認(rèn)為上云是不可逆轉(zhuǎn)的趨勢，在云上構(gòu)筑數(shù)據(jù)平臺是未來絕大多數(shù)企業(yè)的首選。
本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：耿立超，36氪經(jīng)授權(quán)發(fā)布。
