从本文开始，会通过一个系列的篇幅来介绍使用Apache Ignite内存数据组织平台来构建容错、可扩展的基于微服务的解决方案。

详细信息参考：https://liyuj.gitee.io/doc/java/ServiceGrid.html

介绍

当前，很多公司都会将自己的应用或者解决方案构建于微服务架构之上，这样做的主要好处是，可以将一个解决方案拆分为一组松耦合的软件组件（微服务）。这些软件组件可能有自己的版本以及生命周期，甚至有自己的开发团队。此外，这些软件还可能使用不同的语言和技术来开发和维护。但是因为所有的微服务都会是更大的构件（软件或者解决方案）的一部分，所以它们至少需要一个机制来进行彼此的交互和数据交换。

同时，基于微服务的解决方案也会用于高负载或者需要处理快速增长的数据的场景，因此和不是基于微服务的应用和解决方案一样，它也会面临同样的问题和困难。

• 面向磁盘的数据库已经无法跟上快速增长的数据量，这些数据需要以并行的方式进行存储和处理，数据库正在成为整个应用或者解决方案的性能瓶颈；
• 软件的高可用性保证作为一个好功能已经成为过去式，当前，应用的高可用性已经成为事实上的标配。

从本文开始，会通过一个系列的篇幅来一步步地介绍使用Apache Ignite内存数据组织平台来构建容错、可扩展的基于微服务的解决方案。

使用Apache Ignite的基于微服务的解决方案

下图会描述整个解决方案的主要构成，之后会深入，一个一个定义它们的角色。

Ignite集群层

集群有两个作用：

首先，作为主要的数据存储，它直接在内存中保存数据集。因为数据离CPU更近，一个微服务不需要从磁盘上获取数据，这显著地提升了整体的性能。从上图来看，我们指定了一个特定的集群组（数据节点）来专门处理这个问题。

一个数据节点是一个Ignite服务端节点，它持有数据集的一部分，并且可以执行查询和计算。另外，有赖于基于对象序列化的二进制格式化技术，一个数据节点不需要部署模型对象和计算的支撑类，这个叫做对等类加载机制，它可以管理从应用逻辑节点（服务节点）预加载的计算类。

其次，集群管理微服务的生命周期，并且为微服务配备所有必要的API，比如与其他服务或者数据节点进行通信的API。要达到这一点，一个基于Ignite集群的解决方案需要包含前述的服务节点，这些节点部署有微服务，并且应用逻辑也在这里执行。一个服务节点可以部署一个或者多个微服务，这个取决于具体的应用以及负载情况。每个微服务都需要实现Ignite的Service接口，它直接就有了容错和访问其他微服务的能力。

Ignite会处理在服务节点范围内，一个微服务的一个或者多个副本的部署，并且会自动地进行容错和负载平衡。在上述的图1中，这类微服务被命名为MS<N>(MS1,MS2等）。在多个服务和数据节点间传播负载的好处是，如果MS1微服务改变，不需要重启整个集群，所有需要做的就是在部署有MS1微服务的服务节点上更新MS1的相关类，因此只有所有节点的一个子集需要重启。

所有的节点（服务和数据节点）都是相互连接的，这使得部署在一个服务节点上的MS1可以与部署在任何其他的或者自身服务节点上的微服务进行通信，也可以向任何数据节点获取和发送数据以及计算。

持久化存储层

这一层是可选的，可以用于如下的场景：

• 在内存中持有所有的数据是不必要或者不可行的；
• 需要从基于磁盘的副本中恢复数据集的能力，这时整个集群需要停机或者需要重启。

要启用持久化存储层，只需要简单地提供一个实现了CacheStore接口的Ignite数据缓存就可以了。在默认支持的实现中，有RDBMS，MongoDB以及Cassandra。

外部应用层

这是微服务架构应用的”用户”，基本上来说，这是一个触发调用一个一个微服务的各种执行流程的层次。

这个层可以使用具体到每个微服务的外部协议来与微服务进行通信（而在内部，微服务间相互通信可以使用Ignite服务，或者使用Ignite客户端连接进行连接），这方面都很大的灵活性以及多样化的选择。

—-

作为一个系统，一个可能的架构由如下层次组成：

• Ignite集群层
• 持久化存储层
• 外部应用层

本文中会关注第一层（Ignite集群层），可以参考一个GitHub项目，他包含了日常中实现拟议的微服务架构所必须的构建块，尤其是要覆盖如下部分：

• 配置和启动数据节点；
• 使用Ignite的服务API的典型服务实现；
• 配置和启动驻有Ignite服务的服务节点；

Ignite具有非常先进的集群能力，本文针对和集群有关的技术点做一个简短的介绍，然后针对实际应用的可能部署形式做了说明和对比，从中我们可以发现，Ignite平台在部署的灵活性上，具有很大的优势。

Ignite的设计表明整个系统本身就具有固有的可用性和可扩展性。ignite节点间通信允许所有节点接收更新，无需一个快速的主协调器。节点可以不受干扰地添加或删除，以增加可用RAM的数量。
Ignite数据结构具有完全的弹性，允许对单个服务器或多个服务器进行无干扰的自动检测和恢复。

客户端和服务端

Apache Ignite具有一个可选的服务概念，并提供了两种类型的节点:客户端和服务器节点。

• Server 包含数据、缓存、计算和流，并且可以是内存中的Map-Reduce任务的一部分。
• Client 提供远程连接服务器以将元素放入/获取到缓存的能力。它还可以存储部分数据(近缓存)，这是一个较小的本地缓存，存储最近和最频繁访问的数据。
  

  还可以将服务器节点分组到一个集群中执行工作。在集群中，可以限制作业执行、服务部署、流和其他任务只在集群组中运行。
  你可以基于任何谓词创建一个集群组。例如，您可以从一组节点创建一个集群组，其中所有节点负责为testCache缓存数据。默认情况下，所有节点都作为服务节点启动。客户端模式需要显式启用。注意，您不能物理地将数据节点与计算节点分离。在Apache Ignite中，包含数据的服务器也用于执行计算。Apache Ignite客户机节点也参与作业执行。乍一看，这个概念似乎很复杂，但让我们试着澄清这个概念。服务器节点总是存储数据，默认情况下可以参与任何计算任务。另一方面，客户端节点可以操作服务器缓存、存储本地数据并参与计算任务。通常，客户端节点用于从缓存中放置或检索数据。这种混合客户端节点在开发具有多个节点的大型Ignite网格时提供了灵活性。客户端和服务器节点都位于一个网格中，在某些情况下(例如，数据节点中的大容量acid事务)，您不希望在数据节点上执行任何计算。在这种情况下，您可以通过创建相应的集群组来选择只在客户端节点上执行作业。通过这种方式，您可以在一个网格中将数据节点与计算节点分开。可以使用以下伪代码对客户端进行计算:

ClusterGroup clientGroup = ignite.cluster().forClients(); IgniteCompute clientCompute = ignite.compute(clientGroup);
// Execute computation on the client nodes. clientCompute.broadcast(() -> System.out.println("sum of: " + (2+2)));

这种方法有一个缺点。使用这种方法，数据将被分配给独立的节点，并且为了计算这些数据，所有的客户端节点都需要从服务器节点检索数据。它可以产生大量的网络连接并产生延迟。但是，您可以在一个主机上单独的JVM上运行客户机和服务器节点，以减少网络延迟。从部署的角度来看，Apache Ignite服务器可以分为以下几个组：

• 内置应用程序