NebulaGraph 的雲產品交付實踐

❝

作者：喬雷，Vesoft.Inc 雲原生技術專家

NebulaGraph 介紹

NebulaGraph 是由杭州悅數科技有限公司自主研發的一款開源分散式圖資料庫產品，擅長處理千億節點萬億條邊的超大資料集，同時保持毫秒級查詢延時。得益於其 shared-nothing 以及儲存與計算分離的架構設計，NebulaGraph 具備線上水平擴縮容能力；原生分散式架構，使用 Raft 協議保證資料一致性，確保叢集高可用；同時相容 openCypher，能夠無縫對接 Neo4j 使用者，降低學習及遷移成本。

NebulaGraph 經過幾年的發展，目前已經形成由雲服務、視覺化工具、圖計算、大資料生態支援、工程相關的 Chaos 以及效能壓測等產品構成的生態，接下來會圍繞雲服務展開，分享落地過程中的實踐經驗。

交付模式

NebulaGraph 在雲上的交付模式分為自管模式、半托管模式與全託管模式三種。

自管模式

自管模式基於各家雲廠商的的資源堆疊編排產品交付，例如 AWS Cloudformation、Azure ResourceManager、Aliyun Resource Orchestration Service、GCP DeploymentManager 等等。自管模式的特點是所有資源部署在客戶的租戶內，使用者自己運維管理，軟體服務商負責將產品上架到 Marketplace，按照最佳實踐給客戶提供服務配置組裝和一鍵部署的能力，相比於傳統模式下以天計的交付週期，現在幾分鐘內就可以在雲上部署一個圖資料庫。

半托管模式

半托管模式是在自管模式的基礎上為客戶提供了代運維的能力，阿里雲端計算巢通過將應用釋出為服務的方式，為服務商提供了一個智慧簡捷的服務釋出和管理平臺，覆蓋了服務的整個生命週期，包括服務的交付、部署、運維等。當客戶的叢集出現問題時，服務商運維人員的所有操作均被記錄，資源操作通過 ActionTrail 記錄日誌，例項操作保留錄屏，還原運維過程，做到運維安全合規可追溯，避免服務糾紛。

NebulaGraph 採用儲存與計算分離的架構。儲存計算分離有諸多優勢，最直接的優勢就是，計算層和儲存層可以根據各自的情況彈性擴容、縮容。儲存計算分離還帶來了另一個優勢：使水平擴充套件成為可能，通過計算巢提供的彈性伸縮能力，保障自身擴縮容需要。

全託管模式

全託管模式交付由服務商託管的圖資料庫產品，客戶按需訂閱付費，只需選擇產品規格與節點，NebulaGraph 全棧產品便可在幾分鐘內交付。客戶無需關注底層資源的監控運維，資料庫叢集的穩定性保障工作，這些都將由服務商解決。

NebulaGraph DBaaS 依託於 Kubernetes 構建，Kubernetes 的架構設計帶來以下優勢：通過宣告式 API 將整體運維複雜性下沉，交給 IaaS 層實現和持續優化；抽象出 Loadbalance Service、Ingress、NodePool、PVC 等物件，幫助應用層可以更好通過業務語義使用基礎設施，無需關注底層實現差異；通過 CRD（Custom Resource Definition）/ Operator 等方法提供領域相關的擴充套件實現，最大化 Kubernetes 的應用價值。

落地實踐

落地實踐主要講述全託管模式產品的架構演進，雲原生技術與業務平臺的融合。

下圖是 Azure 業務側基礎設施的架構，初始配置時對接到管理平臺需要耗時幾個小時，這在有大量使用者申請訂閱例項的情況下是完全不能接受的。

因此，我們想到了將基礎設施模板化，先定義出 dev、test、prod 三種執行環境，再將資源劃分為 VPC & Peering、Private DNS Zone、Kubernetes、Database、Container Registry、Bastion 等幾個類別，使用 terraform 完成自動化配置。但是，僅完成這一步是遠遠不夠的，為了滿足客戶側 Kubernetes 叢集及時彈性要求，我們定義了 Cluster CRD，將 Cluster 的所有操作放入 Operator 裡執行，terraform 的可執行檔案與模板程式碼打包到容器映象後由 Job 驅動執行，Operator 向 Job 注入雲廠商、地域、子網等環境變數，業務叢集的狀態儲存到 Cluster Status 裡。到此，配置基礎設施實現了手動向自動化的演進。

Operators

紅帽出品了一本關於 Kubernetes 設計模式的書籍 《 Kubernetes Patterns 》，關注這個領域的同學想必不會陌生，這本書的出現是針對目前雲原生時代的設計模式，之前的設計模式更多的是對單個模組或是簡單系統的，但是雲原生時代的開發方式和理念與之前的主機開發模式還是存在很大差異的。

在 DBaaS 平臺上線初期，建立一個訂閱例項大致由以下流程構成：

我們在資料庫裡定義了 Task 表，包含 succeed、failed、running、pending 四種狀態，每個訂閱例項流程的任務節點狀態會儲存到 Task 表。服務啟動後會拉起一個監控執行緒，它主要負責定時檢查訂閱例項狀態，當訂閱例項狀態異常後會傳送告警通知，然後根據預期的狀態執行恢復任務。訂閱例項的生命週期管理是一個長耗時的非同步任務，這裡涉及基礎設施資源管理，業務資料的更新等步驟，針對異常情況下不同流程的恢復處理導致業務邏輯複雜，後期再維護的成本逐漸增加，因此，我們對服務做了拆分重構。

我們先行調研了工作流編排系統，比如 Uber 的 Cadence，基礎設施編排領域的成熟案例有 Banzai Cloud，Hashicorp，但是也因引入三方系統帶來額外的運維成本。

另一套方案基於 Operator 的設計模式實現，核心原理是迴圈控制協調，直到執行成功，將每個訂閱例項的管理流程放入協調器裡，例項狀態儲存到到 Status ，平臺業務層模組驅動 Operator 並同步各種 Event。最終我們選擇了基於 Operator 的實現方案，將各種長耗時的任務剝離出來抽象為 CRD，統一交由 workflow-operator 來管理。

經過重構後，訂閱例項的生命週期管理非常簡潔，複雜度大幅降低。

成本控制

隨著企業將更多核心業務從資料中心遷移到雲上，越來越多的企業迫切需要對雲上環境進行預算制定、成本核算和成本優化。同樣地，客戶也對雲上的費用支出異常敏感。

首先，我們在儲存層服務做了優化，通過 NVMe cache 降低儲存資費。NVMe 是專門為 NAND、快閃記憶體等非易失性儲存設計的，NVMe 協議建立在高速 PCIe 通道上。使用NVMe Cache，可以取得相比於同等大小的高效能磁碟不差的效能，而成本至少可以減少50%。

上次分享有介紹過我們的日誌儲存基於 ES 系統，大家都知道，ES 系統儲存是非常耗費資源的，因此我們對業務平臺的應用日誌儲存做了優化。主要是對 filebeat 做了定製開發，支援多家雲廠商的物件儲存服務，改造 Rotater 支援檔案順序索引，可以按照行數切割檔案；基於 fsnotify 庫監聽檔案事件，將切割出來的小檔案上傳到物件儲存；當獲取日誌時，可以根據 offset 計算出對應的日誌檔案索引從而快速獲取日誌。

從使用者控制檯到資料庫的請求鏈路也做了相應優化。每個雲廠商都會為型別為 LoadBalancer 的 Service 或者 Ingress 提供配套的服務元件，這些元件可以解決負載均衡裝置配置流程繁瑣的問題，通過在 Ingress 資源的 Annotation 裡新增幾個配置項，就可以輕鬆拉起一個負載均衡裝置。但凡事總有利弊，作為服務商簡化了管理，對應的在使用者端就會增加資費成本。另外，在實踐的過程中發現每家雲廠商對基礎設施支援的完成度不盡相同，綜合以上因素考慮，我們基於 nginx-ingress-controller 做了鏈路優化，在管理平臺與業務叢集打通網路的條件下，通過 External Service 將流量轉發到對應的訂閱例項。

在開發測試流程上我們基於 KubeSphere 做了以下嘗試。將基礎設施層抽象出 Cloud 介面，裡面包含節點池、負載均衡、DNS 域名等各個子介面，我們針對本地環境提供 Local Provider 的實現，除非像 Privatelink 比較特殊的服務，但是不會影響整體功能測試。

我們將 Kubernetes 叢集分為兩種，一類是由雲廠商託管的 cloud 叢集，另外一類就是自己搭建的本地叢集，將他們匯入到 KubeSphere 統一管理。

控制成本的核心是資源回收。我們通過 CronJob 定時建立、銷燬 cloud 型別的開發、測試叢集，同時設定 K8s 叢集的系統節點池規格滿足最小化執行需求，內測期間無訪問流量的例項自動回收，通過這些策略將成本控制在一個比較理想的狀態。

為了給不熟悉 Kubernetes 的同學測試業務流程，我們為必要的服務元件提供了 helm charts 包，將他們上傳到 Kubesphere 應用倉庫然後提供應用模板來測試流程。

總結與展望

經過 1 年多的實踐，我們總結出以下幾點心得：

為了滿足安全合規、成本優化、提升地域覆蓋性和避免廠商鎖等需求，以及客戶出於資料主權和安全隱私的考慮，混合雲/多雲架構已經成為通用解決方案。雲原生軟體架構的目標是構建松耦合、具備彈性、韌性的分散式應用軟體架構，可以更好地應對業務需求的變化和發展，保障系統穩定性。IaC 可以進一步延伸到 Evething as Code，覆蓋整個雲原生軟體的交付、運維流程，釋放生產力。成本優化至關重要，不論是對客戶還是對服務商而言。

在應用研發的過程中，越來越多的開發者接受了無伺服器的理念。Serverless 資料庫可按需求自動縮放配置，根據應用程式的需求自動擴充套件容量，並內建高可用和容錯能力，採用 Serverless 資料庫開發者將無需考慮選型問題，只需要關注如何設計 schema ，怎樣查詢資料，及如何進行相應的優化即可。對於 NebulaGraph，我們期望未來可以幫助使用者實現端到端的 Serverless 架構，進一步提升使用者體驗。

一文讀懂 Prometheus 長期儲存主流方案

2022-09-08

在 K8s 叢集上部署 RabbitMQ 實戰

2022-09-07

使用青雲負載均衡器訪問雲上 K8s 叢集內部服務

2022-09-06