CN116743833A - 增强终端与服务通讯能力和网络控制能力的方法和装置 - Google Patents

Abstract

本发明提供了一种增强终端与服务通讯能力和网络控制能力的方法和装置，属于网络安全的技术领域，该方法中，RPC API网关中采用的是IDL‑less的RPC框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现，增强了RPC API网关的通讯能力，且通过RPC API网关对服务流量和传输速率进行控制，保障服务的连续性，增强了RPC API网关的网络控制能力，进而增强了终端与服务的通讯能力和网络控制能力。

Description

增强终端与服务通讯能力和网络控制能力的方法和装置

技术领域

本发明涉及网络安全的技术领域，尤其是涉及一种增强终端与服务通讯能力和网络控制能力的方法和装置。

背景技术

传统模式下，程序的运行都是本地编写程序，编译后在本地执行，调用本地资源，在数据日益膨胀的今天，计算量增大，显然使用这种方式是不行的，需要寻找一种方式能够使用其它主机上的资源来完成计算任务，然后结果汇总到本地主机上，类似于分布式计算，和hadoop的实现方式有点相似，其实hadoop就是利用RPC来实现的。

RPC技术最早出现在1981年由Nelson提出，1984年，Birrell和Nelson把RPC用在支持异构型分布式系统之间通讯，Birrel的RPC模型引入存根进程(stub)作为远程进程的本地代理，调用RPC运行时库(RPC runtime)来传输网络中的调用。stub与rpc runtime屏蔽了网络调用所涉及的众多细节，由于分布式系统的异构性以及分布式计算与计算任务的多样性，RPC作为网络通信与委托计算的实现机制，在实现上种类繁多，其中以Sun公司提出的NFS为主，这个主要是分布式存储；开放软件基金会（OSF）提出的ONC，这个主要用于分布式计算。

API网关提供微服务（如其它主机）的全生命周期管理，实现API定义、开发、测试、部署、运维、调用的标准化与规范化管理。服务目录可将服务资产分类展示以提供共享。提供微服务版本管理和REST、Dubbo不同协议类型接口定义。API网关实现对平台开发微服务或外部应用的反向代理、负载均衡，提供API调用时的安全认证功能。提供API调试和分析功能，实现微服务的代码管理、自动化构建和部署。

对于一般的RPC API网关，能访问到的服务来自于同一个集群，通过服务注册和发布组件来实现服务寻址，通过各式各样的API 网关来达到对服务的访问。

现有技术方案中针对RPC API网关的能力、网络控制能力等技术方式存在的问题如下：

面对多种网络架构复杂问题，RPC API网关能力有待增强：在当前的应用场景下，会遇到各种网络结构，包括总线型、星型、树型、网状和多种基本型相结合的复杂网络组网方式。如级联部署的场景中，存在跨集群访问的需求、不同的集群部署需求和网络访问规则可能互不相同。当访问其他集群的服务时，业务层并不需要关心服务是如何部署，不需要知道哪个区域或集群提供最终的服务实现，只需要关心服务名称和调用参数。

面对带宽资源不足问题，RPC API网关急需提升网络控制能力：终端（可以是指客户端，即本地主机）和控制台（可以是指RPC API网关）通讯常用的方法是使用长连接，当终端数量非常多的情况下，资源占用就会成为问题。这些资源不仅仅包括端口这一类的静态资源，还包括流量这一类的动态资源，网络框架需要通过增强对终端的网络控制能力，满足带宽资源控制的情况下最大限度的利用带宽资源。

综上，如何增强RPC API网关的通讯能力和网络控制能力，以增强终端与服务的通讯能力和网络控制能力成为目前亟需解决的技术问题。

发明内容

有鉴于此，本发明的目的在于提供一种增强终端与服务通讯能力和网络控制能力的方法和装置，以缓解现有的终端与服务的通讯能力差、网络控制能力有待加强的技术问题。

第一方面，本发明实施例提供了一种增强终端与服务通讯能力和网络控制能力的方法，应用于RPC API网关，所述RPC API网关为终端和微服务之间的中间层，且所述RPCAPI网关中采用的是IDL-less的RPC框架，所述方法包括：

获取所述终端发起的服务访问请求；

判断所述服务访问请求与限流规则是否匹配；

如果匹配，则基于限流算法判断所述服务访问请求是否限流；

如果限流，则丢弃所述服务访问请求；

如果不匹配或不限流，则将所述服务访问请求路由至所述微服务中对应的服务器，以使所述服务器执行所述服务访问请求对应的操作，并将所述操作的结果经由所述RPCAPI网关返回至所述终端。

进一步的，所述IDL-less的RPC框架包括：将RPC的服务器的接口汇聚到所述RPCAPI网关内，将RPC的终端的接口汇聚到所述RPC API网关内。

进一步的，所述RPC API网关包括：内置于所述终端内的RPC和存根，以及内置于所述服务器内的RPC和存根。

进一步的，所述RPC API网关提供的传输方式包括：基于TCP的传输和基于Quic协议的UDP传输。

进一步的，基于限流算法判断所述服务访问请求是否限流，包括：

判断所述服务访问请求是否有令牌；

若所述服务访问请求没有令牌，则确定所述服务访问请求限流。

进一步的，所述令牌为从令牌桶获取得到的，所述令牌桶中的令牌为根据限流大小确定的令牌添加速率添加令牌得到的。

进一步的，所述令牌桶设置有最大放置令牌限制，当达到所述最大放置令牌限制时，新添加的令牌被丢弃或者拒绝；

所述令牌桶设置有最小放置令牌限制，当所述令牌桶中的令牌达到所述最小放置令牌限制时，所述服务访问请求处理完之后将不会删除所述服务访问请求的令牌。

第二方面，本发明实施例还提供了一种增强终端与服务通讯能力和网络控制能力的装置，应用于RPC API网关，所述RPC API网关为终端和微服务之间的中间层，且所述RPCAPI网关中采用的是IDL-less的RPC框架，所述装置包括：

获取单元，用于获取所述终端发起的服务访问请求；

第一判断单元，用于判断所述服务访问请求与限流规则是否匹配；

第二判断单元，用于如果匹配，则基于限流算法判断所述服务访问请求是否限流；

丢弃单元，用于如果限流，则丢弃所述服务访问请求；

路由单元，用于如果不匹配或不限流，则将所述服务访问请求路由至所述微服务中对应的服务器，以使所述服务器执行所述服务访问请求对应的操作，并将所述操作的结果经由所述RPC API网关返回至所述终端。

在本发明实施例中，提供了一种增强终端与服务通讯能力和网络控制能力的方法，应用于RPC API网关，RPC API网关为终端和微服务之间的中间层，且RPC API网关中采用的是IDL-less的RPC框架，该方法包括：获取终端发起的服务访问请求；判断服务访问请求与限流规则是否匹配；如果匹配，则基于限流算法判断服务访问请求是否限流；如果限流，则丢弃服务访问请求；如果不匹配或不限流，则将服务访问请求路由至微服务中对应的服务器，以使服务器执行服务访问请求对应的操作，并将操作的结果经由RPC API网关返回至终端。通过上述描述可知，本发明的增强终端与服务通讯能力和网络控制能力的方法中，RPC API网关中采用的是IDL-less的RPC框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现，增强了RPC API网关的通讯能力，且通过RPC API网关对服务流量和传输速率进行控制，保障服务的连续性，增强了RPC API网关的网络控制能力，进而增强了终端与服务的通讯能力和网络控制能力，缓解了现有的终端与服务的通讯能力差、网络控制能力有待加强的技术问题。

附图说明

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

图1为本发明实施例提供的一种增强终端与服务通讯能力和网络控制能力的方法的流程图；

图2为本发明实施例提供的终端、RPC API网关和微服务之间的结构示意图；

图3为本发明实施例提供的基于RPC的远程过程调用原理的示意图；

图4为本发明实施例提供的RPC API网关与终端和服务器的结构示意图；

图5为本发明实施例提供的令牌算法的示意图；

图6为本发明实施例提供的一种增强终端与服务通讯能力和网络控制能力的装置的示意图；

图7为本发明实施例提供的一种电子设备的示意图。

具体实施方式

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

现有的终端与服务的通讯能力差、网络控制能力有待加强。

基于此，本发明的增强终端与服务通讯能力和网络控制能力的方法中，RPC API网关中采用的是IDL-less的RPC框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现，增强了RPC API网关的通讯能力，且通过RPC API网关对服务流量和传输速率进行控制，保障服务的连续性，增强了RPC API网关的网络控制能力，进而增强了终端与服务的通讯能力和网络控制能力。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种增强终端与服务通讯能力和网络控制能力的方法进行详细介绍。

实施例一：

根据本发明实施例，提供了一种增强终端与服务通讯能力和网络控制能力的方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的一种增强终端与服务通讯能力和网络控制能力的方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，获取终端发起的服务访问请求；

在本发明实施例中，该增强终端与服务通讯能力和网络控制能力的方法可以应用于RPC API网关，RPC API网关为终端和微服务之间的中间层，且RPC API网关中采用的是IDL-less的RPC框架。

本发明的增强终端与服务网络控制能力的方法是在微服务（即RPC服务）和终端（即客户端）之间建立一种对数据流量进行控制的能力，所有到RPC服务端的数据流量都控制在一个可接受的范围之内，保障业务持续性。

图2中示出了终端、RPC API网关和微服务之间的结构示意图，RPC API网关是介于终端和微服务之间的中间层，所有的外部请求都会先经过RPC API网关这一层。这样安全、性能、监控可以交由RPC API网关来做。RPC API网关结合接口和网关的双重功能，能够直接进行相关的鉴权，安全控制，日志统一处理，易于监控。

对于后端微服务来说，它们提供的服务都有一个极限的QPS(除代码逻辑外，也跟机器配置有关)，当服务器的压力超过这个极限值时，服务器的响应性能就会快速的下降，然后无法提供服务，所以，服务器需要一个类似于可以限制请求数的功能，使服务器能牺牲掉部分请求，保证还能处理一定量的请求，防止服务器出现压力瓶颈，无法处理所有请求。

限流的作用本质上是差不多的，一般只涉及到两个维度：

时间：对某个时间窗口进行限流；

资源：针对某个API或者某个API的参数进行限流，达到保护后方对应的资源。

限流可以保证在某段时间内的某个资源的请求数量不会超过设计值，达到保护系统的作用，不过不同场景主要差别是限制的资源维度不一样，资源维度的变化从总体服务到某个API到某个API的某个参数，资源维度越来越细，而这个资源维度区分也就是要实现限流的第一步--流量匹配，只要流量匹配了，限流系统就可以开始工作。

在实现时，先获取终端发起的服务访问请求。

步骤S104，判断服务访问请求与限流规则是否匹配；

步骤S106，如果匹配，则基于限流算法判断服务访问请求是否限流；

步骤S108，如果限流，则丢弃服务访问请求；

步骤S110，如果不匹配或不限流，则将服务访问请求路由至微服务中对应的服务器，以使服务器执行服务访问请求对应的操作，并将操作的结果经由RPC API网关返回至终端。

上述过程简言之为：规则匹配，RPC API网关会通过一个函数把流量（即服务访问请求）提取出来，当做Key，这个Key等于某个资源，然后判断这个Key是否匹配到限流规则，如果命中限流规则就开始执行限流规则，并结合这段规则和限流算法来判断该流量是否限流，如果限流就丢弃或者等待，如果没被限流，就直接放行。

所谓的放行即为将服务访问请求路由至微服务中对应的服务器，以使服务器执行服务访问请求对应的操作，并将操作的结果经由RPC API网关返回至终端。

在技术实现上，RPC是建立在Socket之上的，一台主机上运行的主程序，可以调用另一台主机上准备好的子程序，就像本地调用子程序一样，不需要知道底层网络实现的细节。RPC使用类似C/S模型，请求的时候，请求程序为客户端（即终端），而服务提供的程序则是服务器。使用C/S模型忽略通讯的具体细节，从而程序员不必关心C/S之间的通信协议，集中精力实现其过程就可以了，这一点就决定了RPC生成的通讯包不可能对每种应用都有最恰当的处理方法，与Socket相比会占用更多地网络带宽与系统资源。

RPC（Remote Procedure Call 远程过程调用），是一个计算机通信协议。该协议允许运行于一台计算机的程序，像调用本地方法一样，调用另一台计算机的子程序。服务端实现一个函数，客户端使用 RPC 框架提供的接口，像调用本地函数一样调用这个函数，并获取返回值。

基于RPC的远程过程调用原理如下，参考图3：

客户端（即终端）以正常的方式调用客户存根；

客户存根生成一个消息，然后调用本地操作系统；

客户端操作系统将消息发送给远程操作系统；

远程操作系统将消息交给服务器存根；

服务器存根将参数提取出来，而后调用服务器；

服务器执行要求的操作，操作完成后将结果返回给服务器存根；

服务器存根将结果打包成一个消息，而后调用本地操作系统；

服务器操作系统将含有结果的消息发送给客户端操作系统；

客户端操作系统将消息交给客户存根；

客户存根将结果从消息中提取出来，返回给调用它的客户端。

Stub（即存根）负责调用参数和返回值的序列化（serialization）、参数的打包和解包、网络层的通信。

微服务（Microservices）是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。目前以SpringCloud、阿里Dubbo等为流开源微服务框架为主，在ToC业务系统、企业级管理系统领域均得到了广泛使用，可以实现业务解耦、自动伸缩、数据分治、异常隔离、持续升级等优点特性。

在本发明实施例中，提供了一种增强终端与服务通讯能力和网络控制能力的方法，应用于RPC API网关，RPC API网关为终端和微服务之间的中间层，且RPC API网关中采用的是IDL-less的RPC框架，该方法包括：获取终端发起的服务访问请求；判断服务访问请求与限流规则是否匹配；如果匹配，则基于限流算法判断服务访问请求是否限流；如果限流，则丢弃服务访问请求；如果不匹配或不限流，则将服务访问请求路由至微服务中对应的服务器，以使服务器执行服务访问请求对应的操作，并将操作的结果经由RPC API网关返回至终端。通过上述描述可知，本发明的增强终端与服务通讯能力和网络控制能力的方法中，RPC API网关中采用的是IDL-less的RPC框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现，增强了RPC API网关的通讯能力，且通过RPC API网关对服务流量和传输速率进行控制，保障服务的连续性，增强了RPC API网关的网络控制能力，进而增强了终端与服务的通讯能力和网络控制能力，缓解了现有的终端与服务的通讯能力差、网络控制能力有待加强的技术问题。

在本发明实施例中，IDL-less的RPC框架包括：将RPC的服务器的接口汇聚到RPCAPI网关内，将RPC的终端的接口汇聚到RPC API网关内。

参考图4，RPC API网关包括：内置于终端内的RPC和存根，以及内置于服务器内的RPC和存根。

RPC API网关提供的传输方式包括：基于TCP的传输和基于Quic协议的UDP传输。

具体的，本发明提出的增强终端与服务的通讯能力是在RPC API网关和客户端（即终端）之间搭建多种通讯模式，对网络连接涉及TCP传输采用TLS安全协议摆渡、涉及UDP传输QUIC可靠协议摆渡。

代码实现示例：

Server端

package Server;

public interface EchoService {

String echo(String ping);

}

package Server;

public class EchoServiceImpl implements EchoService{

@Override

public String echo(String ping) {

// TODO Auto-generated method stub

return ping !=null?ping+"-->I am ok.":"I am bad.";

}

}

Exporter端

package Exporter;

import java.io.IOException;

import java.io.ObjectInputStream;

import java.io.ObjectOutputStream;

import java.lang.reflect.Method;

import java.net.InetSocketAddress;

import java.net.ServerSocket;

import java.net.Socket;

import java.util.concurrent.Executor;

import java.util.concurrent.Executors;

RPC服务端发布者：

（1）作为服务端，监听客户端的TCP连接，接收到新的客户端连接之后，将其封装成Task，由线程池执行；

（2）将客户端发送的码流反序列化成对象，反射远程调用服务实现者，获取执行结果；

（3）将执行结果对象发反序列化，通过Socket发送给客户端；

（4）远程调用完成之后，释放Socket等连接资源，防止句柄泄露。

@author Administrator

public class RpcExporter {

//创建一个可重用固定线程数的线程池

//Runtime.getRuntime().availableProcessors()返回虚拟机可用的处理器数量

static Executor executor=Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

public static void exporter(String hostname,int port) throwsIOException {

//创建一个监听特定端口的Serversocket,负责接收客户连接请求

ServerSocket server = new ServerSocket();

//绑定主机名端口号

server.bind(new InetSocketAddress(hostname,port));

try{

while(true)

{

executor.execute(new ExporterTask(server.accept()));

}

}finally

{

server.close();

}

}

private static class ExporterTask implements Runnable{

Socket client=null;

public ExporterTask(Socket client){

this.client=client;

}

@Override

public void run() {

// TODO Auto-generated method stub

ObjectInputStream input=null;

ObjectOutputStream output=null;

try{

//获取输入流

input=new ObjectInputStream(client.getInputStream());

//获取调用的接口名

String interfaceName = input.readUTF();

//加载接口

Class<?>service = Class.forName(interfaceName);

//获取调用的方法名

String methodName = input.readUTF();

//获取方法返回类型

Class<?>[] ParameterTypes = (Class<?>[]) input.readObject();

//获取参数

Object[] arguments = (Object[]) input.readObject();

//通过反射获取方法

Method method = service.getMethod(methodName, ParameterTypes);

//通过反射调用方法

Object result = method.invoke(service.newInstance(), arguments);

output = new ObjectOutputStream(client.getOutputStream());

output.writeObject(result);

}catch(Exception e){

e.printStackTrace();

}

finally{

if(output != null)

try{

output.close();

}catch ( IOException e){

e.printStackTrace();

}

if(input !=null)

try{

input.close();

}catch(IOException e){

e.printStackTrace();

}

if(client != null)

try{

client.close();

}catch (IOException e){

e.printStackTrace();

}

}

}

}

}

Client端

package Client;

import java.io.ObjectInputStream;

import java.io.ObjectOutputStream;

import java.lang.reflect.InvocationHandler;

import java.lang.reflect.Method;

import java.lang.reflect.Proxy;

import java.net.InetSocketAddress;

import java.net.Socket;

本地服务代理：

（1）将本地的接口调用转换成JDK的动态代理，在动态代理中实现接口的远程调用；

（2）创建Socket客户端，根据指定地址连接远程服务提供者；

（3）将远程服务调用所需要的接口类，方法名，参数列表等编码参数发送给服务提供者；

（4）同步阻塞等待服务端返回应答，获取应答之后返回。

@author Administrator

@param<S>

public class RpcImporter<S>{

@SuppressWarnings("unchecked")

public S importer(final Class<?>serviceClass,final InetSocketAddressaddr)

{

return (S) Proxy.newProxyInstance(serviceClass.getClassLoader(),newClass<?>[] {serviceClass.getInterfaces()[0]}, new InvocationHandler() {

@Override

public Object invoke(Object proxy, Method method, Object[] args)throws Throwable {

// TODO Auto-generated method stub

Socket socket =null;

ObjectOutputStream output = null;

ObjectInputStream input = null;

try{

socket = new Socket();

socket.connect(addr);

//将远程服务调用所需要的接口类，方法名，参数列表等编码参数发送给服务提供者

output = new ObjectOutputStream(socket.getOutputStream());

output.writeUTF(serviceClass.getName());

output.writeUTF(method.getName());

output.writeObject(method.getParameterTypes());

output.writeObject(args);

//同步阻塞等待服务端返回应答，获取应答之后返回

input= new ObjectInputStream(socket.getInputStream());

return input.readObject();

}

finally{

if(socket != null)

socket.close();

if(output != null)

output.close();

if(input != null)

input.close();

}

}

});

}

}

测试代码：

package test;

import java.net.InetSocketAddress;

import Client.RpcImporter;

import Exporter.RpcExporter;

import Server.EchoService;

import Server.EchoServiceImpl;

public class run {

public static void main(String[] args) {

// TODO Auto-generated method stub

//创建异步发布服务端的线程并启动，用于接受PRC客户端的请求，根据请求参数调用服务实现类，返回结果给客户端

new Thread(new Runnable() {

@Override

public void run() {

// TODO Auto-generated method stub

try{

RpcExporter.exporter("localhost", 8088);

}catch (Exception e){

e.printStackTrace();

}

}

}).start();

//创建客户端服务代理类，构造RPC情求参数，发起RPC调用

RpcImporter<EchoService>importer=new RpcImporter<EchoService>();

EchoService echo = importer.importer(EchoServiceImpl.class, newInetSocketAddress("localhost",8088));

System.out.println(echo.echo("Are u ok?"));

}

}

QUIC协议

QUIC全称Quick UDP Internet Connection，该协议是一种基于UDP的低时延的互联网传输层协议。

QUIC协议对比TCP协议，主要最优化在于：

一、增加多种拥塞控制算法；

二、增加了时间戳选项，可有效提高RTT的测量精准性；

三、大大降低建立连接时间；

四、增加SACK，优化判断丢包的精准性，有效提高数据重传效率。

TCP协议对比QUIC协议，主要优势在于：一是TCP滑动窗口能够同时兼顾流量控制及保序；二是TCP拥有更加简洁的协议头，但又不失可靠性。总而言之，QUIC与TCP各有千秋，在数据吞吐上，QUIC毫无疑问更加优秀，但是在资源占用方面，TCP又是优于QUIC。所以无论是TCP还是QUIC，它们都是在特定环境下不可替代的存在，因此在本发明中将二者互为备份，建立了高效、完整、保密、可靠的通讯连接。

IDL-less的RPC框架：

IDL，Interface description language，即接口描述语言。

IDL是一种很有用的工具，它提供了对接口的描述，约定了接口协议。使得通讯双方通讯时，无需再发送 scheme，有效提高了通讯数据的荷载比。

但对于RPC框架而言，IDL又不仅仅是一个接口描述语言。对于市面上绝大多数的RPC框架而言，IDL还是一个工具和一种使用过程，专指根据 IDL 描述文件，用指定的开发语言，生成对应的服务端接口模块，和客户端程序。这样的好处是，便于开发者快速开发。

依据 IDL 生成对应的客户端和接口模块，这个本质是编译。但对于编译和语言的常规理解和认识，却导致了问题的复杂化：IDL成了一门“编译型”的语言，发展出了一套复杂的规则和语法。而且不同 RPC 框架的 IDL 语言不完全一样。每用一个新的框架，就有一套新的IDL语法和规则，就得重新学习一遍。

传统的 IDL 一旦遇到参数的减少，或者参数类型的更改，IDL 所生成的 RPC 框架的接口代码，则往往需要两个独立的接口处理函数，才能同时处理新旧两个版本的数据。所以，为了更加“优雅”的处理参数的删除和类型的改变，部分 IDL 增强了对“序号/字段编号”这种本不应该存在的语言标识的依赖。字段编号不可重复，一旦确定了，便不能修改。于是字段编号的维护，便成了开发者历史包袱的一部分。

然后对于不定类型的参数，支持该特性的 IDL 会选用 Oneof 或 Union 等来实现，而剩下的 IDL 则直接弃疗。至于不定长参数，类似于 C 语言 printf 那样的参数，这对几乎所有的 IDL 而言，均是噩梦般的存在。因此对于不定长参数的支持，几乎所有的IDL 都是以放弃结束。

本专利选择了 IDL-less的方案，让 IDL 回归到纯粹的接口描述。此时，IDL-less的方案，不仅能轻易支持可选参数、可变类型参数，也能很好的支持参数的增减，和不定长参数。

通过使用IDL-less 的 RPC 框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现。

在本发明的一个可选实施例中，基于限流算法判断服务访问请求是否限流，具体包括如下步骤：

（1）判断服务访问请求是否有令牌；

（2）若服务访问请求没有令牌，则确定服务访问请求限流。

令牌为从令牌桶获取得到的，令牌桶中的令牌为根据限流大小确定的令牌添加速率添加令牌得到的。

令牌桶设置有最大放置令牌限制，当达到最大放置令牌限制时，新添加的令牌被丢弃或者拒绝；

令牌桶设置有最小放置令牌限制，当令牌桶中的令牌达到最小放置令牌限制时，服务访问请求处理完之后将不会删除服务访问请求的令牌。

具体的，参考图5，所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；

根据限流大小，设置按照一定的速率往桶里添加令牌；

桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃或者拒绝；

请求达到后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；

令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流。

限流代码思路如下：

假定需求：每个ip地址1秒内只能发送1次请求，多出来的请求返回429错误。

添加依赖， gateway 默认使用redis的RateLimter限流算法来实现。

<!-- redis -->

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-data-redis-reactive</artifactId>

<version>2.1.3.RELEASE</version>

</dependency>

定义KeyResolver

在GatewayApplicatioin引导类中添加如下代码，KeyResolver用于计算某一个类型的限流的KEY也就是说，可以通过KeyResolver来指定限流的Key。

//指定限流的key

@Bean

public KeyResolver keyResolver() {

return exchange ->{

//根据ip限流

String ip = Objects.requireNonNull(exchange.getRequest().getRemoteAddress()).getHostName();

return Mono.just(ip);

};

}

修改application.yml中配置项，指定限制流量的配置以及REDIS的配置

routes:

- id: goods

uri: lb://goods

predicates:

- Path=/goods/

filters:

- StripPrefix= 1

- name: RequestRateLimiter #请求数限流 名字不能随便写

args:

key-resolver: "#{@keyResolver}"

redis-rate-limiter.replenishRate: 1 #令牌桶每秒填充平均速率

redis-rate-limiter.burstCapacity: 1 #令牌桶总容量

以上是在原来的配置文件中修改，在predicates:下添加依赖。

burstCapacity：令牌桶总容量。

replenishRate：令牌桶每秒填充平均速率。

key-resolver：用于限流的键的解析器的 Bean 对象的名字。它使用 SpEL 表达式根据#{@beanName}从 Spring 容器中获取 Bean 对象。

在配置文件中配置redis

redis:

host: 192.168.200.128

port: 6379

通过限流的API网关达到对服务流量和传输速率的控制，保障服务的连续性，结合RPC服务成为稳定连续可控的网络连接，使得终端和服务之间的连接能力增强。

通过IDL-less方案统一了RPC服务的接口的语义和形式，将RPC服务端的接口汇聚到API网关内，通过API网关对接口流量和传输进行控制。API网关实现对平台RPC服务的反向代理、负载均衡，提供API调用时的安全认证功能。

RPC服务提供两套传输方式，一种是基于TCP的安全可靠传输，一种是基于Quic协议的可靠UDP传输层作为TCP长连接之外的备选方案，相当于在终端和服务之间建立了两条线路，一条TCP实线，一条UDP虚线，RPC不关注底层传输过程，只需要终端将调用的信息最终传输到API网关里即可。

本发明中提出的一种增强通讯能力和网络控制能力的方法，是一种基于RPC API网关网络通讯的扩展，包括对原有的RPC API网关通讯方式进行强化，提高传输效率，提供传输备份，提升网络控制，保障业务连续性，强化整体网络通讯能力和控制能力。

本发明具有以下优点：

1.解决接口需求不一致问题：通过使用IDL-less 的 RPC 框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现。

2.解决单链路问题：通过跨集群的点到点通信的虚拟链路，并提供了基于Quic协议的可靠UDP传输层作为TCP长连接之外的备选方案，为高层RPC调用提供统一的点到点的在访问设备和服务网管之间的一条虚拟的专用通信传输链路，维护连接状态。

3.解决网络带宽占用问题：通过在选择网络传输协议时也考虑了端口资源占用的状况，支持选择端口占用资源少和支持多路复用的协议，传输协议还能够支持通过控制台控制终端发送数据的速率，避免大量终端数据同时打入网关，造成控制台带宽占用的瞬时变大。

4.解决网络通信控制能力不足问题：通过API网关模式网络架构提供了丰富的网络通信控制功能，如带宽限速、传输速率控制；多节点网络学习以及集群服务发布同步组件；提供了和网络层无关的业务代理组件。

实施例二：

本发明实施例还提供了一种增强终端与服务通讯能力和网络控制能力的装置，该增强终端与服务通讯能力和网络控制能力的装置主要用于执行本发明实施例一中所提供的增强终端与服务通讯能力和网络控制能力的方法，以下对本发明实施例提供的增强终端与服务通讯能力和网络控制能力的装置做具体介绍。

图6是根据本发明实施例的一种增强终端与服务通讯能力和网络控制能力的装置的示意图，该增强终端与服务通讯能力和网络控制能力的装置应用于RPC API网关，RPCAPI网关为终端和微服务之间的中间层，且RPC API网关中采用的是IDL-less的RPC框架，如图6所示，该装置主要包括：获取单元10、第一判断单元20、第二判断单元30、丢弃单元40和路由单元50，其中：

获取单元，用于获取终端发起的服务访问请求；

第一判断单元，用于判断服务访问请求与限流规则是否匹配；

第二判断单元，用于如果匹配，则基于限流算法判断服务访问请求是否限流；

丢弃单元，用于如果限流，则丢弃服务访问请求；

路由单元，用于如果不匹配或不限流，则将服务访问请求路由至微服务中对应的服务器，以使服务器执行服务访问请求对应的操作，并将操作的结果经由RPC API网关返回至终端。

在本发明实施例中，提供了一种增强终端与服务通讯能力和网络控制能力的装置，应用于RPC API网关，RPC API网关为终端和微服务之间的中间层，且RPC API网关中采用的是IDL-less的RPC框架，该装置包括：获取终端发起的服务访问请求；判断服务访问请求与限流规则是否匹配；如果匹配，则基于限流算法判断服务访问请求是否限流；如果限流，则丢弃服务访问请求；如果不匹配或不限流，则将服务访问请求路由至微服务中对应的服务器，以使服务器执行服务访问请求对应的操作，并将操作的结果经由RPC API网关返回至终端。通过上述描述可知，本发明的增强终端与服务通讯能力和网络控制能力的装置中，RPC API网关中采用的是IDL-less的RPC框架，在业务层提供统一的RPC访问方式，提供一套面向业务的统一网络访问框架，无论跨集群访问还是在本集群内访问，RPC接口的语义和形式都能进行统一的实现，增强了RPC API网关的通讯能力，且通过RPC API网关对服务流量和传输速率进行控制，保障服务的连续性，增强了RPC API网关的网络控制能力，进而增强了终端与服务的通讯能力和网络控制能力，缓解了现有的终端与服务的通讯能力差、网络控制能力有待加强的技术问题。

可选地，IDL-less的RPC框架包括：将RPC的服务器的接口汇聚到RPC API网关内，将RPC的终端的接口汇聚到RPC API网关内。

可选地，RPC API网关包括：内置于终端内的RPC和存根，以及内置于服务器内的RPC和存根。

可选地，RPC API网关提供的传输方式包括：基于TCP的传输和基于Quic协议的UDP传输。

可选地，第二判断单元还用于：判断服务访问请求是否有令牌；若服务访问请求没有令牌，则确定服务访问请求限流。

可选地，令牌为从令牌桶获取得到的，令牌桶中的令牌为根据限流大小确定的令牌添加速率添加令牌得到的。

可选地，令牌桶设置有最大放置令牌限制，当达到最大放置令牌限制时，新添加的令牌被丢弃或者拒绝；令牌桶设置有最小放置令牌限制，当令牌桶中的令牌达到最小放置令牌限制时，服务访问请求处理完之后将不会删除服务访问请求的令牌。

本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。

如图7所示，本申请实施例提供的一种电子设备600，包括：处理器601、存储器602和总线，所述存储器602存储有所述处理器601可执行的机器可读指令，当电子设备运行时，所述处理器601与所述存储器602之间通过总线通信，所述处理器601执行所述机器可读指令，以执行如上述增强终端与服务通讯能力和网络控制能力的方法的步骤。

具体地，上述存储器602和处理器601能够为通用的存储器和处理器，这里不做具体限定，当处理器601运行存储器602存储的计算机程序时，能够执行上述增强终端与服务通讯能力和网络控制能力的方法。

处理器601可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器601中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器601可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processing，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器602，处理器601读取存储器602中的信息，结合其硬件完成上述方法的步骤。

对应于上述增强终端与服务通讯能力和网络控制能力的方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述增强终端与服务通讯能力和网络控制能力的方法的步骤。

本申请实施例所提供的增强终端与服务通讯能力和网络控制能力的装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本申请实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的系统、装置和单元的具体工作过程，均可以参考上述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

再例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述车辆标记方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，简称ROM）、随机存取存储器（Random Access Memory，简称RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (8)

1.一种增强终端与服务通讯能力和网络控制能力的方法，其特征在于，应用于RPC API网关，所述RPC API网关为终端和微服务之间的中间层，且所述RPC API网关中采用的是IDL-less的RPC框架，所述方法包括：

获取所述终端发起的服务访问请求；

判断所述服务访问请求与限流规则是否匹配；

如果匹配，则基于限流算法判断所述服务访问请求是否限流；

如果限流，则丢弃所述服务访问请求；

如果不匹配或不限流，则将所述服务访问请求路由至所述微服务中对应的服务器，以使所述服务器执行所述服务访问请求对应的操作，并将所述操作的结果经由所述RPC API网关返回至所述终端。

2. 根据权利要求1所述的方法，其特征在于，所述IDL-less的RPC框架包括：将RPC的服务器的接口汇聚到所述RPC API网关内，将RPC的终端的接口汇聚到所述RPC API网关内。

3. 根据权利要求1所述的方法，其特征在于，所述RPC API网关包括：内置于所述终端内的RPC和存根，以及内置于所述服务器内的RPC和存根。

4. 根据权利要求1所述的方法，其特征在于，所述RPC API网关提供的传输方式包括：基于TCP的传输和基于Quic协议的UDP传输。

5.根据权利要求1所述的方法，其特征在于，基于限流算法判断所述服务访问请求是否限流，包括：

判断所述服务访问请求是否有令牌；

若所述服务访问请求没有令牌，则确定所述服务访问请求限流。

6.根据权利要求5所述的方法，其特征在于，所述令牌为从令牌桶获取得到的，所述令牌桶中的令牌为根据限流大小确定的令牌添加速率添加令牌得到的。

7.根据权利要求6所述的方法，其特征在于，所述令牌桶设置有最大放置令牌限制，当达到所述最大放置令牌限制时，新添加的令牌被丢弃或者拒绝；

所述令牌桶设置有最小放置令牌限制，当所述令牌桶中的令牌达到所述最小放置令牌限制时，所述服务访问请求处理完之后将不会删除所述服务访问请求的令牌。

8. 一种增强终端与服务通讯能力和网络控制能力的装置，其特征在于，应用于RPCAPI网关，所述RPC API网关为终端和微服务之间的中间层，且所述RPC API网关中采用的是IDL-less的RPC框架，所述装置包括：

获取单元，用于获取所述终端发起的服务访问请求；

第一判断单元，用于判断所述服务访问请求与限流规则是否匹配；

第二判断单元，用于如果匹配，则基于限流算法判断所述服务访问请求是否限流；

丢弃单元，用于如果限流，则丢弃所述服务访问请求；

路由单元，用于如果不匹配或不限流，则将所述服务访问请求路由至所述微服务中对应的服务器，以使所述服务器执行所述服务访问请求对应的操作，并将所述操作的结果经由所述RPC API网关返回至所述终端。