开源微服务API网关,单核2万QPS,今年最值得学习的开源项目

Posted 架构师之路

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了开源微服务API网关,单核2万QPS,今年最值得学习的开源项目相关的知识,希望对你有一定的参考价值。

文章较长,从概念与场景,到原理与架构,到性能分析,最后是demo,希望大家有收获。


第一部分:解决什么问题。

什么是微服务API网关?
API网关是上承前端用户,下接后端服务的咽喉之地,是所有客户端请求响应出入流量的必经之路。

微服务API网关有什么用?
它除了可以做最基础的反向代理之外,还可以处理通用的公共服务逻辑,如负载均衡、灰度发布、限流熔断、统一认证授权、可观测性、动态路由、协议转换、服务编排、流量镜像、健康检查、监控报警、安全防御等等等等。

说得这么抽象,有没有具体的场景呢?
对应到具体场景,举几个常见的例子。

场景一:负载均衡。
当服务器负载上升时,需要立即对系统资源进行容量评估,适当增加扩容服务器资源,让每台服务器可以平均承载分担请求压力,此时应该采用何种负载策略:轮询、随机还是哈希?果你有API网关,在后台配置好,即可自动实现。

场景二:灰度发布。
上了一个新功能,需要每天自动放 5% 的流量,10天后再一次性全部放开给所有用户。在此期间,可以对新功能加以验证,并对性能和稳定性加以观测优化,提前发现问题、解决问题?果你有API网关,在后台配置好,即可自动实现。

场景三:限流熔断。
双 11 即将来临,可能会出现流量大增,如果没有一定的过载保护策略机制,服务也将面临重大考验。希望实现系统状态不健康或超过阈值时,自动保护上游后端服务,触发限流限频或熔断机制,并即时报警,避免整个服务链条发生雪崩,此需求如何实现?果你有API网关,在后台配置好,即可自动实现。

场景四:统一认证授权。
不少公司用户权限鉴权逻辑散落在各站点服务中,是否可以将目前基于角色的认证逻辑和对外开放平台所使用的 OAuth 授权认证完全抽离出来,统一前置至网关中?果你有API网关,即可统一实现。

场景五:可观测性。
这么多站点,想知道每个站点的流量分布情况;这么多接口,想知道每个接口的处理时间;无数的报错,想知道异常的分布情况;无数的告警短信与邮件,想统一收口告警规则与策略...更重要的是,如何呈现统一的看板,实现相关指标的可视化呢?如果你有API网关,在后台配置配置即可。

既然API网关这么重要,有没有靠谱的,工业级的API网关可以“拿来主义”呢?
推荐一下,Apache APISIXApache基金会最快毕业项目、最活跃的开源API网关项目,个人觉得,它是今年最值得学习的开源项目。

第二部分:架构设计。

Apache APISIX使用了怎样的架构设计方案呢?
一句话概括,它使用了数据平面(data plane)控制平面(control plane)分离的架构方案。

什么是数据平面与控制平面?
数据平面和控制平面,不是Apache APISIX第一次提出,它是计算机网络,报文路由转发里很成熟的概念:
数据平面(data plane):一般用来做快速转发
控制平面(control plane)为快速转发提供必要的信息

它的设计原则是:
(1)在一个路由网关里,转发是最重要的工作,它具备最高的优先级,数据平面(data plane)的设计核心就是高效转发,如何在最短的时间里处理最多的包,往往使用高效内存管理、队列管理、超时管理等技术实现;
(2)控制平面(control plane)则不然,它更偏向于控制与应用;

Apache APISIX的核心架构借鉴了类似的思路。

数据平面以插件的方式,实现流控,认证,安全,日志等等众多的微服务网关核心功能。
控制平面以服务与后台的方式,实现数据收集,命令下发,可视化工作台等功能。
画外音:插件的方式,使得用户可以快速配置需要的功能,并能够定制化自己期望的功能。

第三部分:性能。

通过插件实现了这么多功能,它对请求转发性能有多大影响呢?

可以看到:
(1)单核QPS能跑到1.8W+
(2)延时在0.2ms左右,几乎可以忽略不计;
(3)除了传统的HTTP,还支持Dubbo,MQTT,gRPC等诸多协议;
(4)…
画外音:非常适合做微服务网关。

官网地址https://apisix.apache.org/

第四部分:demo。

这是我觉得这个开源项目最帅气的地方,项目提供了非常完善的中文手册,能够帮助我们快速上手,快速体验:
(1)如何用几个命令快速安装APISIX;
(2)如何快速配置APISIX;
(3)如何测试并验证APISIX;
(4)OK,可以在后台查看并控制你的网关了;
体验之后,再阅读源码,更有感觉哟。

Git地址:https://github.com/apache/apisix
文档地址:
https://apisix.apache.org/zh/docs/apisix/getting-started

这个项目靠谱吗?有哪些公司在使用?
绝非KPI式开源项目,Apache APISIX已经在NASA、腾讯、华为、微博、网易、贝壳、360等公司有着广泛的使用,已然成为世界上最活跃的开源网关项目。
画外音:你没看错,就是美国航空航天局的那个NASA。

对了,如果你对这个项目也感兴趣,欢迎关注项目的官方公众号

APISIX更多干货,欢迎关注


阅读原文,跳转Git主页,标个“星”吧。

1万行代码,单机50万QPS,今年最值得学习的开源RPC框架!

又发现一个不错的,工业级的,高性能RPC框架srpc,分享给大家。

(1)RPC简介;

(2)行业常见RPC框架;

(3)srpc特点;

(4)srpc上手指南,demo示例;

(5)srpc架构设计;

(6)srpc相关资料与资源;

文章较长,建议提前收藏。

什么是RPC?

Remote Procedure Call,远程过程调用。

什么是“远程”,为什么“远”?

先来看下什么是“近”,即“本地函数调用”。

当我们写下:

int result = Add(1, 2);

这行代码的时候,到底发生了什么?

(1)传递两个入参;

(2)调用了本地代码段中的函数,执行运算逻辑;

(3)返回一个出参;

这三个动作,都发生在同一个进程空间里,这是本地函数调用。

那有没有办法,调用一个跨进程的函数呢?

典型的,这个进程部署在另一台服务器上。

最容易想到的,两个进程约定一个协议格式,使用Socket通信,来传输:

(1)入参;

(2)调用哪个函数;

(3)出参;

如果能够实现,那这就是“远程”过程调用。

为什么需要RPC框架呢?

如果没有统一的RPC框架,各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动,造成整体的低效。

RPC框架的职责,就是要屏蔽各种复杂性:

(1)调用方client感觉就像调用本地函数一样,来调用服务;

(2)提供方server感觉就像实现一个本地函数一样,来实现服务;

有哪些常见的,出圈的RPC框架呢?

(1)gRPC,Google出品,支持多语言;

(2)Thrift,Facebook出品,支持多语言;

(3)Dubbo,阿里开源的,支持Java;

(4)bRPC,百度开源的,支持C++,Java;

(5)tRPC,腾讯RPC框架,支持多语言;

(6)...

画外音:还有哪些?

今天和大家分享的srpc,作者是搜狗的媛架构师liyingxin,基于WF,代码量1W左右:

(1)非常适合用来学习RPC的架构设计;

(2)又是一个工业级的产品,QPS可以到50W,应该是行业能目前性能最好的RPC框架了吧,有不少超高并发的线上应用都使用它。

画外音:不服?来战!

什么是srpc?

基于WF的轻量级,超高性能,工业级RPC框架,兼容多协议,例如百度bRPC,腾讯tRPC,Google的gRPC,以及FB的thrift协议。

srpc有些什么特点?

(1)支持多种IDL格式,包括Protobuf,Thrift等,对于这类项目,可以一键迁移;

(2)支持多种序列化方式,包括Protobuf,Thrift,json等;

(3)支持多压缩方法,对应用透明,包括gzip,zlib,lz4,snappy等;

(4)支持多协议,对应用透明,包括http,https,ssl,tcp等;

(5)高性能;

不同客户端线程压力下的性能表现非常稳定,QPS在50W左右,优于同等压测配置的bRPC与thrift。

(6)轻量级,低门槛,1W行左右代码,只需引入一个静态库;

如何快速上手,体验这个帅气的RPC框架呢?

简单来说,只需要三个步骤。

第一步:定义IDL描述文件。

syntax = "proto3";// proto2 or proto3

message EchoRequest

   string message = 1;

   string name = 2;

;

message EchoResponse

   string message = 1;

;

service Example

   rpc Echo(EchoRequest) returns (EchoResponse);

;

第二步:生成代码,并实现ServiceIMPL,server端就搞定了。

class ExampleServiceImpl : public Example::Service

public:

   void Echo(EchoRequest *request,

        EchoResponse *response,

        RPCContext *ctx) override

   

       response->set_message("Hi, " + request->name());

   

;

make一把,一气呵成。

第三步:自己定义一个请求客户端,向服务端发送echo请求。

int main()

   Example::SRPCClient client("127.0.0.1", 1412);

   EchoRequest req;

   req.set_message("Hello, srpc!");

   req.set_name("zhangsan");

   client.Echo(&req, 

        [](EchoResponse *response, RPCContext *ctx));

   return 0;

文末的资料集里,有非常详细的手册链接,一步步照着来就行。

srpc的架构设计思路是怎样的?

作为一个RPC框架,srpc的架构是异常清晰的,用户需要关注这3个层次:

(1)IDL接口描述文件层

(2)RPC序列化协议层

(3)网络通讯层

同时,每一层次又提供了多种选择,用户可以任意的组合:

如上图所示:

(1)IDL层,用户可以选择Protobuf或者Thrift;

(2)协议层,可以选择Thrift,bRPC,tRPC等;

画外音:因此,才能和其他RPC框架无缝互通。

(3)通信层,可以选择tcp或者http;

在此分层架构之下,RPC的客户端要做什么工作,RPC的服务端要做什么工作,srpc框架又做了什么工作呢?

首先必须在IDL中要定义好:

(1)逻辑请求包request;

(2)逻辑响应包response;

(3)服务接口函数method;

RPC-client的工作就异常简单了:

(1)调用method;

(2)绑定回调函数,处理回调;

对应上图中顶部方框的绿色部分。

RPC-server的工作也非常简单,像实现一个本地函数一样,提供远程的服务:

(1)实现method;

(2)接受request,逻辑处理,返回response;

对应上图中底部方框的黄色部分。

srpc框架完成了绝大部分的工作:

(1)对request序列化,压缩,处理生成二进制报文;

(2)连接池,超时,任务队列,异步等处理;

(3)对request二进制报文处理,解压缩,反序列化;

...

对应上图中中间的方框的红色部分,以及大部分流程。

在这个过程中,srpc采用插件化设计,各种复杂性细节,对接口调用方与服务提供方,都是透明的,并且具备良好的扩展性

如上图所示,用户只需要关注IDL,即逻辑请求,响应,接口的调用与实现。框架层面,将各种能力以插件的方式集成进来,向用户提供不同能力的组合选择。

另外,定义好IDL之后,服务端的代码可以利用框架提供的工具自动生成代码,业务服务提供方,只需要专注于业务接口的实现即可,你说帅气不帅气?

画外音:具体的生成工具,与生成方法,请参看git上的文档。

最后,我觉得这个srpc最帅气的地方之一,就是:开源版本即线上工程版本,更新快,issue响应快,并且文档真的很全!

画外音:不少大公司,公司内部的版本和开源的版本是两套代码,开源版本没有文档,KPI完成之后,开源就没人维护了,结果坑了一大票人。

文章的结尾,分享一些学习资源吧。

项目地址:https://github.com/sogou/srpc

项目demo:

README_cn.md

项目架构设计:

docs/wiki.md

作者知乎:

https://www.zhihu.com/people/liyingxin1412/posts

作者联系方式:

发现bug可以随时提交给她,响应绝对快速。

项目地址https://github.com/sogou/srpc

Star:800+

画外音:srpc还有很多优秀的设计,等待大家去挖掘。

末了,希望这个1W行代码的RPC框架,能够帮助大家更透彻的了解RPC的底层原理。

阅读原文,直达代码,欢迎标星。

以上是关于开源微服务API网关,单核2万QPS,今年最值得学习的开源项目的主要内容,如果未能解决你的问题,请参考以下文章

1万行代码,单机50万QPS,今年最值得学习的开源RPC框架!

限流10万QPS跨域过滤器令牌桶算法-网关Gateway内容都在这儿

Netflix正式开源其API网关Zuul 2

微服务开源API网关Fizz Gateway

(原创)大话微服务架构之api网关-apiGateway-技术选型

微服务和API网关限流熔断实现关键逻辑思路