【.com原创稿件】本文首先介绍了数据网格可以提供的基本概念、属性和服务，然后讨论了如何设计可扩展的数据网格以满足实际场景的业务需求。图片来自Pexels。在本文中，我们将首先介绍数据网格可以提供的基本概念、属性和服务，然后讨论如何设计可扩展的数据网格以满足实际场景的业务需求。什么是数据网格？数据网格是一组可以提供共享数据管理的服务。它可以通过类似网格的结构访问来自各种应用程序和服务的异构数据。在技??术实现上，我们通常可以使用强大的中间件应用和服务来实现来自各种应用请求的数据输入和查询。网格中的数据通常可以通过REST和JSON格式的API访问。这些数据可以保存到磁盘或备份到另一个数据库。不同的服务可以将JSON格式的数据保存到网格中，并在不到一毫秒的时间内查询数据（类似于缓存）。以下是数据网格的基本属性：使用API（基于REST的JSON格式）从网格访问数据。它本质上是真正有弹性的，即它可以在没有上限的情况下水平扩展。能够支持任何卷的数据。经久耐用，可应对各种中断和系统故障。提供低延迟响应。它的可选属性包括：可以使用如：JWT、TSL客户端认证等方案对网格中的每个数据请求进行授权。能够清除数据并为更多相关数据腾出空间。能够将数据持久化到磁盘。能够从其他数据源（如RDBMS或NoSQL存储）热加载数据。数据网格的使用在一个真正的微服务架构系统中，每个服务都有自己的私有数据库（即：每个服务模型都配备了一个数据库）。如果这些服务中的任何一个需要跨多个服务获取数据，那么我们需要以JSON、XML或二进制等格式处理来自这些服务的响应。一些请求可能使用REST标准HTTP(S)请求、SOAP请求或RPC请求。然而，真正的挑战不是技术上的，而是微服务将如何处理安全异常、数据验证、握手、网络和数据解析等故障。在实际应用中，我们经常会遇到高依赖的问题。即：生产者服务的任何变化都可能改变响应的结构，而消费者服务可能需要适应这种变化。如果消费者服务仅从其他服务查询数据（而不是请求任何计算），则此方法可能不起作用。为了解决上述问题，我们引入了数据网格方法，它能够提供几乎任意数量的自定义数据存储，并且具有高度可扩展性和易于维护以及低延迟响应。在这里，我们使用ApacheIgnite（https://ignite.apache.org/，以下简称Ignite）作为数据网格设计中的主要组件之一，它提供了一个持久的、弹性的和分布式的内存平台。此外，Ignite还提供多种缓存选项，可以连接到RDBMS和NoSQL存储，以及计算服务等功能。数据定义通常，要为基础架构构建数据网格，所有微服务都应发布自己的数据格式以写入网格。例如：一个用户服务（即：管理系统中所有用户信息的服务）应该发布所有具有upsert和delete操作的用户信息，以及用户数据结构的定义。同时，这样的数据定义应该能够支持版本控制，这样任何新的服务都可以查询到具体的最新版本。相应地，所有相关的消费服务也可以从“数据网格”中查询数据定义，进而构建相应的服务功能。这是已发布的用户数据结构（版本1）的代码示例。对应的网址为：https:///grid/datadefinition&type=user&version=1。以下是用户数据定义版本2的查询代码，对应的URL为：https:///grid/datadefinition&type=user&version=2。高级设计我们可以以一个在线购物网站为例来演示数据网格的系统设计。购物网站是使用各种微服务（例如：用户服务、订单服务、产品目录服务等）构建的。这些微服务有助于从各种目录中订购产品，并最终将它们交付给客户。下图展示了数据网格的完整工作流程：组件服务于数据层这是数据网格的核心，部署了ApacheIgnite的服务器端模式设置，构成了一个“Ignite服务器集群”。在这里，Ignite提供了以下可用于构建可扩展网格的功能：通过内存缓存实现低延迟响应。分布式持久存储。弹性，即：通过增加节点实现横向扩展。容错，即：数据复制，节点故障时自动负载均衡。数据复制和持久化到磁盘或数据库。Ignite还可以在无主架构上工作，并且仅通过分离其他节点来向集群组添加额外的内存缓存空间。此外，借助Ignite提供的各种缓存配置，您可以根据需要调整和增强它。此类配置包括数据持久性选项、缓存逐出策略和数据复制等方面。数据网格的API网关。网关可以将查询请求路由到适当的服务器。同时，也可以向网关注册多个服务，以便根据实际负载处理和调整各种请求。QueryServices和UpdateServices这些是大规模的应用服务，可以用来查询数据，或者更新和添加数据到数据层，也就是“Igniteservercluster”（数据层的可视化见上图).查询服务设置将使用Ignite的客户端库（即：以客户端模式配置）连接到Ignite服务器集群并成为Ignite集群拓扑的一部分。如果这些服务不会作为Ignite客户端节点添加到集群拓扑中，那么我们可以使用Ignite的瘦客户端（如：JavaThinClient或Node.jsThinClient）连接到Ignite服务器集群并执行各种Cache操作。此外，每个服务都可以更新Ignite服务器集群中的一个或多个缓存。向数据网格推送数据会产生开销，但是我们可以通过使用异步机制或者向一些Kafka主题推送数据来解决。在这样的主题中，DataGridUpdateService会将其推送到Ignite服务器集群。注意：AppService将使用Ignite的客户端库进行各种缓存操作。默认情况下，它们作为服务器节点通过加入Ignite服务器集群拓扑来参与缓存任务。当然，这不是必需的。我们需要在Ignite配置文件中启用客户端模式标志（即：设置为true），或者在应用服务初始化时调用一些类似的IgniteAPI。有关Ignite客户端和服务器设置的更多信息，请参阅：https://apacheignite.readme.io/docs/clients-vs-servers使用数据网格的示例在上图中，最左边的组件是微服务，每个组件都有自己的数据库。在传统的非数据网格方法中，上述示例中的订阅服务需要查询用户相关信息（例如：用户的电子邮件地址和住址等）来为用户服务。在圣诞节、感恩节等销售旺季，此类订餐服务可能会遇到大量的交易请求。这样的订购服务必须调用相应的用户服务来获取与交易数量成比例的用户相关信息。当然，排序服务可以缓存用户信息，避免多次网络调用。或者，为了满足越来越大的用户服务负载，我们也可以在集群中增加更多的用户服务节点来处理各种读请求。但是，一般来说，数据网格更适合处理此类业务场景。当微服务有数据更新时，数据会被数据网格更新服务推送到数据网格中。然后Ignite服务器根据缓存配置将数据插入到缓存中。此外，由于Ignite是持久的，我们可以添加任意数量的节点来支持来自各种服务的大型数据集。这些Ignite服务器集群可以启用本地持久性，也可以连接到数据库以持久化各种缓存数据。当微服务需要访问特定数据时，它通过传递必要的查询参数来使用数据网格的查询服务。由于查询服务连接到Ignite服务器，它可以从缓存中查询数据。当然，如果数据不在缓存中，但是启用了持久化，那么Ignite可以从持久化存储中加载相应的数据。在极端情况下，如果数据在缓存和持久存储中都不可用，查询服务可以使用内置逻辑将请求重新路由到相应的微服务以获取数据并将其插入缓存。同时response也会将请求发送给consumerservice，这样下次请求来的时候，可以直接从数据网格本身获取相应的数据。由于插入到缓存中的数据是基于更新服务部署的，因此它确保了任何微服务中更新的数据都将在数据网格中可用。此外，由于Ignite是持久的，我们可以添加任意数量的节点来支持来自各种服务的大型数据集。总结本文提供了将消费者服务与生产者服务解耦的思路，允许用户灵活地向微服务集群中添加更多服务，以构建和部署新的功能集。【原创稿件，合作网站转载请注明原作者和出处为.com】
