CN111857689A - 一种框架、框架的功能配置方法、终端及存储介质 - Google Patents

Abstract

本申请公开了一种基于终端软件开发的框架，包括业务系统和包含不同业务组件的业务组件系统。业务系统在接收到包含目标业务组件的组件配置文件之后，根据组件配置文件从业务组件系统中加载目标业务组件并执行，以完成目标业务逻辑的处理。可见，本申请可为业务系统分配其处理目标业务逻辑所需的目标业务组件，以实现业务组件的灵活可配，此情况下业务系统内只运行目标业务逻辑所需的目标业务组件，从而节约了业务系统的资源；而且，框架可包含分别用于处理不同类的业务逻辑的不同业务系统，从而使框架下的整个业务系统适用于多类业务逻辑处理。本申请还公开了一种框架的功能配置方法、终端及计算机可读存储介质，与上述框架具有相同的有益效果。

Description

一种框架、框架的功能配置方法、终端及存储介质

技术领域

本申请涉及软件开发领域，特别是涉及一种基于终端软件开发的框架、框架的功能配置方法、终端及计算机可读存储介质。

背景技术

系统框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品，即系统框架的功能类似于基础设施，与具体的软件应用无关，但是提供并实现最为基础的软件架构和体系。

目前，大多数系统框架中都包含用于处理业务逻辑的业务系统，并为业务系统提前配置好一套业务组件，在业务系统工作时，会加载系统中已配置好的所有业务组件并执行，以完成业务逻辑的处理。但是，基于业务逻辑的复杂多样化，不同业务逻辑实际所需的业务组件通常有所不同，所以业务系统加载所有业务组件会导致业务系统内运行不需要的业务逻辑，从而占用业务系统的资源。

因此，如何提供一种解决上述技术问题的方案是本领域的技术人员目前需要解决的问题。

发明内容

本申请的目的是提供一种基于终端软件开发的框架、框架的功能配置方法、终端及计算机可读存储介质，可为业务系统分配其处理目标业务逻辑所需的目标业务组件，以实现业务组件的灵活可配，此情况下业务系统内只运行目标业务逻辑所需的目标业务组件，从而节约了业务系统的资源；而且，框架可包含分别用于处理不同类的业务逻辑的不同业务系统，从而使框架下的整个业务系统适用于多类业务逻辑处理。

为解决上述技术问题，本申请提供了一种基于终端软件开发的框架，包括：业务组件系统及N个业务系统，所述业务组件系统分别与N个所述业务系统连接，N为正整数；

所述业务组件系统包含不同的业务组件；其中，所述业务组件用于处理业务逻辑；

每个所述业务系统均用于接收包含目标业务组件的组件配置文件，根据所述组件配置文件从所述业务组件系统中加载所述目标业务组件并执行，以完成目标业务逻辑的处理；其中，不同业务系统分别用于处理不同类的业务逻辑。

优选地，所述业务组件包括业务基础组件和业务功能组件；

所述业务基础组件用于在被所述业务系统加载的情况下，为所述目标业务逻辑的处理提供基础服务；

所述业务功能组件用于在被所述业务系统加载的情况下，基于所述基础服务完成所述目标业务逻辑的处理。

优选地，不同业务组件的接口及通信协议均统一。

优选地，所述框架还包括：监控系统，所述监控系统分别与所述业务组件系统和所述业务系统连接；

所述监控系统用于从所述业务组件系统中加载通信组件，以具备与所述业务系统通讯的服务；

所述监控系统还用于监控所述业务系统的运行情况，并在监控到所述业务系统异常的情况下进行系统恢复处理。

优选地，在监控到所述业务系统无异常的情况下，所述监控系统还用于判断所述业务系统占用业务处理器的资源是否超过预设资源上限阈值，并在所述业务系统占用业务处理器的资源超过预设资源上限阈值的情况下，限制所述业务系统运行，直至所述业务系统占用业务处理器的资源降至所述资源上限阈值以下时重新恢复所述业务系统运行。

优选地，所述框架还包括：诊断调试系统，所述诊断调试系统分别与所述监控系统和所述业务系统连接；

所述诊断调试系统用于在接收到所述监控系统发出的启动信号的情况下对所述业务系统进行异常修复处理，其中，所述监控系统在累计的所述业务系统的异常次数超过预设异常次数阈值的情况下，退出对所述业务系统的监控，并向所述诊断调试系统发出所述启动信号。

优选地，所述框架还包括：守护系统，所述守护系统与所述监控系统连接；

所述守护系统用于在所述监控系统运行的情况下，检测所述监控系统的运行情况，并在检测到所述监控系统异常时进行系统恢复处理。

优选地，所述守护系统还与所述诊断调试系统连接；

相应的，所述守护系统还用于累计所述监控系统的监控异常次数，并在所述监控异常次数超过预设监控异常次数阈值的情况下，退出对所述监控系统的守护，并启动所述诊断调试系统对所述监控系统进行异常修复处理。

为解决上述技术问题，本申请还提供了一种框架的功能配置方法，包括：

预先配备不同业务组件；

接收包含目标业务组件的组件标识的组件配置文件；

根据所述组件配置文件从所述不同业务组件中加载所述目标业务组件并执行，以完成目标业务逻辑的处理。

优选地，所述功能配置方法还包括：

监控所述目标业务组件的执行情况，并在监控到所述目标业务组件的执行异常的情况下进行异常恢复处理。

优选地，所述功能配置方法还包括：

在监控到所述目标业务组件的执行无异常的情况下，判断所述目标业务组件执行时占用业务处理器的资源是否超过预设资源上限阈值；

若是，则限制所述目标业务组件的执行，直至所述业务处理器的资源占用降至所述资源上限阈值以下的情况下重新恢复所述目标业务组件的执行。

优选地，所述功能配置方法还包括：

在监控所述目标业务组件执行的情况下，累计所述目标业务组件执行的异常次数，并判断所述异常次数是否超过预设异常次数阈值；

若是，则退出对所述目标业务组件的执行情况的监控，并对所述目标业务组件的执行异常进行异常修复处理。

优选地，所述功能配置方法还包括：

在监控所述目标业务组件执行的情况下，检测所述目标业务组件执行的情况下所受到的监控管理情况，并在检测到所述监控管理情况异常的情况下进行异常恢复处理。

优选地，所述功能配置方法还包括：

在监控所述目标业务组件执行的情况下，累计所述监控管理情况存在的监控异常次数，并判断所述监控异常次数是否超过预设监控异常次数阈值；

若是，则退出对所述监控管理情况的检测，并对所述监控管理情况的异常进行异常修复处理。

为解决上述技术问题，本申请还提供了一种终端，包括：

存储器，用于存储计算机程序；

处理器，用于在执行所述计算机程序时实现上述任一种框架的功能配置方法的步骤。

为解决上述技术问题，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一种框架的功能配置方法的步骤。

本申请提供了一种基于终端软件开发的框架，包括业务系统和包含不同业务组件的业务组件系统。业务系统在接收到包含目标业务组件的组件配置文件之后，根据组件配置文件从业务组件系统中加载目标业务组件并执行，以完成目标业务逻辑的处理。可见，本申请可为业务系统分配其处理目标业务逻辑所需的目标业务组件，以实现业务组件的灵活可配，此情况下业务系统内只运行目标业务逻辑所需的目标业务组件，从而节约了业务系统的资源；而且，框架可包含分别用于处理不同类的业务逻辑的不同业务系统，从而使框架下的整个业务系统适用于多类业务逻辑处理。

本申请还提供了一种框架的功能配置方法、终端及计算机可读存储介质，与上述框架具有相同的有益效果。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对现有技术和实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种基于终端软件开发的框架的结构示意图；

图2为本申请实施例提供的一种业务系统的组件加载流程图；

图3为本申请实施例提供的一种基于终端软件开发的框架的具体结构示意图；

图4为本申请实施例提供的一种监控系统的监控流程图；

图5为本申请实施例提供的一种守护系统的守护流程图。

具体实施方式

本申请的核心是提供一种基于终端软件开发的框架、框架的功能配置方法、终端及计算机可读存储介质，可为业务系统分配其处理目标业务逻辑所需的目标业务组件，以实现业务组件的灵活可配，此情况下业务系统内只运行目标业务逻辑所需的目标业务组件，从而节约了业务系统的资源；而且，框架可包含分别用于处理不同类的业务逻辑的不同业务系统，从而使框架下的整个业务系统适用于多类业务逻辑处理。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参照图1，图1为本申请实施例提供的一种基于终端软件开发的框架的结构示意图。

该基于终端软件开发的框架包括：业务组件系统1及N个业务系统2，业务组件系统1分别与N个业务系统2连接，N为正整数；

业务组件系统1包含不同的业务组件；其中，业务组件用于处理业务逻辑；

每个业务系统2均用于接收包含目标业务组件的组件配置文件，根据组件配置文件从业务组件系统1中加载目标业务组件并执行，以完成目标业务逻辑的处理；其中，不同业务系统2分别用于处理不同类的业务逻辑。

具体地，本申请的框架包括业务组件系统1和业务系统2，其工作原理为：

业务组件系统1中包含多个用于处理业务逻辑的业务组件，供业务系统2在处理业务逻辑的情况下对应加载使用。业务组件系统1中业务组件的组成具体可根据业务系统2待处理的业务逻辑设计。

业务组件系统1中业务组件的加载流程为：本申请基于业务系统2当前待处理的业务逻辑(称为目标业务逻辑)，确定处理目标业务逻辑所需的业务组件(称为目标业务组件)，并将目标业务组件写入为业务系统2准备的组件配置文件中，然后将组件配置文件发送至业务系统2。业务系统2在接收到组件配置文件的情况下，首先根据组件配置文件确定目标业务组件，然后从包含不同业务组件的业务组件系统1中对应加载目标业务组件并执行，从而完成目标业务逻辑的处理。

更具体地，本申请可将目标业务组件的组件标识写入为业务系统2准备的组件配置文件中，以使业务系统2根据组件配置文件内包含的组件标识确定目标业务组件。

此外，本申请的业务系统2的数量可为一个，也可以多个，多个业务系统2并行运行，不同业务系统2分别用于处理不同类的业务逻辑，从而使整个业务系统适用于多类业务逻辑处理。需要说明的是，每个业务系统2加载业务组件系统1中业务组件的原理相同，本申请在此不再赘述。

比如，系统框架下设置有用于处理终端杀毒防御业务的第一业务系统和用于处理终端防外部攻击业务的第二业务系统，业务组件系统1中包含用于处理终端杀毒防御逻辑的第一业务组件和用于处理终端防外部攻击逻辑的第二业务组件。第一业务系统在接收到包含第一业务组件的组件配置文件的情况下，首先根据组件配置文件确定预加载的第一业务组件，然后从业务组件系统1中对应加载第一业务组件并执行，从而完成终端杀毒防御业务的处理。同样地，第二业务系统在接收到包含第二业务组件的组件配置文件的情况下，首先根据组件配置文件确定预加载的第二业务组件，然后从业务组件系统1中对应加载第二业务组件并执行，从而完成终端防外部攻击业务的处理。

可见，本申请可为业务系统2分配其处理目标业务逻辑所需的目标业务组件，以实现业务组件的灵活可配，此情况下业务系统2内只运行目标业务逻辑所需的目标业务组件，从而节约了业务系统2的资源。而且，本申请的框架可包含分别用于处理不同类的业务逻辑的不同业务系统，从而使框架下的整个业务系统适用于多类业务逻辑处理。此外，业务组件系统1内的业务组件可按需扩展，从而为业务系统2处理更多业务提供可能性。

在上述实施例的基础上：

作为一种可选的实施例，业务组件包括业务基础组件和业务功能组件；

业务基础组件用于在被业务系统2加载的情况下，为目标业务逻辑的处理提供基础服务；

业务功能组件用于在被业务系统2加载的情况下，基于基础服务完成目标业务逻辑的处理。

具体地，本申请的业务组件包括业务基础组件和业务功能组件；其中，业务基础组件用于为业务系统2处理业务逻辑提供基础服务，如通信组件、配置组件、数据库组件等；业务功能组件供业务系统2处理业务逻辑使用。

基于此，业务系统2加载业务组件的具体流程为(参照图2)：1)接收包含目标业务基础组件和目标业务功能组件的组件配置文件；2)根据组件配置文件确定目标业务基础组件和目标业务功能组件；3)从业务组件系统中加载目标业务基础组件；4)对目标业务基础组件进行初始化，以为业务系统处理目标业务逻辑提供基础服务；5)从业务组件系统中加载目标业务功能组件；6)执行目标业务功能组件，以基于基础服务完成目标业务逻辑的处理。

作为一种可选的实施例，不同业务组件的接口及通信协议均统一。

具体地，现有技术中，系统框架的不同业务组件未进行接口及通信协议的统一，导致组件管理难度较大，所以本申请的系统框架中不同业务组件的接口及通信协议均进行统一化配置，从而大大降低了组件管理的难度。

请参照图3，图3为本申请实施例提供的一种基于终端软件开发的框架的具体结构示意图。

作为一种可选的实施例，框架还包括：监控系统3，监控系统3分别与业务组件系统1和业务系统2连接；

监控系统3用于从业务组件系统1中加载通信组件，以具备与业务系统2通讯的服务；

监控系统3还用于监控业务系统2的运行情况，并在监控到业务系统2异常的情况下进行系统恢复处理。

进一步地，本申请的框架还包括监控系统3，其工作原理为：

监控系统3从业务组件系统1中加载通信组件，目的是具备自身与业务系统2通讯的服务，以得知业务系统2执行的具体业务逻辑，从而实现后续对业务系统2的管理。

在业务系统2运行的情况下，即执行目标业务组件的情况下，监控系统3负责监控业务系统2的运行情况，并根据业务系统2的运行情况判断业务系统2是否异常，若业务系统2异常，则进行业务系统2的系统恢复处理，具体可通过重启业务系统2进行业务系统2的系统恢复，从而保证业务系统2的正常运行。

更具体地，判断业务系统2是否异常的过程为：获取业务系统2的运行参数，并判断业务系统2的运行参数是否在预设业务参数范围内，若是，则确定业务系统2正常；若否，则确定业务系统2异常。

作为一种可选的实施例，在监控到业务系统2无异常的情况下，监控系统3还用于判断业务系统2占用业务处理器的资源是否超过预设资源上限阈值，并在业务系统2占用业务处理器的资源超过预设资源上限阈值的情况下，限制业务系统2运行，直至业务系统2占用业务处理器的资源降至资源上限阈值以下时重新恢复业务系统2运行。

进一步地，本申请的监控系统3对业务系统2的管理还包括：

监控系统3在根据业务系统2的运行情况判断业务系统2是否异常的情况下，若业务系统2无异常，则判断业务系统2占用业务处理器的资源是否超过预设资源上限阈值，若未超过预设资源上限阈值，说明业务处理器的资源不必进行释放处理，则保持业务系统2的正常运行；若超过预设资源上限阈值，则限制业务系统2运行，以将业务处理器的资源释放出一部分，并继续监控业务系统2，直至业务系统2占用业务处理器的资源降至资源上限阈值以下的情况下，再重新恢复业务系统2运行，从而保证业务系统2占用业务处理器的资源不超限。

作为一种可选的实施例，框架还包括：诊断调试系统4，诊断调试系统4分别与监控系统3和业务系统2连接；

诊断调试系统4用于在接收到监控系统3发出的启动信号的情况下对业务系统2进行异常修复处理，其中，监控系统3在累计的业务系统2的异常次数超过预设异常次数阈值的情况下，退出对业务系统2的监控，并向诊断调试系统4发出启动信号。

具体地，现有技术中，系统框架的业务系统在出现异常时往往进行异常自修复操作，即业务系统自我管理异常问题，不仅占用业务系统资源，而且增加业务系统开发的难度，所以本申请在系统框架中增设诊断调试系统4，其工作原理为：

在业务系统2运行的情况下，监控系统3监控业务系统2的运行情况，并根据业务系统2的运行情况判断业务系统2是否异常；若业务系统2异常，则重启业务系统2进行业务系统2的系统恢复，并将业务系统2的异常次数(初始值为0)加1，且重新执行监控业务系统2的运行情况的操作，此情况下判断业务系统2的异常次数是否超过预设异常次数阈值；若未超过预设异常次数阈值，则继续执行根据业务系统2的运行情况判断业务系统2是否异常的操作；若超过预设异常次数阈值，说明业务系统2重启已无法恢复系统正常，此情况下需要修复业务系统2，则监控系统3退出对业务系统2的监控，即不再继续执行根据业务系统2的运行情况判断业务系统2是否异常的操作，并启动诊断调试系统4对业务系统2进行异常修复处理，如对业务系统2进行重新升级等修复操作，从而恢复业务系统2的正常运行。

可见，本申请采用诊断调试系统4对业务系统2进行异常修复处理，不占用业务系统2的资源，且降低业务系统2开发的难度。

综上，监控系统3对任一业务系统2(称为目标业务系统)的监控流程均包括(参照图4)：在目标业务系统运作情况下，监控目标业务系统；判断目标业务系统的异常次数是否超过预设异常次数阈值；若超过预设异常次数阈值，则退出对目标业务系统的监控，并启动诊断调试系统对目标业务系统进行异常修复处理；若未超过预设异常次数阈值，则判断目标业务系统是否异常；若目标业务系统异常，则重启目标业务系统，并将目标业务系统的异常次数加1，且返回执行监控目标业务系统的运行情况的操作；若目标业务系统无异常，则判断目标业务系统占用业务处理器的资源是否超限；若超限，则限制目标业务系统运行，并返回执行监控目标业务系统的操作；若不超限，则保持目标业务系统的正常运行。

作为一种可选的实施例，框架还包括：守护系统5，守护系统5与监控系统3连接；

守护系统5用于在监控系统3运行的情况下，检测监控系统3的运行情况，并在检测到监控系统3异常时进行系统恢复处理。

进一步地，本申请的框架还包括守护系统5，其工作原理为：

在监控系统3运行情况下，守护系统5负责检测监控系统3的运行情况，并根据监控系统3的运行情况判断监控系统3是否异常，若监控系统3异常，则进行监控系统3的系统恢复处理，具体可通过重启监控系统3进行监控系统3的系统恢复，从而保证监控系统3的正常运行。

更具体地，判断监控系统3是否异常的过程为：获取监控系统3的运行参数，并判断监控系统3的运行参数是否在预设监控参数范围内，若是，则确定监控系统3正常；若否，则确定监控系统3异常。

作为一种可选的实施例，守护系统5还与诊断调试系统4连接；

相应的，守护系统5还用于累计监控系统3的监控异常次数，并在监控异常次数超过预设监控异常次数阈值的情况下，退出对监控系统3的守护，并启动诊断调试系统4对监控系统3进行异常修复处理。

进一步地，本申请的守护系统5还与诊断调试系统4连接，其工作原理为(参照图5)：

在监控系统3运行情况下，守护系统5检测监控系统3的运行情况，并判断监控系统3是否异常；若监控系统3无异常，则返回执行检测监控系统3的运行情况的操作；若监控系统3异常，则将监控系统3的监控异常次数(初始值为0)加1，并判断监控系统3的监控异常次数是否超过预设监控异常次数阈值；若未超过预设监控异常次数阈值，则重启监控系统3，并返回执行检测监控系统3的运行情况的操作；若超过预设监控异常次数阈值，说明监控系统3重启已无法恢复系统正常，此情况下需要修复监控系统3，则守护系统5退出对监控系统3的守护，并启动诊断调试系统4对监控系统3进行异常修复处理，如对监控系统3进行重新升级等修复操作，从而恢复监控系统3的正常运行。

可见，本申请的诊断调试系统4既可实现对业务系统2的异常修复，又可实现对监控系统3的异常修复，从而实现二者的统一异常修复管理。而且，诊断调试系统4还提供系统调试框架供运维人员调试业务系统2及监控系统3。

综上，本申请的框架包括业务组件系统1、业务系统2、监控系统3、诊断调试系统4及守护系统5，与现有的大多数单一功能的框架(如通信框架，异步事件框架等)相比，框架功能多样化，框架整体统一化，从而提高了软件开发的效率。

本申请还提供了一种框架的功能配置方法，包括：

预先配备不同业务组件；

接收包含目标业务组件的组件标识的组件配置文件；

根据组件配置文件从不同业务组件中加载目标业务组件并执行，以完成目标业务逻辑的处理。

作为一种可选的实施例，功能配置方法还包括：

监控目标业务组件的执行情况，并在监控到目标业务组件的执行异常的情况下进行异常恢复处理。

作为一种可选的实施例，功能配置方法还包括：

在监控到目标业务组件的执行无异常的情况下，判断目标业务组件执行时占用业务处理器的资源是否超过预设资源上限阈值；

若是，则限制目标业务组件的执行，直至业务处理器的资源占用降至资源上限阈值以下的情况下重新恢复目标业务组件的执行。

作为一种可选的实施例，功能配置方法还包括：

在监控目标业务组件执行的情况下，累计目标业务组件执行的异常次数，并判断异常次数是否超过预设异常次数阈值；

若是，则退出对目标业务组件的执行情况的监控，并对目标业务组件的执行异常进行异常修复处理。

作为一种可选的实施例，功能配置方法还包括：

在监控目标业务组件执行的情况下，检测目标业务组件执行的情况下所受到的监控管理情况，并在检测到监控管理情况异常的情况下进行异常恢复处理。

作为一种可选的实施例，功能配置方法还包括：

在监控目标业务组件执行的情况下，累计监控管理情况存在的监控异常次数，并判断监控异常次数是否超过预设监控异常次数阈值；

若是，则退出对监控管理情况的检测，并对监控管理情况的异常进行异常修复处理。

本申请提供的功能配置方法的介绍请参考上述框架的实施例，本申请在此不再赘述。

本申请还提供了一种终端，包括：

存储器，用于存储计算机程序；

处理器，用于在执行计算机程序时实现上述任一种框架的功能配置方法的步骤。

本申请提供的终端的介绍请参考上述功能配置方法的实施例，本申请在此不再赘述。

本申请还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现上述任一种框架的功能配置方法的步骤。

本申请提供的计算机可读存储介质的介绍请参考上述功能配置方法的实施例，本申请在此不再赘述。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其他实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (11)

1.一种基于终端软件开发的框架，其特征在于，包括：业务组件系统及N个业务系统，所述业务组件系统分别与N个所述业务系统连接，N为正整数；

所述业务组件系统包含不同的业务组件；其中，所述业务组件用于处理业务逻辑；

每个所述业务系统均用于接收包含目标业务组件的组件配置文件，根据所述组件配置文件从所述业务组件系统中加载所述目标业务组件并执行，以完成目标业务逻辑的处理；其中，不同业务系统分别用于处理不同类的业务逻辑。

2.如权利要求1所述的基于终端软件开发的框架，其特征在于，所述业务组件包括业务基础组件和业务功能组件；

所述业务基础组件用于在被所述业务系统加载的情况下，为所述目标业务逻辑的处理提供基础服务；

所述业务功能组件用于在被所述业务系统加载的情况下，基于所述基础服务完成所述目标业务逻辑的处理。

3.如权利要求1所述的基于终端软件开发的框架，其特征在于，不同业务组件的接口及通信协议均统一。

4.如权利要求1所述的基于终端软件开发的框架，其特征在于，所述框架还包括：监控系统，所述监控系统分别与所述业务组件系统和所述业务系统连接；

所述监控系统用于从所述业务组件系统中加载通信组件，以具备与所述业务系统通讯的服务；

所述监控系统还用于监控所述业务系统的运行情况，并在监控到所述业务系统异常的情况下进行系统恢复处理。

5.如权利要求4所述的基于终端软件开发的框架，其特征在于，在监控到所述业务系统无异常的情况下，所述监控系统还用于判断所述业务系统占用业务处理器的资源是否超过预设资源上限阈值，并在所述业务系统占用业务处理器的资源超过预设资源上限阈值的情况下，限制所述业务系统运行，直至所述业务系统占用业务处理器的资源降至所述资源上限阈值以下时重新恢复所述业务系统运行。

6.如权利要求4所述的基于终端软件开发的框架，其特征在于，所述框架还包括：诊断调试系统，所述诊断调试系统分别与所述监控系统和所述业务系统连接；

所述诊断调试系统用于在接收到所述监控系统发出的启动信号的情况下对所述业务系统进行异常修复处理，其中，所述监控系统在累计的所述业务系统的异常次数超过预设异常次数阈值的情况下，退出对所述业务系统的监控，并向所述诊断调试系统发出所述启动信号。

7.如权利要求6所述的基于终端软件开发的框架，其特征在于，所述框架还包括：守护系统，所述守护系统与所述监控系统连接；

所述守护系统用于在所述监控系统运行的情况下，检测所述监控系统的运行情况，并在检测到所述监控系统异常时进行系统恢复处理。

8.如权利要求7所述的基于终端软件开发的框架，其特征在于，所述守护系统还与所述诊断调试系统连接；

相应的，所述守护系统还用于累计所述监控系统的监控异常次数，并在所述监控异常次数超过预设监控异常次数阈值的情况下，退出对所述监控系统的守护，并启动所述诊断调试系统对所述监控系统进行异常修复处理。

9.一种框架的功能配置方法，其特征在于，包括：

预先配备不同业务组件；

接收包含目标业务组件的组件标识的组件配置文件；

根据所述组件配置文件从所述不同业务组件中加载所述目标业务组件并执行，以完成目标业务逻辑的处理。

10.一种终端，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于在执行所述计算机程序时实现如权利要求9所述的框架的功能配置方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求9所述的框架的功能配置方法的步骤。

Images