更多技術交流、求職機會，歡迎關注位元組跳動資料平台微信公衆号，回複【1】進入官方交流群
Data Catalog公有雲遇到的挑戰
Data Catalog經曆了一個從0到1在火山引擎公有雲部署并逐漸優化和疊代釋出10+版本的過程，在這個過程中經曆不少挑戰，下面将介紹其中比較典型的問題以及我們探索并實踐的一些解決方案。
網絡和資料安全
為保證網絡安全和多租戶資料安全，火山引擎上公有雲産品部署的環境劃分為“公共服務區”和“售賣區”，同時售賣區又分割為若幹私有網絡（即VPC），然後公共服務區和售賣區以及售賣區的VPC之間都是網絡隔離的。
Data Catalog會依賴一些内部公共服務，這類服務通常都部署在公共服務區，而按照網絡和資料安全規範，Data Catalog作為獨立雲産品需要部署在售賣區獨立VPC内，類似的情況Data Catalog依賴的資料中台産品也需部署在獨立VPC内，例如EMR、LAS和Bytehouse。另外，Data Catalog對外會提供OpenAPI，外部客戶可以通過火山引擎的API網關來通路這些API，但API網關服務是在公共服務區，無法直接通路到Data Catalog服務，基于以上情況，為了正常對外提供服務，我們需要解決網絡隔離問題同時還要保證安全性。
解決方案：
- 服務部署：為了能夠在售賣區部署，經過調研我們選擇火山引擎提供的容器服務（VKE）和負載均衡（CLB）來進行基礎服務部署和建構，其中CLB提供四層負載均衡能力，容器服務是高性能 Kubernetes 容器叢集管理服務。Data Catalog基于容器服務提供的無狀态負載（Deployment）、定時任務（CronJob）、服務（Service）等雲原生容器管理功能進行基本服務和排程任務部署，同時也使用火山引擎的存儲和中間件，以上元件均在同一個VPC内，能夠保證網絡連通以及資料安全。
- 網絡打通：為解決上文所說的網絡隔離問題，經過調研我們使用了公司通用的網絡代理服務（PLB/Shuttle），該網絡代理可做到網絡打通的同時保證四層網絡流量的安全，進而達到我們和各依賴方如公共服務（API網關、IAM等、獨立部署的雲服務（EMR/LAS等）的網絡連通目标。
- 資料安全：火山引擎部署環境做網絡隔離，主要是保證安全性，我們雖然使用網絡代理打通網絡，但是仍需保證各個環節的安全性，考慮到服務間互動都是通過HTTP請求，我們對和外部互動的接口都增加了SSL和雙向認證的機制，同時在安全認證方面，我們沒有使用Nginx或Java原生的方案，而是借助于火山引擎内部安全服務中的ZTI團隊的envoy元件來實作，同時使用sidecar模式和我們後端服務容器內建部署，既降低了服務端部署改造成本，也解耦了服務端業務邏輯和安全認證邏輯。
多租戶适配
這裡先對多租戶相關概念做一些解釋：
- 租戶：一個客戶、公司、個人開通或購買了火山引擎的雲産品，火山引擎就會通知對應的服務提供者，對應雲産品會感覺到他的開通，這個客戶就是這個雲産品的一個租戶，實際場景可以類比于一個公司是一個租戶，不同的公司是不同的租戶。
- 多租戶服務：雲服務要為多個租戶提供服務，需要做到租戶隔離，保證各租戶的通路控制、資料、服務響應等各方面的使用都是隔離的，彼此互不感覺互不影響的。要做到租戶隔離，就需要雲服務能通過邏輯或實體隔離的方式來将各租戶對應資料和通路隔離開來，避免互相影響。
此前，在位元組跳動内部實踐中不存在多租戶場景，是以面向公有雲使用者服務時，Data Catalog針對支援多租戶服務的能力，需要進行專門适配。
解決方案：
Data Catalog在中繼資料存儲層借用了Apache Atlas的設計與實作。Atlas的底層使用JanusGraph做圖引擎，JanusGraph是基于Gremlin圖查詢語義實作的計算引擎，而社群版Atlas不支援多租戶場景。我們通過在Atlas上增加JanusGraph Partition Strategy适配，實作存儲層租戶邏輯隔離。
參考以上示例，JanusGraph的Partition Strategy可以支援設定的read/write Partition的value，并保證隻讀/寫指定Partition的資料，進而達到資料隔離，我們将租戶資訊和Partition Strategy相結合，實作了多租戶場景下讀寫資料的邏輯隔離，保證了資料安全性。
内外部功能一緻
Data Catalog在位元組跳動内部已打磨多年，産品形态和技術架構比較成熟，但随着公有雲部署和ToB産品疊代，因内部外基礎服務差異和ToB引入新的使用場景和上下遊元件導緻内外部産品功能和技術實作的差異也越來越多。
在前幾個版本中，我們嘗試使用獨立的代碼分支和版本來支援ToB功能，避免内部新功能對ToB産生影響，但我們發現随着版本差異越來越大，代碼和功能的合并和相容就變得非常困難，在其中一次整體代碼合并時，出現了好幾千的檔案diff和上百處merge conflict，我們花費了一周時間多的時間合并代碼和進行多環境測試回歸驗證，最終完成了合并。功能和代碼的不一緻已經成為影響研發效率和需求傳遞進度的很重要因素，必須要進行優化。
解決方案：
我們主要從産品功能和代碼版本兩方面來處理内外部一緻性問題：
産品功能
- 産品功能的标準化：原則上所有功能都應做到内外部一緻，隻允許部分功能點的實作差別。我們期望能将各功能都進行标準化，基礎子產品和通用能力（如中繼資料模型、搜尋、血緣）原則上需保持内外一緻，内外部依賴或需求場景差異較大的功能（如中繼資料接入和采集、庫表管理）改造為标準化流程，将差異部分盡量減小，做到隻通過配置、插件、版本控制工具等方式就能适配，減少研發和運維成本。
- 明确的一緻性規劃：從子產品到功能點逐個對比内部外實作情況，制定長期roadmap，明确差異點的支援排期，并提高對齊内部功能的工作優先級，逐漸減少差異。
- 新功能的相容性：新功能的設計需考慮内外部一緻性，包括産品的互動和研發的技術方案都需考慮外部場景并明确相容方案，原則上對特殊場景定制化功能都需考慮通用場景适配，盡量保持多環境的相容性。
技術實作
- 統一的代碼分支管理規範：原則上内外部的代碼是一緻的即統一的分支。具體來說，不管域内外功能都需相容多環境并在多環境驗證才能合并代碼，外部如公有雲在發版周期中會基于内部主分支代碼（如master分支）建立一個新的release-x.x.x分支，進行回歸驗證和公有雲上線，同時線上持續使用release-x.x.x分支以保證線上環境穩定，release-x.x.x分支需定期合回主分支。新的版本會繼續基于主分支開發，并持續保持該規範。
- 明确的發版規劃：根據實際情況，内部通常疊代比較靈活發版頻率較快，而外部通常要求穩定性，會定期發版（如每月一個版本），考慮到發版周期的差異，我們會以外部固定周期為标準，細粒度控制需求評估、功能開發、QA測試、回歸測試等各環節所在時間段，明确封闆時間，降低内外部互相影響。
- 一緻性意識和自動化多環境驗證：通過多輪分享和教育訓練在技術團隊内部對齊一緻性意識，清楚内外部差異點FAQ等，另外，如上所說新功能技術設計方案需明确多環境相容性。同時，引入自動化的多環境驗證環節，盡早發現不相容或不一緻的問題，減少人工判斷和測試的成本。
OpenAPI
在DataLeap Beta版本釋出之後，有内外部客戶在試用，當時就有客戶提出OpenAPI的需求，但在Beta版本我們還未支援OpenAPI。公司内部有OpenAPI規範和平台，Data Catalog也借助相關平台實作了内部的OpenAPI，但是ToB場景的公共平台不同且會遇到ToB場景特定的問題（如安全認證、多租戶、API開通計費等），需要綜合考慮來對外提供解決方案。
解決方案：
如前文介紹，火山引擎内部公共服務有API網關的通用服務（TOP），并有若幹API釋出規範，Data Catalog調研了該API網關并解決以上核心問題來支援ToB OpenAPI。以下介紹一下主要流程和關注點：
API管理
- Data Catalog借助于API網關管理OpenAPI，包括注冊和開通、通路控制、限流等。
- API規範：火山引擎OpenAPI有明确的參數規範，Data Catalog也需符合該規範，但因内部OpenAPI參數格式不同，需做相容，考慮到新API的支援成本，借助于Spring的Interceptor和Advice以及定制JSON序列化和反序列化邏輯，實作了自動的參數格式轉化，降低API格式相容的開發成本。
- 通路控制：火山引擎作為雲服務提供商，使用業界規範的AKSK密鑰管理規範，API使用者需建立AKSK并通過該資訊來通路API才可通過通路控制，而API網關會通過IAM進行鑒權，通過後會給服務提供者也就是API注冊者透傳使用者的身份（如租戶ID，使用者ID），友善API提供者使用。
- 安全認證：處理API網關提供的基礎鑒權，Data Catalog也增加了更多機制來保障安全性，包括雙向認證、租戶開通狀态檢測等。
- API文檔：對于每一個OpenAPI都根據火山引擎規範編寫了詳細的參數說明，彙總為一個正式API文檔，友善使用者查閱使用。
API請求流程
- 使用者或服務通過AKSK通路API，或者通過前端控制台間接通路API。
- API網關通過IAM進行鑒權，将識别到的使用者身份通過HTTP header透傳給服務提供者。
- 服務提供者接收到請求并通過HTTP header擷取使用者身份，進行下一步處理。
總結
火山引擎Data Catalog産品是基于位元組跳動内部平台，經過多年打磨業務場景和産品能力，在公有雲進行部署和釋出，期望幫忙更多外部客戶創造資料價值。目前公有雲産品已包含内部成熟的産品功能同時擴充若幹ToB核心功能，正在逐漸對齊業界領先Data Catalog雲産品各項能力。文中提及的内容其實還有繼續優化的空間，以及随着客戶的使用，還有面臨一些新的問題，包括多租戶性能優化、服務穩定性保障等，火山引擎DataLeap研發團隊都在持續探索和解決，期望能更好的支援ToB客戶的業務訴求并實作商業價值的同時，提供優質穩定的服務和豐富的擴充能力。
點選跳轉大資料研發治理套件-火山引擎了解更多