ESFramework介绍之(20)―― 插件自动升级

    当我们的服务平台搭建成功后,所需要做的主要事情就是开发服务端功能插件(IFunAddin)和客户端插件(IPassiveAddin),每个插件对(AddinPair)实现了一组相似或相近的需求/功能。

    好了,我们已经开发了十多对插件对,然后分别XCopy到了各个服务器节点上,“整个系统”已经投入了运行。通过前面的介绍(回顾),相信大家对我们的“整个系统”有了个大致的映像。我们的IRAS服务器通常只存在于一个节点上,而我们的AS和对应的多个FS通常分布在非常多个节点上(比如每个大中城市都分配一个AS),而且这些节点相距非常遥远,深圳AS位于深圳、上海AS位于上海、武汉AS位于武汉等等。整个系统非常正常稳定的运行了一段时间后,某一天,用户要求增加一个新功能,这时你说,“非常简单,只需要开发一个对应的功能插件和客户端插件即可”。是的,对开发来说确实只需要这样,但是对于部署了?你需要“跑到”每个节点上安装新的功能插件,你也需要“跑到”所有的客户端那里安装新的客户端插件。安装是很容易的,XCopy就行了,但是,你“跑”得过来吗?

    看来,插件能够自动升级、自动加载/运行是非常重要的。手动进行这些工作,不仅效率低、而且非常容易出错。好了,我们来看ESFramework是如何对插件自动升级进行支持的。
    插件自动升级包括以下几个方面的意思:
(1) 当发现有更新版本的插件时,下载新版本插件覆盖旧版本插件。(插件版本升级)
(2) 当发现有原来没有的插件时,下载新插件。(添加新功能)
(3) 当发现原来的某插件在标准的插件目录中已经不存在时,删除本地对应的插件。(删除某项功能)

    AddinUpgradeType枚举反映了以上几种情况。

    public enum AddinUpgradeType
    {
        Add ,Remove ,Update ,Keep //keep 表示不需更新
    }

    我们需要在某个地方保存“标准的插件目录”信息,这通常是位于CommonDb(公共数据库,每个AS、FS、IRAS都可以访问)。标准插件目录中存储了每个插件的最新版本信息,这些信息由AddinVersionInformation类表示:

1     public class AddinVersionInformation
2     {
3         public int     AddinKey ;
4         public float NewVersion ;
5         public bool  Valid ;
6         public string AddinFileName ;
7     }

    插件的自动升级由IAddinUpgrador支持,每当启动升级过程时,IAddinUpgrador的工作步骤如下:
(1) 获取标准目录中的所有插件信息,并与本地的插件信息相比较,得到一个AddinUpgradeContent集合,集合中的AddinUpgradeContent对象反映了对某个插件应该进行怎样的操作――下载新版本覆盖、删除、下载新添加的插件。        AddinUpgradeContent定义如下:

1     public class AddinUpgradeContent
2     {
3         public int AddinKey = -1 ;
4         public AddinUpgradeType UpgrageType = AddinUpgradeType.Keep;
5         
6         public string AddinFileName ;//下载插件后存储于本地的名称
7     }

(2) 对于每个AddinUpgradeContent,IAddinUpgrador进行审查,并根据UpgrageType执行对应的操作。
    比如是覆盖本地的插件,则IAddinUpgrador首先会删除本地存储介质上的插件,然后下载新版本插件到本地,接着要求IAddinManagement从内存中动态移除对应的插件,最后,命令IAddinManagement加载新版本的插件。这里存在一个插件动态替换的问题,大家可以通过链接进行了解。

(3) 将升级成功/失败的信息输出、或记录到日志中。

    IAddinUpgrador接口定义如下:

    public interface IAddinUpgrador
    {
        IAddinUpgradeHelper  AddinUpgradeHelper{set ;}        
        IAddinManagement     AddinManagement{set ;}        
        string                 LocalAddinDirectory{set ;}

        IAddinUpgradeMsgOutputer AddinUpgradeMsgOutputer{set ;}

        void StartUpgrador() ;
    }

    public interface IAddinUpgradeHelper
    {
        string GetAddinUrl(int addinKey) ;
        AddinVersionInformation[] GetAddinVersionNew() ;
    }

    public interface IAddinUpgradeMsgOutputer
    {
        void PutoutMsg(string msg) ; //用于记录升级成功、异常等信息
    }

    关于IAddinUpgrador的实现,大家可以参考发布的ESFramework源码中的Addin目录。

    在我们的FS或客户端程序中(因为这两个地方需要实现插件自动升级),我们通常设置一个定时器,每隔一段时间就调用IAddinUpgrador. StartUpgrador()方法一次,来实现自动升级过程。

    这里讲的是插件自动升级的过程,如果我们的服务平台发生了改变,AS、FS需要升级,该如何处理?其实思想与本文是差不多的,这将在下篇文章中介绍。
    感谢关注!

上一篇文章:ESFramework介绍之(19)―― 对动态组ActiveGroup的支持

转到  :ESFramework 可复用的通信框架(序)

 

 

时间: 2024-07-30 01:54:33

ESFramework介绍之(20)―― 插件自动升级的相关文章

ESFramework介绍之(22)―― 服务器系统自动升级

    (本文名字取为"服务器系统自动升级",实际上适用于所有应用程序自动升级的情况.)    前文介绍了在服务器或客户端应用程序运行的过程中,插件如何自动升级.更新.基于前文相同的理由,AS.FS.IRAS也需要有自动升级的功能.     与插件在运行时动态更新不同,服务器系统无法在运行时动态更新,只有在服务器系统重新启动的时候,才是自动升级的切入点.(1)对于功能服务器FS,可以采用持续/逐个更新的方式,即依次重启每个功能服务器.这样可以避免功能服务被中断的情况发生.需要注意的是,

CS结构软件自动升级实现(一)

前段时间做了一个工具发布给公司的各部门使用后反馈了不少BUG,每次修改后均需要发邮件通知各用户替换最新版本,很不方便,因此后来就写了一个自动升级的功能,这样每次发布新的版本时只需要将其部署到自动升级服务器上,工具使用用户运行工具时就会连接到自动升级服务器,检查是否有版本更新,如果有则完成更新后再运行最新版本,否则就运行当前工具版本. 为了使这个自动升级模块具有通用性,我将其做成可以单独运行的程序,而并非集成到工具中,这样则可以为各类软件提供自动升级的功能.自动升级模块采用SOCKET方式实现升级

ESFramework介绍之(8)-- 客户端插件IPassiveAddin

    前文已经提到了,在IServerAgent的基础上,客户端也可以采用插件的结构形式,客户端插件需要实现IPassiveAddin接口.    我的想法是,当客户端主程序加载一个新的PassiveAddin时,可以在某个菜单的子Items上添加一项,当双击这个子菜单项时,则弹出该客户端插件提供的"业务操作窗体".这只是使用客户端插件的可行方式之一,你完全可以根据你的应用来决定使用形式.IPassiveAddin接口定义如下:  1     /// <summary> 

ESFramework介绍之(13)-- 功能插件处理器工厂

    上文讲述的是AS中的基于连接池的消息处理器,现在我们把焦点转移到功能服务器FS上来,看看FS上消息分派的过程.当FS接收到到一个请求后,会从已加载的功能插件列表中选择一个合适的插件来处理这个消息,而每一个功能插件就相当于一个消息处理器.FS和AS的结构一致:    要注意的是,功能服务器FS上收到的所有消息都应该交给功能插件来处理,不存在其它的处理方式.这是使得FS"纯粹"的必须要求.上图已经很清楚的表示了功能插件处理器工厂的位置和作用.它借助插件管理器实现"工厂&q

ESFramework介绍之(9)-- 插件对(Addin Pair)调试“框架”

    使用ESFramework开发C/S(通常为4层.3层也没问题)应用,当需要增加一项新的业务时,我们需要做的仅仅是开发两个插件,一个是服务端的业务功能插件(FunAddin),一个是客户端插件(PassiveAddin),这两个插件合在一起称为Addin Pair.开发这两个插件,只需要关注于业务,而其它与业务无关的比如网络通信.加密.数据安全,都不用管.ESFramework很好的将这些关注点分离开来,使得写"业务"插件的程序员的工作变得非常单纯,在ESFramework介绍

ESFramework介绍之(29)―― 插件公共设施 AddinUtil

    (本文适用于 ESFramework V0.2+)    不知你是否还记得,前面我们讲过,ESFramework规定了插件有如下特点: (1)一个插件是一个独立的物理单元.它可以独立的提供一项完整的服务(功能),而不需要依赖于其它插件. (2)插件能自我描述 ―― 插件的所有对外的发布信息都由插件自己内部提供,而不依赖于外部文件或注册表. (3)插件能自我管理 ―― 插件如果需要配置信息,则插件自己能读取和修改配置信息,而不是框架来完成这些事情.(4)插件自我独立   ―― 一个插件不得

ESFramework介绍之(26)-- 支持复杂插件(InnerDealer 和 InnerDispatcher)

    (本文内容适合于 ESFramework V0.2+)    通常,最单纯的情况是一个插件对应某一特定类型的功能请求,但是,在有的应用中也会出现这样的情况,有多种类型的功能请求相互关联.并且可能交叉,如果是这样,对应每种类型的请求都开发一个插件可能会非常困难,因为这可能会牵涉到插件之间的相互引用/访问,这违背了插件的"自治"性.最好的办法还是将它们放在一个插件中,通过ServiceItemIndex(你一定还记得消息头定义中除了ServiceKey外还有个ServiceItem

基于C/S的4层架构 —— ESFramework介绍之(6)

    ESFramework的4层结构的4层分别是:客户端(Client).应用服务器(AS).功能服务器(FS).数据库服务器.它们之间的联系图示意如下:     FS (FunctionServer),功能服务器,处理并且仅处理所有的功能性请求,不参与用户管理.状态保持等,提供最纯粹的功能服务.    AS (ApplicationServer),应用服务器,转发所有的功能请求给FS,并处理所有的非功能请求,并管理终端用户.进行状态保持.日志记录等.    上图中的功能服务器FS的个数可能

自动升级系统的设计与实现(源码)

(最新OAUS版本请参见:自动升级系统OAUS的设计与实现(续)) 对于PC桌面应用程序而言,自动升级功能往往是必不可少的.而自动升级可以作为一个独立的C/S系统来开发,这样,就可以在不同的桌面应用中进行复用.基于ESFramework的文件传送功能,我实现了一个可直接复用的自动升级系统OAUS,现在将其分享给大家.这篇文章将着重介绍OAUS的相关背景.使用方法,至于详细的实现细节,大家可以直接下载源码研究.如果了解了OAUS的使用,源码的理解就非常容易了.如果需要直接部署使用自动升级系统,那么