Apinto 网关进阶教程，插件开发入门指南
Apinto 是基于Go语言，由 Eolink 自主研发的一款高性能、可扩展、易维护的云原生 API 网关。Apinto 能够帮助用户简单、快速、低成本、低风险地实现：系统微服务化、系统集成、向合作伙伴、开发者开放功能和数据。

通过 Apinto，企业能够专注于自身业务的发展，并且让企业间能互相借力，实现共赢。

借助 Apinto 强大的插件拓展能力，用户可像乐高积木一样根据需要自行拓展Apinto 的插件，丰富 Apinto 的能力。

本篇文章将给大家介绍如何开发 Apinto插件，自行拓展 Apinto 网关能力。

前置知识

插件执行流程

插件系统定义了 Access 、Proxy 两个插件执行周期，其执行阶段定义如下：

· Access：客户端请求 Apinto，将请求转发给上游服务前执行；

· Proxy：将响应返回给客户端前执行；

请求从客户端发出，到达路由进行转发前，按顺序从上到下进行每个插件的 Access 执行阶段，转发获取响应后，从下到上执行每个插件的 Proxy 执行阶段。

插件执行流程如下图，请求处理即为转发前执行的操作，响应处理即为转发获得响应后的操作。

插件实现 UML 图

插件实现采用工厂设计模式，系统初始化时，自动将插件工厂注册到插件管理器中，当有新增插件/修改插件需求时，插件工厂实例会创建插件执行器实例。

开发插件

为了更加直观介绍自定义开发插件，本文将以开发 响应重写 插件为例，完整代码可参考 [Apinto 项目响应插件]

定义插件配置

开发插件前，先确定插件的功能和界限，根据需求定义插件配置格式，此处以 响应重写 插件为例。
```
{
    "status_code":0,
    "body":"",
    "body_base64":true,
    "headers":{

    },
    "match":{
        "code":[

        ]
    }
}
```
根据上述配置，定义插件配置结构体。
```
type Config struct {
 StatusCode int               `json:"status_code" label:"响应状态码" minimum:"100" description:"最小值：100"`
 Body       string            `json:"body" label:"响应内容"`
 BodyBase64 bool              `json:"body_base64" label:"是否base64加密"`
 Headers    map[string]string `json:"headers" label:"响应头部"`
 Match      *MatchConf        `json:"match" label:"匹配状态码列表"`
}

type MatchConf struct {
 Code []int `json:"code" label:"状态码" minimum:"100" description:"最小值：100"`
}
```
实现插件执行器

1）定义执行器结构
```
type ResponseRewrite struct {
 drivers.WorkerBase
 statusCode int
 body       string
 headers    map[string]string
 match      *MatchConf
}
```
2）实现 eosc.IWorker 接口
```
type IWorker interface {
   Id() string
   Start() error
   Reset(conf interface{}, workers map[RequireId]IWorker) error
   Stop() error
   CheckSkill(skill string) bool
}
```
当插件配置被修改时，将会调用 Reset 方法，重置执行器内置数据，当插件被删除时，将会调用 Stop 方法。

3）实现 eosc.IFilter 接口
```
type IFilter interface {
   DoFilter(ctx EoContext, next IChain) (err error)
   Destroy()
}
```
该接口在转发流程中被调用，其中DoFilter方法执行插件主流程，Destory方法则在插件被删除时，销毁实例。

由于插件有顺序，在实际调用时，会将插件编排成调用链，并通过next.DoChain(ctx)操作调用下一个插件，您可以自定义调用插件前的操作，即 Access阶段 ，也可以自定义调用插件后的操作，即 Proxy阶段 。代码示例如下：
```
func (r *ResponseRewrite) DoFilter(ctx eocontext.EoContext, next eocontext.IChain) (err error) {
 return http_service.DoHttpFilter(r, ctx, next)
}

func (r *ResponseRewrite) DoHttpFilter(ctx http_service.IHttpContext, next eocontext.IChain) error {
 if next != nil {
  err := next.DoChain(ctx)
  if err != nil {
   log.Error(err)
  }
 }

 return r.rewrite(ctx)
}

func (r *ResponseRewrite) Destroy() {
 r.statusCode = 0
 r.body = ""
 r.headers = nil
 r.match = nil
}
```
定义工厂创建方法
```
func NewFactory() eosc.IExtenderDriverFactory {
 return drivers.NewFactory[Config](Create, Check)
}

func Create(id, name string, conf *Config, workers map[eosc.RequireId]eosc.IWorker) (eosc.IWorker, error) {
 err := conf.doCheck()
 if err != nil {
  return nil, err
 }

 //若body非空且需要base64转码
 if conf.Body != "" && conf.BodyBase64 {
  conf.Body, err = utils.B64DecodeString(conf.Body)
  if err != nil {
   return nil, err
  }
 }

 r := &ResponseRewrite{
  WorkerBase: drivers.Worker(id, name),
  statusCode: conf.StatusCode,
  body:       conf.Body,
  headers:    conf.Headers,
  match:      conf.Match,
 }

 return r, nil
}
```
结合上文代码，当插件新建时，插件工厂会调用 Create 方法和 Check 方法，Create 方法负责初始化插件执行器实例，Check 方法一般用来校验插件配置的合法性，Check 方法用户可以按需实现，但 Create 方法必须实现。

定义工厂注册方法
```
const (
 Name = "response_rewrite"
)

func Register(register eosc.IExtenderDriverRegister) {
 register.RegisterExtenderDriver(Name, NewFactory())
}
```
将插件注册到拓展驱动管理器中

文件名：app/apinto/worker.go

使用插件

开发完成后，新插件就会被同步到节点插件中。我们可以在控制台界面 基础设施 > 节点插件新建插件。

新建插件时选择eolinker.com:apinto:{插件名}，本次演示的插件名为response_rewrite，因此选择插件eolinker.com:apinto:response_rewrite。

若想了解插件的详细使用教程，可点击链接。

写在最后

本文简单介绍了插件入门相关细节，使用者可以根据业务需要，自行开发、安装/卸载、开启/关闭、编排插件，丰富网关能力，强化网关功能。

未来我们计划支持多语言插件，引入插件市场，个人开发者/企业可以将开发的插件贡献到插件市场中，与 Apinto 社区的使用者共享，合作共赢。
2023年11月10日
一文带你快速了解和入门 Apinto 网关！

Hello，大家好！

我是本次分享的主讲人刘健，本次主要带大家认识 Apinto 网关以及如何实现快速入门操作。

首先，让我们一起了解 API 网关的概念。它类似于一个门户，用于管理和控制应用程序与外部世界之间的通信。就像您住在一个大型公寓楼里，每个房间都有自己的门一样，API 网关就是负责管理并控制谁可以访问应用程序的“门卫”。

API 网关有几个主要的好处：

首先，它提供了一个统一的入口点，简化了应用程序与外部服务之间的通信。应用程序只需要与API网关进行交互，而不需要直接与每个外部服务进行通信。这样可以减少开发工作量，并提高应用程序的可维护性。

其次，API 网关可以提供安全性和访问控制。它可以验证传入请求的身份和权限，并确保只有授权的请求才能访问特定的服务。这有助于保护应用程序免受潜在的安全威胁。

此外，API 网关还可以提供请求转换和协议转换功能。它可以将传入的请求转换为适合每个服务的格式，并将响应从服务的格式转换为应用程序所需的格式。这样，应用程序可以与不同类型的服务进行交互，而无需担心数据格式的兼容性问题。

Apinto 是一款由 Eolink 团队自主研发的高性能、可扩展、易维护的云原生 API 网关，基于 Go 语言开发。Apinto 的优势在于能够简化系统微服务化、系统集成以及向合作伙伴和开发者开放功能和数据的过程。

想象一下，你的公司拥有一个庞大的电子商务平台，每天处理数百万次请求。Apinto 可以帮助你统一管理所有 API接口，确保安全性，简化与外部服务的通信，以及为合作伙伴和开发者提供简单、快速、低成本、低风险的接入方式。

使用 Apinto，企业可以专注于自身业务的发展，同时与其他企业相互合作，实现共赢。

Apinto 由控制面板和网关节点两部分组成，用户可以通过控制面板进行可视化配置，操作简单，上手难度极低。

网关节点是流量的核心出入口，承载着南北流量间的通信需求，防止 API 接口和用户数据被不当暴露。它能够对请求进行身份认证，有效拦截恶意请求，并合理分配上游服务流量，从而降低上游服务器的业务压力，保障业务的安全性和稳定性。

值得一提的是，经过 Apinto 网关的流量都将被记录，并进行深度分析，以梳理出有关 API 数据的价值资产，让您可以更好地了解和优化您的业务。

我们只需要简单几步，就可以将接口托管在 Apinto 网关上，实现安全转发。为了方便演示，我已经部署好了控制面板和网关节点，并创建好了演示集群。

基本操作分为两步，我们需要先创建上游并发布，然后创建、发布 API，就可以直接调用了，如果您希望对接口进行鉴权，我们还需要创建应用并选择合适的鉴权算法。

首先，我们进入上游服务列表，点击新建上游服务，选择上游服务的请求协议，填写上游服务的静态访问地址，若企业内部有 Nacos、Consul、Eureka 等注册中心，则可以勾选使用服务发现的单选框，选择相应的服务发现。

填写完后，我们需要将上游服务上线到演示环境的集群，点击发布管理，选中待上线的集群，将上游服务上线到演示集群中。

接着，我们新建 API，Apinto 支持：

HTTP、HTTPS、Websocket、Webservice、SOAP、Restful 等协议 API。

我们将新建一个 HTTP API，填写路由匹配规则，包括请求方式、请求路径，绑定刚刚创建的上游服务，填写转发路径，填写完后，点击保存，和上游服务一样，将其上线到演示集群。

完成上述两步，API 就托管到 Apinto 网关上了，接下来，我们使用测试工具进行调用。

我们先输入网关节点的地址，网关节点地址可以在集群的节点列表页面获取，填写刚刚创建的 API 请求路径，请求方式为 POST，点击测试，我们就可以得到该 API 经过网关代理后的响应结果。

通过 Apinto，您不仅可以得到安全转发的 API，还可以在仪表盘中查看该接口的请求情况。Apinto 提供了全面且细粒度的调用统计功能，拥有丰富的统计数据和统计维度，您可以按照环境和集群自定义监控报表。

此外，您还可以逐级查看应用、API 和上游服务的统计数据，满足深度统计的需求。

而当出现问题时，我们也为您准备了多维度告警规则，帮助您及时发现和解决潜在的问题。

我们提供API、上游、集群、逻辑分区等多维度告警规则，具有失败率、响应时间、带宽占用、状态码等多个告警触发指标，提供同比、环比等多种告警计算方式，帮助使用者根据业务实际情况制定合理、可靠、灵活的告警策略。

如果您需要对接口设置鉴权，我们支持 Apikey、Basic、JWT、AK/SK 等四种鉴权方式，为您提供更加灵活的选择。

除此之外，Apinto 还提供了多种服务治理策略，支持多维度筛选请求流量。通过使用灰度发布策略，我们可以实现系统升级过程中的无缝切换。

而通过 API 访问权限，我们可以实现 IP 黑白名单和 URL 黑白名单功能，有效地拦截非法请求。同时，以应用为维度，我们可以授权应用访问 API 的范围。

Apinto 控制面板内置 API 市场，您可以轻松对接专业的 API 开放与交易平台，为个人开发者和企业提供多维度、全方位的 API 接口。无需重复开发，只需一键添加到网关，即可开始使用。

我们也考虑到了方便您的日常管理，控制面板提供了日志检索功能，您可以在无需服务器权限的情况下，直接查看节点日志，并支持在控制面板中下载日志。

控制面板的所有模块都支持插件化，用户可以在插件市场中查看已启用的插件，并根据业务需求安装、卸载、启用或停用插件。

写在最后

最后，值得一提的是，Apinto 内置了几十种插件，涵盖安全防护、流量管控、日志记录等多个分类，满足绝大多数企业需求。而且这些插件可以实现动态配置，无需停机重启，实时生效，保证业务的连续性和可靠性。

感谢大家的耐心观看，这就是 Apinto 的快速入门和基本介绍。如果在使用过程中有任何疑问，或者您有好的想法，欢迎随时与我们联系，我们期待与您进一步交流。再次感谢大家！

](https://github.com/eolinker/apinto)

2023年9月6日
Apinto V0.14版本发布-6大插件重磅更新
大家好！

距离上次更新已经过去一段时间了，这段日子里我们一直在酝酿新的功能，本次的迭代将给大家带来 6 大插件的更新~一起来看看有哪些变化吧！

新特性

1）新增额外参数v2 插件，支持对转发参数进行加密、拼接等操作。

该插件为额外参数插件的升级版本，在v1版本中，我们只能设置静态参数转发给上游服务，存在一定的局限性。

在某些场景，如：对参数进行签名、加密等操作，v1版本无法完成。

额外参数 v2 在 v1 版本的基础上，新增了以下功能特性：
- 支持引用系统变量（如：请求URI、应用名称等），记录客户端请求特性。
- 支持对参数进行动态处理。如：md5加密、字符串拼接、获取当前请求时间戳和日期等动态操作。
以字符串拼接为例，我们希望通过拼接请求体参数name、version、driver的方式，生成x-apispace-token头部，插件配置如下：
```
{
    "params":[
        {
            "name":"x-apinto-token",
            "position":"header",
            "type":"$concat",
            "value":[
                "{name}",
                "{version}",
                "{driver}"
            ]
        }
    ],
    "request_body_type":"json"
}
```
客户端请求体内容如下：
```
{
    "name":"apinto",
    "version":"v1",
    "driver":"http"
}
```
经过 Apinto 转发，后端服务收到的请求头x-apinto-token为：
```
apintov1http
```
2）新增次数扣减插件，可根据不同用户配置计数扣减，对API调用进行计数限制。

假设你经营一家超市，每个顾客购物时需要使用购物袋。为了管理超市的容量和资源，你设置了每个顾客最多可以使用的购物袋数量。这个限制就类似于次数扣减，在 API 网关中，每个请求都会消耗一定的次数。

超市代表 API 网关，顾客代表发起 API 请求的客户端，购物袋代表可用的请求配额。次数扣减确保 API 请求的数量保持在可接受的限制范围内，防止过载，并确保资源的公平分配，就像超市限制购物袋数量一样，防止过度使用。

当可用次数用完时，可以通过购买额外的请求次数或根据特定条件自动充值来增加可用的请求配额。

Apinto 网关支持以下两种次数扣减方式：

· 对单一请求进行单次计数：每成功转发一次，计数为1次。

· 对单一请求进行批量计数：可配置参数拆分规则，如短信接口，参数 phone 允许输入多个手机号码，此时根据批量扣次的规则，计数为手机号码个数。

次数扣减架构图如上，该插件依赖 Redis 集群进行次数扣减同步，在配置该插件前，需要部署好 Redis 集群并在 Apinto 控制台配置并发布 Redis 配置，如下图：

3）新增参数校验插件，拦截无效请求。

该插件支持校验请求体、请求头部、Query 参数 的有效性和合法性，过滤/拦截无效请求。在进行参数校验时，支持正则表达式校验、前缀校验、后缀校验、包含校验、全等校验、为空校验等多种校验方式。

参数校验插件执行简化流程图如下，该图省略路由匹配、剩余插件执行等操作。

4）新增请求体校验插件，限制请求体大小。

当客户端向服务器发送请求时，请求体中可能包含大量的数据，如文件上传、表单提交等。如果没有对请求体大小进行限制，那么客户端可以发送非常大的请求体，这可能导致网络拥塞，影响其他用户的访问速度和体验；其次，处理大量的请求体数据会消耗服务器的计算和存储资源，降低服务器的性能和响应速度。

同时，恶意用户可能利用大请求体来进行拒绝服务（Denial of Service）攻击，通过消耗服务器资源来使其无法正常工作。因此，通过限制请求体大小，可以有效地控制网络流量、保护服务器资源和防止潜在的安全威胁。

5）新增格式转换插件，支持JSON与XML数据格式互转。

XML和JSON是目前主要的两种数据交换格式。

由于历史原因，一些后端服务系统采用SOAP协议开发，使用XML作为数据通讯格式。

现在大多数行业中的开放 API 都使用JSON格式进行通信。然而，由于后端服务技术过时，无法进行改造。

为了向用户提供更便利的调用方式，我们可以使用格式转换插件来解决JSON和XML之间的互转问题。这样，我们就能够通过JSON格式开放给用户调用，同时与后端服务系统进行无缝交互。

当客户端请求体为JSON时，经过 Apinto 网关后，将会将数据转换成XML发送给后端服务；接收到后端服务返回的XML后，Apinto 将会把该内容转成JSON返回给客户端，如下图所示：

同理，当客户端请求体为XML时，也会自动转换成JSON发送给后端服务。

6）新增响应体重写v2 插件。

当匹配响应状态码、响应体、响应头部后，重写响应信息。不仅支持对上游服务返回的响应进行重写，而且支持对插件报错设置的默认响应进行重写。

对上游服务返回的响应流程图如下：

建议将该插件执行顺序尽量靠前，如下图：

写在最后

目前 Apinto 及其周边项目已经开源，我们希望通过 Apinto 强大的插件拓展能力，用户可像乐高积木一样根据需要自行拓展 Apinto 的插件，以满足不同的业务市场需求。

Apinto 目前属于萌芽阶段，我们希望集合广大开源爱好者的力量，与大家一起讨论方案，接受大家的批评指正，一起将产品打磨完善，做下一个端与端间的Traffic Middleware。这是一个开放和积极的项目，我们诚挚地邀请您一起参与到我们的项目开源工作中。每一个贡献都是有意义的，包括但不限于：
- 查找 bugs，取得性能上的提升
- 帮助完善文档，提供用户操作体验
- 提交你们的 issue，让我们知道您的奇思妙想
- 参与自定义插件的开发，丰富 Apinto 的能力
- ...
欢迎各位开源爱好者参与到 Apinto 项目中，和我们一起为开源事业贡献自己的力量！
2023年9月5日

性能 | Apinto 网关压测记录

测试目的

通过控制变量法，使用压力测试工具直接对后端服务、网关代理请求到后端服务的场景进行压测，对比分析各网关性能差异。

测试方案

1）软件信息

2）被测接口

基本信息

👉请求地址：172.18.65.54:8980/ping

👉响应数据：静态HTML，减少可能造成压测性能影响的因素。

响应头部

响应体

3）网络拓扑结构

压测程序、网关程序、后端服务程序应部署在不同的服务器，避免同一服务器多个程序发生资源争抢。服务器均部署在同一个局域网中，服务器间使用内网IP进行通信，避免外部网络波动影响压测结果，具体拓扑结构图如下。

网关代理压测

4）硬件资源

5）性能调优

修改三台服务机器最大 TCP 连接数，提高服务器最高支持的并发数

编辑 /etc/sysctl.conf

修改net.ipv4.tcp_max_syn_backlog配置为65535

让配置生效

开始测试

在测试过程中，应遵循控制变量原则，避免程序资源争抢，当压测任一网关时，其余网关程序应当停止运行。

另外，我们需要关闭网关多余的 I/O 操作，比如请求日志打印，否则会造成数据的误差。为了尽可能模拟多个用户同时并发，避免触发连接 keep-alive，保证每次请求的连接都是新创建的，因此，在进行发送请求时，需要携带请求头 Connection:Close。

本文仅记录 100 并发、200 并发下，连续请求 1 分钟时各网关产品的表现情况。

Apinto

请求路径：http://172.18.65.76:8099/ping

100并发下执行1分钟

执行命令

./wrk -t8 -c100 -d60s -H "Connection: Close" --latency http://172.18.65.76:8099/ping

结果展示

Running 1m test @ http://172.18.65.76:8099/ping
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.57ms    2.59ms 202.08ms   91.26%
    Req/Sec     5.25k   298.96    10.19k    86.09%
  Latency Distribution
     50%    2.02ms
     75%    3.30ms
     90%    4.91ms
     99%    9.96ms
  2507816 requests in 1.00m, 4.76GB read
Requests/sec:  41728.11
Transfer/sec:     81.02MB

200并发下执行1分钟

执行命令

./wrk -t8 -c200 -d60s -H "Connection: Close" --latency http://172.18.65.76:8099/ping

结果展示

Running 1m test @ http://172.18.65.76:8099/ping
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.46ms    4.70ms 223.80ms   77.54%
    Req/Sec     5.24k   334.33    13.98k    83.99%
  Latency Distribution
     50%    4.40ms
     75%    7.50ms
     90%   11.48ms
     99%   20.98ms
  2502384 requests in 1.00m, 4.74GB read
Requests/sec:  41637.53
Transfer/sec:     80.85MB

Nginx

100并发下执行1分钟

请求路径：http://172.18.65.76:8999/ping

执行命令

./wrk -t8 -c100 -d60s -H "Connection: Close" --latency http://172.18.65.76:8999/ping

结果展示

Running 1m test @ http://172.18.65.76:8999/ping
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.22ms   17.00ms 212.10ms   98.05%
    Req/Sec     3.07k   664.30     6.28k    72.81%
  Latency Distribution
     50%    1.75ms
     75%    2.46ms
     90%    3.43ms
     99%  109.18ms
  1465380 requests in 1.00m, 2.81GB read
Requests/sec:  24382.41
Transfer/sec:     47.81MB

200并发下执行1分钟

执行命令

./wrk -t8 -c200 -d60s -H "Connection: Close" --latency http://172.18.65.76:8999/ping

结果展示

Running 1m test @ http://172.18.65.76:8999/ping
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.68ms   23.83ms   1.00s    96.62%
    Req/Sec     3.09k   771.87     7.15k    71.45%
  Latency Distribution
     50%    2.29ms
     75%    3.48ms
     90%    5.32ms
     99%  155.15ms
  1478385 requests in 1.00m, 2.83GB read
Requests/sec:  24598.89
Transfer/sec:     48.23MB

Kong

请求路径：http://172.18.65.72:8000/ping

100并发下执行1分钟

执行命令

./wrk -t8 -c100 -d60s -H "Connection: Close" --latency http://172.18.65.76:8000/ping

结果展示

Running 1m test @ http://172.18.65.76:8000/ping
  8 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.91ms   15.80ms 361.41ms   94.35%
    Req/Sec     2.04k   301.81     2.76k    72.99%
  Latency Distribution
     50%    3.71ms
     75%    9.81ms
     90%   18.00ms
     99%   46.10ms
  972890 requests in 1.00m, 1.96GB read
Requests/sec:  16213.08
Transfer/sec:     33.41MB

200并发下执行1分钟

执行命令

./wrk -t8 -c200 -d60s -H "Connection: Close" --latency http://172.18.65.76:8000/ping

结果展示

Running 1m test @ http://172.18.65.76:8000/ping
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    17.63ms   37.04ms 581.50ms   92.13%
    Req/Sec     2.05k   618.45     3.18k    82.57%
  Latency Distribution
     50%    6.43ms
     75%   15.28ms
     90%   41.98ms
     99%  131.93ms
  966126 requests in 1.00m, 1.94GB read
Requests/sec:  16099.00
Transfer/sec:     33.18MB

测试图表展示

QPS

横轴为并发数，纵轴为当前并发量时，各网关每秒能够处理的请求数。

错误数

横轴为并发数，纵轴为当前并发量时，各网关返回的非200、300状态码的错误响应数量。

请求耗时

横轴为并发数，纵轴为当前并发量时的请求耗时情况，单位：ms。

总结

Apinto 网关性能表现优异。相同环境下，Apinto 拥有比 Nginx 高 65% 左右的吞吐量表现，拥有极强的性能表现和优异的稳定性，99% 的请求都可以在 100ms 内转发完成，代理损耗极低。

Nginx 和 Kong 在 1000 并发时，开始出现了错误请求，相比之下，Apinto 即使在 1000 并发时，依然表现良好，稳定工作。

2023年7月6日

Apinto Dashboard V3.2发布！新增 API 商城，海量接口免费试用！
前言

在控制台插件底层的支持下，经过一个月的开发迭代，ApintoDashboard V3.2版本发布更新。此次更新接入了API市场，提供海量接口，任君挑选，免费试用。

另外，使用者可以在控制台上查看/下载节点错误日志、请求Access日志，不再需要进入到服务器中操作。🚀

新特性

一. 新接入专业 API 市场

敬请免费试用【海量高品质接口】

APISpace 是 Eolink 旗下专业的 API 开放与交易平台，已为数百万开发者提供专业 API 服务，海量高品质接口，一分钟快速接入，大大降低获取数据的成本和难度，极大提升开发效率，省心又省力!

🔥🔥🔥 精选接口

APISpace 提供\热门**品类接口：**
- 手机号码归属地：提供全国移动、联通、电信等手机号码归属地查询，上亿条数据囊括最新的170、166、147等号段，更新及时、准确度高。
- 手机号码在网时长：查询手机号码的在网时长查询，支持三网手机号，返回从开户到目前使用的时间范围，有助于精准营销和风险控制。
- 天气预报查询：支持全国以及全球多个城市的天气查询，包含国内3400+个城市以及国际4万个城市的实况数据，同时也支持国内任意经纬度查询，接口会返回该经纬度最近的站点信息；更新频率分钟级别。
- IP 归属地 - IPv4区县级：根据IP地址查询归属地信息，包含43亿全量IPv4，支持到中国地区（不含港台地区）区县级别，含运营商数据。
- 验证码短信：支持三大运营商，虚拟运营商短信发送，电信级运维保障，独享专用通道，3秒可达，99.99％到达率，支持大容量高并发。
- 全国快递物流查询：1.提供包括申通、顺丰、圆通、韵达、中通、汇通等600+快递公司在内的快递物流单号查询。2.与官网实时同步更新。3.根据单号自动识别快递公司，识别单号不收费
- 运营商三要素：输入姓名、身份证号码、手机号码，验证此三种信息是否一致，返回验证结果（是否一致）、手机归属地、运营商名称
- 通用文字识别 OCR：多场景、多语种、高精度的整图文字检测和识别服务，多项指标行业领先，可识别中、英、日、韩、法、德多种语言
- 手机号码在网状态：传入手机号码，查询手机号在网状态，返回在网、在网不可用、不在网（销号/未启用/停机）等多种状态。支持移动、电信、联通手机号码。
- 二维码识别 OCR：对图片中的二维码、条形码进行检测和识别，返回存储的文字内容。
- ......
没有找到合适的？即刻点击查看更多专业接口🖱️

挑选您所需的接口项目，一键添加到网关 ，就可以直接访问Apinto网关进行调用啦～

二. 新增控制台日志检索插件

1.可查询集群中各节点的日志列表

2.支持追踪节点日志、请求 Access 日志

3.支持在控制台下载日志，无需进入服务器操作

写在最后

Apinto 网关开箱即用，整个过程仅用 2 小时就能快速入门，喜欢或感兴趣的小伙伴们赶紧去下载安装体验吧！

希望大家多多支持 Apinto 团队，以便我们提供更好的开源体验，记得Star 和 Fork 一下喔~

[
2023年7月6日
Apinto Dashboard V3.0发布-控制台插件化，重新定义操作模式

经过将近两个月的开发迭代，Apinto 控制台迎来一次重大更新。本次发布的 v3.0 版本控制台，重新定义了控制台的操作模式，控制台的所有模块，均实现了插件化，使用者可以根据业务需要，安装/卸载、开启/停用控制台插件。

未来我们计划引入插件市场，个人开发者、企业可将自己开发的插件上传，使用者可以到插件市场中，挑选符合自己业务需求的插件进行安装下载，即插即用。🚀

新特性

在本次的更新，我们优化了 Dashboard 的整体 UI，新版本将给大家带来更好的操作体验！

另外，我们实现了控制台的插件化管理，后续我们会持续上架更多的插件丰富网关的功能。

此次更新同步推出日志输出插件、Redis 配置插件、InfluxDB 配置插件。

1）支持简易用户操作，包括登录、注销、修改密码等操作设置；

2）单用户登录控制，同一账号同一时间只能在一处登录；

3）初始账号：admin ，初始密码：12345678 ，部署完成后，建议修改密码。

写在最后

Apinto 网关开箱即用，整个过程仅用 2 小时就能快速入门，喜欢或感兴趣的小伙伴们赶紧去下载安装体验吧！

希望大家多多支持 Apinto 团队，以便我们提供更好的开源体验，记得 Star 和 Fork 一下喔~

2023年6月5日
Apinto Dashboard v2.0发布：可视化控制台让配置更轻松！

大家好， Eolink 旗下开源网关 Apinto 本次带来了 Apinto Dashboad V2.0 的版本发布。
Dashboad 需要与 Apinto 主版本一起使用，目前 Dashboad 可兼容 Apinto 0.12.4 以上版本。
👉Apinto : https://github.com/eolinker/apinto

Apinto Dashboad 简介

Apinto API 网关具有优异的性能表现、良好的扩展性以及极低的使用和维护成本。

Apinto Dashboard 作为配套可视化控制台项目，相比于 Apinto Dashboard v1.x 版本，它提供了优秀的用户体验，更加友好的交互体验，更加简洁的配置流程，操作简单，上手难度极低，更好地帮助用户和企业简单、快速、低成本、低风险地实现：系统微服务化、系统集成、向合作伙伴、开发者开放功能和数据。

本次发布的控制台包括集群管理、应用程序管理、精细服务治理和企业插件等四大亮点功能，可以满足企业对 API 网关更高级场景化需求的要求。

功能特性

2.1 集群管理

Apinto 开源网关不同于其他开源网关，提供网关集群统一管理，一次性配置业务可发布上线到相应的集群，解决多集群维护多套业务配置的问题，极大提高运维效率，降低繁杂配置事故率。

2.2 应用管理

Apinto 网关提出应用管理概念，统一管理应用及其生命周期。应用作为业务通讯的发起者角色，始终贯穿着整个调用链，Apinto 网关对应用请求的流量进行鉴权认证，并对其所请求的流量进行服务治理，同时还对其监控告警，统计应用调用情况。

2.3 精细化服务治理

Apinto 提出精细化流量管理方案，即所有调用方的请求流量都经过网关，通过对应用、API、上游服务、请求方式、IP、请求路径、应用自定义标签等组合条件筛选请求流量，执行限量、访问、熔断、灰度、缓存等策略规则，帮助企业快速、灵活地制定策略，以满足不同业务场景的需求，并全方位治理好服务。

2.4 企业插件

Apinto 网关即将推出企业插件模块，并且陆续提供业务型企业插件如：用户角色权限、监控告警、日志、API文档、开放平台、安全防护、数据分析、调用链、Mock、在线调测、安全测试、国密、多协议等。此外，Apinto 还支持用户自定义企业插件，支持独立部署。

Apinto 迭代计划

如果您是个人开发者，可基于 API 网关相关的业务场景开发有价值的网关插件或企业级插件，并且愿意分享给 Apinto，您将会成为 Apinto 的杰出贡献者或得到一定的收益。
如果您是企业，可基于 Apinto 网关开发企业级插件，成为 Apinto 的合作伙伴。

Apinto 网关开箱即用，喜欢或感兴趣的小伙伴们赶紧去下载安装体验吧！希望大家多多支持 Apinto 团队，以便我们提供更好的开源体验，记得 Star 和 Fork 一下喔
👉开源地址：https://github.com/eolinker/apinto

2023年3月21日
Apinto v0.12.1发布-新增两个插件，丰富路由特性
新特性

1、新增流量镜像（eolinker.com:apinto:proxy_mirror）插件

流量镜像（eolinker.com:apinto:proxy_mirror）插件提供了镜像客户端请求的能力。流量镜像是将线上真实流量拷贝到镜像服务中，以便在不影响线上服务的情况下，对线上流量或请求内容进行具体的分析。

使用流量镜像插件前，请求调用链如下图：

使用流量镜像插件后，请求调用链如下图：

2、新增http mocking（eolinker.com:apinto:http_mocking）插件

API Mock是一种技术，它允许程序员在不依赖后端数据的情况下，模拟web服务器端API的响应。通常使用API Mock来测试前端应用程序，而无需等待后端程序员构建完成。API Mock可以模拟任何HTTP请求方法，并进行响应测试。

Apinto提供 HTTP Mocking 插件来模拟Api Mock请求响应数据，无需等到后端接口上线，通过模拟数据进行前端应用程序调试。

3、丰富http路由特性，支持静态资源路由

在 Apinto v0.12 版本之前，若客户端想获取静态资源，仍然采取代理转发到上游服务获取资源，耗时费力，且增加上游服务压力，不可取。为了解决这一痛点，Apinto v0.12 版本新增了静态资源路由，可以设置接口的默认返回，满足客户端需求，这包括静态HTML页面、静态的接口数据（Json、XML等格式数据）、页面重定向等等。

下面，我们通过Apinto Dashboard 配置了一个重定向到Apinto官网的静态资源路由示例：

写在最后

目前Apinto 及其周边项目已经开源，我们希望通过Apinto强大的插件拓展能力，用户可像乐高积木一样根据需要自行拓展Apinto的插件，以满足不同的业务市场需求。
Apinto 目前属于萌芽阶段，我们希望集合广大开源爱好者的力量，与大家一起讨论方案，接受大家的批评指正，一起将产品打磨完善，做下一个端与端间的Traffic Middleware。
这是一个开放和积极的项目，我们诚挚地邀请您一起参与到我们的项目开源工作中。每一个贡献都是有意义的，包括但不限于：
- 查找bugs，取得性能上的提升
- 帮助完善文档，提供用户操作体验
- 提交你们的issue，让我们知道您的奇思妙想
- 参与自定义插件的开发，丰富apinto的能力
- ...
欢迎各位开源爱好者参与到Apinto 项目中，和我们一起为开源事业贡献自己的力量。

联系我们
- 官网网址：https://www.apinto.com
- Github 链接：https://github.com/eolinker/apinto
- 论坛地址：https://community.apinto.com/
- 帮助文档：https://help.apinto.com/docs
- QQ群号：725853895
- 微信群二维码：
2023年3月9日
Apinto v0.11.1发布-支持gRPC、Dubbo2协议的转换
新特性

协议转换功能上线，支持HTTP与gRPC、HTTP与Dubbo2之间的协议互转

Apinto v0.10.0已经支持了多协议的基本功能，进行了多协议支持的一次验证。

在不久前，我们通过社区调研了解到，大部分使用者更期望能够进行协议的互转，尤其是 HTTP 转 gRPC 。我们可以通过Apinto对外开放HTTP接口，使用 HTTP转gRPC插件进行内外部请求的转换，以此来满足开放企业内部gRPC接口的需求。

在本次版本，我们新上线了四个插件，用于协议之间的互转，如下：
- eolinker.com:apinto:grpc_to_http ：将客户端 gRPC请求转换成 HTTP请求转发给上游服务，并将上游服务的 HTTP响应转换成 gRPC响应转发给客户端
- eolinker.com:apinto:http_to_grpc ：将客户端 HTTP请求转换成 gRPC请求转发给上游服务，并将上游服务的 gRPC响应转换成 HTTP响应转发给客户端
- eolinker.com:apinto:dubbo2_to_http ：将客户端 dubbo2请求转换成 HTTP请求转发给上游服务，并将上游服务的 HTTP响应转换成 dubbo2响应转发给客户端
- eolinker.com:apinto:http_to_dubbo2 ：将客户端 HTTP请求转换成 dubbo2请求转发给上游服务，并将上游服务的 dubbo2响应转换成 HTTP响应转发给客户端
新增编码转换器(transcode) 模块

该模块主要用于对客户端请求/服务端响应内容进行编码转码操作，如：protobuf编码转换器。

在实现 Grpc协议和Http协议的协议转换功能时，需要用到protobuf编码转换器，转换关系如下图所示

未来我们将支持更多的编码转换器，满足更多使用场景。

接入Prometheus

1、新增了Prometheus输出器：

能够配置多个自定义的prometheus指标来收集请求的信息。

具备以下特性：
- 包含请求总数,请求耗时等九种收集类型
- 可自定义指标的收集数据的类型
- 可自定义指标的标签
2、新增Prometheus插件

通过给路由配置该插件，当请求到达网关时，能够将请求的信息和配置的指标列表发送给指定的prometheus输出器，由各个prometheus输出器内同名的指标处理并采集请求内的信息。

Apinto-Dashboard变更

此外，Apinto-Dashboard v1.2.0-beta 同步更新，该版本新增文件上传功能。

写在最后

目前Apinto 及其周边项目已经开源，我们希望通过Apinto强大的插件拓展能力，用户可像乐高积木一样根据需要自行拓展Apinto的插件，以满足不同的业务市场需求。
Apinto 目前属于萌芽阶段，我们希望集合广大开源爱好者的力量，与大家一起讨论方案，接受大家的批评指正，一起将产品打磨完善，做下一个端与端间的Traffic Middleware。
这是一个开放和积极的项目，我们诚挚地邀请您一起参与到我们的项目开源工作中。每一个贡献都是有意义的，包括但不限于：
- 查找bugs，取得性能上的提升
- 帮助完善文档，提供用户操作体验
- 提交你们的issue，让我们知道您的奇思妙想
- 参与自定义插件的开发，丰富apinto的能力
- ...
欢迎各位开源爱好者参与到Apinto 项目中，和我们一起为开源事业贡献自己的力量。

联系我们
- 官网网址：https://www.apinto.com
- Github 链接：https://github.com/eolinker/apinto
- 论坛地址：https://community.apinto.com/
- 帮助文档：https://help.apinto.com/docs
- QQ群号：725853895
- 微信群二维码：
2023年2月25日
Apinto V0.9版本发布
新特性

1、支持websocket协议转发，在路由中启用即可生效

2、Apinto访问地址标准化，引入广播地址，以支持docker容器、kubernetes pod间通信。
旧配置
```
listen:
  - 8099 # 服务端口
ssl: # 服务端口的ssl配置
    listen:
      - port: 8099 ## 端口
        certificate: ## 证书配置
          - cert: ""
            key: ""
admin: # 管理端口配置
  scheme: http
  listen: 9400
  ip: 0.0.0.0
  certificate:
    key: ""
    cert: ""

certificate: # 证书默认目录
    dir: /etc/apinto/cert
```
新版本配置（使用旧配置时会自动充血并初始化新配置）
```
version: 2 # 配置版本，新版本为2，非 2 当做旧版本
certificate: # 证书根目录
    dir: /etc/apinto/cert

client:
  advertise_urls: # open api 服务的广播地址
  - http://192.168.3.110:9400
  - http://192.168.3.116:9400
  - http://10.8.0.15:9400
  certificate:  # 对 https 的证书配置
  - cert: 
    key: 
  listen_urls:
  - http://0.0.0.0:9400 # open api 服务的监听地址
gateway: # 网关服务配置
  advertise_urls: # 广播地址
  - tcp://192.168.3.110:8081
  - tls://192.168.3.116:8081
  - tcp://10.8.0.15:8081
  listen_urls: # 监听地址
  - tcp://0.0.0.0:8081
  - tls://192.168.3.116:8081 
peer: # 节点通信配置
  advertise_urls:
  - http://192.168.3.110:9401
  - http://192.168.3.116:9401
  - http://10.8.0.15:9401
  certificate: 
  - cert:
    key: 
  listen_urls: # 监听地址
  - http://0.0.0.0:94001 
```
3、新增监控插件，并支持将请求记录输出到InfluxDB。

4、修改网关连接上游服务默认最大连接数为10240，默认最大连接等待时间为60s，客户端请求体最大为100M

5、输出器驱动新增作用范围配置（scope），默认支持scope：access_log、monitor。
当access log插件output配置为空列表时，scope为access_log的输出器会默认生效。如下：

Bug修复

1、修复匿名应用删除后仍生效的问题

2、修复路由禁用后，缺少提示的问题

写在最后

目前Apinto 及其周边项目已经开源，我们希望通过Apinto强大的插件拓展能力，用户可像乐高积木一样根据需要自行拓展Apinto的插件，以满足不同的业务市场需求。
Apinto 目前属于萌芽阶段，我们希望集合广大开源爱好者的力量，与大家一起讨论方案，接受大家的批评指正，一起将产品打磨完善，做下一个端与端间的Traffic Middleware。
这是一个开放和积极的项目，我们诚挚地邀请您一起参与到我们的项目开源工作中。每一个贡献都是有意义的，包括但不限于：
- 查找bugs，取得性能上的提升
- 帮助完善文档，提供用户操作体验
- 提交你们的issue，让我们知道您的奇思妙想
- 参与自定义插件的开发，丰富apinto的能力
- ...
欢迎各位开源爱好者参与到Apinto 项目中，和我们一起为开源事业贡献自己的力量。

联系我们
- 官网网址：https://www.apinto.com
- Github 链接：https://github.com/eolinker/apinto
- 论坛地址：https://community.apinto.com/
- 帮助文档：https://help.apinto.com/docs
- QQ群号：725853895
- 微信群二维码：
2023年1月10日