“戒備”與“偏見(jiàn)”

幾年前，我所在的一家傳統(tǒng)行業(yè)的頭部企業(yè)啟動(dòng)了一系列數(shù)字化轉(zhuǎn)型項(xiàng)目，在配套的 IT 基礎(chǔ)設(shè)施建設(shè)上，“上云”已是大勢(shì)所趨。

在此前數(shù)年的工作中，我斷斷續(xù)續(xù)地使用著公有云產(chǎn)品，大多數(shù)情況下，我們只選擇 IaaS 層級(jí)的服務(wù)，也就是只使用虛擬實(shí)例，對(duì) PaaS 和云平臺(tái)特定的 Serverless 服務(wù)敬而遠(yuǎn)之。作為一名架構(gòu)師，我對(duì)公有云的此類產(chǎn)品一直懷有一種“戒備”心理。

一方面，從技術(shù)發(fā)展路線上，不管是個(gè)人還是團(tuán)隊(duì)，我們都希望學(xué)習(xí)并使用行業(yè)主流且平臺(tái)中立的技術(shù)，這些技術(shù)大多數(shù)都是開(kāi)源的，有著活躍的社區(qū)和良好的周邊生態(tài)，包括高質(zhì)量的文檔、豐富的技術(shù)專著，以及互聯(lián)網(wǎng)上大量的討論文章等等；另一方面，從公司角度出發(fā)，我們也不希望企業(yè)與某一朵云深度綁定，這似乎總讓人缺少一種“安全感”。

此外，對(duì)于還沒(méi)有準(zhǔn)備好擁抱云計(jì)算的技術(shù)人員來(lái)說(shuō)，上云會(huì)給他們帶來(lái)一種危機(jī)感：“既然你都已經(jīng)做得這么好了，那以后還要我做什么呢”？這一感受最初產(chǎn)生于 IT 的基礎(chǔ)設(shè)施團(tuán)隊(duì)，之后系統(tǒng)架構(gòu)師也會(huì)有些許同感，這也是很多 PaaS 和 Serverless 服務(wù)“不受歡迎”的原因。但對(duì)于云廠商而言，由于這類服務(wù)的利潤(rùn)率更高，他們會(huì)更加熱衷于推薦此類服務(wù)，這會(huì)讓本已十分敏感的用戶更加警惕，以至產(chǎn)生抗拒心理。

回到公司的數(shù)字化轉(zhuǎn)型項(xiàng)目，在聽(tīng)取了多方意見(jiàn)之后，公司決定僅使用虛擬實(shí)例構(gòu)建應(yīng)用系統(tǒng)和數(shù)據(jù)平臺(tái)，盡可能避免深度介入平臺(tái)特定服務(wù)，甚至連非常基礎(chǔ)的對(duì)象存儲(chǔ)服務(wù)也沒(méi)有采用。我們數(shù)據(jù)團(tuán)隊(duì)負(fù)責(zé)構(gòu)建大數(shù)據(jù)平臺(tái)，在一批虛擬實(shí)例上搭建了一個(gè) Hadoop/Spark 集群后，就開(kāi)始了長(zhǎng)期的數(shù)倉(cāng)建設(shè)工作。

之后，隨著數(shù)據(jù)規(guī)模的不斷上漲，集群也經(jīng)歷過(guò)幾次擴(kuò)容，得益于 Hadoop 集群管理工具和自動(dòng)化運(yùn)維工具的支持，每次擴(kuò)容倒也不算麻煩。當(dāng)時(shí)，我們對(duì)基礎(chǔ)設(shè)施的總體狀況是滿意的：“你總得維護(hù)一堆機(jī)器，然后定期擴(kuò)容，哪個(gè)系統(tǒng)不是這樣呢？”

“上云”改變了什么？

幾年后，機(jī)緣巧合，我去了一家業(yè)界知名的云計(jì)算公司。所謂“食君之祿、忠君之事”，入職后，我必須廣泛而深入地學(xué)習(xí)這家公司的云產(chǎn)品，這些產(chǎn)品既有基于開(kāi)源產(chǎn)品封裝的“云化”版本，又有深度定制的 PaaS 和 Serverless 服務(wù)，這些產(chǎn)品都借助云平臺(tái)的虛擬化能力，將動(dòng)態(tài)伸縮與可維護(hù)性做到了極致。

隨著對(duì)云平臺(tái)和云系統(tǒng)架構(gòu)的深入學(xué)習(xí)和應(yīng)用，我開(kāi)始越來(lái)越清晰地認(rèn)識(shí)到，由于過(guò)去對(duì)云計(jì)算固有的偏見(jiàn)，阻礙了自己正確看待云計(jì)算對(duì)系統(tǒng)架構(gòu)和開(kāi)發(fā)模式帶來(lái)的深刻影響，在走訪了大量公有云企業(yè)用戶之后，我真切地感受到了云之所以成功和必將成功的“關(guān)鍵”。

大多數(shù)用戶選擇上云的初衷是希望減輕在 IT 基礎(chǔ)設(shè)施上的負(fù)擔(dān)，避免在機(jī)房建設(shè)，網(wǎng)絡(luò)規(guī)劃和服務(wù)器采購(gòu)上一次性投入大量資金，并且還將繼續(xù)在后期投入資源去管理和維護(hù)。

隨著對(duì)云計(jì)算的深度應(yīng)用，很快我們就會(huì)發(fā)現(xiàn)，上云所影響的并不僅僅是基礎(chǔ)設(shè)施，上層應(yīng)用系統(tǒng)的架構(gòu)在基礎(chǔ)設(shè)施“服務(wù)化”的影響下，也慢慢進(jìn)化出了一些云上特有的架構(gòu)模式和最佳實(shí)踐，這些模式和實(shí)踐在自建（on-premises）場(chǎng)景下并不適用，或效果不夠顯著，但是在云上則顯示出了強(qiáng)大的威力。

本文，我想針對(duì)數(shù)據(jù)平臺(tái)的架構(gòu)設(shè)計(jì)，選擇最具實(shí)質(zhì)意義與深刻影響的幾個(gè)方面分享一些個(gè)人觀點(diǎn)。

存儲(chǔ)與計(jì)算分離

Snowflake 的成功讓業(yè)界看到了“存儲(chǔ)與計(jì)算分離”架構(gòu)的巨大優(yōu)勢(shì)，這一架構(gòu)充分利用了云計(jì)算平臺(tái)靈活的伸縮能力，幾乎成為了當(dāng)前在云上構(gòu)建數(shù)據(jù)平臺(tái)的事實(shí)標(biāo)準(zhǔn)。

過(guò)去，硬件資源的最小粒度是服務(wù)器，CPU、內(nèi)存和硬盤之間是緊密耦合的，系統(tǒng)基本是以服務(wù)器為單位進(jìn)行伸縮的，這本是平常不過(guò)的事情，但是在云平臺(tái)上，當(dāng)基礎(chǔ)設(shè)施被“服務(wù)化”之后，就出現(xiàn)了獨(dú)立的存儲(chǔ)服務(wù)（如 AWS 的 S3 和阿里云的 OSS）和計(jì)算服務(wù)（如 AWS 的 EMR 和阿里云的 EMR），這給數(shù)據(jù)平臺(tái)的架構(gòu)設(shè)計(jì)開(kāi)辟了新的思路，“存儲(chǔ)與計(jì)算分離”就是最重要的一條架構(gòu)準(zhǔn)則。

在存儲(chǔ)與計(jì)算分離架構(gòu)下，所有數(shù)據(jù)將統(tǒng)一存放在對(duì)象存儲(chǔ)服務(wù)上，所有計(jì)算服務(wù)與對(duì)象存儲(chǔ)服務(wù)無(wú)縫打通，可以像讀寫(xiě)本地磁盤一樣讀寫(xiě)上面的數(shù)據(jù)。如此一來(lái)，計(jì)算資源和存儲(chǔ)資源就可以在各自的維度上自由伸縮，不再受彼此的制約。

“無(wú)狀態(tài)”集群

存儲(chǔ)與計(jì)算分離之后，衍生出了一系列強(qiáng)大而先進(jìn)的新架構(gòu)，無(wú)狀態(tài)集群就是其中最“酷”的一個(gè)，這種集群在過(guò)去自建（on-premises）模式下是無(wú)法想象的，“無(wú)狀態(tài)”意為著集群可以“即用即啟，用后釋放”，很多云上的高階用戶已經(jīng)在普遍使用這種模式處理他們的 ETL 作業(yè)了，他們每天會(huì)在零時(shí)過(guò)后的某個(gè)時(shí)刻拉起一個(gè)臨時(shí)集群，執(zhí)行所有的 daily 作業(yè)，待全部執(zhí)行完畢之后隨即釋放集群，從而將批處理的計(jì)算成本壓縮到了極致。

這里需要知道一個(gè)技術(shù)細(xì)節(jié)：多數(shù)云平臺(tái)都支持通過(guò)命令行或 API 啟動(dòng)一個(gè)集群，所以創(chuàng)建集群的成本（工作量）幾乎可以忽略不計(jì)（這與本地化搭建一個(gè) Hadoop 集群是完全不同的），研發(fā)團(tuán)隊(duì)可以將命令行或 API 調(diào)用寫(xiě)入到工作流中，作為批處理的前置任務(wù)，這樣就可以實(shí)現(xiàn)上述做法了。

特別地，數(shù)據(jù)平臺(tái)如果要實(shí)現(xiàn)集群“無(wú)狀態(tài)”，還需要解決一個(gè)問(wèn)題：即需要將數(shù)據(jù)的表結(jié)構(gòu)等元數(shù)據(jù)以服務(wù)形式開(kāi)放出來(lái)供計(jì)算服務(wù)使用，只有這樣，當(dāng)集群下次重建時(shí)才能接續(xù)此前的狀態(tài)繼續(xù)處理。通常，云廠商都會(huì)提供與行業(yè)主流元數(shù)據(jù)接口（例如 Hive 的 Metastore）兼容的元數(shù)據(jù)服務(wù)，如 AWS 的 Glue Data Catalog，阿里云的 DLA Meta 等。

一些團(tuán)隊(duì)也會(huì)在自建（on-premises）模式下嘗試存儲(chǔ)與計(jì)算分離，通常它們會(huì)選擇兼容某種對(duì)象存儲(chǔ)標(biāo)準(zhǔn)（如 AWS 的 S3）的硬件設(shè)備作為統(tǒng)一的存儲(chǔ)層，將所有數(shù)據(jù)存放在此類設(shè)備上?？陀^地說(shuō)，這些嘗試是值得肯定的，但是在非云場(chǎng)景下，其“收益”并不明顯，就是說(shuō)“看不出好在哪里”。因?yàn)樵谧越ǎ╫n-premises）模式下，頻繁地啟停集群是非常罕見(jiàn)的，也毫無(wú)意義，暫停集群后釋放的資源并不能分配給其他系統(tǒng)，除非所有服務(wù)器被 Kubenetes 統(tǒng)一管理，但這就是另一個(gè)故事了。

“多集群”策略

通常，不同的應(yīng)用場(chǎng)景對(duì)計(jì)算集群有不同的需求，例如批處理、實(shí)時(shí)處理以及 Ad-Hoc/OLAP 查詢所使用的組件和配置都各不相同，此外，不同部門、不同團(tuán)隊(duì)在使用資源時(shí)經(jīng)常會(huì)發(fā)生沖突，導(dǎo)致作業(yè)阻塞。過(guò)去，在單一集群模式下，技術(shù)團(tuán)隊(duì)只能依賴 Yarn 等資源配置工具針對(duì)不同應(yīng)用場(chǎng)景、不同用戶制定資源分配策略，由于多場(chǎng)景疊加多租戶，使得資源分配策略異常復(fù)雜，集群資源的整體利用率很難達(dá)到較高水平。

在實(shí)現(xiàn)存儲(chǔ)與計(jì)算分離之后，“多集群”策略可以輕松解決上述問(wèn)題，也就是面向特定應(yīng)用場(chǎng)景和租戶創(chuàng)建專職集群，針對(duì)使用場(chǎng)景進(jìn)行最佳配置，同時(shí)，租戶之間也實(shí)現(xiàn)了絕對(duì)的資源隔離。由于數(shù)據(jù)與元數(shù)據(jù)是共享的，且如前所述，創(chuàng)建集群可通過(guò)命令行一鍵完成，所以創(chuàng)建多集群的成本幾乎可以忽略不計(jì)。

多集群策略可以有效地分解企業(yè)級(jí)架構(gòu)上的復(fù)雜性，是應(yīng)對(duì)復(fù)雜數(shù)據(jù)生態(tài)的強(qiáng)力措施。

“無(wú)服務(wù)器”架構(gòu)

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)境，他們只需要做一件事：編寫(xiě)代碼。

Serverless 是一件美好的事嗎？不同的用戶態(tài)度可能會(huì)大相徑庭，這取決于團(tuán)隊(duì)自身的背景和對(duì)云計(jì)算的擁抱程度。Serverless 的哲學(xué)在于“把精力用到最核心的問(wèn)題上”，喜歡 Serverless 的用戶會(huì)對(duì)其贊不絕口，因?yàn)樗_實(shí)將團(tuán)隊(duì)從基礎(chǔ)設(shè)施和運(yùn)行環(huán)境的維護(hù)上徹底解放了出來(lái)，使得團(tuán)隊(duì)可以集中精力交付更多的開(kāi)發(fā)任務(wù)。但是也有技術(shù)人員會(huì)對(duì) Serverless 持一種輕蔑態(tài)度，認(rèn)為這種服務(wù)只適合開(kāi)發(fā)簡(jiǎn)單的應(yīng)用，或者只有技術(shù)實(shí)力不強(qiáng)的團(tuán)隊(duì)才會(huì)選擇。

對(duì)于后者我們不予置評(píng)，但是對(duì)“Serverless 服務(wù)只適用于中小規(guī)模開(kāi)發(fā)”的言論，需要謹(jǐn)慎看待，從我過(guò)去接觸到的大量企業(yè)用戶來(lái)看，得出該結(jié)論的原因很有可能是對(duì)所使用的 Serverless 服務(wù)了解不深造成的。大部分初級(jí)用戶是通過(guò) Serverless 服務(wù)的控制臺(tái)頁(yè)面編寫(xiě)和調(diào)試程序的，這種圖形化界面使用起來(lái)非常簡(jiǎn)單，在很短時(shí)間內(nèi)就可以有所產(chǎn)出，這也是很多團(tuán)隊(duì)喜歡 Serverless 的原因之一，但是基于圖形化界面進(jìn)行開(kāi)發(fā)有著無(wú)法克服的弊端，包括：代碼缺乏版本控制，無(wú)法多人協(xié)作開(kāi)發(fā)，程序規(guī)模變大后難以維護(hù)等等，這些并不是 Serverless 本身的問(wèn)題，而是基于 Serverless 的開(kāi)發(fā)沒(méi)有進(jìn)行“工程化”導(dǎo)致的。人們會(huì)將這些問(wèn)題錯(cuò)誤地歸結(jié)到了 Serverless 上，進(jìn)而得出了“Serverless 服務(wù)不適合大規(guī)模開(kāi)發(fā)”的結(jié)論。

關(guān)于 Serverless 項(xiàng)目的工程化，我們有過(guò)很好的實(shí)踐經(jīng)驗(yàn)，通常 Serverless 服務(wù)都會(huì)提供 CLI 與 API 用于部署和運(yùn)行程序，這些 CLI 與 API 與用戶界面上的操作是等價(jià)的。一個(gè)非常好的做法是基于這些接口將部署和運(yùn)行等操作編寫(xiě)成自動(dòng)化腳本，脫離對(duì)用戶界面的依賴，然后將這些腳本和程序代碼一起組織成一個(gè)工程項(xiàng)目，放到 Git Repository 上，這樣就可以對(duì)程序代碼進(jìn)行版本控制了，然后再利用構(gòu)建工具打包，并通過(guò) DevOps 工具自動(dòng)化部署，這樣一個(gè) Serverless 項(xiàng)目就轉(zhuǎn)換成了一個(gè)常規(guī)項(xiàng)目，可以復(fù)用所有常規(guī)項(xiàng)目的開(kāi)發(fā)流程與規(guī)范，構(gòu)建大規(guī)模 Serverless 項(xiàng)目將不是問(wèn)題。

云計(jì)算 VS. 開(kāi)源生態(tài)

我們已經(jīng)說(shuō)了很多云計(jì)算的“好”，最后回應(yīng)一下對(duì)云計(jì)算與開(kāi)源生態(tài)相左的“擔(dān)憂”，從目前的行業(yè)態(tài)勢(shì)來(lái)看，主流云廠商其實(shí)早已認(rèn)識(shí)到這個(gè)問(wèn)題，并在產(chǎn)品設(shè)計(jì)上努力向開(kāi)源標(biāo)準(zhǔn)靠攏。只有使用行業(yè)廣泛認(rèn)可的技術(shù)，云計(jì)算才有活力，也才能緩解用戶對(duì)云平臺(tái)綁定的擔(dān)憂，進(jìn)而吸引更多的用戶向云上遷移。

在數(shù)據(jù)領(lǐng)域，各主流云廠商都有基于 Hadoop、Spark 等主流開(kāi)源大數(shù)據(jù)產(chǎn)品封裝的“云化”版本，與 Cloudera 的 CDH 類似。同時(shí)，很多 Serverless 服務(wù)也大多基于主流開(kāi)源產(chǎn)品封裝，或者保持一致的編程接口，例如 AWS 的 Glue 就是基于 Spark 的 Serverless 服務(wù)，編程接口與開(kāi)源 Spark 一致。

總的來(lái)說(shuō)，云計(jì)算與開(kāi)源生態(tài)不是也不應(yīng)該是對(duì)立的，一方面，云廠商有向開(kāi)源生態(tài)靠攏的商業(yè)驅(qū)動(dòng)力，另一方面，有能力的云廠商也應(yīng)該積極回饋開(kāi)源社區(qū)，一起營(yíng)造更好的雙贏局面。

一點(diǎn)展望

由于過(guò)往的獨(dú)特經(jīng)歷，我先后經(jīng)歷過(guò)“半云”、“全云”以及“非云”等多種環(huán)境，真切地體會(huì)到了云計(jì)算對(duì)數(shù)據(jù)平臺(tái)的深刻影響。當(dāng)今的數(shù)據(jù)平臺(tái)建設(shè)，“云上”和“云下”已經(jīng)幾乎是兩個(gè)賽道了，如果以個(gè)人的一點(diǎn)淺見(jiàn)展望一下的話，我認(rèn)為上云是不可逆轉(zhuǎn)的趨勢(shì)，在云上構(gòu)筑數(shù)據(jù)平臺(tái)是未來(lái)絕大多數(shù)企業(yè)的首選。

本文來(lái)自微信公眾號(hào) “InfoQ”（ID：infoqchina），作者：耿立超，36氪經(jīng)授權(quán)發(fā)布。

關(guān)鍵詞： 遠(yuǎn)比 深刻 數(shù)據(jù)