寬橋推出BroCanal超融合一體機方案，打造微服務數據中台

現今企業在轉型微服務所面臨最大的問題就是「資料」，傳統集中式資料系統架構的速度和規模，已經遠遠跟不上現今數位應用發展的需要。只要資料架構的問題不解決，微服務架構的實現就會遭遇重大瓶頸，難以支撐數位轉型的終極目標；為了解決棘手的資料問題，正確地打造數據中台就是各企業眼前的首要課題。

為了讓企業更快速且無痛打造數據中台，落實微服務所需要的 Data Mesh 分散式架構，寬橋有限公司（BroBridge）推出 BroCanal 一體機解決方案，結合資料快取技術、資料發佈管理以及資料中心管理平台，具備整合不同類型資料庫系統如：Microsoft SQL Server、IBM DB2、Oracle、Postgres、MySQL、Mariadb及 Mainframe 上的各式資料源，並以快照管線緩衝技術大幅提升資料負載能力，避免微服務應用巨量連線衝擊資料庫系統。

微服務迫切需要以 Data Mesh 概念實現的數據中台

數據中台是以 Data Mesh 概念實現的分散式資料平台，以高速擴展的資料供應架構和資料抽象層，滿足微服務應用快速發展的需要，並供應巨量碎片化應用的資料需求。高速供應資料給應用服務是數據中台的首要任務，也要確保資料源的資料庫系統在大量存取時不能受到嚴重的效能衝擊。

BroCanal 的數據網格 Data Mesh 邏輯架構如下圖：

此架構下，數據中台將藉由實現資料抽象層，以快速存取數據中台內的分散式數據網格，無論資料來源為何種資料格式(結構化資料、非結構化資料)，應用程式都可以輕易地快速取得所需資料，無須再煩惱跨系統資料串接、整合和交換等議題。此外，受益於資料抽象層，應用需求與資料源有實體的隔離，在巨量微服務運作的場景下，資料安全也得到一定保障。

資料存取效能方面，滿足應用程式的巨量查詢是數據中台的核心，資料的傳輸和供應全依賴快照管線進行數據快取，確保資料能準確快速發佈到離應用服務最近的中繼資料庫節點，藉此分散核心資料庫的負載，大幅提高整體效能表現。

改善資料庫查詢效能表現

傳統的資料管理架構下，無論是資料庫系統、資料倉儲或者資料湖都是將資料數據統整在同一處，往往這意味著，當實際應用端在使用這些資料時必須仰賴單一資料庫的效能表現。而同樣的資料集因為業務需求不同，對資料有不同的呈現需求，比如說(光是銀行的交易明細，就有100多種以上的呈現需求)，因此各種不同面向的查詢、跨資料集的關聯條件，導致資料庫系統不堪負荷，應用程式在查詢讀取資料時效能不彰，除了使用者體驗差之外，對於數據交換也構成了極大的障礙，最後導致設計良好的應用導入之後變成一個災難的開始。當然，過往也有很多企業用戶是透過規劃Master/Slave 資料庫的抄寫機制，每當有需要擴展新的 Slave 時仍須由 Master 同步資料，導致兩者同步時間過長，資料量一大，有可能同步需要 2 小時以上，同樣造成維運上的困擾，甚至如果是跟商品資訊有關，就會直接影響到業務操作。透過數據中台的搭建，可以對資料提前進行不同角度的快照和快取，在最短的時間內將資料推送到應用程式可觸及的容器平台上面，省去應用程式關聯查詢時的繁雜工作。

解決批次資料處理效能衝擊問題

許多企業為了進行大規模資料分析或生成多重統計報表，又或者是為了兩個異質系統進行資料交換，需要定期進行批次資料處理（例如：批次資料查詢、輸出等）。累積了大量資料後進行資料查詢和處理，除了資料處理不即時外，亦會大幅度衝擊資料庫系統效能，甚至導致正常業務無法順暢運行。如果查詢又橫跨多個資料庫系統，影響範圍甚至會擴大。

導入數據中台後，針對所有需要收集資料的資料庫系統，皆可以快照管線進行即時的資料快取，然後依照不同的結果需要，以不同的抽象表單的格式呈現，實現「一次讀取發佈，多次快照落地（Provision Once, Snapshot Many）」的需求，無需再因為一次性或多應用同時批次處理大量資料，導致核心資料庫受到嚴重衝擊。

解決跨系統資料整合問題

除了維護上遇到的效能問題之外，當有業務需求要提供指定資料表供應用端存取，通常也無法直接開放該應用端使用核心資料庫。資料庫管理員為了應對這種來自各種業務情境的微服務，還得依照需求設計出供應資料的介面給各個應用程式存取。但是對於企業內部的資料整合，因為資料量過於巨大且複雜，很多情況下不適合使用 API 、寫檔等方式，一方面跨系統呼叫查詢效能不彰，另一方面會涉及多方組織人員的責任歸屬問題和溝通障礙。即便嘗試將指定資料同步到相對應的新建資料庫，也會面臨時間與人力的過度消耗。

利用數據中台，各方系統只需要將自家資料庫系統，介接並發佈到數據中台之上，就能讓有需要的其他系統進行資料訂閱取用。未來無論什麼應用需求，資料源都無需再做其他設定或 API 開發。

改善多資料源的處理管線效率不彰問題

傳統的集中式資料處理機制（例如：ETL）在面對多資料源時，會因為資料篩選（Filter）、關聯聚合（Aggregate）、資料轉換（Transform）等工作，嚴重被來自不同資料源的資料相依性所牽制，大量的來回查詢（Query）、子查詢（Subquery），更有甚者會造成「左手扒右耳」的窘境，除了造成網路頻寬的負擔之外，更嚴重衝擊資料源的系統效能。

由於一筆資料的關聯工作，都會有大量查詢工作遍佈在整個系統之中，使得系統內從上到下的所有程式都極為忙碌；查詢條件之間有關聯性，需要等到所有查詢工作都完成後才能完成一筆資料的處理工作，這樣鎖住整個系統的同步性（Synchronous）的設計，使得資料處理管線效率相當低落。此外，當有多個應用存在時，其資料的拉取需求會為整個系統帶來更大的壓力，使整個系統不堪負荷。

在導入分散式 Data Mesh 架構的數據中台之後，重心會放在資料發佈和供應效率，讓各自應用領域的資料處理邏輯被分散在各自應用節點上進行，大幅降低資料源和中間處理管線的工作，也降低資料源和特定處理節點的壓力，實現跨系統、資料源的聚合和關聯平行處理。

打造數據中台困難重重，導入 BroCanal 迎刃而解

分散式 Data Mesh 的架構與過往集中式系統架構不同，對於缺少經驗的大多數企業來說，新的分散式資料管理平台的設計和建置相當複雜且不易，錯誤的數據中台設計不但會為微服務的發展造成阻礙，也會拖垮整個系統效能表現。

一個可用的微服務數據中台之所以打造不易，主要關鍵是工作範疇將橫跨基礎設施（Infrastructure）、應用（Application）和資料湖（Data Lake）等領域，不但需要大量採用新的雲原生技術（如：容器技術、虛擬化技術、儲存技術、資料快照管線技術等），也要對應用程式進行改造，更要設計一系列貫穿不同應用系統、資料庫、儲存系統的分散式管理架構。因此對於還尚在導入容器技術、分散式技術和微服務架構的企業來說，設計並搭建分散式數據中台將是一個層度更高的難題，困難重重。

依照過往案例經驗，正常規劃搭建 Kubernetes 架構、維運、應用拆分、資料拆分、服務網格(Service Mesh)、數據網格(Data Mesh)，最短也需要6個月週期。有鑑於此，致力於數位轉型平台解決方案的 寬橋（BroBridge），著眼於傳統底層架構與新型態架構之間的橋樑，將多年的數位轉型經驗凝聚成超融合一體機解決方案「BroCanal」，讓企業無需再煩惱數據中台的設計規劃和建置問題，其中內建超高速、高可用資料快取與發佈平台「GRAVITY」，讓用戶在數位轉型的過程之中不用自己從頭開發、建構，從快速部署底層系統架構，包含支援雲原生(Cloud-Native)的Kubernetes平台、軟體定義存儲(SDS)、軟體定義網路(SDN)、虛擬主機管理、拆解、移轉傳統應用到微服務架構，並落實 Data Mesh，在最短的時間內達成一次到位，並滿足絕大多數的數位轉型的技術工作需求。

BroCanal 不僅僅是數據中台

BroCanal 核心採用 Kubernetes 容器技術，管理數據中台的資料快取管線的和中繼資料庫，確保分散式 Data Mesh 架構的穩定性。此外，針對有特殊考量的資料庫系統需求，亦可匯入、生成、管理既有虛擬平台上的（Virtual Machine），使用者能以內建的虛擬平台管理建置額外的高效資料庫叢集。

不僅如此，BroCanal 更配備了軟體定義存儲(SDS)、軟體定義網路(SDN)環境，讓使用者能快速地將傳統 VM 轉移至 BroCanal 平台，與容器應用統一平台進行運作及管理。無論你的需求是遷移既有 VM、建置 Kubernetes 叢集、管理 Kubernetes的極細部設定、部署及管理容器應用，BroCanal 都可以在單一的使用者介面，一鍵自動完成這些相當繁瑣的任務，如下圖：

新一代數據中台

BroCanal 提供絕佳的高可用性、擴充性、以及穩固的底層架構設計，除了大幅提升應用及資料庫效能之外，資料管線管理的靈活性也讓金融、高科技製造、醫療等各行業的業務應用系統能夠建構一個穩定、即時、調度極為靈活的新一代的數據管理中台，完成碎片化中台系統的建構任務。

寬橋（BroBridge）長期深耕微服務技術，包括 GRAVITY 的技術細節，以及關於微服務架構所需的資料管理和平台設計理論與實作，時常於官網與BroBridge Medium上發表微服務、容器平台技術應用，以及在Kubernetes官方組織-雲原生基金會（CNCF, Cloud Native Computing Foundation）的國際版面貢獻相關技術文章，相關資訊如下：
#1 於CNCF/KubeConf Expert Voice 刊載 About Data Caching and Provisioning Strategy of Microservice Architecture
#2 於CNCF/Kubernetes 官網刊載Why do we hit a wall when introducing microservice architecture?
#3 於CNCF/Kubernetes 官網刊載 The magic trick of CQRS: decoupling of microservice data