點(diǎn)擊下方“JavaEdge”，選擇“設(shè)為星標(biāo)”

第一時(shí)間關(guān)注技術(shù)干貨！

免責(zé)聲明~ 任何文章不要過(guò)度深思！ 萬(wàn)事萬(wàn)物都經(jīng)不起審視，因?yàn)槭郎蠜](méi)有同樣的成長(zhǎng)環(huán)境，也沒(méi)有同樣的認(rèn)知水平，更「沒(méi)有適用于所有人的解決方案」； 不要急著評(píng)判文章列出的觀點(diǎn)，只需代入其中，適度審視一番自己即可，能「跳脫出來(lái)從外人的角度看看現(xiàn)在的自己處在什么樣的階段」才不為俗人。 怎么想、怎么做，全在乎自己「不斷實(shí)踐中尋找適合自己的大道」

Netflix的在線數(shù)據(jù)存儲(chǔ)團(tuán)隊(duì)構(gòu)建了一個(gè)名為數(shù)據(jù)網(wǎng)關(guān)（Data Gateway）的平臺(tái)，使我們的數(shù)據(jù)存儲(chǔ)工程師能夠提供強(qiáng)大的數(shù)據(jù)抽象，保護(hù)Netflix應(yīng)用開發(fā)人員免受復(fù)雜分布式數(shù)據(jù)庫(kù)和不兼容API變更的影響。在這篇開篇帖子中，我們將介紹這個(gè)平臺(tái)，作為系列文章的第一部分，展示我們?nèi)绾问褂眠@個(gè)平臺(tái)提高應(yīng)用開發(fā)人員每天使用的數(shù)據(jù)創(chuàng)建、訪問(wèn)和維護(hù)的抽象層次。

動(dòng)機(jī)

在Netflix，我們采用并為數(shù)據(jù)層的大量開源（OSS）技術(shù)和數(shù)據(jù)庫(kù)做出了貢獻(xiàn)，包括Apache Cassandra、EVCache（memcached）、[OpenSearch](https://opensearch.org/）等。傳統(tǒng)上，在線數(shù)據(jù)平臺(tái)運(yùn)營(yíng)這些數(shù)據(jù)存儲(chǔ)，并通過(guò)客戶端庫(kù)提供它們的OSS API。例如，我們運(yùn)營(yíng)Apache Cassandra集群，并為開發(fā)人員提供基于Thrift或Cassandra查詢語(yǔ)言（CQL）協(xié)議的客戶端庫(kù)。這種策略使得數(shù)據(jù)平臺(tái)能夠利用OSS，因?yàn)檫@意味著較少的工程師可以為更多的用戶運(yùn)營(yíng)更多類型的數(shù)據(jù)庫(kù)。然而，雖然這促進(jìn)了快速擴(kuò)張，但將應(yīng)用程序與Netflix不控制的多種API耦合在一起，從長(zhǎng)遠(yuǎn)來(lái)看，維護(hù)成本顯著增加。

大多數(shù)數(shù)據(jù)庫(kù)都有龐大的API表面積和很少的保護(hù)措施，這導(dǎo)致了一些使用上的反模式，需要高級(jí)知識(shí)來(lái)避免，可能需要數(shù)年才能被發(fā)現(xiàn)。例如，開發(fā)人員必須避免將太多數(shù)據(jù)寫入一行或一個(gè)字段，而每個(gè)數(shù)據(jù)存儲(chǔ)的限制都在變化。隨著Netflix工程組織的增長(zhǎng)和用例的激增，工程師們?cè)跍p輕數(shù)據(jù)庫(kù)濫用和重新設(shè)計(jì)應(yīng)用程序的負(fù)擔(dān)上遇到了更多的問(wèn)題。這也增加了產(chǎn)品中斷的風(fēng)險(xiǎn)，因?yàn)榇蠖鄶?shù)關(guān)鍵應(yīng)用程序都依賴于數(shù)據(jù)庫(kù)服務(wù)，而數(shù)據(jù)庫(kù)遷移本質(zhì)上是危險(xiǎn)的。

此外，某些用例需要結(jié)合不同的數(shù)據(jù)庫(kù)架構(gòu)，以實(shí)現(xiàn)具有可擴(kuò)展性、可用性和一致性能的所需API。隨著時(shí)間的推移，我們發(fā)現(xiàn)Netflix的開發(fā)人員一次又一次地實(shí)現(xiàn)相同的模式——例如，在鍵值查找中添加緩存——換句話說(shuō)，就是“重新發(fā)明輪子”。

最后，我們必須將Netflix的標(biāo)準(zhǔn)服務(wù)發(fā)現(xiàn)、遠(yuǎn)程過(guò)程調(diào)用彈性技術(shù)、認(rèn)證和授權(quán)系統(tǒng)集成到每一個(gè)OSS數(shù)據(jù)庫(kù)中，以便Netflix應(yīng)用程序能夠使用它們。將每一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)和每個(gè)數(shù)據(jù)庫(kù)協(xié)議與這些系統(tǒng)集成是具有挑戰(zhàn)性的，因?yàn)槊總€(gè)實(shí)現(xiàn)都是不同的，必須由不同的專家（例如Memcached專家、Cassandra專家等）維護(hù)。

介紹數(shù)據(jù)網(wǎng)關(guān)

Netflix的數(shù)據(jù)網(wǎng)關(guān)是一個(gè)為解決這些問(wèn)題而構(gòu)建的平臺(tái)，它使得Netflix能夠輕松構(gòu)建和管理穩(wěn)定的在線數(shù)據(jù)訪問(wèn)層（DAL）。它通過(guò)提供定制的API使用標(biāo)準(zhǔn)的IPC協(xié)議，如gRPC和HTTP，簡(jiǎn)化和保護(hù)數(shù)據(jù)訪問(wèn)，抽象背后的分布式數(shù)據(jù)庫(kù)的復(fù)雜性，防止它們的使用反模式，同時(shí)增強(qiáng)安全性、可靠性和可擴(kuò)展性。

組件概覽

數(shù)據(jù)網(wǎng)關(guān)位于應(yīng)用程序和數(shù)據(jù)庫(kù)之間，使Netflix能夠提供用戶友好、安全和可靠的數(shù)據(jù)持久性服務(wù)。該平臺(tái)旨在：

**用戶友好：**托管數(shù)據(jù)訪問(wèn)層，為Netflix的常見(jiàn)使用模式提供熟悉的gRPC或HTTP API，例如鍵值或時(shí)間序列。

**安全：**將mTLS、連接管理、認(rèn)證和授權(quán)委托給高性能的服務(wù)網(wǎng)格作為通用解決方案。

**可靠：**將OSS數(shù)據(jù)存儲(chǔ)的API表面積減少到只有它們的安全可擴(kuò)展子集，防止反模式，并提供彈性技術(shù)的間接層，包括斷路器、后壓和負(fù)載卸載。

數(shù)據(jù)網(wǎng)關(guān)實(shí)例

如您所見(jiàn)，數(shù)據(jù)網(wǎng)關(guān)的數(shù)據(jù)平面實(shí)例由以下組成：

• **EC2實(shí)例：**標(biāo)準(zhǔn)云計(jì)算Linux虛擬機(jī)，由Netflix性能團(tuán)隊(duì)調(diào)整為高性能和低延遲。

• **數(shù)據(jù)網(wǎng)關(guān)代理：**邊車進(jìn)程，協(xié)調(diào)專門構(gòu)建的容器鏡像，并在健康時(shí)管理服務(wù)注冊(cè)（即發(fā)現(xiàn)）。

• **容器運(yùn)行時(shí)：**標(biāo)準(zhǔn)OCI容器運(yùn)行時(shí)，運(yùn)行、監(jiān)控、重啟和連接代理和DAL容器。

• **Envoy代理：**行業(yè)標(biāo)準(zhǔn)的服務(wù)網(wǎng)格容器作為反向代理。

• **數(shù)據(jù)抽象層（DAL）：**作為容器部署的應(yīng)用程序代碼，托管專門構(gòu)建的HTTP或gRPC數(shù)據(jù)訪問(wèn)服務(wù)，如鍵值。

• **聲明式配置：**簡(jiǎn)潔的聲明式配置提供目標(biāo)集群和數(shù)據(jù)平面實(shí)例狀態(tài)。

應(yīng)用程序客戶端通過(guò)標(biāo)準(zhǔn)的Netflix發(fā)現(xiàn)服務(wù)或AWS負(fù)載均衡器（例如ALB/NLB）連接到這些網(wǎng)關(guān)。Envoy終止TLS，授權(quán)每個(gè)連接，然后將請(qǐng)求轉(zhuǎn)發(fā)到適當(dāng)?shù)腄AL容器，這些容器使用數(shù)據(jù)庫(kù)特定協(xié)議與數(shù)據(jù)庫(kù)通信以完成每個(gè)查詢。

配置和聲明式交付

聲明式配置通過(guò)數(shù)據(jù)網(wǎng)關(guān)代理在實(shí)例上驅(qū)動(dòng)部署，也在整個(gè)艦隊(duì)中驅(qū)動(dòng)。我們將聲明式配置分為兩類：運(yùn)行時(shí)和部署。

運(yùn)行時(shí)配置

單個(gè)實(shí)例目標(biāo)狀態(tài)的配置稱為“運(yùn)行時(shí)”配置。此配置包括所需的數(shù)據(jù)抽象容器的組合、它們的環(huán)境和與代理的網(wǎng)絡(luò)連接，以形成一個(gè)數(shù)據(jù)平面實(shí)例。以下是一個(gè)運(yùn)行時(shí)配置的示例：

# 配置代理以接受協(xié)議
proxy_config:
public_listeners:
secure_grpc: {mode: grpc, tls_creds: metatron, authz: gandalf, path: 8980}

# 配置實(shí)現(xiàn)協(xié)議的DAL容器
container_dals:
cql:
container_listeners: {secure_grpc: 8980}
image: "dgw-kv"
thrift:
container_listeners: {secure_grpc: 8980}
image: "dgw-kv"
env:
STORAGE_ENGINE: "thrift"

# 配置協(xié)議的高級(jí)布線
wiring:
thrift: {mode: shadow, target: cql}

這指定了兩個(gè)名為cql和thrift的鍵值DAL容器，從dgw-kv鏡像的部署特定版本創(chuàng)建，以及一個(gè)代理監(jiān)聽(tīng)主機(jī)端口8980的外部互TLS（mTLS通過(guò)metatron）連接。這個(gè)協(xié)議被命名為secure_grpc，這些連接應(yīng)該使用mTLS進(jìn)行身份驗(yàn)證，使用Netflix的Gandalf授權(quán)系統(tǒng)進(jìn)行授權(quán)，并將每個(gè)請(qǐng)求轉(zhuǎn)發(fā)到容器內(nèi)部監(jiān)聽(tīng)secure_grpc的DAL進(jìn)程8980端口。最后，布線部分指定我們希望thrift調(diào)用陰影到cql容器。這在下面的圖表中可視化：

雖然運(yùn)行時(shí)配置限于單個(gè)實(shí)例，我們還必須配置這些實(shí)例的愿望部署。部署愿望聲明性地描述了數(shù)據(jù)網(wǎng)關(guān)的部署屬性。以下是一個(gè)部署配置的示例：

deploy_desires:
# 訪問(wèn)模式和容量是什么
capacity:
model_name: org.netflix.key-value
query_pattern:
access_pattern: latency
estimated_read_per_second: {low: 2000, mid: 20000, high: 200000}
estimated_write_per_second: {low: 2000, mid: 20000, high: 200000}
data_shape:
estimated_state_size_gib: {low: 20, mid: 200, high: 2000}
reserved_instance_app_mem_gib: 20
# 這個(gè)部署對(duì)Netflix有多重要
service_tier: 0
# 應(yīng)該部署哪個(gè)版本的軟件
version_set:
artifacts:
dals/dgw-kv: {kind: branch, value: main}
# 運(yùn)行時(shí)配置也是一個(gè)容器！
configs/main: {kind: branch, sha: ${DGW_CONFIG_VERSION}}
# 我們應(yīng)該在哪里部署，包括多個(gè)集群
locations:
- account: prod
regions: [us-east-2, us-east-1, eu-west-1, us-west-2]
- account: prod
regions: [us-east-1]
stack: leader
# 誰(shuí)擁有（負(fù)責(zé)）這個(gè)部署
owners:
- {type: google-group, value: our-cool-team@netflix.com}
- {type: pager, value: our-cool-pagerduty-service}
# 誰(shuí)消費(fèi)（使用）這個(gè)部署，以及什么角色？
consumers:
- {type: account-app, value: prod-api, group: read-write}
- {type: account-app, value: studio_prod-ui, group: read-only}

這個(gè)配置指定了高層次的愿望：容量需求和工作負(fù)載上下文，服務(wù)重要性，軟件組合包括鏡像和運(yùn)行時(shí)配置的版本，部署位置包括區(qū)域和賬戶，以及訪問(wèn)控制。服務(wù)層是一個(gè)簡(jiǎn)潔的上下文片段，作為0到3+之間的數(shù)值提供，指示重要性，并影響車隊(duì)管理、容量規(guī)劃和警報(bào)。

我們使用部署愿望來(lái)為每個(gè)分片提供硬件和軟件，例如，使用RPS和數(shù)據(jù)大小的期望容量作為輸入到我們的自動(dòng)化容量規(guī)劃器，它將這個(gè)愿望編譯為價(jià)格最優(yōu)的EC2實(shí)例選擇以及期望的ASG縮放策略。我們還使用部署愿望來(lái)通知艦隊(duì)的持續(xù)部署，同時(shí)實(shí)現(xiàn)更安全的階段性推出（即，首先部署較不重要的層），工件固定和其他關(guān)鍵功能。

我們稱一組集群為“分片”，因?yàn)樗鼈優(yōu)橛袪顟B(tài)服務(wù)提供故障隔離邊界。在Netflix，分片部署或單租戶架構(gòu)對(duì)于在線數(shù)據(jù)服務(wù)是首選的，因?yàn)樗鼈冏钚』诵袨椴划?dāng)應(yīng)用程序的影響范圍，并保護(hù)更廣泛的Netflix產(chǎn)品免受嘈雜鄰居的影響。到2024年，數(shù)據(jù)網(wǎng)關(guān)平臺(tái)聲明性地管理著數(shù)千個(gè)分片的艦隊(duì)，用于數(shù)十種不同的數(shù)據(jù)抽象。

數(shù)據(jù)網(wǎng)關(guān)代理協(xié)調(diào)專門構(gòu)建的組件

每個(gè)數(shù)據(jù)網(wǎng)關(guān)的核心是我們?cè)贜etflix EC2 VM上放置的代理，它從簡(jiǎn)潔的配置啟動(dòng)，管理所需的容器，并將代理連接起來(lái)，最終向用戶公開數(shù)據(jù)抽象的組合。

如果您熟悉docker-compose，數(shù)據(jù)網(wǎng)關(guān)在哲學(xué)上是類似的，只是集成了一流的網(wǎng)格代理和一個(gè)持續(xù)運(yùn)行的代理，不斷推動(dòng)[pdf]實(shí)例朝著目標(biāo)配置和狀態(tài)。我們集成多個(gè)組件以提供網(wǎng)關(guān)：

• **可靠的系統(tǒng)組件：**EC2 VM、containerd、數(shù)據(jù)網(wǎng)關(guān)代理、有效壓縮的軟件鏡像。

• **進(jìn)程間通信：**可插入的注冊(cè)到服務(wù)注冊(cè)表，mTLS、認(rèn)證、授權(quán)、連接管理以及外部和內(nèi)部實(shí)例網(wǎng)絡(luò)。

• **監(jiān)控：**完整的系統(tǒng)健康檢查，自動(dòng)修復(fù)死亡或失敗的容器。

• **配置和軟件：**軟件和配置的版本集，以及基于環(huán)境的配置。

您可能會(huì)問(wèn)，“為什么不使用Kubernetes”？確實(shí)，Kubernetes pods加上istio是一個(gè)更通用的計(jì)算平臺(tái)，但也是一個(gè)復(fù)雜的解決方案，用于解決我們的相對(duì)簡(jiǎn)單的問(wèn)題。在Netflix，計(jì)算平臺(tái)團(tuán)隊(duì)有很好的單租戶EC2實(shí)例部署，并且在此模式下性能隔離和工具非常好。如果我們偏離這條鋪好的道路，我們的團(tuán)隊(duì)將負(fù)責(zé)運(yùn)營(yíng)Kubernetes和Istio。我們沒(méi)有興趣采用和維護(hù)這樣一個(gè)復(fù)雜的多租戶調(diào)度器和容器解決方案來(lái)解決我們的相對(duì)簡(jiǎn)單的組件組合問(wèn)題，這些組件共位于一個(gè)主機(jī)上。

簡(jiǎn)單地說(shuō)，Kubernetes并沒(méi)有解決我們的許多實(shí)際問(wèn)題，例如允許我們獨(dú)立于pod啟動(dòng)和停止容器，它更復(fù)雜，并為我們的基礎(chǔ)設(shè)施帶來(lái)了許多我們不愿意在骨干數(shù)據(jù)層中的依賴。數(shù)據(jù)網(wǎng)關(guān)平臺(tái)旨在只有三個(gè)外部依賴：一個(gè)Linux VM（EC2）、一個(gè)健壯的調(diào)度器（ASG）和一個(gè)blob存儲(chǔ)系統(tǒng)（S3）。這種表面積的減少對(duì)于一個(gè)將為Netflix部署所有基礎(chǔ)數(shù)據(jù)訪問(wèn)層的骨干基礎(chǔ)設(shè)施組件來(lái)說(shuō)非常有吸引力——由一個(gè)小團(tuán)隊(duì)維護(hù)。

案例研究：鍵值服務(wù)

在Netflix，我們將鍵值服務(wù)（KV）作為DAL部署在數(shù)據(jù)網(wǎng)關(guān)平臺(tái)上。鍵值是基于數(shù)據(jù)網(wǎng)關(guān)構(gòu)建的HashMap[String, SortedMap[Bytes, Bytes]]映射映射數(shù)據(jù)模型和查詢API，具有每個(gè)命名空間的一致性和持久性控制，抽象了數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)。鍵值被Netflix的數(shù)百個(gè)團(tuán)隊(duì)用于為全活躍的全球應(yīng)用程序提供在線數(shù)據(jù)持久性。

鍵值服務(wù)數(shù)據(jù)網(wǎng)關(guān)

鍵值DAL運(yùn)行一個(gè)Java Spring Boot應(yīng)用程序，為鍵值A(chǔ)PI暴露gRPC和HTTP接口。這個(gè)應(yīng)用程序組合了各種存儲(chǔ)引擎，并在上面實(shí)現(xiàn)了諸如對(duì)沖、旁路緩存、透明大數(shù)據(jù)分塊、自適應(yīng)分頁(yè)、通過(guò)資源限制器的斷路器等特性。

鍵值DAL鏡像是使用JIB構(gòu)建的。Netflix的標(biāo)準(zhǔn)應(yīng)用程序框架是Spring Boot，但數(shù)據(jù)網(wǎng)關(guān)平臺(tái)與任何OCI兼容的鏡像兼容，無(wú)論應(yīng)用程序編程語(yǔ)言或客戶端操作系統(tǒng)如何。DAL鏡像在CI（持續(xù)集成）期間安全地上傳到S3工件存儲(chǔ)，并進(jìn)行校驗(yàn)和以檢測(cè)供應(yīng)鏈篡改。

鍵值使用運(yùn)行時(shí)配置實(shí)現(xiàn)環(huán)境特定配置。例如：

proxy_config:
public_listeners:
secure_grpc: {authz: gandalf, mode: grpc, path: "8980", tls_creds: metatron}
secure_http: {authz: gandalf, mode: http, path: "8443", tls_creds: metatron}

container_dals:
kv:
# 可插拔的啟動(dòng)命令
container_cmd: /apps/dgw-kv/start.sh
container_listeners: {http: "8080", secure_grpc: "8980", secure_http: "8443"}
# 配置堆和其他屬性
env:
MEMORY: 8000m
spring.app.property: property_value
# 定義“健康”用于啟動(dòng)檢查
healthcheck:
test:
- CMD-SHELL
- /usr/bin/curl -f -s --connect-timeout 0.500 --max-time 2 http://envoy:8080/admin/health
image: "dgw-kv"

# 配置Netflix發(fā)現(xiàn)目標(biāo)
registrations:
- address: shard.dgwkvgrpc,shard.dgwkv
mode: nflx-discovery

代理運(yùn)行一個(gè)名為kv的容器，由container_dals.kv對(duì)象配置，包括鏡像名稱、環(huán)境變量、容器健康檢查命令和要公開的容器端口。

代理將為public_listeners中的每個(gè)條目配置一個(gè)Envoy主機(jī)偵聽(tīng)器，綁定在所有地址（0.0.0.0ipv4或::ipv6）。這些偵聽(tīng)器通過(guò)名稱轉(zhuǎn)發(fā)到容器偵聽(tīng)器，例如secure_grpc指定從主機(jī)端口::8980路由到DAL容器端口8980。代理確保沒(méi)有主機(jī)端口沖突。代理最后確定使用registrations配置在服務(wù)發(fā)現(xiàn)中注冊(cè)哪個(gè)數(shù)據(jù)網(wǎng)關(guān)分片。

容器級(jí)別的運(yùn)行時(shí)配置與應(yīng)用程序細(xì)節(jié)（如監(jiān)聽(tīng)的端口或健康檢查端點(diǎn)）無(wú)關(guān)。它與多種數(shù)據(jù)網(wǎng)關(guān)應(yīng)用程序兼容，并實(shí)現(xiàn)了更便宜的推出，通過(guò)將快速變化的配置與應(yīng)用程序代碼庫(kù)解耦。

案例研究：安全RDS

安全RDS使用數(shù)據(jù)網(wǎng)關(guān)平臺(tái)實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的透?jìng)骷軜?gòu)，以保護(hù)到PostgreSQL和MySQL的L4連接。這個(gè)架構(gòu)在Envoy進(jìn)程中終止mTLS連接，然后將底層L4流代理到后端AWS RDS集群。這通過(guò)Netflix的標(biāo)準(zhǔn)mTLS認(rèn)證和授權(quán)系統(tǒng)保護(hù)客戶端訪問(wèn)，并依賴于后端AWS服務(wù)器TLS。

客戶端安裝一個(gè)前向代理邊車進(jìn)程，該進(jìn)程發(fā)現(xiàn)數(shù)據(jù)網(wǎng)關(guān)并在客戶端的主機(jī)端口localhost:5432（PostgreSQL）上偵聽(tīng)。當(dāng)客戶端使用標(biāo)準(zhǔn)RDBMs客戶端（如JDBC）連接到前向代理時(shí)，前向代理使用客戶端應(yīng)用程序的metatron TLS證書通過(guò)mTLS連接到數(shù)據(jù)網(wǎng)關(guān)端口5432。在數(shù)據(jù)網(wǎng)關(guān)服務(wù)器上，連接針對(duì)客戶端的身份進(jìn)行授權(quán)。如果允許，客戶端應(yīng)用程序通過(guò)L4 mTLS隧道從其出站代理連接，通過(guò)數(shù)據(jù)網(wǎng)關(guān)剝離mTLS，然后通過(guò)RDS終止連接，使用標(biāo)準(zhǔn)服務(wù)器端TLS。

安全RDS數(shù)據(jù)網(wǎng)關(guān)

這種架構(gòu)使我們能夠無(wú)縫地使用Netflix的認(rèn)證和授權(quán)鋪好路徑，為任何數(shù)據(jù)庫(kù)協(xié)議提供安全保障，我們已經(jīng)為AWS RDS、Open Search、CockroachDB、Neptune等使用了它。此外，我們還計(jì)劃使用這種技術(shù)來(lái)保護(hù)其他現(xiàn)成的數(shù)據(jù)庫(kù)，而無(wú)需修補(bǔ)這些數(shù)據(jù)庫(kù)。它還使用戶名/密碼認(rèn)證變得多余，只要數(shù)據(jù)庫(kù)集群是單租戶的，因?yàn)檎J(rèn)證由Netflix的Metatron mTLS處理，授權(quán)由Netflix的Gandalf系統(tǒng)處理。我們還可以將現(xiàn)有的用戶名/密碼認(rèn)證數(shù)據(jù)庫(kù)納入這個(gè)平臺(tái)，通過(guò)Netflix的秘密系統(tǒng)安全地加密憑據(jù)，使用分片的數(shù)據(jù)訪問(wèn)控制策略。

安全RDS運(yùn)行時(shí)配置指定沒(méi)有容器DALs，而是配置反向代理路由到network_dals.rds.listeners.secure_postgres下的RDS實(shí)例和一個(gè)網(wǎng)絡(luò)DAL目標(biāo)：

proxy_config:
public_listeners:
secure_postgres: {mode: tcp, path: "5432", tls_creds: metatron, authz: gandalf}

# RDS Gateways run no DAL containers
container_dals: {}

network_dals:
rds:
listeners:
secure_postgres: postgresql://rds-db.ih34rtn3tflix.us-east-1.rds.amazonaws.com:5432
mode: logical_dns

工程師需要出于各種原因遷移數(shù)據(jù)存儲(chǔ)之間的數(shù)據(jù)，我們之前已經(jīng)介紹過(guò)?，F(xiàn)代數(shù)據(jù)存儲(chǔ)針對(duì)特定的使用模式和數(shù)據(jù)模型而設(shè)計(jì)，因此當(dāng)使用模式發(fā)生變化時(shí)，數(shù)據(jù)存儲(chǔ)技術(shù)也會(huì)發(fā)生變化。數(shù)據(jù)庫(kù)遷移通常是必不可少的，因?yàn)榘踩┒?、棄用的API、過(guò)時(shí)的軟件或需要增強(qiáng)性能/功能等因素。無(wú)論是轉(zhuǎn)移數(shù)據(jù)以減輕嘈雜鄰居問(wèn)題還是提供新功能，這些遷移在無(wú)法進(jìn)行就地升級(jí)時(shí)，在維護(hù)系統(tǒng)完整性和效率方面發(fā)揮著關(guān)鍵作用。為了使這些過(guò)程對(duì)開發(fā)人員無(wú)縫，數(shù)據(jù)網(wǎng)關(guān)平臺(tái)提供了一個(gè)流量陰影層，以復(fù)制數(shù)據(jù)并在不同的存儲(chǔ)引擎之間性能測(cè)試查詢負(fù)載。有了數(shù)據(jù)網(wǎng)關(guān)，我們可以管理整個(gè)遷移生命周期：

數(shù)據(jù)網(wǎng)關(guān)通過(guò)在數(shù)據(jù)平面實(shí)例中部署兩個(gè)DAL容器來(lái)支持流量陰影，一個(gè)作為連接到現(xiàn)有數(shù)據(jù)存儲(chǔ)的“主”容器，另一個(gè)作為連接到新數(shù)據(jù)存儲(chǔ)的“次”容器。我們配置反向代理將實(shí)時(shí)流量路由到主容器，并將“陰影”（換句話說(shuō)，復(fù)制）流量路由到次容器。在從主容器到次容器回填數(shù)據(jù)后，我們?nèi)缓筇嵘稳萜饕越邮罩髁髁?，從而完成?shù)據(jù)遷移。以下是一個(gè)運(yùn)行時(shí)配置的示例，其中thrift作為主DAL，cql作為次DAL：

proxy_config:
public_listeners:
secure_grpc: { mode: grpc, path: 8980 }

container_dals:
cql:
container_listeners:
secure_grpc: 8980
thrift:
container_listeners:
secure_grpc: 8980

wiring:
thrift: { mode: shadow, target: cql }

我們使用這個(gè)平臺(tái)提供的數(shù)據(jù)遷移能力遷移了數(shù)百個(gè)已棄用的Apache Cassandra 2數(shù)據(jù)庫(kù)到新的主要版本3。由于Cassandra 3對(duì)Thrift存儲(chǔ)引擎有向后不兼容的更改，因此無(wú)法安全地執(zhí)行就地更新，因此我們必須遷移數(shù)百個(gè)應(yīng)用程序和Cassandra集群。我們首先將應(yīng)用程序從直接Cassandra訪問(wèn)遷移到數(shù)據(jù)網(wǎng)關(guān)代理到他們現(xiàn)有的thrift數(shù)據(jù)的鍵值服務(wù)，然后通過(guò)陰影流量和回填將用戶數(shù)據(jù)從Cassandra 2遷移到Cassandra 3。

使用相同的基礎(chǔ)設(shè)施組件集中數(shù)據(jù)遷移是一個(gè)重要的杠桿點(diǎn)，因?yàn)樗刮覀冞@些專家能夠自動(dòng)化這個(gè)過(guò)程，節(jié)省了數(shù)千個(gè)工程小時(shí)，并減少了數(shù)據(jù)損壞的風(fēng)險(xiǎn)。

結(jié)論和未來(lái)工作

數(shù)據(jù)網(wǎng)關(guān)證明了Netflix對(duì)我們?cè)诰€數(shù)據(jù)層的技術(shù)革新和運(yùn)營(yíng)卓越的承諾。它不僅解決了即時(shí)的運(yùn)營(yíng)挑戰(zhàn)，而且為未來(lái)的運(yùn)營(yíng)數(shù)據(jù)存儲(chǔ)的進(jìn)步鋪平了道路，以滿足Netflix不斷增長(zhǎng)的業(yè)務(wù)需求，從我們不斷增長(zhǎng)的SVOD業(yè)務(wù)到新的業(yè)務(wù)線，如廣告、游戲和直播。

在后續(xù)的文章中，我們計(jì)劃分享更多關(guān)于我們?nèi)绾问褂眠@個(gè)平臺(tái)快速開發(fā)、部署和維護(hù)為我們的開發(fā)人員提供高級(jí)數(shù)據(jù)抽象的細(xì)節(jié)，例如：

• 在任意L4/L7數(shù)據(jù)庫(kù)前統(tǒng)一認(rèn)證和授權(quán)

• gRPC 鍵值服務(wù)，為我們的開發(fā)人員抽象出不斷演變的鍵值存儲(chǔ)引擎（Cassandra、EVCache、Netflix構(gòu)建的其他自定義存儲(chǔ)）數(shù)千種不同的用例。

• gRPC 時(shí)間序列服務(wù)，組合多個(gè)存儲(chǔ)引擎以實(shí)現(xiàn)大規(guī)模攝取、保留策略以及搜索和檢索。

• gRPC 實(shí)體服務(wù)，提供靈活的CRUD+QE（查詢和事件）接口，融合CockroachDB、鍵值、Kafka和Elasticsearch

關(guān)注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

★ 作者簡(jiǎn)介：魔都架構(gòu)師，多家大廠后端一線研發(fā)經(jīng)驗(yàn)，在分布式系統(tǒng)設(shè)計(jì)、數(shù)據(jù)平臺(tái)架構(gòu)和AI應(yīng)用開發(fā)等領(lǐng)域都有豐富實(shí)踐經(jīng)驗(yàn)。 各大技術(shù)社區(qū)頭部專家博主。具有豐富的引領(lǐng)團(tuán)隊(duì)經(jīng)驗(yàn)，深厚業(yè)務(wù)架構(gòu)和解決方案的積累。 負(fù)責(zé)： 中央/分銷預(yù)訂系統(tǒng)性能優(yōu)化 活動(dòng)&券等營(yíng)銷中臺(tái)建設(shè) 交易平臺(tái)及數(shù)據(jù)中臺(tái)等架構(gòu)和開發(fā)設(shè)計(jì) 車聯(lián)網(wǎng)核心平臺(tái)-物聯(lián)網(wǎng)連接平臺(tái)、大數(shù)據(jù)平臺(tái)架構(gòu)設(shè)計(jì)及優(yōu)化 LLM Agent應(yīng)用開發(fā) 區(qū)塊鏈應(yīng)用開發(fā) 大數(shù)據(jù)開發(fā)挖掘經(jīng)驗(yàn) 推薦系統(tǒng)項(xiàng)目 目前主攻市級(jí)軟件項(xiàng)目設(shè)計(jì)、構(gòu)建服務(wù)全社會(huì)的應(yīng)用系統(tǒng)。 ”

參考：

• 編程嚴(yán)選網(wǎng)

編程嚴(yán)選網(wǎng)：http://www.javaedge.cn/ 專注分享軟件開發(fā)全生態(tài)相關(guān)技術(shù)文章、視頻教程資源、熱點(diǎn)資訊等，全站資源免費(fèi)學(xué)習(xí)，快來(lái)看看吧~ 【編程嚴(yán)選】星球

歡迎長(zhǎng)按圖片加好友，我會(huì)第一時(shí)間和你分享軟件行業(yè)趨勢(shì)，面試資源，學(xué)習(xí)方法等等。

添加好友備注【技術(shù)群交流】拉你進(jìn)技術(shù)交流群

關(guān)注公眾號(hào)后，在后臺(tái)私信：

• 更多教程資源應(yīng)有盡有，歡迎關(guān)注并加技術(shù)交流群，慢慢獲取

• 為避免大量資源被收藏白嫖而浪費(fèi)各自精力，以上資源領(lǐng)取分別需要收取1元門檻費(fèi)！