【51CTO.com原創稿件】在本文中，我們先介紹數據網格的基本概念、屬性、以及能夠提供的服務，然后討論了如何設計可擴展的數據網格，以滿足實際場景的業務需求。

[[314899]]

圖片來自 Pexels

在本文中，我們將先介紹數據網格(Data Grid)的基本概念、屬性、以及能夠提供的服務，然后討論如何設計可擴展的數據網格，以滿足實際場景的業務需求。

什么是數據網格?

數據網格是一組能夠提供共享數據管理的服務，它可以通過網格狀的結構，去訪問源自各種應用程序與服務的異構數據。

在技術實現上，我們通常可以采用功能強大的中間件應用程序和服務，實現對于源于各種應用請求的數據輸入與查詢。

網格中的數據往往可以通過諸如 REST、以及 JSON 格式的 API 被訪問到。這些數據既可以被保存到磁盤上，也能夠備份到另一個數據庫里。

不同的服務可以將 JSON 格式的數據保存到網格之中，并在不到一毫秒的時間內實現數據查詢(類似于緩存)。

以下便是數據網格的基本屬性：

• 使用 API(基于 REST 的 JSON 格式)從網格進行數據訪問。
• 其本質上具有真正的彈性，即：可以水平縮放而沒有上限。
• 能夠支持任何體量的數據。
• 具有耐用性，可應對各種宕機和系統故障。
• 提供低延遲的響應。

它的選配屬性則包括：

• 可以利用諸如：JWT、TSL 客戶端驗證等方案，對網格中的每一種數據請求進行授權。
• 能夠清除數據，并為更多相關數據留出空間。
• 能夠將數據持久地保存到磁盤上。
• 能夠從諸如：RDBMS 或 NoSQL 存儲等其他數據源，進行數據的熱加載(hot-load)。

數據網格的使用

在一個真正的微服務架構系統中，每一項服務都擁有自己的私有數據庫(即：每個服務模型都配有一個數據庫)。

如果其中的任何一項服務需要橫跨多個服務獲取數據的話，那么我們就需要以諸如：JSON、XML 或二進制格式，來處理這些服務的響應。

而有些請求既可能使用的是 REST 標準的 HTTP(S)請求，也可能使用 SOAP 請求，還有可能使用 RPC 等請求。

不過，真正的挑戰并非在技術上，而是在處理諸如安全異常、數據驗證、握手、網絡、數據解析等失敗的情況下，微服務將如何應對。

在實際應用中，我們常常會碰到高度依賴性的問題。也就是說：生產者(producer)服務中的任何變更都可能會更改響應的結構，而消費者(consumer)服務也可能需要跟著適應此類變更。

如果消費者服務僅從其他服務中查詢數據(而非請求任何計算結果)，那么該方式則可能無效。

為了解決上述問題，我們引入了數據網格的方法，該方法幾乎能夠提供任意數量的自定義數據存儲，并且具有高度可擴展性和易于維護的低延遲響應。

在此，我們將 Apache Ignite(https://ignite.apache.org/，以下簡稱為 Ignite)作為數據網格設計中的主要組件之一，由它提供具有持久性、彈性和分布式的內存平臺。

此外，Ignite 還提供了多種緩存選項，可連接 RDBMS 和 NoSQL 存儲，以及計算服務等功能。

數據定義

通常，若要為基礎架構構建數據網格，所有的微服務都應當發布各自寫入網格的數據格式。

例如：用戶服務(即：管理某個系統中所有用戶信息的服務)應當發布所有具有 upsert 和 delete 操作的用戶信息，以及用戶數據結構的定義。

同時，此類數據定義應當能夠支持版本控制，以便任何新的服務都可以查詢到特定的最新版本。

據此，所有相關的消費者服務也都可以從“數據網格”中查詢到數據定義，進而構建相應的服務功能。

以下是一個已發布的用戶數據結構(版本 1)的代碼示例。其對應的 URL 為：

https:///grid/datadefinition&type=user&version=1.

如下是對于用戶數據定義版本 2 的查詢代碼，其對應的 URL 為：

https:///grid/datadefinition&type=user&version=2.

高級設計

我們可以使用某個在線購物網站為例，來展示數據網格的系統設計。該購物網站是采用各種微服務(例如：用戶服務、訂單服務、產品目錄服務、以及其他服務)來構建的。

這些微服務有助于實現從各種目錄中訂購產品，并最終將其交付給客戶。下圖是數據網格的完整工作流程：

各個組件服務

數據層

這是數據網格的核心，其中部署了 Apache Ignite 的服務器端模式設置，并構成了“Ignite 服務器群集”。

在此，Ignite 提供了如下可用于構建可擴展網格的功能：

• 通過內存中緩存，實現低延遲的響應。
• 分布式的持久存儲。
• 彈性，即：通過添加節點，實現水平擴展。
• 容錯，即：數據復制，以及在節點出現故障時的自動負載均衡。
• 針對磁盤或數據庫的數據復制和持久性。

Ignite 也可以在無主控的架構上工作，并通過拆分其他節點，只向群集組中添加額外的內存內(in-memory)緩存空間。

另外，通過 Ignite 提供的各種緩存配置，您可以按需對其進行調整和增強。此類配置包括：數據持久性選項、緩存的逐出策略、以及數據復制等方面。

數據網格的 API 網關

該網關可以將查詢請求路由到適當服務器上。同時，多個服務也可以被注冊到該網關上，以便根據真實的負載，來處理和調節各種請求。

查詢服務與更新服務

這是一些大規模的應用服務，可用于查詢數據，或將數據更新并添加到數據層，也就是“Ignite 服務器群集”上(有關數據層的可視化，請參見上圖)。

查詢服務設置將使用 Ignite 的客戶端庫(即：配置為客戶端模式)連接到 Ignite 服務器群集，并成為 Ignite 群集拓撲中的一部分。

如果這些服務并不會被作為 Ignite 的客戶端節點加入群集拓撲，那么我們可以使用 Ignite 的瘦客戶端(如：Java Thin Client 或 Node.js Thin Client)去連接到 Ignite 服務器集群，并執行各種緩存操作。

而且，每個服務都能夠更新 Ignite 服務器群集中的一到多個緩存。

將數據推送到數據網格雖然會產生開銷，但是我們可以通過使用異步機制，或者將數據推送到某些 Kafka 的 topic 上來解決。

在此類 topic 中，數據網格的更新服務(Data Grid Update Service)會將其推送到 Ignite 的服務器群集之中。

注意：應用服務會使用 Ignite 的客戶端庫，來進行各項緩存操作。在默認情況下，它們通過加入 Ignite 服務器群集拓撲，來充當服務器節點，以參與緩存任務。

當然，這并不是必需的。我們需要在 Ignite 的配置文件中啟用客戶端模式標志(即：設置為 true)，或者在應用服務的初始化時，調用某個類似的 Ignite API。

有關 Ignite 客戶端和服務器設置的更多信息，請參見：https://apacheignite.readme.io/docs/clients-vs-servers

使用數據網格的示例

在上圖中，最左側的組件是微服務，其中每個服務都有自己的數據庫。在傳統的非數據網格方法中，上例中的訂購服務需要針對用戶服務，去查詢用戶的相關信息(例如：用戶的電子郵件與地址等)。

而在圣誕節、感恩節等銷售旺季，此類訂購服務可能會遇到大量的交易請求。那么此類訂購服務就必須調用相應的用戶服務，以獲取與交易數量成比例的用戶相關信息。

當然，訂購服務可以緩存用戶的信息，以避免多個網絡的調用。或者，為了滿足不斷增加的用戶服務負載，我們還可以向集群添加更多的用戶服務節點，以處理各種讀取請求。不過，總的說來，數據網格更適合于處理此類業務場景。

當某個微服務有數據更新時，該數據將會被數據網格更新服務推送到數據網格之中。Ignite 服務器進而根據緩存配置將數據插入到緩存里。

此外，由于 Ignite 具有持久性，因此我們可以添加任意數量的節點，以支持來自各種服務的大型數據集。

這些 Ignite 服務器群集既可以通過原生持久性來啟用，也可以連接到數據庫上，以便保留各種緩存數據。

當某個微服務需要訪問特定的數據時，它會通過傳遞必要的查詢參數，來使用數據網格的查詢服務。

由于查詢服務連接著 Ignite 服務器，因此它可以從緩存中查詢到數據。當然，如果數據不在緩存中，卻已經啟用了持久性，那么 Ignite 則可以從持久性存儲中加載相應的數據。

在極端情況下，如果緩存和持久性存儲中的數據都不可用，那么查詢服務則可以通過內置的邏輯，將請求重新路由到相應的微服務上，以獲取數據并將其插入到緩存中。

同時，該響應也會將請求發送給消費者服務，以便在下一個請求到來時，直接從數據網格本身獲取對應的數據。

由于插入到緩存中的數據是基于更新服務來部署緩存的，因此它確保了在任何微服務中的更新數據，都會在數據網格中可用。

此外，由于 Ignite 具有持久性，因此我們可以添加任意數量的節點，以支持來自各種服務的大型數據集。

總結

本文提供了將消費者服務與生產者服務相解耦的思路，進而讓用戶能夠靈活地向微服務群添加更多的服務，以構建和部署新的功能集。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】