面向資料的架構DOA - eyassh
這是軟體架構中一個鮮為人知的模式,值得更多關注。一個 Joshi 在RTI 的 2007 年白皮書中首次描述了面向資料的架構,2017 年維也納大學的 Christian Vorhemus 和 Erich Schikuta 在這篇 iiWAS 論文中再次描述了面向資料的架構。DOA 一方面是單體二進位制檔案和資料儲存(單體架構)之間的傳統二分法的反轉,另一方面是小型、分散式、獨立的二進位制檔案,每個二進位制檔案都有自己的資料儲存(微服務和麵向服務的架構)。
在面向資料的架構中,單體資料儲存是系統中狀態的唯一來源,由鬆散耦合的無狀態微服務執行。
在單體服務中,大部分伺服器端程式碼位於一個程式中,該程式與一個或多個資料庫通訊,處理功能計算的多個方面。
在單體伺服器中,程式碼仍然可以元件化並分離到單獨的模組中,但程式的不同元件之間沒有強制的API 邊界。程式中唯一嚴格定義的 API 通常是
- (a)在 UI 和伺服器之間(在他們決定的任何 REST/HTTP 協議中)
- (b)在伺服器和資料儲存之間(在他們決定的任何查詢語言中) ) 或在伺服器及其外部依賴項之間。
另一方面,面向服務的體系結構(SOA) 將單體程式分解為每個獨立的元件化功能的服務。
由於 SOA 中的每個服務都定義了自己的 API,因此每個服務都可以獨立訪問並與之互動。開發人員除錯或模擬單個部分可以單獨呼叫單個元件,新流程可以重新組合這些單個服務以啟用新行為。
微服務是一種面向服務的架構。根據您的要求,它們可能與 SOA 不同,因為這些服務旨在特別小和輕量級,或者它們只是 SOA 的同義詞。
隨著微服務生態系統的發展,它開始大規模地受到以下問題的影響:
- 隨著元件數量的增加,整合複雜度的N²增長,
- 網路的形狀變得難以先驗推理;即建立或維護測試環境或沙箱將需要大量推理以確保圖中沒有任何元件具有外部依賴關係
面向資料的架構
在面向資料的架構(DOA) 中,系統仍然圍繞小型、鬆散耦合的元件進行組織,就像在 SOA 微服務中一樣。但 DOA 在兩個關鍵方面與微服務不同:
- 元件始終是無狀態的 :DOA 要求根據集中管理的全域性模式來描述資料或狀態層,而不是對每個相關元件進行元件化和聯合資料儲存。
- 元件之間的互動被最小化,而是透過資料層進行互動。在我們的交易系統案例中,接收不同證券價格的元件只是在我們的資料儲存中以規範的形式釋出價格。系統可以透過向資料層查詢價格來使用這些價格,而不是透過特定 API 從特定服務(或一組服務)請求價格。在這裡,整合成本是線性化的。DOA 模式更改意味著可能需要更新多達N個元件,而不是它們之間的多達N²個連線。
當單個高階資料型別由不同的提供者填充時,這才是真正的亮點。
如果我們用一張表替換一項服務,那麼我們並沒有簡化很多事情。好處是如果有多個相同通用資料型別的源。如果一個交易系統連線到多個市場,每個市場都將客戶的請求釋出到一個表中,那麼下游系統可以查詢這個表,而不必擔心客戶請求來自哪裡。
既然DOA中元件與元件的互動被最小化了,那麼如何用透過資料層的互動來代替今天 SOA 中的元件間通訊呢?
- 1. 資料生產和消費
將元件組織成資料的生產者和消費者是設計 DOA 系統的主要方式。
在 SOA 交易系統中,從市場接受訂單的元件可能會生成 RPC 來確定如何對訂單進行定價、報價或交易。在 DOA 中,微服務消費接受來自市場的請求(通常以 SOA 方式)並生成RFQ,而微服務生產者則生成定價資料等;另一個微服務會查詢 RFQ,連同其所有定價和輸出報價、訂單或任何自定義需要實現最後的響應資料。
- 2. 觸發動作和行為
元件之間通訊的最簡單方法雖然是RPC。設計良好的 DOA 系統應該看到其大部分元件間通訊被生產者/消費者正規化所取代,但您可能仍需要元件 X 直接告訴 Y 執行 Z 的方法。
將 RPC 重構為事件及其影響。即,詢問是否不是元件 X 向發生事件E的元件 Y 傳送 RPC,而是 X 是否可以生成事件E並讓元件 Y 透過使用這些事件來驅動響應?這種方法,我稱之為基於資料的事件。
基於資料的事件:是我們通常如何進行元件通訊的強大反轉。它如此強大的原因是因為它允許我們將鬆散耦合這個術語提升到一個新的水平。系統不需要知道誰在消費他們的事件,並且生產者不需要擔心事件來自哪裡,只需擔心業務 -這些事件的邏輯語義含義。
這種架構不是靈丹妙藥。在面向資料的架構消除了各類問題的地方,新的問題出現了:它要求設計人員認真考慮資料所有權。多個寫入者修改同一記錄的情況可能很脆弱,通常會鼓勵系統仔細劃分記錄寫入所有權。而且由於元件間 API 是在資料中編碼的,因此必須經過深思熟慮,才能使用一種共享的全域性模式。
相關文章
- 面向資料的架構架構
- 面向資料架構的雲演變架構
- 如何構建面向使用者的資料分析架構架構
- 面向服務的架構架構
- 面向架構程式設計架構程式設計
- 面向資源的架構:REST的另一面架構REST
- 面向演算法的架構設計演算法架構
- 面向服務架構(SOA)的原則架構
- 面向模式構建系統架構 (轉)模式架構
- 架構之:資料流架構架構
- 按照業務領域畫資料架構圖 業務架構 資料架構架構
- 面向模式的軟體架構,卷3:資源管理模式模式架構
- 【虹科乾貨】Lambda資料架構和Kappa資料架構——構建現代資料架構架構APP
- 亞馬遜如何變成 SOA(面向服務的架構)?亞馬遜架構
- 說說面向服務的體系架構SOA架構
- 資料治理:資料整合架構的演進架構
- 大資料架構和模式(三)——理解大資料解決方案的架構層大資料架構模式
- 微服務下的資料架構微服務架構
- 面向未來,我們來聊一聊什麼是現代化資料架構架構
- 大資料架構師大資料架構
- ES資料庫架構資料庫架構
- 資料管道架構概述架構
- 雲TIAS:面向未來的智慧城軌ICT架構架構
- 轉:亞馬遜如何變成 SOA(面向服務的架構)?亞馬遜架構
- 讀資料湖倉08資料架構的演化架構
- 如何構建零信任的雲資料架構架構
- 介面、資料結構、資訊架構的區別資料結構架構
- 資料管理架構:單體資料架構與分散式資料網格比較 - enyo架構分散式
- 架構與資料庫的關係架構資料庫
- mysql資料庫的基礎架構MySql資料庫架構
- 架構離不開資料結構架構資料結構
- 大資料架構和模式(一)——大資料分類和架構簡介大資料架構模式
- 資料架構之我見架構
- 大資料架構之:Spark大資料架構Spark
- NUMA 架構與 資料庫架構資料庫
- 面向微服務架構設計理念與實踐微服務架構
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 京東白條資料架構進化之路:要在資料的不確定性中探索架構的穩定性架構