从本文开始，会通过一个系列的篇幅来介绍使用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服务的服务节点；
• 一个连接到集群并且触发服务执行的虚拟应用。

微服务位于内存数据网格架构之上时的数据节点

正如第一篇中提到的，数据节点是持有数据集一部分数据的服务端节点，应用逻辑端会在这个数据集上执行查询和计算。通常来说，这种类型的节点对应用逻辑是透明的，因为这些节点只是简单地存储数据集，然后当应用访问数据时高效地进行处理就可以了。

下面会看一下在实现层面如何定义一个数据节点。

可以下载这个GitHub项目然后找到 data-node-config.xml，它会用于创建一个新的数据节点，这个配置包含了一组与数据节点有关的段落和参数。

首先，需要为每一个要部署到集群中的Ignite缓存配置一个特定的节点过滤器。这个过滤器会在缓存启动时被调用，它会定义一个要存储缓存数据的集群节点的子集--数据节点。同样的过滤器在网络拓扑发生变化时也会被调用，比如新节点加入集群或者旧节点离开集群。过滤器的实现需要加入每个节点的类路径中，不管该节点是否会成为数据节点。

<bean class="org.apache.ignite.configuration.CacheConfiguration">
...
  <property name="nodeFilter">
    <bean class="common.filters.DataNodeFilter"/>
  </property>
</bean>

第二，实现过滤器，在本例中，使用了一个非常明确的实现，DataNodeFilter，它通过检查data.node参数来确定一个节点是否会被视为数据节点。如果一个节点在属性映射中配置了这个参数，那么他会成为一个数据节点然后数据会驻留于此，否则该节点会被忽略。

 public boolean apply(ClusterNode node) {
  Boolean dataNode = node.attribute("data.node");
  return dataNode != null && dataNode;
}

第三，data-node-config.xml为每个使用这个配置启动的节点的属性映射添加了data.node属性，就像下面这样：

<property name="userAttributes">
  <map key-type="java.lang.String" value-type="java.lang.Boolean">
    <entry key="data.node" value="true"/>
  </map>
</property>

最后，通过使用示例中的DataNodeStartup文件，或者将data-node-config.xml传递给Ignite的ignite.sh/bat脚本来启动一个数据节点的实例。如果选择了后者，那么一定要将java/app/common目录中的所有类文件构建成一个jar包，然后还要将这个jar文件加入到每个数据节点的类路径中。

微服务位于内存数据网格架构之上时的服务节点

在实现层次上服务节点的定义与前述数据节点的用法没有什么大的不同。基本上，需要建立一个方式，即指定一个特定的微服务将要部署在哪些节点上，它们会是整个集群的一个子集。

最初，需要使用服务网格API实现一个微服务，为后文起见，可以回顾一下那个GitHub示例中的已有服务实现，即Maintenance Service。

这个服务可以调度一个车辆维护的服务，并且可以查看已做保养的清单，它实现了所有服务网格的必要方法，包括init(...)，execute(...)以及cancel(...)，并且在这个接口中增加了新的方法：

 public interface MaintenanceService extends Service {
  public Date scheduleVehicleMaintenance(int vehicleId);
  public List<Maintenance> getMaintenanceRecords(int vehicleId);
}

将这个维护服务配置并且部署到特定的Ignite节点（服务节点）上有几种方式。在本例中，通过maintenance-service-node-config.xml启动的每个节点，都可以考虑进行维护服务的部署，下面可以看一下配置。

首先，确保维护服务的实例只会被部署到指定了节点过滤器的节点上：

<bean class="org.apache.ignite.services.ServiceConfiguration">
  <property name="nodeFilter">
    <bean class="common.filters.MaintenanceServiceFilter"/>
  </property>
</bean>

第二，维护服务使用的过滤器，只会被部署到在属性映射中配置了maintenance.service.node的节点上：

 public boolean apply(ClusterNode node) {
  Boolean dataNode = node.attribute("maintenance.service.node");
  return dataNode != null && dataNode;
}

最后，通过如下的XML片段，使用maintenance-service-node-config.xml启动的每个节点在映射中都会包含这个属性：

<property name="userAttributes">
  <map key-type="java.lang.String" value-type="java.lang.Boolean">
    <entry key="maintenance.service.node" value="true"/>
  </map>
</property>

就这些了，使用MaintenanceServiceNodeStartup文件，或者将maintenance-service-node-config.xml传递给Ignite的ignite.sh/bat脚本，就可以启动维护服务节点的一个或者多个实例，如果选择了后者，一定要确保将java/app/common和java/services/maintenance目录中的所有文件打包成一个jar文件，然后将这个jar文件添加到每个服务将要被部署的节点的类路径上。

示例中包含了另一个与车辆管理有关的Ignite服务，使用VehicleServiceNodeStartup文件或者使用经过vehicle-service-node-config.xml配置的ignite.sh/bat，可以启动至少一个部署有该服务的服务节点，如果选择了ignite.sh/bat方式，不要忘了组装一个jar文件然后将其加入相关节点的类路径上。

在内存数据网格之上运行微服务的示例应用

一旦准备好了数据节点，维护服务和车辆服务节点也都启动运行了，那么就可以运行第一个示例应用来访问这个分布式微服务了。

在示例中找到并且启动TestAppStartup，这个应用会接入集群，往预定义的缓存中注入虚拟数据，然后与服务进行交互。

MaintenanceService maintenanceService = ignite.services().serviceProxy(MaintenanceService.SERVICE_NAME,
MaintenanceService.class, false);
int vehicleId = rand.nextInt(maxVehicles);
Date date = maintenanceService.scheduleVehicleMaintenance(vehicleId);

如果注意了，应用会使用服务代理来与服务进行交互，代理的好处就是，启动应用的节点不需要在本地类路径中持有服务的实现，也不需要在本地部署一个服务。

-----------

描述的是集群如何与持久化存储集成以及外部应用如何发请求给微服务 -- 应用与集群无关也不会依赖Ignite的API。

这里还会提到第二部分中介绍的GitHub工程，因此，要确保将其检出到本机并且更新到最新版。

数据节点的持久化存储

Ignite是一个内存数据平台，默认将数据保持在内存中。然而，也可以将其持久化到磁盘上。比如希望确保即使集群重启数据也不会丢失。 要开启持久化，只需要解决三个小事情：

1. 决定使用什么技术作为持久化存储（关系数据库、MongoDB、Cassandra、Hadoop等等）；
2. 找到一个已有的CacheStore接口实现，或者如果有必要也可以自己开发一个；
3. 将实现加入缓存配置中。

就这么多了！做完之后，第一部分中描述的数据节点，就会与持久化存储进行交互，如下图所示：

要强调的是，如果内存中的数据发生变更，数据会被自动地传播到磁盘上，或者如果内存中没有对应该主键的值，会即时从持久化中进行数据的预加载。 下面看一下基于这个GitHub工程，如何为微服务架构实现以及插入一个自定义的持久化存储。

为了演示方便，创建了一个虚拟持久化存储实现，它实际上将数据存储在一个ConcurrentHashMap中，这个演示只是为了说明，如果需要创建一个自定义的持久化存储实现，Ignite基本上只需要实现三个方法：

 /** {@inheritDoc} */
public BinaryObject load(Long key) throws CacheLoaderException {
System.out.println(" >>> Getting Value From Cache Store: " + key);
return storeImpl.get(key);
}

/** {@inheritDoc} */
public void write(Cache.Entry entry) throws CacheWriterException {
System.out.println(" >>> Writing Value To Cache Store: " + entry);
storeImpl.put(entry.getKey(), entry.getValue());
}

/** {@inheritDoc} */
public void delete(Object key) throws CacheWriterException {
System.out.println(" >>> Removing Key From Cache Store: " + key);
storeImpl.remove(key);
}

下一步，在数据节点的配置中，通过在名为maintenance的缓存配置中添加一行代码，就可以开启这个自定义存储。

<property name="cacheStoreFactory">
  <bean class="javax.cache.configuration.FactoryBuilder" factory-method="factoryOf">
    <constructor-arg value="common.cachestore.SimpleCacheStore"/>
  </bean>
</property>

最后，要检查一下Ignite集群与持久化存储的通信，怎么做呢，在开发环境中打开GitHub工程然后启动一个数据节点的实例（DataNodeStartup文件），一个维护服务节点的实例（MaintenanceServiceNodeStartup文件）和一个车辆服务节点的实例（VehicleServiceNodeStartup文件）。所有节点互联之后，启动TestAppStartup，它会接入集群，注入数据然后调用服务。TestAppStartup执行完毕后，打开 DataNodeStartup的日志窗口，就可以看到类似下面这样的一个字符串：

 >>> Writing Value To Cache Store: Entry [key=1, val=services.maintenance.common.Maintenance [idHash=88832938, hash=1791054845, date=Tue Apr 18 14:55:52 PDT 2017, vehicleId=6]]

之所以显示这个字符串，是因为TestAppStartup触发了一个maintenance缓存的更新，它会自动地给前述虚拟持久化存储发送一个更新。

从外部应用接入

TestAppStartup是一个与部署在Ignite集群中的微服务进行交互的应用样例，某种意义上来说它是一个内部应用，因为它直接接入集群并且调用了服务网格的API。

但是对于外部应用来说，它不可能也不应该知道集群及其整体的部署，那么它怎么与微服务进行交互呢？一个简单的方案就是，Ignite服务以不同的方式监听来自外部应用的请求然后做出响应。

比如，当MaintenanceService的一个实例部署进集群后，它通过一个预定义的端口开启一个服务套接字来接收远程的连接（查看MaintenanceServiceImpl可以了解更多细节）。那么使用ExternalTestApp启动一个外部应用之后，它就会使用服务套接字与服务连接，然后获得每个车辆的维护调度，ExternalTestApp的输出大致如下：

>>> Getting maintenance schedule for vehicle:0
>>> Getting maintenance schedule for vehicle:1
>>> Getting maintenance schedule for vehicle:2
>>> Getting maintenance schedule for vehicle:3
>>> Getting maintenance schedule for vehicle:4
>>> Getting maintenance schedule for vehicle:5
>>> Getting maintenance schedule for vehicle:6
  >>> Maintenance{vehicleId=6, date=Tue Apr 18 14:55:52 PDT 2017}
>>> Getting maintenance schedule for vehicle:7
>>> Getting maintenance schedule for vehicle:8
>>> Getting maintenance schedule for vehicle:9
>>> Shutting down the application.

在这个系列中，展示了在Ignite集群中如何部署和维护一个基于微服务的解决方案。这个方案不需要关注微服务生命周期以及高可用性等事情，交给Ignite就行了，只需要关注实际业务逻辑即可。再者，所有的数据以及微服务都是在整个集群中分布的，这就意味着不用再担心性能和容错性-Ignite都已经解决了。

来源：https://my.oschina.net/liyuj/blog/892755

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服务器可以分为以下几个组：

• 内置应用程序
• 服务器在单独的JVM

1.相关概念

1.1.节点平等

Ignite没有master节点或者server节点，也没有worker节点或者client节点，按照Ignite的观点所有节点都是平等的。但是开发者可以将节点配置成master，worker或者client以及data节点。

1.2.发现机制

Ignite节点之间会自动感知，集群可扩展性强，不需要重启集群，简单地启动新加入的节点然后他们就会自动地加入集群。这是通过一个发现机制实现的，他使节点可以彼此发现对方，Ignite默认使用TcpDiscoverySpi通过TCP/IP协议来作为节点发现的实现，也可以配置成基于多播的或者基于静态IP的，这些方式适用于不同的场景。

1.3.部署模式

Ignite可以独立运行，也可以在集群内运行，也可以将几个jar包嵌入应用内部以嵌入式的模式运行，也可以运行在Docker容器以及Mesos和Yarn等环境中，可以在物理机中运行，也可以在虚拟机中运行，这个广泛的适应性是他的一个很大的优势。

1.4.配置方式

Ignite的大部分配置选项，都同时支持通过基于Spring的XML配置方式以及通过Java代码的编程方式进行配置，这个也是个重要的优点。

1.5.客户端和服务端

Ignite中各个节点是平等的，但是可以根据需要将节点配置成客户端或者服务端，服务端节点参与缓存，计算，流式处理等等，而原生的客户端节点提供了远程连接服务端的能力。Ignite原生客户端可以使用完整的Ignite API，包括近缓存，事务，计算，流，服务等等。 所有的Ignite节点默认都是以服务端模式启动的，客户端模式需要显式地启用，如下：

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="clientMode" value="true"/>
</bean>

2.创建集群

一个Ignite节点可以从命令行启动，可以用默认的配置也可以传递一个配置文件。可以启动很多的节点然后他们会自动地发现对方。 要启动一个基于默认配置的网格节点，打开命令行然后切换到IGNITE_HOME（安装文件夹），然后输入如下命令：

$ bin/ignite.sh

然后会看到大体如下的输出：

1.[02:49:12] Ignite node started OK (id=ab5d18a6)
2.[02:49:12] Topology snapshot [ver=1, nodes=1, CPUs=8, heap=1.0GB]

在嵌入式模式中，通过如下的代码同样可以启动一个节点：

Ignite ignite = Ignition.start();

3.集群组

从设计上讲，所有集群节点都是平等的，所以没有必要以一个特定的顺序启动任何节点，或者给他们赋予特定的规则。然而，Ignite可以因为一些应用的特殊需求而创建集群节点的逻辑组，比如，可能希望只在远程节点上部署一个服务，或者给部分worker节点赋予一个叫做worker的规则来做作业的执行。比如，下面这个例子只把作业广播到远程节点（除了本地节点）:

final Ignite ignite = Ignition.ignite();
IgniteCluster cluster = ignite.cluster();
IgniteCompute compute = ignite.compute(cluster.forRemotes());
compute.broadcast(() -> System.out.println("节点Id: " + ignite.cluster().localNode().id()));

Ignite内置了很多预定义的集群组，同时还支持集群组的自定义。可以基于一些谓词定义动态集群组，这个集群组只会包含符合该谓词的节点。下面这个例子，一个集群组只会包括CPU利用率小于50%的节点，注意这个组里面的节点会随着CPU负载的变化而改变:

IgniteCluster cluster = ignite.cluster();
ClusterGroup readyNodes = cluster.forPredicate((node) -> node.metrics().getCurrentCpuLoad() < 0.5);

4.集群配置

Ignite中，通过DiscoverySpi节点可以彼此发现对方，可以配置成基于多播的或者基于静态IP的。Ignite提供了TcpDiscoverySpi作为DiscoverySpi的默认实现，它使用TCP/IP来作为节点发现的实现。 对于多播被禁用的情况，TcpDiscoveryVmIpFinder会使用预配置的IP地址列表，只需要提供至少一个远程节点的IP地址即可，但是为了保证冗余一个比较好的做法是提供2-3个网格节点的IP地址。如果建立了与任何一个已提供的IP地址的连接，Ignite就会自动地发现其他的所有节点。 也可以同时使用基于多播和静态IP的发现，这种情况下，除了通过多播接受地址以外，TcpDiscoveryMulticastIpFinder也可以使用预配置的静态IP地址列表。 下面的例子，显示的是如何通过预定义的IP地址列表建立集群：

TcpDiscoverySpi spi = new TcpDiscoverySpi();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
// 设置预定义IP地址，注意端口或者端口范围是可选的。
ipFinder.setAddresses(Arrays.asList("1.2.3.4", "1.2.3.5:47500..47509"));
spi.setIpFinder(ipFinder);
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setDiscoverySpi(spi);
// 启动集群
Ignition.start(cfg);

5.零部署

和计算等有关的代码可能是任意自定义的类，在Ignite中， 远程节点会自动感知这些类，不需要显式地将任何jar文件部署或者移动到任何远程节点上。这个行为是通过对等类加载（P2P类加载）实现的，他是Ignite中的一个特别的分布式类加载器，实现了节点间的字节码交换。当对等类加载启用时，不需要在集群内的每个节点上手工地部署代码，也不需要每次在发生变化时重新部署。 可以通过如下方法启用对等类加载；

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="peerClassLoadingEnabled" value="true"/>
</bean>

6.云部署

对于很多的云环境，通常有多播被禁用以及IP地址不固定的限制，对于这种情况，Ignite提供了发现的扩展机制解决了该问题，并且内置了对于常见的云服务（比如AWS）的支持，本文不赘述，开发者可以参照相关的文档。

7.Docker等其他环境的部署

对于Docker、Mesos、Yarn等环境，Ignite同样支持，本文不赘述，开发者可以参照相关的文档。

8.部署实践

Ignite的部署模式非常的灵活，在实际的场景中可以针对实际需要采用不同的部署方式，下面做简单的总结和对比：

8.1.独立式Ignite集群

这种情况下，集群的部署完全独立于应用，这个集群可以用于分布式计算，分布式缓存，分布式服务等，这时应用以客户端模式接入集群进行相关的操作，大体是如下的部署模式：

优点 对已有的应用运行环境影响小，并且这个集群可以共享，为多个应用提供服务，对整个应用来说，额外增加了很多的计算和负载能力。 缺点 需要单独的一组机器，相对成本要高些，如果缓存操作并发不高或者计算不饱和，存在资源利用率低的情况。整体架构也变得复杂，维护成本也要高些。

8.2.嵌入式Ignite集群

这种情况下，可以将必要的jar包嵌入已有应用的内部，利用Ignite的发现机制，自动建立集群，大体是如下的部署模式：

优点 无需额外增加机器，成本最低，Ignite可以和应用无缝集成，所有节点都为服务端节点，可以充分利用Ignite的丰富功能。这个模式可扩展性最好，简单增加节点即可快速扩充整个系统的计算和负载能力。 缺点 Ignite占用了服务器的部分资源，对应用整体性能有影响，可能需要进行有针对性的优化，应用更新时，集群可能需要重启，这时如果Ignite需要加载大量的数据，重启的时间可能变长，甚至无法忍受。

8.3.混合式Ignite集群

这种情况下，将上述2种模式混合在一起，即同时增加机器部署独立集群，同时又将Ignite嵌入应用内部以服务端模式运行，通过逻辑集群组进行资源的分配，整体上形成更大的集群，大体是如下的部署模式：

这种模式更为灵活，调优后能做到成本、功能、性能的平衡，综合效果最佳。这时可以将缓存的数据通过集群组部署到应用外部的节点上，这样可以避免频繁的冷启动导致缓存数据频繁的长时间加载，对于计算，也能够动态地充分利用所有计算节点的资源。

来源： https://my.oschina.net/liyuj/blog/651036?p=1