这是关于如何在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都已经解决了。