Skip to end of metadata
Go to start of metadata

       在UFLO2中简化了集群部署方式,对于我们开发好的应用来说,如果需要集群部署,需要做两件事情:一件是替换UFLO中默认基于内存的缓存服务;另一件就是配置一些集群参数。我们先来看看如何替换UFLO中默认基于内存的缓存服务。

替换缓存服务

 

       要替换UFLO中默认基于内存的缓存服务,我们只需要编写一个com.bstek.uflo.service.CacheService接口实现类,并将其配置到Spring中即可。CacheService接口源码如下:

CacheService接口源码

       在实现这个接口时,我们可以将所有的缓存信息存储到一个缓存服务器,比如Radis或MemoryCache等,然后将实现类开配置到Spring当中,这样UFLO在启动时即可检测到这个实现类的存在,从而替换其默认的放在内存中的缓存实现类。

       下面是一个CacheService实现类,它连接了Redis将流程相关信息缓存到Redis服务器。

连接Redis服务器的CacheService接口实现 类源码
SerializeUtils类源码

 

配置集群参数

       在UFLO中允许我们在任务节点上配置各种类型的提醒(任务到达提醒、过期提醒等),一旦我们配置了提醒,那么在产生提醒的任务时,UFLO会自动运行JOB引擎,在后台周期性执行这些提醒任务。在集群环境下,如果我们也使用了任务中的各种提醒,那么就需要在项目中配置一些集群参数,从而实现多个集群实例下,只有一个实例运行JOB引擎,同时一个实例的JOB引擎宕机后,其它实例能检测到,并继续运行JOB引擎,从而保证任务提醒功能的正确运行。

       集群环境下,我们需要在应用当中添加一个名为“uflo.clusterInstanceNames”的参数,该参数的作用是用来指定当前集群实例的名字,实例名之间用“,”号分隔,比如“uflo.clusterInstanceNames=app1,app2,app3”,这就表示当前应用集群部署有三个实例,我们分别将其命名为app1,app2,app3,这个参数配置完成后,我们还需要在每个集群实例对应的appServer上配置一个名为“uflo.instanceName”的JVM参数,该参数配置好后,在当前appServer的应用中就可以通过System.getProperty("uflo.instanceName")方法获取到,需要注意的是“uflo.instanceName”参数的值与“uflo.clusterInstanceNames”属性的值需要对应起来,比如实例A上我们定义“uflo.instanceName”参数为"app1";实例B上我们定义“uflo.instanceName”参数为"app2";实例C上我们定义“uflo.instanceName”参数为"app3"。这样在部署到JOB引擎会首先在uflo.instanceName”参数为"app1"的实例A应用服务器上运行;如果实例A应用服务器因为某些原因宕机,那么实例B应用服务器将会继续运动JOB引擎,依次类推。

宕机后下一实例运行间隔

实际运行时,实例A所在应用服务器如果宕机,实例B所在应用服务器大约会在90秒左右时间检测到,并在实例B所在的应用中启动JOB引擎继续运行各种类型的任务提醒JOB。

 

       下图是配置在Eclipse中Jetty的JVM参数“uflo.instanceName”的配置方式:

       添加JVM参数需要以-D开头,所以上图中可以看到“uflo.instanceName”参数定义时写为-Duflo.instanceName=app1,表示定义一个JVM参数“uflo.instanceName”值为“app1”。

       如果是采用Tomcat,那么可以切换到Tomcat安装目录下的bin目录,打开其中的catalina.bat文件(windows下Tomcat配置),查询"set JAVA_OPTS"字符串位置,在其后添加-Duflo.instanceName值即可,如下图:

       在上图中我们定义了JVM参数“uflo.instanceName”值为“app2”。

 

 

Labels
  • No labels