dubbo 服务压测_Dubbo高性能网关--Flurry介绍

1.背景

什么是API网关,它的作用是什么，产生的背景是啥？

从架构的角度来看，API网关暴露http接口服务,其本身不涉及业务逻辑,只负责包括请求路由、负载均衡、权限验证、流量控制、缓存等等功能。其定位类似于Nginx请求转发、但功能要多于Nginx,背后连接了成百上千个后台服务，这些服务协议可能是rest的，也可能是rpc协议等等。

网关的定位决定了它生来就需要高性能、高效率的。网关对接着成百上千的服务接口,承受者高并发的业务需求，因此我们对其性能要求严苛，其基本功能如下:

协议转换

一般从前端请求来的都是HTTP接口,而在分布式构建的背景下，我们后台服务基本上都是以RPC协议而开发的服务。这样就需要网关作为中间层对请求和响应作转换。

将HTTP协议转换为RPC，然后返回时将RPC协议转换为HTTP协议

请求路由

网关背后可能连接着成本上千个服务,其需要根据前端请求url来将请求路由到后端节点中去，这其中需要做到负载均衡

统一鉴权

对于鉴权操作不涉及到业务逻辑，那么可以在网关层进行处理，不用下层到业务逻辑。

统一监控

由于网关是外部服务的入口，所以我们可以在这里监控我们想要的数据，比如入参出参，链路时间。

流量控制，熔断降级

对于流量控制，熔断降级非业务逻辑可以统一放到网关层。

有很多业务都会自己去实现一层网关层，用来接入自己的服务，但是对于整个公司来说这还不够。

2.Flurry Dubbo API网关

Flurry是云集自研的一款轻量级、异步流式化、针对Dubbo的高性能API网关。与业界大多数网关不同的是，flurry自己实现了 http与dubbo协议互转的流式化的dubbo-json协议，可高性能、低内存要求的对http和dubbo协议进行转换。除此之外，其基于 netty作为服务容器，提供服务元数据模型等等都是非常具有特点的。下面我们将详细介绍 flurry的特性:

2.1 基于Netty容器

传统网关大多采用tomcat作为容器,其请求于响应没有做到异步,tomcat会有一个核心线程池来处理请求和响应,如果RT比较高的话,将会对性能有一定的影响。

Flurry 网关请求响应基于Netty线程模型,后者是实现了Reactive,反应式模式规范的,其设计就是来榨干CPU的，可以大幅提升单机请求响应的处理能力。

最终,Flurry通过使用Netty线程模型和NIO通讯协议实现了HTTP请求和响应的异步化。

每一次http请求最终都会由Netty的一个Client Handler来处理,其最终以异步模式请求后台服务，并返回一个CompletableFuture,当有结果返回时才会将结果返回给前端。

见下面一段例子:

ServerProcessHandler

public class ServerProcessHandler extends SimpleChannelInboundHandler {

public void handlerPostAsync(RequestContext context, ChannelHandlerContext ctx) throws RpcException {

CompletableFuture jsonResponse = asyncSender.sendAsync(context, ctx);

jsonResponse.whenComplete((result, t) -> {

long et = System.curr