Apache Ignite（六）：Ignite的集群部署

Ignite的集群部署

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

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嵌入应用内部以服务端模式运行，经过逻辑集群组进行资源的分配，总体上造成更大的集群，大致是以下的部署模式： 这种模式更为灵活，调优后能作到成本、功能、性能的平衡，综合效果最佳。这时能够将缓存的数据经过集群组部署到应用外部的节点上，这样能够避免频繁的冷启动致使缓存数据频繁的长时间加载，对于计算，也可以动态地充分利用全部计算节点的资源。