在本文中，我将介绍数据网格的概念，它提供的属性、服务，最后如何根据您的需求设计可扩展的数据网格。
什么是数据网格？
数据网格是一组提供共享数据管理系统的服务，其中来自各种应用程序和服务的异构数据可通过形成类似网格的结构进行访问。这可以使用支持各种应用程序请求的数据入口/查询的强中间件应用程序和服务。
网格中的数据由 API 访问（REST 首选和 JSON 格式）。数据可以保存到磁盘，也可以由另一个数据库备份。网格在性质上必须非常有弹性（水平可扩展），并且应该支持几乎任何数量的数据。多个服务可以将 JSON 格式的数据保存到此网格，并在亚毫秒内（类似于缓存）进行查询。
以下是数据网格的属性：
- 来自网格的数据访问使用基于 API 和 REST 的 JSON 格式执行。
- 真正的弹性性质 – 可以水平缩放，没有上限。
- 耐用性 – 可处理停机时间和系统故障。
- 提供低延迟响应。
可选（具有）属性：
- 考虑到数据的重要性，可以授权从网格中请求数据
- JWT、TSL客户端验证等解决方案。
- 能够清除数据并为更相关的数据腾出空间。
- 能够将数据保存到磁盘。
- 能够从其他数据源（如 RDBMS 或 NoSQL 存储）热加载数据。
您可能还喜欢：
数据网格、计算网格、服务网格和执行 SQL 查询的示例。
使用数据网格
在真正的微服务体系结构世界中，每个服务都有自己的私有数据库（每个服务模型的数据库），如果任一服务需要跨多个服务获取数据，则具有挑战性。前期挑战可能是处理来自这些服务的响应，这些响应采用各种格式（如 JSON、XML 或二进制格式）。有些请求可能使用REST 标准超过 HTTP（S），有些使用 SOAP，有些使用 RPC 等。
这些不是技术难题，但在 Microservice 中实现（如：处理安全异常、数据验证、握手、网络、数据解析等）故障时相当麻烦。虽然可以放心地假定这是最常用的方法，但引入了高依赖性因素如果使用者服务仅从其他服务查询数据（而不是请求任何计算结果），则这可能效率不高。
为了解决上述问题，我们引入了一种数据网格方法，该方法几乎提供任何体积的自定义数据存储，具有高度可扩展且易于维护的低延迟响应。我们可以使用Apache Ignite（称为”未来点火”）作为数据网格设计中的主要组件之一，该组件提供持久、弹性和分布式内存平台。Ignite 提供了多种缓存选项、连接到 RDBMS 和 NoSQL 存储的能力以及计算服务。
数据定义
通常，要为基础结构构建数据网格，所有微服务都应发布它们写入网格的数据的格式。例如，用户服务（用于管理系统所有用户的服务）应发布所有 upsert 的所有用户信息并删除操作。用户服务应发布用户数据结构的数据定义。此数据定义应支持版本控制，以便任何新服务都可以查询特定/最新版本。所有从属使用者服务都可以从数据网格查询数据定义并开始构建服务功能。下面是已发布的用户数据结构的示例（版本 1）。
https：//lt;host>/网格/数据定义和类型_用户&版本=1。
{
"用户"： |
"描述""用户数据的结构"。
"所有者""user_service"，
"版本"1，
"字段"： |
"名称""id""类型""uuid""描述""此用户的唯一标识符"
9896px;”>
"名称""电子邮件""类型""字符串""必需"true _，
"名称""移动""类型""字符串""必需"true _，
"名称""名称""名称""类型""字符串""描述""用户的名字"。
"名称""zipcode""类型""字符串""描述""用户位置的邮政编码"。
"名称""状态""类型""字符串""必需"真实"值"：["已注册""非活动""已删除"|
}
}
对于用户数据定义的版本 2，查询可以是：https：//lt;host>/网格/数据定义和类型_用户版本_2。
xxxxxxxxx
{
"用户"： |
"描述""用户数据的结构"。
"所有者""user_service"，
"版本"2，
"字段"： |
"名称""id""类型""uuid""描述""此用户的唯一标识符"
9896px;”>
"名称""称呼""类型""字符串""描述""用户萨利。"必需"真正的"价值"："先生""女士""夫人"，"博士"*，
"名称""最后登录""类型""日期时间""描述""用户上次登录时间"。
"名称""电子邮件""类型""字符串""必需"true _，
"名称""移动""类型""字符串""必需"true _，
13"名称""zipcode""类型""字符串""描述""用户位置的邮政编码"。
"名称""状态""类型""字符串""必需"真实"值"：["已注册""非活动""已删除"|
]
}
}
高级设计
数据网格的系统设计可以使用在线购物网站的示例进行解释。购物网站使用各种微服务（如用户服务、订单服务、产品目录服务和其他服务）构建，这些服务可帮助实现从各种目录中放置产品并最终交付给客户png”数据-新=”假”数据大小=”346582″数据大小格式化”346.6 kB”数据类型=”temp”数据 url=”/存储/临时/12970198-158091366 117.png”src=”http：//www.cheeli.com.cn/wp-内容/上传/2020/02/12970198-1580091366117.png”样式=”宽度：739px;显示：块;垂直对齐：顶部;边距：5px自动;文本对齐：中心;高度：416.145px;”/>
组件服务
数据层
这是数据网格的核心，部署 Apache Ignite 设置（服务器模式）。此设置形成”点火服务器群集”。Ignite 提供的一些功能有助于构建可扩展的网格：
- 内存内缓存 = 用于低延迟响应。
- 分布式和耐用存储。
- 弹性（通过添加节点来水平扩展）。
- 容错能力（数据复制和节点故障时自动加载平衡）。
- 数据复制和持久性（磁盘或数据库）。
Ignite 还适用于无主体系结构，并旋转其他节点只会向群集组添加额外的内存缓存空间。Ignite 还提供各种缓存配置;根据您的需要，可以调整和增强。配置包括数据持久性选项、缓存逐出策略、数据复制等。
数据网格 API 网关
这是将查询路由到相应服务器的网关。可以在网关中注册多个服务，以便可以按负载处理和缩放请求。
查询服务和更新服务
这些是大量应用程序服务器，用于查询数据或更新/将数据添加到数据层中。这些服务从/更新数据从/到”点火服务器群集”（请参阅上图的数据层可视化）。
查询服务对仅查询数据的服务进行分类。此设置中的服务使用 Ignite 客户端库（配置为客户端模式）连接到 Ignite 服务器群集，并成为 Ignite 群集拓扑的一部分。如果这些服务不打算将群集拓扑作为 Ignite 客户端节点加入，则我们可以使用精简 Ignite 客户端（如 Java瘦客户端或Node.js 瘦客户端）连接到 Ignite 服务器群集并执行缓存操作。每个服务可能更新 Ignite 服务器群集中的 1 个或更多缓存。
将数据推送到数据网格可能会有开销，但可以通过使用异步机制或将数据推送到某些 Kafka 主题来克服，数据网格更新服务将使用数据，该服务会将其推送到 Ignite Server 群集。
注意： 应用程序服务使用 Ignite 客户端库进行缓存操作这不是必需的，这是必需的。必须在 Ignite 配置文件中启用客户端模式标志（设置为 true），或者在应用程序服务初始化时调用类似的 Ignite API。有关 Ignite 客户端和服务器设置的详细信息，请参阅此链接。
在示例中使用数据网格
在上图中，最左侧的组件是微服务，其中每个服务都有自己的数据库。在非数据网格方法中，订单服务可能需要查询用户服务以查询用户相关信息（如用户电子邮件、地址等）。在圣诞销售或感恩节销售等特定时间，订单服务可能会遇到大量交易。在这种情况下，订单服务可能必须调用用户服务来获取与订单事务数量成比例的用户相关信息（如用户电子邮件、地址等）。
或者，订单服务可以缓存用户信息，以避免多次网络调用。或者，为了满足用户服务负载的增加，我们可能需要向群集添加更多用户服务节点来处理读取请求。同样，其他服务可能还需要向上扩展，从而遇到大量读取流量。这是可以引入数据网格的位置。
每当其中一个微服务中有数据更新时，该数据将使用数据网格更新服务推送到数据网格。此更新服务连接到点火服务器，然后将数据插入缓存。插入到缓存中的数据将基于在更新服务中部署的缓存配置。这可确保在任何微服务中更新的任何数据也可用于数据网格。此外，由于 Ignite 是持久的，我们可以添加任意数量的节点来支持来自各种服务的大型数据集。可以使用本机持久性启用 Ignite Server 群集，也可以连接到数据库，以便可以保留缓存数据。
当其中一个微服务需要访问特定数据时，它会通过传递必要的查询参数来使用数据网格查询数据网格。查询服务连接到点火服务器，然后从缓存中查询数据。如果数据在缓存中可用，它将作为响应发送。如果数据在缓存中不可用，Ignite 可以从持久存储加载数据（如果启用了持久性）。
可能存在数据在缓存中和持久存储中不可用的情况。查询服务可以具有内置逻辑，用于将请求重新路由到相应的微服务、获取数据并将其插入缓存中。相同的响应可以发送回请求此数据的消费者服务。在下一个请求中，将从数据网格本身提取数据。
插入到缓存中的数据将基于在更新服务中部署的缓存配置此外，由于 Ignite 是持久的，我们可以添加任意数量的节点来支持来自各种服务的大型数据集。
总结
本文试图解决消费者服务可以与生产者服务分离的问题。这也使用户能够灵活地向微服务团添加更多服务，并构建和部署新的功能集。
