一种服务实现方法、电子设备及存储介质与流程

本发明涉及后台服务开发领域，特别是一种服务实现方法、电子设备及存储介质。

背景技术：

面向服务的架构(soa)为应用提供统一、通用的交互接口，具有复用性强、松散耦合、规范开发等特点，是当前主流的软件架构。常见的soa架构基于java2企业版(j2ee)或net平台实现，由应用层、业务逻辑层、服务层及数据访问层构成，每一层都有清晰的角色和分工，无需关注其它层的逻辑细节。其中，soa的关键部分就是利用企业服务总线(esb)集中进行服务的通信、交互、集成、监控等管理，并对外发布统一生命周期的服务实现业务需求。

虽然soa架构实现了业务组件的彼此解耦合，但是其中心化的服务管理机制，造成了服务间的相互耦合，不利于系统的维护和升级。每当软件需求或运行环境发生变化时，需要暂停整个服务，通过原生开发调整代码，重新编译、集成、部署成功后，才能响应用户需求。总的来说，存在以下问题：1)扩展性差，需要依次扩展每个层次的代码逻辑；2)若服务器出现性能瓶颈，无法拆分部署服务，只能被动整加服务集群节点，并且无法解决数据耦合的问题；3)java和c#都是编译执行的语音，即使功能发生微小变更，都需要重新编译、发布等，增加了系统维护的人力成本和时间成本；4)不支持实时调试，需要停止重启服务后才能生效。

技术实现要素：

为了克服现有技术的不足，本发明的目的之一在于提供一种服务实现方法，其能够解决现有技术中服务开发系统构建时存在扩展性差、用户需求升级周期等问题。

本发明的目的之二在于提供一种电子设备，其能够解决现有技术中服务开发系统构建时存在扩展性差、用户需求升级周期等问题。

本发明的目的之三在于提供一种计算机可读存储介质，其能够解决现有技术中服务开发系统构建时存在扩展性差、用户需求升级周期等问题。

本发明的目的之一采用如下技术方案实现：

一种服务实现方法，包括以下步骤：

模型创建步骤：获取项目的实际业务需求，并根据项目的实际业务需求创建业务类型；

判断步骤：从规则函数库中获取基础规则，并判断基础规则是否满足项目的实际业务需求，若是，则执行服务实现步骤；若否，则规则扩展步骤；

服务实现步骤：根据业务类型和规则函数库来利用脚本语言生成脚本文件，进而根据脚本文件实现项目的服务并发布；

规则扩展步骤：根据项目的实际业务需求生成自定义规则并将自定义规则存储于规则函数库中，然后执行服务实现步骤。

进一步地，还包括服务更新步骤：根据用户的新需求，利用脚本语言开发生成新的脚本文件或对现有服务的脚本文件进行修改后生成新的脚本文件，并根据新的脚本文件实现相应的服务并发布。

进一步地，所述服务实现步骤还包括：将发布的服务保存到服务器缓存中。

本发明的目的之二采用如下技术方案实现：

一种电子设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：

模型创建步骤：获取项目的实际业务需求，并根据项目的实际业务需求创建业务类型；

判断步骤：从规则函数库中获取基础规则，并判断基础规则是否满足项目的实际业务需求，若是，则执行服务实现步骤；若否，则规则扩展步骤；

服务实现步骤：根据业务类型和规则函数库来利用脚本语言生成脚本文件，进而根据脚本文件实现项目的服务并发布；

规则扩展步骤：根据项目的实际业务需求生成自定义规则并将自定义规则存储于规则函数库中，然后执行服务实现步骤。

进一步地，所述处理器执行所述程序时还实现以下步骤：服务更新步骤：根据用户的新需求，利用脚本语言开发生成新的脚本文件或对现有服务的脚本文件进行修改后生成新的脚本文件，并根据新的脚本文件实现相应的服务并发布。

进一步地，将发布的服务保存到服务器缓存中。

本发明的目的之三采用如下技术方案实现：

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如本发明目的之一采用的服务实现方法的步骤。

相比现有技术，本发明的有益效果在于：

通过本发明提出的服务实现方法，能够为开发人员提供多人在线协作的服务开发环境，并且基于关系建模及自定义脚本语言实现相互独立的服务；另外，在需求发生变更时，能够即时修改服务并即时生效，无需重新编译、集成、发布，提高了服务的开发效率，降低了服务的维护更新成本，实现对服务的细粒度管理、针对性维护。

附图说明

图1本发明服务实现方法的流程图；

图2本发明中业务模型的具体实例图；

图3本发明利用脚本实现服务的示意图；

图4本发明服务开发平台的架构图。

具体实施方式

下面结合附图以及具体实施方式，对本发明做进一步描述，需要说明的是，在不相冲突的前提下，以下描述的各实施例之间或各技术特征之间可以任意组合形成新的实施例。

本发明提出一种服务实现方法。在服务的设计上，基于去中心化、可扩展的设计思想，通过构建业务模型合理地划分服务，实现服务之间的解耦合；在服务的实现上，提供统一的服务开发平台及装置，支持多人协作的持续集成式服务开发，解决服务开发中存在的扩展困难、升级周期长等问题。

如图1所示，本发明的服务实现方法包括以下步骤：

步骤s1：模型创建：根据实际业务需求创建业务模型。本发明通过可视化建模的方式来建立模型，进而可实现模型和数据的持久化、事务性操作及事件绑定，在建立模型时，还需要结合业务逻辑构建模型与模型之间的关系。

服务开发的实质是对业务模型的组织与应用，于是快速高效地建立规范化、冗余小、灵活一致的业务模型至关重要。

比如本发明提供一实施例：通过不动产登记业务进一步说明模型创建的过程，也即是根据业务特征及系统需求，梳理、归纳业务模型，并通过图形化用户界面完成业务模型定制的过程。

如图2所示，不动产登记业务涉及业务主表、业务从表以及业务流程表。其中，业务主表记录登记业务的基础信息；业务从表记录登记业务的关联信息，例如附件；业务流程记录登记业务的当前流程：受理—>初审—>复审—>审核—>登簿—>缮证—>发证—>归档。

在创建模型时，首先输入模型的基本信息，例如模型编号、主键等，然后在模型属性中配置所关联的物理存储结构，最后建立业务模型之间的关联关系。

进一步地，本发明提供业务模型的查询、修改、删除功能，利用模型属性控制数据的增、删、改、查权限，支持数据的过滤排序，实现事件的监控绑定。

该模型建立的过程均通过可视化建模工具，而非代码编写的方式来实现，由于可视化建模工具其学习成本低，灵活易用。

另外，本发明还提供了具体的创建业务模型时的代码实现，具体如下：

步骤s2：规则判断：判断系统提供的规则函数库中的基础规则是否能够实现实际业务需求，若是，则执行步骤s3；若否，则执行步骤s4。

其中，基础规则是由工程师预先开发并存储于系统中的，是由系统提供。而与基础规则相对应的规则函数库中还包括自定义规则，该自定义规则指的是用户根据实际业务需求自行定义的规则。也也即是说，当基础规则不能够满足实际业务需求时，就需要通过用户自行来扩展相应的自定义规则来实现实际业务需求。

比如不动产登记业务涉及附件上传功能，基础规则不能够满足该功能需求，需执行步骤s4对规则进行扩展生成该需求功能相应的自定义规则。

步骤s4：规则扩展：根据实际业务需求生成自定义规则并将其存储于规则函数库中，然后执行步骤s3。

本发明实施例中自主扩展的附件上传规则如表1所示：

表1

优选地，本发明的规则扩展还提供以下两种方式：一是在底层框架的基础上，使用c#或java语言扩展平台的底层函数库，以适应复杂的服务开发及对接需求。由于服务开发平台底层分别实现了.net和java两套框架，支持利用原生代码开发扩展底层规则，例如，增加新的接口方式；二是基于脚本语言扩展规则，即通过脚本函数实现服务的继承与相互调用，实现了公共类服务的复用，提高了开发效率。

例如扩展规则时，通过原生代码开发进行扩展底层规则，其具体如下实现：

另外，通过脚本函数进行扩展时，首先定义编号，比如：

然后依据脚本的形式在数据库中存储，具体代码如下：

例如扩展脚本函数_math，该函数可用于执行数学任务，其在规则扩展时的代码实现具体如下：

步骤s3：服务实现：在业务模型和规则函数库的基础上，使用脚本语言开发服务并在线实时发布。

服务发布时，还需要设置服务的访问权限(get和post)。

如图3所示，使用脚本语言将参数、规则、外部函数注入脚本解析器，动态解释、实时执行，高效地实现服务逻辑。

下面以附件上传服务为例，说明将指定目录下的文件(url1)上传到指定服务器地址(url2)的实现：

fileupload("url2","url1")；

因为服务通过脚本语言实现，所以省去了服务开发中的编译、集成、发布环节，开发者只需通过图形用户界面设置服务的访问权限，即是否对外发布服务；设置服务的访问方式，即是否允许通过get或post方式访问服务，即可完成服务从实现到发布的全过程。

然而，在实际的服务开发过程中，往往会存在业务需求的变更或新增，为了能够及时地响应需求的变化，服务更新的过程为：使用脚本语言扩展现有的服务或开发新的服务，每个服务都拥有独立的生命周期，支持单独修改、更新任意服务。

另外，服务发布后将自动保存到服务器缓存中，为服务的热更新提供支持。服务的热更新是指在不停用服务的情况下，开发者对服务进行即时更新，在用户无感知的情况下完成系统修复及升级，用户只要重新上线就能体验更新后的服务。

进一步地，还包括步骤s5：服务更新步骤：根据用户的新需求，利用脚本语言开发生成新的脚本文件或对现有服务的脚本文件进行修改后生成新的脚本文件，并根据新的脚本文件实现相应的服务并发布。

也即是，本发明的具体工作原理为：当开发新服务的时候，首先执行步骤s1创建业务模型，然后执行步骤s2判断利用平台提供的基础规则是否能实现业务需求，若是，则执行步骤s3服务实现；若否，则执行步骤s4规则扩展；若业务需求发生变化时，执行服务更新的过程。

如图4所示，本发明还公开一种利用本发明提供服务实现方法的服务开发平台，包括：模型管理器、脚本解析器、可扩展规则库数据库访问引擎及前端用户界面，其中模型管理器、脚本解析器、可扩展规则库已经数据库访问引擎组成了一底层支撑框架，为前端用户界面的显示提供相应的支撑。

该服务开发平台能够支持多人在线协作地持续集成式服务开发，与传统的开发方式相比，有效提高了服务的开发效率，降低了服务的维护更新成本。

其中，模型管理器用于实现用户-业务逻辑-数据库之间的关联绑定；脚本解析器对脚本语言进行动态解释、实时执行，省去编译、集成的环节；可扩展规则库提供文件操作、数据库操作、关系模型操作、缓存操作、数据类型转换、即时通讯、加密解密、权限管理、异常处理等功能，支持按需扩展；数据库访问引擎用于控制多种数据源的访问权限并快速处理事务；前端用户界面提供在线的服务开发环境，支持多人协作、在线测试，即时修改即时生效。本发明公开的一种服务实现方法，具有以下特点：

1)通过合理地划分服务边界，实现服务的去中心化，独立发布、部署、维护，减少服务间的彼此耦合，增强系统的健壮性。

2)利用可视化建模的方式进行创建模型而非代码编写的方式实现数据的持久化、事务性操作、过滤排序及事件绑定，提供的可视化建模工具，学习成本低，灵活易用。

3)使用脚本语言(比如javascript)实现业务逻辑，支持脚本的动态解析和实时执行，省去服务的编译、集成、部署环节，为服务开发和升级提供便利。

4)支持在线、实时发布服务，结合缓存技术做到服务的热更新，实现服务的细粒度管理、针对性维护。

本发明还提供了一种电子设备，其包括存储器、处理器以及存储在存储器上并可在处理上运行的计算机程序，所述处理器执行所述程序时实现如文中所述的项目服务开发系统的构建方法的步骤。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如文中所述的项目服务开发系统的构建方法的步骤。

上述实施方式仅为本发明的优选实施方式，不能以此来限定本发明保护的范围，本领域的技术人员在本发明的基础上所做的任何非实质性的变化及替换均属于本发明所要求保护的范围。