适配VSCode插件的gRPC多类型消息转发的方法

技术领域

本发明涉及软件开发技术领域，尤其涉及到使用到webview，且对流式传输以及双向传输都有需求的消息交互技术领域，具体的说，是一种适配VSCode插件的gRPC多类型消息转发的方法。

背景技术

在现代IDE(Integrated Development Environment，集成开发环境)的发展前景下，VS Code成为了IDE行业中的领头羊，开发者可以通过其插件拓展系统开发专属于自己业务需求的插件或程序，来使其进一步适应于各种场景，满足各种形式的开发需求。在插件开发过程中，传统的HTTP请求对于要求快速灵活请求的IDE定制或插件开发并不是很契合，其单调的单向请求响应模型以及相对于其他轻量级交互协议较弱的性能更成为了在IDE定制开发中的极大阻碍。而gRPC作为一种现代开源高性能过程调用轻量级框架，其基于HTTP2.0协议的双向流式传输以及多种序列化协议的支持使其成为了一种更为适合IDE定制开发的交互协议。另外，其独有的protocol Buffer语言平台中立机制可以保证数据前后端共用一套数据描述方式，降低了双方沟通的成本，从技术上保证了接口数据类型信息的即时性，避免了前后端因数据结构以及文档更新滞后性造成的诸多问题。但gRPC相对于HTTP也存在不少痛点。例如无法做到像HTTP那样的广泛适配性，无法做到开箱即用。对各平台不同的技术实现方案的需求也成为了应用其到跨平台IDE中一个较大的痛点。尤其对于Web，因为浏览器目前没有办法提供完整可控制的HTTP 2.0，因此所必要的进一步的转发方案对于跨平台部署和开发都造成了相当大的障碍。如何在插件开发及其内嵌web应用中，在保证跨平台的情况下，做到对普通请求，服务端推送，流式传输，双向流式传输，断线重连等多种功能的支持，达到提高IDE开发中消息交互的效率，降低开发成本的目的，目前尚没有一种可行的方法。

发明内容

本发明的目的在于提供一种适配VSCode插件的gRPC多类型消息转发的方法，用于解决现有技术中无法在插件开发及其内嵌web应用中，在保证跨平台的情况下，做到对普通请求，服务端推送，流式传输，双向流式传输，断线重连等多种功能的支持的问题。

本发明通过下述技术方案解决上述问题：

一种适配VSCode插件的gRPC多类型消息转发的方法，包括：

步骤S100、在选定的客户端环境(如内嵌webview，插件环境或其他JS类似环境)中实现一组用于发送请求的函数(此函数使用的方式类似于普通web客户端的请求函数，其中包括请求的路径，请求的参数等消息)通过该函数收集客户端的请求的路径、参数和数据，添加类型和时间戳后将整个请求缓存并进行转发，以便后续步骤使用，实现客户端的请求信息可以完整无误地传递到iframe，这样就可以在下一步骤中进行转发，防止客户端发起异常的，无法控制的请求数据；

在使用者层面来说，此函数为了与普通web客户端的使用方式一致，采用常用的Promise异步函数的方式或者返回一个事件监听对象的方式。另外在此步骤还可以对请求信息进行校验，增加时间戳来支持并发，添加打印日志便于调试等功能；

步骤S200、获取请求的路径、参数，类型后，webview环境下通过iframe message机制进行消息筛选与转发，通过内置标识进行筛选并进行双向转发，使其消息能正常到达VSCode插件端代码；

这步骤实现将客户端发起的message转发给插件端，将插件端发起的message转发给客户端，通过类型区分这两类信息或其他请求类型的信息。在此步骤中，判定为客户端发起的请求将会调取VSCode插件开发系统提供的API传递给插件端，判定为插件端返回的响应函数则会通过iframe message机制中的消息传递函数转发给webview。从而实现两种信息的中转与转发。

步骤S300、插件端获取转发的请求的路径、参数和类型，按照约定标准对接收到的消息进行解析和格式化，提取出所有gRPC所需要的请求信息并采用标准的gRPC Node.JS请求流程发起gRPC请求，最后将响应结果封装成与步骤S100中的请求对应的格式，分别根据不同的函数类型进行消息封装与消息转发；

这一步骤将原来web发起gRPC的场景巧妙地转化为了Node.JS发起gRPC请求，具有以下优势：1)Node.JS不需要像浏览器web技术栈那样考虑各个浏览器对于HTTP 2.0技术的完全支持和控制，不需要涉及到请求代理转发，也就不涉及现存方案中请求代理跨平台部署困难的痛点。2)Node.JS原本就是VSCode插件开发的宿主环境技术栈，利用其进行gRPC请求合情合理，且没有多余的技术债务与性能负担。

步骤S400、客户端环境接收到所需的响应消息与参数，根据之前所调用的函数类型，分别转配为不同的响应内容进行返回。

步骤S300中，为了支持并发请求转发，在消息转发过程中加上一个依赖于当时时间戳的唯一标识，依照此唯一标识将消息转发给对应的响应函数或对象，确保每个监听函数拿到自己对应的响应结果。

所述唯一标识为一个对象池的唯一标识id，用于请求对象管理。对象池的实现保证了整个转发过程中，无论返回顺序或者并发数量如何，每个请求的对象都有一个或多个响应对象根据时间戳基准的id与之对应。从根本上保证了请求的可靠性和并发性，杜绝了别的技术方案可能会出现的请求错位和并发混乱的问题。

所述请求函数包括普通客户端请求函数，流式请求事件监听函数和服务端推送消息监听函数。接下来根据S100提到的响应类型分别阐述：

普通客户端请求函数封装为普通的异步Promise对象，在接受到响应时即可返回相应的结果。流式请求的组合响应也可等待所有的流式数据组合传输完成后，组合为完整的结果按照普通客户端请求函数的方式进行返回。

流式请求事件监听函数会在客户端发起请求时返回一个等同与gRPC的流式响应对象。在此对象上监听相应的事件，客户端会在接受到转发响应时，依次触发相应的事件。确保客户端的响应事件对象与标准gRPC的流式响应对象表现一致。

服务端推送消息监听函数会直接在发起请求时保持一个事件监听。无需发起请求，只要服务端推送与订阅一致的事件时，客户端即可接收到服务端推送的消息。

步骤S400与步骤S100对应，主要承担的职责就是对于响应信息进行一个总体的封装。其相对于S100主要的区别在于相对于请求信息，响应信息由于存在多种使用方式，所以要根据类型进行多种异步封装，以便于客户端使用。此步骤的目的就是将整个请求转发的过程封装处理为和正常HTTP请求类型的使用方式。让开发者无需过多地去关注不同技术栈之间的差距，像传统HTTP请求类型去调用函数即可拿到相应的响应信息。至此，整个请求响应转发的生命周期都已完成。在开发者层面来说，采用此方案之后，最大的更改只是更改了请求的函数函数，别的所有性能问题和兼容性问题都由gRPC的轻量化特性和Node.JS的一致性所抹平，对于业务来说，几乎没有学习成本，简单容易上手。对于性能来说，本方案由于gRPC本身二进制成帧和压缩和支持在单个TCP连接上多个HTTP 2.0的特性可以将请求时间缩短近一半。(经本地测试采用HTTP请求的平均时长在334.5ms，而gRPC可以缩短到184.89ms)

本发明与现有技术相比，具有以下优点及有益效果：

(1)本发明提供了一个VSCode插件开发跨平台时依旧稳定存在，而且对gRPC请求支持较好的Node.JS环境并依赖其进行转发；避免了因web无法完整支持HTTP 2.0所导致无法避免的多环境多依赖复杂的请求转发工具的部署和安装。同时本发明对于所需多类型的消息转发都有着比较完善的支持，使在VSCode及其内嵌webview开发过程中的gRPC请求开箱即用，简化了开发者的使用成本。另外依赖gRPC的全双工通信，轻量高效的特性，使得本发明在VSCode插件开发中可以赋予开发者更多的实现可能，为其他HTTP请求无法抑或不便实现的开发情况提出了方案和可能性，极大地拓展了VSCode插件开发的可能性。

(2)还可以拓展为插件端与其他场景客户端之间的双向通信以及其他相关的消息转发功能，整个方案具有良好的可拓展性。

附图说明

图1为本发明的消息流向系统架构图。

具体实施方式

下面结合实施例对本发明作进一步地详细说明，但本发明的实施方式不限于此。

在介绍本发明的实施例之前，首先对本文涉及的技术名词给予解释说明，如下：

IDE(IntegratedDevelopment Environment)：集成开发环境，通常包括编程语言编辑器，自动构建工具，调试器和图形用户界面(GUI)构建工具。

VSCode(Visual Studio Code)：一款微软公司提供的开源IDE，在开发人员中有着广泛的使用，其插件系统为其提供了及其丰富的拓展功能。

gRPC：一个现代开源的远程过程调用(Remote Procedure Call)框架，可以在任何地方运行。它可以有效地连接服务，从而实现高效的客户端-服务器通信。

webview：将web网页作为一个模块嵌入到目标开发容器的技术。通常用于移动端或者桌面端的内容开发与维护，具有跨平台，低耦合的特性。

HTTP：超文本传输协议。目前主流的用于客户端(浏览器)与服务器交互的应用级网络协议。在web环境中主要用来传输HTML页面，图片，脚本，样式表等资源。

HTTP 2.0：HTTP的2.0版本。其相对于目前广泛使用的HTTP 1.1版本，主要有以下特性：多路复用，二进制分帧，首部压缩，服务端推送。

protobuf Buffer：一种轻量级的数据交换格式，可以用于结构化数据序列化，通常用于数据存储或者RPC数据交换格式。gRPC依赖其提供数据交互的能力，规定了数据的类型和格式。而且可以同时被服务端和客户端使用，避免了传输格式不统一，数据解析错误等问题。

iframe message：iframe为一种在web中嵌入另一个标准web的技术。iframe中嵌入的网页相对于父页面来说是一个独立的页面，但其也可以通过postMessage方法向父页面发送消息，从而实现iframe与父页面的通信。

Node.js：目前最为广泛使用的JavaScript服务端运行环境。使得JavaScript可以在服务端运行，从而实现了前后端统一的开发语言。

Promise：一种主要应用于JavaScript编程语言异步编程的解决方案。可以避免回调地狱，使得异步编程更加简洁，易于理解。

实施例1：

结合附图1所示，一种适配VSCode插件的gRPC多类型消息转发的方法，包括：

步骤1.请求封装。在所选定的客户端环境中(web或其他客户端环境)实现一组供开发者使用的函数。此函数主要参数为请求的路径，请求的参数等消息。获取消息后，在消息体参数上添加请求类型与以时间戳为基础的唯一标识。将整个请求信息按照ifamemessage的机制发送给iframe等待转发。每个请求封装为订阅者模式，以便于后续响应信息的封装。

步骤2.消息转发。在iframe父容器层面进行消息监听。接收到请求消息后，根据消息体中的请求判定是请求信息还是响应信息。请求则通过VSCode插件API向插件端进行转发，如果是响应信息则通过iframe message机制向子容器进行转发。在整个过程中，如果发现不在现有转发类型的消息则不予处理，不影响与本方法无关的消息处理。

步骤3.Node.js gRPC消息发送与响应。在接受到请求消息后，依照gRPC Node.JS的标准客户端流程向gRPC服务器发起gRPC请求。根据返回的响应类型，分一次性或多次两种类型向客户端进行响应。

步骤4.响应封装。在客户端环境下，接收到来自于插件端环境的响应消息。根据请求类型进行响应消息封装：

普通请求在步骤3中一次性返回，根据唯一id找到对应监听的请求订阅对象，触发其数据事件，一次性返回响应结果。

流式传输在此步骤的特点为多个相同路径的请求或者响应。所以根据请求或者响应保留请求订阅对象，并持续触发对应的数据事件。

服务端推送消息不发起请求，调用时监听一个消息类型并返回一个事件监听对象。与第一种类型的对比仅仅为不主动发起请求，其余与第一种类型相同。

步骤5.并发请求转发支持。在步骤1、步骤4的封装中实现一个以唯一id为主键，订阅对象为值的哈希对象池。每次接受到响应时，根据请求体中所带的id来找到当初的订阅对象，并触发其数据事件。

尽管这里参照本发明的解释性实施例对本发明进行了描述，上述实施例仅为本发明较佳的实施方式，本发明的实施方式并不受上述实施例的限制，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。