一种分布式运行时介质的运行方法及装置与流程

本发明属于大数据技术领域，具体涉及一种分布式运行时介质的运行方法及装置。

背景技术：

服务网格是作为服务间通信的基础设施层提供技术服务的，其负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。其核心是提供统一的全局方法来控制和测量应用或服务之间的所有请求流量，在实践中，服务网格通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。现有的服务网格并没有给我们带来跟更多的新功能，它是用于解决其他工具已经解决过的问题如负载平衡、断路、重试、检测等，服务网格是在以kubernetes为基础的云原生生态环境下的功能重实现。服务网格提出的边车代理(sidecar)模式，很好的解决了微服务架构中网络通信的问题。

但除了网络(networking)外，生命周期(lifecycle)、状态(state)、捆绑(binding)也是分布式应用要解决的问题之一。网络问题可以借由服务网格比如istio予以解决。其他三个目前没有很好的解决方案，应用在开发时仍需注意这三个方面，增加了开发人员的负担与开发成本。

技术实现要素：

本发明属于大数据技术领域，针对现有技术中的问题，本发明通过http/grpc协议暴露封装分布式能力，在边车中集成各个语言的轻量级sdk，使其具备跨语言的特点，通过模块化能力抽取加上友好的双协议通信，开发人员可以轻松构建在云和边缘上运行并包含多种语言和弹性的分布式应用程序。同时边车作为一个独立的进程，和业务是解耦的，随着模式发展下去，微服务的治理功能会越来越丰富，也能够在不久的将来逐步解决中台架构下微服务化存在的问题。

为解决上述技术问题，本发明提供以下技术方案：

第一方面，本发明提供一种分布式运行时介质的运行方法，包括：

根据调用请求生成访问链接；

根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。

一实施例中，所述根据调用请求生成访问链接包括：

解析所述调用请求，以确定分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法；

根据所述分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法生成访问链接。

一实施例中，所述根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，包括：

利用命名解析组件解析以及和所述第一应用id查找所述第一应用侧边车；

接收所述处理结果，并转发至所述第一应用。

一实施例中，所述以使所述第一应用转发所述处理结果至所述第二应用侧边车以及第二应用包括：

接收由所述第一应用所发送的处理结果，并转发至所述第二应用侧边车，以使所述第二应用侧边车将所述处理结果转发至所述第二应用。

一实施例中，所述第一应用与所述第二应用采用不同编译语言编写。

第二方面，本发明提供一种分布式运行时介质的运行装置，包括：

访问链接生成模块，用于根据调用请求生成访问链接；

第一边车调用模块，用于根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。

一实施例中，所述访问链接生成模块包括：

调用请求计息单元，用于解析所述调用请求，以确定分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法；

访问链接生成单元，用于根据所述分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法生成访问链接。

一实施例中，所述第一边车调用模块包括：

第一边车查找单元，用于利用命名解析组件解析以及和所述第一应用id查找所述第一应用侧边车；

处理结果转发第一单元，用于接收所述处理结果，并转发至所述第一应用；

处理结果接收单元，用于接收由所述第一应用所发送的处理结果，并转发至所述第二应用侧边车，以使所述第二应用侧边车将所述处理结果转发至所述第二应用；

所述第一应用与所述第二应用采用不同编译语言编写。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现分布式运行时介质的运行方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现分布式运行时介质的运行方法的步骤。

从上述描述可知，本发明实施例提供的分布式运行时介质的运行方法及装置，首先根据调用请求生成访问链接；接着，根据访问链接调用第一应用侧边车，并转发第一应用的处理结果至第一应用，以使第一应用转发处理结果至第二应用侧边车以及第二应用。本发明通过http/grpc协议暴露封装分布式能力，在边车中集成各个语言的轻量级sdk，使其具备跨语言的特点，通过模块化能力抽取加上友好的双协议通信，开发人员可以轻松构建在云和边缘上运行并包含多种语言和弹性的分布式应用程序。同时边车作为一个独立的进程，和业务是解耦的，随着模式发展下去，微服务的治理功能会越来越丰富，也能够在不久的将来逐步解决中台架构下微服务化存在的问题。

附图说明

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

图1为本发明的实施例中分布式运行时介质的运行方法流程示意图；

图2为本发明的实施例中步骤100的流程示意图；

图3为本发明的实施例中步骤200的流程示意图一；

图4为本发明的实施例中步骤200的流程示意图二；

图5为本发明的具体应用实例中分布式运行时介质的运行方法的流程示意图；

图6为本发明实施例中分布式运行时介质的运行装置结构框图；

图7为本发明的实施例中访问链接生成模块10的结构框图；

图8为本发明的实施例中第一边车调用模块20的结构框图一；

图9为本发明的实施例中第一边车调用模块20的结构框图二；

图10为本发明的实施例中的电子设备的结构示意图。

具体实施方式

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本发明的实施例提供一种分布式运行时介质的运行方法的具体实施方式，参见图1，该方法具体包括如下内容：

步骤100：根据调用请求生成访问链接。

可以理解的是，边车模式(sidecarpattern)和哈雷车类似原理：把一个应用的不同组件部署到不同的进程或容器中，以提供隔离和封装，应用的各个组件各自维护更新。这种模式还可以使应用由异构组件和技术组成，比如java服务和consul注册中心。为应用添加其他功能：监控、日志、配置中心、路由及熔断等功能；这样避免了在应用本身利用aop技术或其他添加代码的方式让应用的体积变大。具体地，边车模式具有以下优点：低耦合：为应用容器添加增强功能，而对其不变动；单一职责：每个容器的职责不同；即使sidecar容器失败，应用容器不受影响；可复用；各自更新，不相互影响

步骤100在实施时，具体地，首先使用http/grpcapi这种与语言无关的方式暴露封装的分布式能力供应用调用，同时抽取分布式能力作为构建块，封装成分布式运行时并通过规范的api暴露以提供不同的分布式能力，诸如服务调用，状态管理，发布订阅，监控等。相比较于服务网格，本方案中的边车是对应用暴露的。

接着，按照post/get/put/deletehttp://localhost:<drport>/version/invoke/<appid>/method/<method-name>的格式进行访问，drport为分布式运行时边车暴露的端口，version是对应的版本号，invoke是指进行服务间的调用，appid是应用侧应用的唯一识别号，method-name具体到调用的方法。那假设pythonapp需要访问nodeapp的方法，就需要post一个请求到比如http://localhost:3500/v1.0/invoke/nodeapp/method/neworder。

步骤200：根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。

具体地，首先第一应用侧边车与实际服务是配对的，拥有服务所包含的接口，因此会把调用请求再次转发给服务即第一应用，完成相应的业务处理。第一应用侧处理完后把结果返回给自身侧的边车。

接着，第一应用侧边车把处理结果发送第二应用侧边车，第二应用侧边车再把该处理结果发送至第二应用，从而完成一次服务调用。

从上述描述可知，本发明实施例提供的分布式运行时介质的运行方法，首先根据调用请求生成访问链接；根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。本发明通过http/grpc协议暴露封装分布式能力，在边车中集成各个语言的轻量级sdk，使其具备跨语言的特点，通过模块化能力抽取加上友好的双协议通信，开发人员可以轻松构建在云和边缘上运行并包含多种语言和弹性的分布式应用程序。同时边车作为一个独立的进程，和业务是解耦的，随着模式发展下去，微服务的治理功能会越来越丰富，也能够在不久的将来逐步解决中台架构下微服务化存在的问题。

一实施例中，参见图2，步骤100包括：

步骤101：解析所述调用请求，以确定分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法；

步骤102：根据所述分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法生成访问链接。

针对步骤101以及步骤102，这里提供了一种服务间方法调用的接口规范，需要按照post/get/put/deletehttp://localhost:<drport>/version/invoke/<appid>/method/<method-name>的格式进行访问，其中：drport为分布式运行时边车暴露的端口，version是对应的版本号，invoke是指进行服务间的调用，appid是应用侧应用的唯一识别号，method-name具体到调用的方法。假设pythonapp需要访问nodeapp的方法，就需要post一个请求到比如http://localhost:3500/v1.0/invoke/nodeapp/method/neworder。

一实施例中，参见图3，步骤200包括：

步骤201：利用命名解析组件解析以及和所述第一应用id查找所述第一应用侧边车；

其中命名解析依赖轻量级的各种语言的sdk实现。这些诸如drport，url形式均在应用侧以配置的方式直接定义。使用接口规范的意义就是为了实现对服务间网络通信的控制以完成诸如服务发现、流量控制、重试熔断、安全访问等功能，而这相关的网络控制功能也是集成在边车代理中。

步骤202：接收所述处理结果，并转发至所述第一应用。

一实施例中，参见图4，步骤200还包括：

步骤203：接收由所述第一应用所发送的处理结果，并转发至所述第二应用侧边车，以使所述第二应用侧边车将所述处理结果转发至所述第二应用；

一实施例中，所述第一应用与所述第二应用采用不同编译语言编写。

使用http/grpcapi这种与语言无关的方式暴露封装的分布式能力供应用调用，并且在边车中集成各个语言的轻量级sdk，使其具备跨语言的特点，通过模块化能力抽取加上友好的双协议通信，开发人员可以轻松构建在云和边缘上运行并包含多种语言和弹性的分布式应用程序。

为进一步地说明本方案，本发明还以nodeapp(第一应用)以及pythonapp(第二应用)为例，提供分布式运行时介质的运行方法的具体应用实例，参见图5，具体包括如下内容。

属于介绍：

分布式运行时：提供了分布式应用运行所需要的执行环境。

构建块：用于提供某种分布式基础能力的运行时模块。

s1：按照接口规范建立调用链接。

通过封装服务调用能力实现跨服务方法调用，比如nodeapp暴露了一个api：http://10.0.0.2:8000/neworder，按照现有技术中的方式，可以直接httppost这个api访问。在服务网格中，也还是使用原有的posturl，服务网格的边车代理做了流量挟持，以应用无感的方式做了服务调用。但在本申请中，分布式运行时提供了一种服务间方法调用的接口规范，需要按照post/get/put/deletehttp://localhost:<drport>/version/invoke/<appid>/method/<method-name>的格式进行访问，drport为分布式运行时边车暴露的端口，version是对应的版本号，invoke是指进行服务间的调用，appid是应用侧应用的唯一识别号，method-name具体到调用的方法。那假设pythonapp需要访问nodeapp的方法，就需要post一个请求到比如http://localhost:3500/v1.0/invoke/nodeapp/method/neworder。

s2：调用pythonapp侧的边车。

url会先调到在pythonapp侧的边车，此侧边车通过命名解析组件解析以及和唯一的appid找到nodeapp侧的边车并把请求转发给它。

s3：转发处理结果至pythonapp。

首先，nodeapp侧的边车再把处理结果返回给pythonapp侧的边车。接着，pythonapp侧的边车再把数据返回给pythonapp。完成了一次服务调用。

此外在这种接口规范下分布式运行时还能做到建立在事件驱动架构的基础之上的资源绑定及事件触发。通过建立触发器与资源的绑定，可以从任何外部源(例如数据库，队列，文件系统等)接收和发送事件，而无需借助消息队列，即可实现灵活的业务场景。分布式运行时有两种绑定模式，输入绑定：当外部资源的事件发生时，借助输入绑定，应用即可通过特定的api：posthttp://localhost:<appport>/<name>收到外部资源的事件，用于处理特定逻辑。输出绑定：输出绑定允许调用外部资源。比如，在订单处理场景中，在订单创建成功后，可以将订单信息通过分布式运行时的绑定api：post/puthttp://localhost:<drport>/v1.0/bindings/<name>输出到kafka特定队列上。

另一方面，服务间的状态共享、并发一致性问题则是分布式绕不开的话题。对于状态共享，分布式运行时以友好的httpapi的方式进行状态的存储和读取，并支持通过选项设置并发和一致性行为。存储：posthttp://localhost:<drport>/v1.0/state/<storename>

读取：gethttp://localhost:<drport>/v1.0/state/<storename>/<key>

删除：deletehttp://localhost:<drport>/v1.0/state/<storename>/<key>

可以理解的是，模块化以及接口规范带来的好处就在于开发的时候只需要关心规范接口，并使用某些简单易得的存储组件来进行调试，比如数据库存储组件等；运行的时候可以引入(替换)为其他存储组件，而无需改变业务代码。

从上述描述可知，本发明实施例提供的分布式运行时介质的运行方法，首先根据调用请求生成访问链接；接着，根据访问链接调用第一应用测边车，并转发第一应用的处理结果至第一应用；最后转发处理结果至第二应用侧边车以及第二应用。本发明优化了现有服务网格技术功能只覆盖网络通信层面的不足，将分布式能力进行封装下沉作为运行时搭配接口规范以简化分布式应用开发的技术复杂度，提供了一种服务网格能力优化的方法。

基于同一发明构思，本申请实施例还提供了一种分布式运行时介质的运行装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于分布式运行时介质的运行装置解决问题的原理与分布式运行时介质的运行方法相似，因此分布式运行时介质的运行装置的实施可以参见分布式运行时介质的运行方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现分布式运行时介质的运行方法的分布式运行时介质的运行装置的具体实施方式，参见图6，分布式运行时介质的运行装置具体包括如下内容：

访问链接生成模块10，用于根据调用请求生成访问链接；

第一边车调用模块20，用于根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。

一实施例中，参见图7，所述访问链接生成模块10包括：

调用请求计息单元101，用于解析所述调用请求，以确定分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法；

访问链接生成单元102，用于根据所述分布式系统中的边车端口、版本号、服务间的调用信息、应用的唯一识别号以及调用方法生成访问链接。

一实施例中，参见图8，所述第一边车调用模块20包括：

第一边车查找单元201，用于利用命名解析组件解析以及和所述第一应用id查找所述第一应用侧边车；

处理结果转发第一单元202，用于接收所述处理结果，并转发至所述第一应用；

一实施例中，参见图9，所述第一边车调用模块20还包括：

处理结果接收单元203，用于接收由所述第一应用所发送的处理结果，并转发至所述第二应用侧边车，以使所述第二应用侧边车将所述处理结果转发至所述第二应用；

所述第一应用与所述第二应用采用不同编译语言编写。

从上述描述可知，本发明实施例提供的分布式运行时介质的运行装置，首先根据调用请求生成访问链接；接着，根据访问链接调用第一应用测边车，并转发第一应用的处理结果至第一应用；最后转发处理结果至第二应用侧边车以及第二应用。本发明通过http/grpc协议暴露封装分布式能力，在边车中集成各个语言的轻量级sdk，使其具备跨语言的特点，通过模块化能力抽取加上友好的双协议通信，开发人员可以轻松构建在云和边缘上运行并包含多种语言和弹性的分布式应用程序。同时边车作为一个独立的进程，和业务是解耦的，随着模式发展下去，微服务的治理功能会越来越丰富，也能够在不久的将来逐步解决中台架构下微服务化存在的问题。

本申请的实施例还提供能够实现上述实施例中的分布式运行时介质的运行方法中全部步骤的一种电子设备的具体实施方式，参见图10，电子设备具体包括如下内容：

处理器(processor)1201、存储器(memory)1202、通信接口(communicationsinterface)1203和总线1204；

其中，处理器1201、存储器1202、通信接口1203通过总线1204完成相互间的通信；通信接口1203用于实现服务器端设备以及客户端设备等相关设备之间的信息传输；

处理器1201用于调用存储器1202中的计算机程序，处理器执行计算机程序时实现上述实施例中的分布式运行时介质的运行方法中的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：根据调用请求生成访问链接；

步骤200：根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。

本申请的实施例还提供能够实现上述实施例中的分布式运行时介质的运行方法中全部步骤的一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的分布式运行时介质的运行方法的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：根据调用请求生成访问链接；

步骤200：根据所述访问链接调用第一应用侧边车，并转发所述第一应用的处理结果至第一应用，以使所述第一应用转发所述处理结果至第二应用侧边车以及第二应用。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。