【稿件】在本文中,我们先介绍数据网格的基本概念、属性、以及能够提供的服务,然后讨论了如何设计可扩展的数据网格,以满足实际场景的业务需求。
成都创新互联是一家专业从事成都网站建设、成都网站设计的网络公司。作为专业网站设计公司,成都创新互联依托的技术实力、以及多年的网站运营经验,为您提供专业的成都网站建设、营销型网站及网站设计开发服务!
[[314899]]
图片来自 Pexels
在本文中,我们将先介绍数据网格(Data Grid)的基本概念、属性、以及能够提供的服务,然后讨论如何设计可扩展的数据网格,以满足实际场景的业务需求。
什么是数据网格?
数据网格是一组能够提供共享数据管理的服务,它可以通过网格状的结构,去访问源自各种应用程序与服务的异构数据。
在技术实现上,我们通常可以采用功能强大的中间件应用程序和服务,实现对于源于各种应用请求的数据输入与查询。
网格中的数据往往可以通过诸如 REST、以及 JSON 格式的 API 被访问到。这些数据既可以被保存到磁盘上,也能够备份到另一个数据库里。
不同的服务可以将 JSON 格式的数据保存到网格之中,并在不到一毫秒的时间内实现数据查询(类似于缓存)。
以下便是数据网格的基本属性:
它的选配属性则包括:
数据网格的使用
在一个真正的微服务架构系统中,每一项服务都拥有自己的私有数据库(即:每个服务模型都配有一个数据库)。
如果其中的任何一项服务需要横跨多个服务获取数据的话,那么我们就需要以诸如: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 具有持久性,因此我们可以添加任意数量的节点,以支持来自各种服务的大型数据集。
总结
本文提供了将消费者服务与生产者服务相解耦的思路,进而让用户能够灵活地向微服务群添加更多的服务,以构建和部署新的功能集。
【原创稿件,合作站点转载请注明原文作者和出处为.com】
新闻名称:微服务中如何设计高扩展、易维护的“数据网格”?
链接URL:http://www.shufengxianlan.com/qtweb/news1/405501.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联