作者丨Leonardo Creed
編譯丨諾亞
出品 | 51CTO技術(shù)棧（微信號：blog51cto）
在過去的幾個月里，我寫了關(guān)于大型科技公司的各種技術(shù)“幕后揭秘”的文章，例如 Meta 的內(nèi)部無服務(wù)器平臺、 Google 內(nèi)部喜愛的代碼審查工具等等。不過，蘋果的基礎(chǔ)設(shè)施并不那么公開。我想了解 Apple 是如何構(gòu)建 iCloud 的，在這篇文章中，我將介紹我所知道的一切。
Apple 將 FoundationDB 和 Cassandra 用于其云端后端服務(wù) iCloud 和 CloudKit。而且本文的標(biāo)題并沒有弄錯：蘋果確實(shí)在其極端的多租戶架構(gòu)中存儲了數(shù)十億個數(shù)據(jù)庫。
一、閱讀指南
我發(fā)現(xiàn)，論文中以及蘋果的實(shí)踐經(jīng)驗(yàn)與Meta無服務(wù)器平臺架構(gòu)的設(shè)計(jì)原則和教訓(xùn)高度契合。
1、兩者都巧妙地運(yùn)用了異步處理技術(shù)，以實(shí)現(xiàn)用戶功能的流暢性。Meta在其無服務(wù)器架構(gòu)中，將非面向用戶的函數(shù)任務(wù)利用該技術(shù)進(jìn)行處理，從而避免影響用戶體驗(yàn)。而蘋果則在Record Layer（在下文將詳細(xì)解釋）的幾乎全部功能上采用異步處理方式，目的是隱藏延遲，確保用戶感受到的是即時響應(yīng)。
2、兩者都廣泛采用無狀態(tài)架構(gòu)設(shè)計(jì)，鑒于它們都有極高的可擴(kuò)展性需求。（注：無狀態(tài)架構(gòu)意味著服務(wù)器不保存任何會話或請求之間的持久化狀態(tài)信息，從而使得每個請求都能獨(dú)立處理，且可以根據(jù)需要輕松地增加或減少服務(wù)器實(shí)例以應(yīng)對流量變化。）
3、兩者都通過邏輯隔離資源來確保可靠性和可用性。
4、兩者都以簡化的方式處理各類需求。蘋果提到，為存儲“小數(shù)據(jù)”和“大數(shù)據(jù)”分別配置和運(yùn)營獨(dú)立系統(tǒng)是很有誘惑力的做法，但這會增加運(yùn)維的復(fù)雜性。因此，蘋果選擇用一個抽象層來處理所有類型的數(shù)據(jù)需求。同樣地，Meta在他們的無服務(wù)器平臺上也采用相同策略，提供了一個統(tǒng)一的抽象層，用于處理各種函數(shù)負(fù)載。
5、兩者都通過構(gòu)建抽象層來優(yōu)化開發(fā)者體驗(yàn)，讓應(yīng)用開發(fā)者無需過多關(guān)注可擴(kuò)展性需求。這些需求由底層分布式系統(tǒng)工程師在更深層次的架構(gòu)中處理。
6、深知用戶需求。無論是Meta還是Apple，它們提供的每一層架構(gòu)、API設(shè)計(jì)以及每一個設(shè)計(jì)決策都是基于對特定技術(shù)使用者（無論是應(yīng)用開發(fā)團(tuán)隊(duì)還是可觀測性團(tuán)隊(duì)）清晰理解的基礎(chǔ)上制定的。
二、Cassandra
Cassandra 是一種分布式、寬列式NoSQL數(shù)據(jù)庫管理系統(tǒng)，最初由Facebook開發(fā)，用于支持Facebook收件箱搜索功能的實(shí)現(xiàn)。有趣的是，后來的Meta自身已逐步用ZippyDB替代了大量原本使用Cassandra的地方。
根據(jù)DataStax的信息，iCloud的部分功能由Cassandra提供支持。蘋果運(yùn)營著全球規(guī)模最大的Cassandra部署之一。
他們報(bào)告指出：
- 超過30萬個實(shí)例/節(jié)點(diǎn)
- 數(shù)據(jù)規(guī)模達(dá)到數(shù)百PB（甚至EB級別）
- 每個集群處理超過2 PB的數(shù)據(jù)，且擁有數(shù)千個這樣的集群
- 每秒處理數(shù)百萬次查詢
- 支持?jǐn)?shù)千個應(yīng)用程序
Cassandra在iCloud中的應(yīng)用確實(shí)彰顯了其管理海量數(shù)據(jù)的能力，達(dá)到EB級別。蘋果在其服務(wù)器上采用多節(jié)點(diǎn)Cassandra部署策略，并且團(tuán)隊(duì)在設(shè)計(jì)時非常注重“爆炸半徑”（blast radius）控制和數(shù)據(jù)分片（sharding），以最大程度地減少故障影響范圍并優(yōu)化數(shù)據(jù)分布與訪問性能，從而確保iCloud服務(wù)的數(shù)據(jù)可用性接近100%。
與此同時，蘋果公司內(nèi)部仍在積極改進(jìn)Cassandra技術(shù)。來自蘋果公司的Scott Andreas最近發(fā)表了關(guān)于Cassandra未來發(fā)展的演講。同時，在蘋果的招聘頁面上，經(jīng)常可以看到他們?yōu)榉植际较到y(tǒng)工程師崗位列出熟練使用Cassandra的要求。
盡管Cassandra在處理大規(guī)模分布式存儲方面表現(xiàn)出色，但在蘋果iCloud的特定場景下，結(jié)合使用CloudKit和Cassandra時遇到了兩個關(guān)鍵的可擴(kuò)展性限制，這導(dǎo)致他們采用了 FoundationDB。
1、在Cassandra單一分區(qū)內(nèi)，即使編輯的是不同的記錄，同一時間也只能進(jìn)行一個操作。這意味著對于那些需要多個用戶或設(shè)備同時處理共享數(shù)據(jù)的應(yīng)用程序來說，可能會出現(xiàn)性能瓶頸和并發(fā)控制問題。
2、在Cassandra中，如果需要在一個原子操作內(nèi)同時更新多個記錄，這些更新操作會受限于單個Cassandra分區(qū)。每個分區(qū)都有其能夠處理的最大數(shù)據(jù)量限制，隨著分區(qū)內(nèi)數(shù)據(jù)的不斷增長，Cassandra的性能往往會隨之下降。
FoundationDB 和 Record Layer 解決了這兩個問題。
三、FoundationDB
蘋果對FoundationDB的公開程度要高得多。他們于 2015 年收購了 FoundationDB，此后發(fā)表了多篇論文，詳細(xì)介紹了他們對 FoundationDB 的使用。
FoundationDB 是一個開源的分布式事務(wù)型鍵值存儲系統(tǒng)，旨在處理大規(guī)模的數(shù)據(jù)量，并且在讀寫混合負(fù)載以及寫入密集型工作負(fù)載方面表現(xiàn)出色。此外，F(xiàn)oundationDB 也符合 ACID（原子性、一致性、隔離性和持久性）原則。
蘋果在CloudKit（其云端后端服務(wù)）中廣泛使用了FoundationDB Record Layer。
來源：《FoundationDB Record Layer：開源結(jié)構(gòu)化存儲》
從GitHub上的描述來看，Record Layer是一個基于FoundationDB的Java API，它提供了一種面向記錄的存儲方式，可以大致類比為一個簡單的關(guān)系型數(shù)據(jù)庫。具體特性包括：
1、結(jié)構(gòu)化類型：記錄以Protocol Buffer（protobuf）消息的形式進(jìn)行定義和存儲，Protocol Buffer是一種最初由Google設(shè)計(jì)的數(shù)據(jù)序列化協(xié)議。
2、索引：Record Layer支持多種索引類型，如值索引（大多數(shù)數(shù)據(jù)庫都提供的那種）、排名索引和聚合索引。索引和主鍵可以通過protobuf選項(xiàng)或程序化方式來定義。
3、復(fù)雜類型：支持復(fù)雜數(shù)據(jù)類型，例如列表和嵌套記錄，并且能夠針對這些嵌套結(jié)構(gòu)定義索引。
4、查詢功能：雖然Record Layer并未提供查詢語言，但它提供了API接口，支持對一個或多個記錄類型進(jìn)行掃描、過濾和排序操作，同時還包含一個能夠自動選擇合適索引的查詢規(guī)劃器。
5、多個記錄存儲與共享模式：Record Layer允許創(chuàng)建并管理多個獨(dú)立的記錄存儲實(shí)例，所有實(shí)例都采用共享（且可動態(tài)演變）的模式。舉例來說，不同于在一個單一數(shù)據(jù)庫中存儲所有用戶數(shù)據(jù)的方式，每個用戶可以擁有自己的記錄存儲，甚至可以根據(jù)需要跨不同的FDB集群實(shí)例進(jìn)行分片處理。
6、極輕量級：Record Layer被設(shè)計(jì)用于大型、分布式、無狀態(tài)環(huán)境，旨在實(shí)現(xiàn)從打開存儲到執(zhí)行首次查詢之間的時間間隔達(dá)到毫秒級別。
7、擴(kuò)展性強(qiáng)：新的索引類型以及自定義索引鍵表達(dá)式可以動態(tài)地融入到記錄存儲中。
根據(jù)FoundationDB Record Layer論文所述，蘋果使用FoundationDB Record Layer為服務(wù)數(shù)億用戶的大型應(yīng)用提供強(qiáng)大的抽象層支持。CloudKit 使用Record Layer來托管數(shù)十億個獨(dú)立的數(shù)據(jù)庫，其中許多數(shù)據(jù)庫共享相同的模式（schema）。
四、為什么要使用 FoundationDB Record Layer
FoundationDB、Record Layer 和 CloudKit 的結(jié)構(gòu)如下所示：
來源：《FoundationDB Record Layer: 開源結(jié)構(gòu)化存儲》
- FoundationDB 負(fù)責(zé)所有的分布式系統(tǒng)和并發(fā)控制工作。
- Record Layer 作為中間層，充當(dāng)了關(guān)系數(shù)據(jù)庫，以便開發(fā)者能夠更輕松地與 FoundationDB 進(jìn)行交互。
- CloudKit 是最頂層的服務(wù)，為應(yīng)用開發(fā)者提供了豐富的功能和API。雖然CloudKit是構(gòu)建在Record Layer之上的一個典型應(yīng)用案例，但內(nèi)部還有其他服務(wù)和組件也基于Record Layer構(gòu)建，比如用于處理JSON文檔存儲等需要結(jié)構(gòu)化存儲的場景。
Record Layer 使蘋果能夠在大規(guī)模上實(shí)現(xiàn)多租戶支持。
實(shí)際上，這樣的描述可能還顯得保守了。
Record Layer 被用于極端的多租戶環(huán)境，其中每個應(yīng)用程序的每個用戶都能獲得獨(dú)立的記錄存儲空間。這意味著Record Layer 托管著數(shù)十億個共享數(shù)千種模式的獨(dú)立數(shù)據(jù)庫。
來源：《FoundationDB Record Layer: 開源結(jié)構(gòu)化存儲》
Record Layer 能夠在如此大規(guī)模上成功處理多租戶問題，主要?dú)w功于其兩個核心架構(gòu)決策：
1、無狀態(tài)操作：Record Layer 設(shè)計(jì)為無狀態(tài)模式，這意味著通過簡單地增加更多無狀態(tài)實(shí)例，就可以輕松擴(kuò)展計(jì)算資源。
這種設(shè)計(jì)使得負(fù)載均衡器和路由器的工作變得更為簡化，它們只需關(guān)注數(shù)據(jù)的位置而非計(jì)算服務(wù)器的具體能力。同時，由于無狀態(tài)服務(wù)器無需維護(hù)會話狀態(tài)等信息，因此分配給客戶端的資源集合得以減少。
2、記錄存儲抽象化管理：Record Layer 使用記錄存儲抽象層來高效管理資源分配和可擴(kuò)展性。這個抽象層代表了整個邏輯數(shù)據(jù)庫，包含了序列化數(shù)據(jù)、索引以及運(yùn)行時狀態(tài)。
每個記錄存儲都有特定的鍵范圍分配，確保不同租戶的數(shù)據(jù)在邏輯上保持分離。如有必要遷移某個租戶的數(shù)據(jù)，過程十分直接，只需將分配給該租戶的鍵范圍遷移到新的集群中即可，因?yàn)楣芾砼c使用該記錄存儲所需的所有信息都包含在這個鍵范圍內(nèi)。
五、CloudKit 如何使用 FoundationDB 和Record Layer
來源：《FoundationDB Record Layer: 多租戶結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng)》
在CloudKit中，每個應(yīng)用程序由一個遵循特定模式的“邏輯容器”來表示。這個模式詳細(xì)定義了必要的記錄類型、字段和索引，以實(shí)現(xiàn)高效的數(shù)據(jù)檢索和查詢功能。應(yīng)用程序在CloudKit內(nèi)部將其數(shù)據(jù)組織到不同的“區(qū)域”（zones）中，這樣可以按邏輯分組記錄，便于與客戶端設(shè)備進(jìn)行選擇性同步。
對于每一位用戶，CloudKit在FoundationDB中分配一個唯一的子空間。在這個子空間內(nèi)，針對用戶使用的所有應(yīng)用程序，CloudKit都會為每個應(yīng)用創(chuàng)建一個記錄存儲。換言之，CloudKit實(shí)際上管理著大量邏輯數(shù)據(jù)庫——即用戶數(shù)量乘以應(yīng)用程序數(shù)量所得到的數(shù)量級，每一個都包含其自身的記錄集、索引和元數(shù)據(jù)，總量高達(dá)數(shù)十億個獨(dú)立數(shù)據(jù)庫。
當(dāng)CloudKit接收到來自客戶端設(shè)備的請求時，它會通過負(fù)載均衡機(jī)制將請求導(dǎo)向可用的CloudKit服務(wù)進(jìn)程。該服務(wù)進(jìn)程隨后與Record Layer中的相應(yīng)記錄存儲進(jìn)行交互，以完成請求操作。
CloudKit將定義好的應(yīng)用程序模式轉(zhuǎn)換為Record Layer中的元數(shù)據(jù)定義，并將其存儲在獨(dú)立的元數(shù)據(jù)存儲中。此外，CloudKit還會添加特定的系統(tǒng)字段來豐富這些元數(shù)據(jù)，如記錄的創(chuàng)建時間、修改時間以及記錄所在的區(qū)域信息。為了實(shí)現(xiàn)對每個區(qū)域內(nèi)記錄的有效訪問，區(qū)域名稱會被作為前綴附加到主鍵上。除了用戶自定義的索引外，CloudKit還管理“系統(tǒng)索引”，例如為了管理存儲配額而維護(hù)的一種根據(jù)記錄類型追蹤其大小的索引。
FoundationDB和Record Layer結(jié)合使用，共同解決了蘋果面臨的一些關(guān)鍵問題，這些問題單靠Cassandra或FoundationDB都無法完美解決。
六、已解決的問題
1、個性化全文搜索
FoundationDB在解決用戶個性化全文搜索，以快速訪問其數(shù)據(jù)方面發(fā)揮了重要作用。蘋果的系統(tǒng)利用了FoundationDB的鍵順序特性，能夠?qū)崿F(xiàn)對文本開頭（前綴匹配）進(jìn)行快速搜索，并且無需額外開銷即可處理更復(fù)雜的搜索需求，如查找相近詞或特定順序排列的詞語（鄰近搜索和短語搜索）。
在傳統(tǒng)的搜索系統(tǒng)中，通常需要后臺運(yùn)行額外的進(jìn)程來保持搜索索引的實(shí)時更新。而蘋果的系統(tǒng)則實(shí)現(xiàn)了所有操作的實(shí)時性，這意味著一旦數(shù)據(jù)發(fā)生變化，搜索索引會立即得到更新，無需任何額外步驟。這種設(shè)計(jì)不僅提高了搜索效率，還確保了數(shù)據(jù)的一致性和時效性，為用戶提供更為流暢、準(zhǔn)確的搜索體驗(yàn)。
2、高并發(fā)區(qū)域
FoundationDB為CloudKit處理同時發(fā)生的大量更新提供了更為平滑和一致的方式。
在以前使用Cassandra時，CloudKit依賴于一個特殊的索引來追蹤各個區(qū)域內(nèi)的數(shù)據(jù)變化以實(shí)現(xiàn)跨設(shè)備同步。當(dāng)設(shè)備需要更新數(shù)據(jù)時，會通過檢查這個索引來獲取最新信息。但這種方法存在一個問題：當(dāng)多臺設(shè)備幾乎同時進(jìn)行更新操作時，可能會引發(fā)沖突。
而采用FoundationDB后，CloudKit利用了一種特殊類型的索引，它可以精確地跟蹤每一次更改的順序，而且不會導(dǎo)致沖突。這種機(jī)制是通過為每次變更分配一個唯一的“版本號”來實(shí)現(xiàn)的，當(dāng)CloudKit需要進(jìn)行同步時，它會根據(jù)這些版本號來確定設(shè)備錯過了哪些更新內(nèi)容。
然而，在將數(shù)據(jù)從一個存儲集群轉(zhuǎn)移到另一個存儲集群（可能是為了更均勻地分布負(fù)載）時，情況變得復(fù)雜起來，因?yàn)槊總€集群都有自己獨(dú)立的、不匹配的版本號。為解決這一問題，CloudKit為每位用戶的每份數(shù)據(jù)賦予了一個稱為“化身”的“遷移計(jì)數(shù)”，每當(dāng)用戶的數(shù)據(jù)被遷移到新集群時，“化身”值就會遞增。每個記錄更新都會包含用戶當(dāng)前的“化身”號碼，從而確保即使在遷移之后，CloudKit仍可以根據(jù)化身號和版本號來正確判斷出更新的順序。
當(dāng)CloudKit切換到這個新系統(tǒng)時，面臨的挑戰(zhàn)之一是如何處理那些尚未帶有版本號的老數(shù)據(jù)。他們巧妙地解決了這個問題，通過運(yùn)用一種特殊函數(shù)，該函數(shù)可以先按照舊系統(tǒng)的方式對老的更新進(jìn)行排序，然后再加入新系統(tǒng)的更新。這意味著無需對應(yīng)用程序進(jìn)行復(fù)雜的改動或遺留過時代碼。此函數(shù)綜合考慮了化身、版本以及舊的更新計(jì)數(shù)器值，確保了記錄順序的準(zhǔn)確性。
3、高延遲查詢
FoundationDB 是為高并發(fā)設(shè)計(jì)的，而非針對低延遲。這意味著它能夠同時處理大量任務(wù)，而不是專注于單個任務(wù)的速度。
來源：《FoundationDB Record Layer: 開源結(jié)構(gòu)化存儲》
為了充分利用這種設(shè)計(jì)，Record Layer在處理任務(wù)時采用了大量的異步操作方式——它會將任務(wù)排隊(duì)等待未來完成，期間可以繼續(xù)進(jìn)行其他工作。這種方法有助于掩蓋這些任務(wù)執(zhí)行過程中可能出現(xiàn)的延遲。
然而，F(xiàn)oundationDB用于與數(shù)據(jù)庫通信的工具最初是采用單線程模式設(shè)計(jì)，一次只做一件事并使用一個網(wǎng)絡(luò)線程。在早期版本中，這種設(shè)置導(dǎo)致了系統(tǒng)內(nèi)部的擁堵，因?yàn)樗腥蝿?wù)都在等待輪到自己在這條網(wǎng)絡(luò)線程上執(zhí)行。Record Layer也沿用了這種單線程處理方法，這導(dǎo)致了性能瓶頸。
為了解決這一問題，蘋果公司著手減輕這條網(wǎng)絡(luò)線程的工作負(fù)載。現(xiàn)在，通過讓系統(tǒng)同時從多個角度與數(shù)據(jù)庫協(xié)同工作，而非形成單一的任務(wù)隊(duì)列，使得復(fù)雜的任務(wù)看上去執(zhí)行速度更快。這樣一來，由于系統(tǒng)無需等待一個任務(wù)完成后再開始另一個任務(wù)，所以延遲或所謂的“緩慢感”被有效地隱藏起來。
4、沖突事務(wù)
在FoundationDB中，如果一個事務(wù)正在讀取某些鍵值，而另一個事務(wù)在同一時刻修改了這些相同的鍵值，則會導(dǎo)致“事務(wù)沖突”。FoundationDB通過提供對可能導(dǎo)致沖突的鍵集合進(jìn)行精確控制的能力，從而允許精細(xì)管理這些沖突。
避免不必要的沖突的一個常見方法是對一組鍵執(zhí)行一種特殊的、不會引發(fā)沖突的讀取操作，即所謂的“快照”讀取。如果這種讀取發(fā)現(xiàn)重要鍵值，那么事務(wù)只會針對那些特定鍵標(biāo)記潛在沖突，而不是整個鍵范圍。這樣可以確保事務(wù)只受到與其結(jié)果真正相關(guān)的更改影響。
Record Layer采用了這一策略來高效地管理其排名索引系統(tǒng)中的一部分結(jié)構(gòu)——跳表（skip list）。然而，手動設(shè)置這些沖突范圍可能較為復(fù)雜，并且可能導(dǎo)致難以識別的錯誤，特別是當(dāng)它們與應(yīng)用程序的主要邏輯混合在一起時。因此，建議構(gòu)建于FoundationDB之上的系統(tǒng)創(chuàng)建更高級別的工具，如自定義索引，以處理這些模式。這種方法有助于避免將放寬沖突規(guī)則的責(zé)任留給每個客戶端應(yīng)用，否則可能會導(dǎo)致錯誤和一致性問題的發(fā)生。
參考鏈接：
https://read.engineerscodex.com/p/how-apple-built-icloud-to-store-billions
