在Ignite上運行微服務：第一部分

在Ignite上運行微服務：第一部分

從本文開始，會經過一個系列的篇幅來介紹使用Apache Ignite內存數據組織平臺來構建容錯、可擴展的基於微服務的解決方案。

介紹

當前，不少公司都會將本身的應用或者解決方案構建於微服務架構之上，這樣作的主要好處是，能夠將一個解決方案拆分爲一組鬆耦合的軟件組件（微服務）。這些軟件組件可能有本身的版本以及生命週期，甚至有本身的開發團隊。此外，這些軟件還可能使用不一樣的語言和技術來開發和維護。可是由於全部的微服務都會是更大的構件（軟件或者解決方案）的一部分，因此它們至少須要一個機制來進行彼此的交互和數據交換。

同時，基於微服務的解決方案也會用於高負載或者須要處理快速增加的數據的場景，所以和不是基於微服務的應用和解決方案同樣，它也會面臨一樣的問題和困難。

• 面向磁盤的數據庫已經沒法跟上快速增加的數據量，這些數據須要以並行的方式進行存儲和處理，數據庫正在成爲整個應用或者解決方案的性能瓶頸；
• 軟件的高可用性保證做爲一個好功能已經成爲過去式，當前，應用的高可用性已經成爲事實上的標配。

從本文開始，會經過一個系列的篇幅來一步步地介紹使用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客戶端鏈接進行鏈接），這方面都很大的靈活性以及多樣化的選擇。

未完待續

這個架構具備水平擴展的能力，能夠在內存中保存數據集，微服務也具備高可用的特性。在之後的文章中，會經過一個示例來展現如何實現這個設計，敬請期待。

本文譯自Denis Magda的博客。