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嵌入應用內部以服務端模式運行，經過邏輯集羣組進行資源的分配，總體上造成更大的集羣，大致是以下的部署模式： 這種模式更爲靈活，調優後能作到成本、功能、性能的平衡，綜合效果最佳。這時能夠將緩存的數據經過集羣組部署到應用外部的節點上，這樣能夠避免頻繁的冷啓動致使緩存數據頻繁的長時間加載，對於計算，也可以動態地充分利用全部計算節點的資源。