這是關於如何在Ignite內存數據網格之上設計和實現微服務架構的系列文章的最後一篇,前兩篇文章以下:java
最後一篇文章描述的是集羣如何與持久化存儲集成以及外部應用如何發請求給微服務 -- 應用與集羣無關也不會依賴Ignite的API。node
這裏還會提到第二部分中介紹的GitHub工程,所以,要確保將其檢出到本機而且更新到最新版。git
Ignite是一個內存數據平臺,默認將數據保持在內存中。然而,也能夠將其持久化到磁盤上。好比但願確保即便集羣重啓數據也不會丟失。 要開啓持久化,只須要解決三個小事情:github
就這麼多了!作完以後,第一部分中描述的數據節點,就會與持久化存儲進行交互,以下圖所示:數據庫
要強調的是,若是內存中的數據發生變動,數據會被自動地傳播到磁盤上,或者若是內存中沒有對應該主鍵的值,會即時從持久化中進行數據的預加載。 下面看一下基於這個GitHub工程,如何爲微服務架構實現以及插入一個自定義的持久化存儲。apache
爲了演示方便,建立了一個虛擬持久化存儲實現,它實際上將數據存儲在一個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的日誌窗口,就能夠看到相似下面這樣的一個字符串:app
>>> 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都已經解決了。