一种服务优化的计算机系统及其方法
【专利摘要】一种服务优化的计算机系统及其方法，包含有:一分流器，提供多重分流机制以提供更适合请求分派及更佳的负载平衡，以及一服务平台，提供量化式热部署机制、保全机制、及模块分类管理功能。结合两者，可运用于分布式系统，提供自动实时(热)备援及永续服务的云端运算。
【专利说明】
一种服务优化的计算机系统及其方法
技术领域
[0001]本发明为一种服务优化的计算机系统及其方法，目前以Java程序语言企业版(Java 2 Platform,Enterprises Edit1n，J2EE)实现该方法(但不限定任何程序语言)，运用于云端技术，平台即服务(PaaS)Platform as a Service。
【背景技术】
[0002]分布式系统有很多不同的定义，一般认为:“一个分布式系统是一些独立的计算机集合，但是对这个系统的用户来说，系统就像一台电脑一样。”这个定义有两方面的含义:第一，从硬件角度来讲，每台计算机都是自主的；第二，从软件角度来讲，用户将整个系统看做是一台电脑。这两者都是必需的，缺一不可。云端运算Cloud Computing的本质其实就是分布式运算Distributed Computing。以现有的架构而言是由一循环分流器做为负载平衡器，将请求以轮替分式分派到应用服务器(AP Sever)，进言之，负载平衡算法包括有:LeastConnect1n(最少联机数)为依照联机数来判断，联机数越少代表该主机负载越低；Weighted Least Connect1n(加权式最小连接)与Least Connect1n相同，但是会再依据权重来做调整。Round Robin(轮循)以轮替式的方式做负载平衡，例如有三台真实主机，第一条联机导至第一台真实主机，第二条联机导至第二台真实主机，第三条联机导至第三台真实主机，第四条联机导至第一台真实主机，依此类推;Weighted Round Robin(加权式轮循)与Round Robin(轮循)相同，但是会再依据权重来做调整;Source Hash(来源哈希)以来源IP地址做为判断负载状况，当客户端主机联机至Virtual Server(虚拟服务器)时，会使用客户端主机的来源地址经由Hash函式，算出应由后端真实主机接受服务，而将联机导至该真实主机。而一般运行于应用服务器的程序架构是以MVC架构为基础，即将一程序分为视图层(View)及控制层(ControlIer)、商务逻辑层(BusinessLogic)及数据储存层(DAO)，而为了维持分布式系统提供优化维运服务，尚有以下议题。
[0003]1.热部署(Hot Deployment,Hot Swap):即模块程序更新时，系统不需停机，提供同样服务。一般系统程序开发皆以MVC架构为基础，而视图层(View)依规范，可自动重新编译，更新而不需重新开机故不需考虑;若将控制层设计为模块的单一入口，撰写该模块共享且极少变更的功能；则控制层亦不需因修改而部署，而最常需要变更的程序为商务逻辑层(BusinessLogic)、数据存取层(DAO)及其它相关档案，故需解决热部署的问题为此部分的程序。
[0004]1.1目前虽然J2EE有所谓热部署(Hot Deployment)的机制，可用以减少版本更新时的停机时间，但使用者仍需重新登入;又由于一般设计、开发时将各独立模块(子系统)合为壹模块，以致于热部署时，整个系统需要重新启动，因重新部署的程序太多而造成内存不足已致于无法运作(当机)[注:模块有时亦称为子系统，为功能的集合;壹模块为包括多个独立模块(子系统)且由同一个会谈(Sess1n)存取]。
[0005]1.2已知相似的发明尚有如中国申请号0吧01010114369实现软件系统热部署的方法及系统，其所提出的发明方法包括:(I)在软件系统中设置用以处理核心业务的第一业务处理引擎和第二业务处理引擎，该第一业务处理引擎连接对应的第一业务规则储存单元，第二业务处理引擎连接对应的第二业务规则储存单元；(2)设置第一业务处理引擎和第二业务处理引擎的其中之一为运行状态，另一个处于等待状态；(3)当软件系统的处理设置发生变化时，更新处于等待状态的业务处理引擎对应的处理设置;及(4)将处于等待状态的业务处理引擎设定为运行状态，并将原处于运行状态的业务处理引擎设定为等待状态。
[0006]简言之是以切换的方式来解决实现热部署，但与本案的方法不同。
[0007]1.4在中国专利申请号为200610123883.0的专利申请中提到一种实现热部署的方法，就是将升级前的服务器进行备份，同时对外提供服务，等升级完毕后再切换到升级后的web服务器，从而对外表现为热部署。但这种实现热部署的方法需要提供两台服务器来实现热部署。其不适之处有以下两点。
[0008]1.4.1将整个服务器备份为另一个服务器来实现热部署的方法，需要增设新的服务器，由此增加成本。
[0009]1.4.2引入开放式服务网关架构来实现热部署，需要将模式层设置在开放式服务网关架构的各个子模块当中，当模式层发生改变时，虽然web应用的类加载器能够实现热部署，但是开放式服务网关架构的各个子模块同样需要重新启动，不能完全意义上实现热部署。而且，需要对现有的系统进行大量的改动，存在稳定性不高、安全性差的问题，只适合在没有运行的业务系统上适用，不适合现已运行的系统上的应用(引用申请号CN201010114369 的论述)。
[0010]2.除热部署外，部署后的议题尚有二，新旧版本是否应同时并存，或只执行最新版本。
[0011]3.容错应用，一个单元或资源(软件或硬件)的故障或部署不影响其它资源的正常功能。故应该在部署时提供量化式部署(即可使壹模块分割后、量化为各自独立的模块，即以一类(别)加载器一模块的方式部署)。
[0012]4.为使系统的运行环境免于因部署、或因其它因素如:请求量迅增、某一请求不当执行等因素造成系统内存存量不足以致系统无法运作，故应提供监控机制以防止此问题发生，并且使模块可即插即用、自动扩充以保全系统的运行。
[0013]5.更佳的分散方式应可将商务逻辑层(BusinessLogic)及数据存取层(DAO)再予以分散至其它计算机，且能配合当代主流开发架构完成分散运算。
[0014]6.现有系统架构皆是设计以一循环(Round-Robin)分流器，将请求以轮替的方式分派至应用服务器，因无足够的信息，以致无法更精准达到负载平衡，以Least Connect1n(最少联机数)为例，若一联机带有大量数据处理，则Least Connect 1n的负载平衡并不准确;再以Round Robin(轮循)为例，若主机有两台，而请求所需处理的笔数依序为100笔，10笔，100笔，10笔，就会造成分派不均的情况。
[0015]7.应能提供特定族群专属的执行环境(如专属的CPU或CPU的核心、内存空间)。
[0016]8.应能提供系统开发人员分类管理模块并升级模块程序库的功能。
【发明内容】
[0017]本案的目的在于提供一种服务优化的计算机系统及其方法，即能对一般使用者提供多重分流以达更佳的负载平衡，亦能对系统开发人员提供热部署(包括模块的新增、移除以及修改)、以及热备援以达永续服务的系统，以及优化模块分类管理功能。
[0018]本案主要以分流器及服务平台的组合而提供一种服务优化的计算机系统，分流器的结构为一选择器、一平台注册中心、一网络服务器;服务平台的结构为一量化式部署器、一模块过载保全机制、一零请求监控机制、一热部署监控机制、一信息记录器、一服务平台目录、一请求过载保全机制及一网络服务器。
[0019]分流器藉由平台注册中心所提供的服务平台信息及模块信息以提供分流策略达成更佳的负载平衡;服务平台提供保全机制使得在部署及请求时，免于因服务平台内存存量不足而无法运作，而且以量化式(热)部署器部署模块以缩短部署时间，并加入一信息通知器以同步服务平台信息及模块信息于平台注册中心，使分流器得以运用热部署模块名称关联相同功能的模块及版本，以分流策略中最新版本分流方式达成永续服务;并在分流器中加入一平台监控机制以提供热备援机制及服务平台中加入一模块程序库优先机制、一模块分类管理机制以达成服务优化的计算机系统。
[0020]接下来，以实施方式藉由介绍分流器结构及其运作方式，所提供的相关机制及功能;服务平台结构及其运作方式，所提供的相关机制及功能，并通过请求过程说明分流器及服务平台如何达成永续服务及服务优化的理由。
【附图说明】
[0021]图1:是分布式系统架构及运作示意图。
[0022]图2:是分流器结构及其运作示意图。
[0023]图3:是服务平台结构及运作示意图。
[0024]图4:是服务平台目录结构图。
[0025]图5:是请求过程及请求保全机制运作示意图。
【具体实施方式】
[0026]请参考图1:分布式系统架构及运作示意图，此图是藉由现有的组件及开发架构加以改良而成。现有的元件包括有:一网络应用程序(客户端)、一循环分流器(Round-Robin)(伺服端)、一网络服务器(伺服端)，并将本发明的元件分流器及服务平台分别安装在个别的网络服务器，以及将现有开发架构的非视图层及控制层的程序及相关档案移至服务平台执行，而成为分布式系统架构，并提供服务优化的计算机系统。其能提供服务优化的理由有以下七点。
[0027]—、提供服务平台内存存量管控机制，以保全系统运作。
[0028]二、提供多种分流策略，以达更精准的负载平衡。
[0029]三、提供特定族群专属的执行环境(如专属的CPU或CPU的核心、内存空间)。
[0030]四、提供自动实时(热)备援的机制，增强系统的服务，以保全系统运作。
[0031 ]五、提供模块分类管理功能并升级模块程序库的功能。
[0032]六、提供服务不中断(热部署及请求时皆能保全系统运作，但有瞬时即逝的暂停服务)。
[0033]七、提供永续的服务(热部署及请求时皆能保全系统运作且持续服务)。
[0034]而能实现上述的功能，主要是本发明的元件:一分流器及一服务平台。
[0035]请参考图2:分流器结构及其运作示意图，分流器，包含有:一选择器、一平台注册中心、一平台监控机制及网络服务器(现有元件)。
[0036]1.选择器:用以依分流策略，分派请求。
[0037]2.平台注册中心:用以提供登录或同步服务平台及模块信息的记录。
[0038]3.平台监控机制:用以监控服务平台状态，并依设定自动启动备援服务平台。
[0039]4.网络服务器:用以安装并启动分流器，以使分流器可接收请求，为一现有组件。
[0040]5.运作方式:藉由网络服务器的启动，读取分流器配置文件各参数值(请参考分流器配置文件说明)，并启动分流器，创建选择器及平台注册中心以待服务平台及模块注册，在注册完成后，启动平台监控机制，等待请求。
[0041]注:网络服务器为一上位概念，为一可接收请求的服务器或容器，可为应用服务器、EJB容器等等。
[0042]请参考图3:服务平台结构及其运作示意图，服务平台，包含有:一模块管理员，包含有:1.量化式部署机制、2.模块程序库优先机制、3.模块过载保全机制、4.零请求监控机制、5.热部署监控机制、6.信息记录器、7.信息通知器、8.模块委任机制、9.请求过载保全机制(请求超时超量保全机制及请求量迅增保全机制)，及一网络服务器(现有组件)。
[0043]丨.模块管理员:
[0044]1.1.量化(细粒化)部署机制:用以进行各种模式的部署(请参考部署模式说明)，使设计者可依模块功能或数量，规划出独立的模块(单一功能至多个功能)，其用意在于使系统的各功能模块可依相互独立、完全穷尽(MECE)的思考原则下设计，促使各模块独立，以利于移植、安装并缩短启动时间。
[0045]1.2.模块程序库优先机制:用以优先取得不同版本的相同程序库，相较于存在共享程序库目录下相同程序库，有利于让新模块得以使用新版程序库部署而不影响原系统运作，有助于系统技术升级。
[0046]1.3.模块过载保全机制:用以保全服务平台免于部署时因服务平台内存存量不足而无法运行。
[0047]1.4.零请求监控机制:用以防止因模块需要重新部署或移除而中断尚在执行中的请求。
[0048]1.5.热部署监控机制:用以监控运行中的模块及模块目录的相关档案异动以及模块的新增，并调用量化式部署机制完成热部署。
[0049]1.6.信息记录器:用以提供于量化式部署机制及热部署监控机制记录平台信息及模块信息。
[0050]1.6.1平台信息，包含有:服务平台名称、状态、服务平台内存存量、服务平台地址、服务平台保全定量、模块部署预估量、平台注册中心地址、请求过载保全定量、请求期限定量、及模块监控间隔时间。
[0051 ] 1.6.2模块信息，包含有:模块名称(实体名称)、版本、模块状态、类别加载器、待请求总笔数、待请求处理总笔数、热部署模块名称(逻辑名称)、模块实际部署所需量等信息。
[0052]1.7.信息通知器:用以向平台注册中心登录及同步服务平台及模块信息，由量化式部署机制、热部署监控机制及请求过载保全机制所触发。
[0053]1.8.模块委任机制:用以将请求委任该模块执行请求。
[0054]1.9.请求过载保全机制:用以保全系统免于因请求过载而无法运行。
[0055]2.网络服务器(现有组件):用以安装并启动服务平台，以使服务平台可接收请求。
[0056]3.运作方式:藉由网络服务器的启动读取服务平台配置文件各参数值(请参考服务平台配置文件说明)，依初始化部署(流程)，完成模块的初始化而成为运行中的模块，并同步服务平台及模块信息于信息记录器(平台/模块)，之后启动热部署监控机制，以执行监控部署(流程)，而完成服务平台的启动。启动后，等待客户端请求或触发信息通知器藉由平台注册中心地址登录服务平台及模块信息，并使分流器利用服务平台地址与该服务平台建立连接，而完成服务平台及模块的注册，等待由分流器分派请求。
[0057]注:服务平台的网络服务器可由分流器启动或人工启动；分流器与服务平台亦可安装于同一台网络服务器，为分散系统的缘故而分别安装于不同的网络服务器。
[0058]接下来说明服务平台的初始化部署(流程)、监控部署(流程)、请求过程以及保全机制，并藉此说明服务优化的各点理由。
[0059]请参考图3:服务平台结构及其运作示意图、图4:服务平台目录结构图。
[0060]1.初始化部署(流程):量化式部署机制依部署模式在系统目录下的平台目录，依序搜寻各模块(即图3中系统目录/平台目录下的MA、MB、MC、MD)并依目录层次及目录名称的关系及服务平台名称创建各模块的名称，之后以模块程序库优先机制建立各模块档案信息(依序为模块程序集合、热部署版本档案、模块档案集合、模块程序库集合以及共享程序库集合)后，创建各模块的类别加载器，并通过模块过载保全机制的检核以完成部署，完成后，同步该平台信息及其所有模块信息，并启动热部署监控机制。
[0061]运作状态说明:
[0062]1.1依据服务平台保全定量及模块部署预估量的设定，由模块过载保全机制判断目前系统内存存量是否足以完成部署。
[0063]1.1.1若足够则启动且设定该模块状态为启动中，完成部署后设定模块状态为运行中(即图3中运行中的模块MA、MB、MC、MD)且同步该模块信息。
[0064]1.1.1.1若启动失败，则设定该模块状态为待启动(由热部署监控机制再启动)且同步该模块信息。
[0065]1.1.2若不足够则不启动，并设定该模块状态为待启动(由热部署监控机制再启动)且同步该模块信息。
[0066]注:1.同步平台信息及模块信息的对象为信息记录器及平台注册中心。
[0067]2.藉由模块程序库优先机制升级模块程序库的功能。
[0068]2.监控部署(流程):热部署监控机制于平台目录中依序监控搜寻各模块的模块程序集合、模块档案集合、模块程序库集合及共享程序库集合是否异动、或已移除并监控检查运行中的各模块的模块状态，藉由量化式部署机制、模块程序库优先机制、模块过载保全机制及零请求监控机制完成重新部署或移除以及模块的新增，在完成所有模块检查后，同步该平台信息及其所有模块信息，并依模块监控间隔时间再监控。
[0069I运作状态说明:
[0070]2.1若该模块状态待启动，则依步骤1.1重新部署该模块。
[0071 ] 2.2若该模块目录为新增，则依步骤1.1部署该模块。
[0072]2.3若该模块目录已移除且无请求，则设定模块状态为待移除且立即同步该模块信息后执行移除该模块，完成后，设定模块状态为已移除立即同步该模块信息。
[0073]2.3.1若有请求则设定该模块状态为待移除(请求中)且立即同步该模块信息，在该模块的请求都已执行完成后(零请求)执行移除该模块，完成后，设定模块状态为已移除立即同步该模块信息。
[0074]2.4若该模块相关档案异动且无请求，设定该模块状态为待更新且立即同步该模块信息后依步骤I.I重新部署该模块，并在完成部署设定该模块状态为运行中且立即同步该模块信息。
[0075]2.4.1若有请求则设定该模块状态为待更新(请求中)且立即同步该模块信息，使其不得再接受请求，在该模块的请求都已执行完成后(零请求)，执行该模块的重新部署，并在完成部署设定该模块状态为运行中且立即同步该模块信息，以接收请求。
[0076]注:藉由监控部署(流程)达成提供服务不中断。
[0077]请参考图5:请求过程及请求保全机制运作流程图。
[0078]3.在请求时，选择器藉由请求信息(热部署模块名称、版本、服务范畴名称、请求处理笔数、请求内容)的热部署模块名称(逻辑名称)，至平台注册中心，在相同的热部署模块名称中依所设定的分流策略(依最新版、或依指定版本、或依服务范畴、或依待请求处理总笔数最少、或依待请求总笔数最少、或依服务平台内存存量存量最多、或依上述分流策略组合)选择状态为运行中的模块名称及服务平台地址。
[0079]再将模块名称、请求内容、请求处理笔数，藉由服务平台地址转传至该模块的服务平台，并藉由模块委任机制，以模块名称于信息记录器中，取得该模块执行请求，并将累计请求数及累计请求处理笔数记录于信息记录器中，在请求完成后，扣除该请求笔数及该请求处理笔数，同时取得服务平台记忆存量并将请求结果、待请求处理总笔数、待请求总笔数及服务平台内存存量回传选择器，同步于平台注册中心(供下一个请求参考)，最后回传请求结果。
[0080]注:请求处理笔数为请求内容需要商务逻辑处理的笔数。
[0081]待请求处理总笔数=累计请求处理笔数加上或扣除该请求处理笔数。
[0082]待请求总笔数=累计请求笔数加上或扣除该请求笔数(一般而言，该请求笔数=
Do
[0083]若请求笔数为I，而该请求处理笔数可为I至多笔。
[0084]注:藉依待请求处理总笔数最少、或依待请求总笔数最少、或依服务平台内存存量最多的分流方式达成提供多种分流策略及更精准的负载平衡。
[0085]注:藉由依服务范畴的分流方式达成为特定族群提供专属的执行环境，进言之，藉由预先将一服务平台设定供其所执行的内存量及CHJ或CPU的核心，若请求信息中附带有服务范畴名称并与服务平台名称相同，则分派至该服务平台；另一种服务范畴的分流方式为将服务范畴名称与模块名称比对，找出合适的模块名称集合(可能一或多个模块名称)，或再依其它分流策略分派请求。
[0086]注:藉由分流策略中依最新版的分流方式，而达成永续的服务，进言之，以图3中系统目录/模块目录下的MA、MB为例，假设服务平台名称为SI，若以热部署模块名称为MX，将功能相同的两模块S1.MA及S1.MB建立关联(建立关联方式可采用任何可供记录的电子文件如:档案、多层次目录的名称等等)，而在S1.MA重新部署前，立即同步模块状态为待更新，使请求皆由S1.MB完成，在S1.MA完成部署后，同步模块状态为运行中且其版本为最新版，而使得请求皆由S1.MA完成，待S1.MB亦完成部署并与S1.MA为相同的版本，再依其它分流方式完成请求的分派。
[0087]4.保全机制说明:
[0088]4.1模块过载保全机制
[0089]4.1.1初始化部署时需满足下列条件:该服务平台内存存量需大于该服务平台保全定量+该模块部署预估量，始可部署。
[0090]4.1.2监控部署时需满足下列条件:该服务平台内存存量需大于该服务平台保全定量+该模块实际部署所需量，始可部署。
[0091]4.2请求过载保全机制
[0092]4.2.1请求超时超量保全，设定该服务平台一请求期限定量及请求过载保全定量，在该服务平台的模块委任机制委任该模块执行该请求时，同时启动一保全监控机制，定期检查该请求所使用的记忆量，及所花费的时间，若有超时超量则中断该请求的执行，并回报中断原因，以保全该服务平台免于因请求过载而无法运行。
[0093]4.2.2请求量迅增保全，设定该服务平台一服务平台保全定量，定期与该服务平台内存存量相比较，若该服务平台内存存量低于所设定的服务平台保全定量，则同步该服务平台状态为暂停服务，待该服务平台内存存量高于所设定的服务平台保全定量时，再同步该服务平台状态为服务中。
[0094]注:藉由4.1及4.2达成服务平台内存存量管控机制，保全系统运作。
[0095]4.3平台监控机制，依平台监控间隔时间，监控服务平台为服务中的数量，若服务平台的状态为服务中的量数低于服务平台服务定量时，则启动备援服务平台启动设定档，以达成备援服务平台的自动扩充；
[0096]若大于或等于服务平台服务定量时，则启动备援服务平台关闭设定档。
[0097]注:藉由4.3达成自动实时(热)备援的机制，增强系统的服务，保全系统运作。
[0098]5.配置文件说明:
[0099]5.1分流器配置文件参数说明，包含有:
[0100]5.1.1服务平台设定档:包含各服务平台启动及关闭文件路径的记录。
[0101]5.1.2备援服务平台设定档:包含各备援服务平台启动及关闭文件路径的记录。
[0102]5.1.3服务平台服务定量:保全该分布式系统所需服务平台的数量。
[0103]5.1.4平台监控间隔时间:提供于平台监控机制再监控平台注册中心的间隔时间。
[0104]5.2服务平台配置文件参数说明，包含有:
[0105]5.2.1系统名称:用以定义系统名称。
[0106]5.2.2系统目录:如D:\abc\system。
[0107]5.2.3服务平台名称:该服务平台名称，如:SI。
[0108]5.2.4服务平台地址:该服务平台地址，提供分流器连接该服务平台。
[0109]5.2.5平台注册中心地址:提供登录及同步该服务平台信息、模块信息的平台注册中心的地址。
[0110]5.2.6平台目录名称:用以定义存放各模块的目录名称。
[0111]5.2.7部署模式:如部署模式说明。
[0112]5.2.8服务平台保全定量:保全服务平台运行的内存定量。
[0113]5.2.9模块部署预估量:模块部署时，预估所需的内存基本量。
[0114]5.2.10请求过载保全定量:该服务平台的请求可执行最大内存使用量。
[0115]5.2.11请求期限定量:该服务平台的请求可执行的最久时间。
[0116]5.2.12模块监控间隔时间:提供于热部署监控机制再监控的间隔时间。
[0117]6.部署模式说明:假设一系统目录(如c:\systemrf，有一包含各模块的平台目录(如:module)，若有一模块，置于一名为MA的目录，贝Ij依不同的部署模式(Module、Package、Operat1n)，其所呈现的目录结构层次及其模块名称(实体名称)，如下所示:
[0118]6.1 Module模式:平台目录下包含一层目录，该模块所有相关档案置于此目录中，以此方式部署的目录结构为系统目录+平台目录+该模块目录。如例，则其目录结构为c: \syst em\modu I e \MA，该模块的模块名称为:MA，配合服务平台名称(若为SI )，则模块名称为:Sl-MA0
[0119]6.2 Package模式:平台目录下包含两层目录，该模块所有相关档案置于该模块目录的第二层目录，以此方式部署的目录结构为系统目录+平台目录+该模块目录的第一层目录+该模块目录的第二层目录。如例，贝lJ其目录结构可为c: \sy stem\moduI e\X\MA，该模块的模块名称则为:X.MA，配合服务平台名称(若为SI)，则模块名称为:S1.X.MA。
[0120]6.3 Operat1n模式:平台目录下包含三层目录，该模块所有相关档案置于该模块目录的第三层目录，以此方式部署的目录结构为系统目录+平台目录+该模块目录的第一层目录+该模块目录的第二层+该模块目录的第三层目录。如例，则其目录结构可为cSyStem\m0dule\X\Y\MA，该模块的模块名称则为:X.Y.MA，配合服务平台名称(若为SI)，则模块名称为:S1.X.Y.MA。
[0121]注:藉由部署模式所提供的多层目录结构命名模块名称而达成模块分类管理；亦可以以此建立模块关联的热部署模块名称，如以S1.X.1及S2.X.2，即可视为不同平台下对莫块的不同版本。
[0122]7.服务平台目录说明(请参考图4:服务平台目录结构图):
[0123]7.1系统目录/平台目录:即服务平台配置文件参数所设定的系统目录名称及平台目录名称，各模块至于平台目录中。
[0124]7.2模块目录:为一模块的相关档案存放目录。
[0125]7.2.1模块程序集合:为该模块的应用程序集合如商业逻辑程序、数据存取对象(DAO)等。
[0126]7.2.2热部署版本档案:提供设定热部署模块名称(逻辑名称)、版本(注:热部署模块名称用以关联相同功能的模块，而视为同一模块;版本用以设定该模块版本)。
[0127]7.2.3模块相关档案目录:即存放该模块设定文件、多国语言文件等等的目录。
[0128]7.2.4模块档案集合:为该模块设定文件、多国语言文件等等。
[0129]7.2.5模块程序库目录:为只提供该模块所需参考程序库的目录。
[0130]7.2.6模块程序库集合:为只提供该模块所需参考的程序库。
[0131]7.3共享程序库目录:为提供各模块所需参考程序库的目录。
[0132]7.3.1共享程序库集合:为提供各模块所需参考的各类程序库。
[0133]以上所述仅为本发明的较佳实施例，并将方法(机制)、流程名词化以便说明，任何名词的修改但其功能相似或依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。
【主权项】
1.一种使计算机系统热部署模块时服务不中断的服务平台，其特征在于包含有:一量化式部署器，用以将壹模块量化部署各独立模块，并藉由部署流程而缩短重新部署时间；一模块过载保全机制，用以保全服务平台免于部署时因服务平台内存存量不足而无法运行；一零请求监控机制，用以防止因模块需要重新部署或移除而中断尚在执行中的请求;一热部署监控机制，用以监控运行中的模块及模块目录的相关档案异动以及模块的新增;一信息记录器，用以记录各服务平台及模块信息;一模块委任器，用以将请求依模块名称委任该模块执行;一服务平台目录，包含有:用以置放一模块目录及一模块相关档案;请求过载保全机制，用以保全系统免于因请求过载而无法运行，以及一网络服务器，用以安装并启动服务平台，使服务平台可接收请求以提供服务。2.—种使计算机系统热部署模块时服务不中断的方法，其特征在于包含有:一量化式部署器，用以将壹模块量化部署各独立模块，并藉由部署流程而缩短重新部署时间；一模块过载保全机制，用以保全服务平台免于部署时因服务平台内存存量不足而无法运行;一零请求监控机制，用以防止因模块需要重新部署或移除而中断尚在执行中的请求;一热部署监控机制，用以监控运行中的模块及模块目录的相关档案异动以及模块的新增、删除;一信息记录器，用以记录各服务平台及模块信息;一模块委任器，用以将请求依模块名称委任该模块执行;一服务平台目录，包含有:用以置放一模块目录及一模块相关档案;一请求过载保全机制，用以保全系统免于因请求过载而无法运行，以及一网络服务器，用以安装并启动服务平台，使服务平台可接收请求以提供服务。3.如权利要求1或2所述的模块过载保全机制，其特征在于其方法包含步骤:初始化部署时，该服务平台内存存量需大于该服务平台保全定量加上该模块部署预估量，始可部署；在监控部署时，该服务平台内存存量需大于该服务平台保全定量加上该模块实际部署所需量，始可部署。4.如权利要求1或2所述的请求过载保全机制，其特征在于进一步包含有:请求超时超量保全机制，其方法包含步骤:在请求委任后，同时启动一请求监控程序，监控该请求的执行时间及该请求的内存使用量，若超过请求期限定量或请求过载保全定量则中断该请求的执行。5.如权利要求1或2所述的请求过载保全机制，其特征在于进一步包含有:请求量迅增保全机制，其方法包含步骤:依该服务平台保全定量的设定，定期与该服务平台内存存量相比较，若该服务平台内存存量低于所设定的该服务平台保全定量，则设定该服务平台状态为暂停服务。6.如权利要求1或2所述的零请求监控机制，其特征在于其方法包含步骤:在请求时，将该请求累计于该模块信息记录器中的待请求总笔数，在该模块完成请求后，响应前，将该模块信息记录器中的待请求总笔数扣除该请求，移除或重新部署时，该模块待请求总笔数需为零，始可重新部署或移除。7.一种提供多重分流策略的负载平衡分流器，其特征在于包含有:一选择器，用以依分流策略，分派请求;一平台注册中心，用以提供登录或同步服务平台及模块信息的记录；以及一网络服务器，用以安装并启动分流器，以使分流器可接收请求。8.如权利要求7所述的多重分流策略，其特征在于为依最新版本分流、依指定版本、依服务范畴分流、依待请求处理总笔数最少、依待请求总笔数最少、依服务平台内存存量存量最多及上述分流策略相互组合，包括上述任意两项分流策略。9.如权利要求7所述的多重分流策略，其所以能达成是依平台注册中心的服务平台信息及模块信息，其特征在于其取得信息的方法包含步骤:藉由定期或不定期同步服务平台信息或模块信息于平台注册中心，或藉由请求时或回应时，同步服务平台信息或模块信息于平台注册中心。10.如权利要求8所述的依服务范畴分流，其达成为特定族群提供专属的执行环境，其特征在于其方法包含步骤:藉由预先将至少一服务平台设定其所执行的内存量及CPU或CPU的核心，并使请求信息中附带有服务范畴名称且与服务平台名称或模块名称比对，或再配合其它分流策略，以找出该服务平台以分派请求。11.一种服务优化的计算机系统，其特征在于包含有:一服务平台:即请求项第I项所述的服务平台并加入一信息通知器，用以登录或同步平台信息及模块信息于平台注册中心；一具有依最新版本分流及其它分流策略之一的分流器;一模块程序库优先机制，用以优先取得不同版本的相同程序库;一模块分类管理机制，提供至少二层目录结构以命名模块名称而分类模块;一自动实时备援的机制，用以在服务中的服务平台数量不足时，自动启动备援服务台；一可供记录的电子文件以设定热部署模块名称及版本，将功能相同的模块建立关连，藉由分流策略的依最新版本分派请求而达成永续的服务。12.一种服务优化的计算机方法，其特征在于包含有:一服务平台:即请求项第I项所述的服务平台并加入一信息通知器，用以登录或同步平台信息及模块信息于平台注册中心；一具有依最新版本分流及其它分流策略之一的分流器;一模块程序库优先机制，用以优先取得不同版本的相同程序库;一模块分类管理机制，提供至少二层目录结构以命名模块名称而分类模块;一自动实时备援的机制，用以在服务中的服务平台数量不足时，自动启动备援服务台；一可供记录的电子文件以设定热部署模块名称及版本，将功能相同的模块建立关联，藉由分流策略的依最新版本分派请求而达成永续的服务。13.如权利要求11或12所述的自动实时备援的机制，其特征在于其方法包含步骤:在服务平台中于分流器中加入一平台监控机制，用以监控服务平台的状态，若服务平台的状态为服务中的数量低于服务平台服务定量时，则启动备援服务平台启动设定档，使服务平台于初始化部署后藉由平台注册中心地址向平台注册中心登录完成注册。14.如权利要求11或12所述的模块程序库优先机制，用以优先取得不同版本的相同程序库，存在该模块程序库目录的程序库将优先被取用，相较于存在共享程序库目录下相同的程序库;其特征在于其方法包含步骤:在该模块目录结构，提供该模块程序库目录及共享程序库目录，并置放相关程序库，在建立程序库时，先行建立该模块程序库目录下的程序库，再建立共享程序库目录下的程序库。
【文档编号】H04L29/08GK106027591SQ201610177195
【公开日】2016年10月12日
【申请日】2016年3月24日
【发明人】林胜雄
【申请人】林胜雄