首页 文章 精选 留言 我的

精选列表

搜索[API速率],共10000篇文章
优秀的个人博客,低调大师

Apache APISIX 2.12.0 发布,云原生的微服务 API 网关

继 2.11.0 版本发布之后,Apache APISIX 也在即将到来的新春佳节,为大家带来 2022 年第一个带有新功能的版本。 新功能 更多的 Serverless 集成 在上个版本里,Apache APISIX 增加了对 Azure Function 的支持。而这次新版本在功能上又加入了对更多 Serverless 厂商的支持。如今用户也可以在 Apache APISIX 中结合 AWS Lambda 和 Apache OpenWhisk,在网关上进行特定函数的暴露。 更多的鉴权插件 此次的新版本,还将带来两个众人翘首以盼的新插件:forward-auth和opa。 forward-auth插件跟 Traefik 的同名插件功能类似,该插件可以允许把当前请求的信息发送给外部服务进行鉴权。 opa插件则整合了著名的 Open Policy Agent,该插件可以通过 OPA 来完成复杂的鉴权功能。 通过上述两个插件,将为 Apache APISIX 的鉴权功能锦上添花,给用户带来更多丰富和上手简单的鉴权操作。 更多的日志功能 除了上边提到的鉴权插件,本次新版本还将带来三个新的日志插件:google-cloud-logging、splunk-hec-logging以及rocketmq-logger。 从插件名称上也很容易理解,通过上述三个插件可以把日志分别发送到 Google Cloud、Splunk 和 Apache RocketMQ。未来,Apache APISIX 将会对接越来越多的日志服务商和开源 Broker,让日志处理变得更加轻松。 支持记录响应体 同时,此次 2.12.0 版本还在日志层面支持记录响应体。与 Apache APISIX 其他功能一样,该功能也可以通过表达式进行动态开启。这样在使用中,就可以实现仅在上游返回特定的 Content-Type 和 Content-Length 时进行日志记录,不用再去顾虑全量采集响应体而带来的问题了。 具体示例可参考下方: { "plugins": { "kafka-logger": { "broker_list" : { "127.0.0.1":9092 }, "kafka_topic" : "test2", "include_resp_body": true, "include_resp_body_expr": [ [ "sent_http_content_length", "<", "4096" ], [ "sent_http_content_type", "==", "application/json" ], ] } }, "upstream": { "nodes": { "127.0.0.1:1980": 1 }, "type": "roundrobin" }, "uri": "/hello"} 上述配置会仅在 Content-Length < 4096 且 Content-Type 为 "application/json" 才记录日志。 支持注册自定义变量 另一个跟日志紧密相关的功能,就是新版本的 Apache APISIX 已支持注册自定义变量。同时结合 APISIX 的自定义日志格式,就可以实现完全自定义上报的日志内容。即无需修改具体的日志插件,就能实现日志生成和上报的解耦合。这里我们通过一个示例进行简单演示一下。 比如我们可以在自己的插件中注册一个a6_route_labels的变量: local core = require "apisix.core" core.ctx.register_var("a6_route_labels", function(ctx) local route = ctx.matched_route and ctx.matched_route.value if route and route.labels then return route.labels end return nilend) 并在自定义日志格式中使用它: { "log_format": { "host": "$host", "labels": "$a6_route_labels", "client_ip": "$remote_addr" }} 假设我们的 Route 长这样: { "plugins": { "http-logger": { "uri": "http://127.0.0.1:1980/log", "batch_max_size": 1, "concat_method": "json" } }, "upstream": { "nodes": { "127.0.0.1:1982": 1 }, "type": "roundrobin" }, "labels": { "k": "v" }, "uri": "/hello"} 最终就会收到如下所示的日志: {"client_ip":"127.0.0.1","host":"localhost","labels":{"k":"v"},"route_id":"1"} L4 代理支持 TLS over TCP 上游 在 2.12.0 版本中还引入了新的 Upstream Scheme,现在 Apache APISIX 已支持代理到 TLS over TCP 上游了。 具体做法可参考下方,只需在 Upstream 配置中指明 Scheme 为 TLS 即可。 { "scheme": "tls", "nodes": { "127.0.0.1:1995": 1 }, "type": "roundrobin"} 至此 Apache APISIX 的 TCP 代理功能得到了 TLS 全方位的支持。此外,我们还支持在静态文件中配置 L4 代理的 Access Log:​​​​​​​ stream: enable_access_log: false # enable access log or not, default false access_log: logs/access_stream.log access_log_format: "$remote_addr [$time_local] $protocol $status $bytes_sent $bytes_received $session_time" # create your custom log format by visiting http://nginx.org/en/docs/varindex.html access_log_format_escape: default # allows setting json or default characters escaping in variables 更新 多语言插件持续完善 WASM 生态功能更加丰富 在之前版本中,Apache APISIX 已开放了对 WASM 生态的支持。而在 2.12.0 版本中,针对 WASM 生态又做了不少的更新细节。 目前 Apache APISIX 已经支持在 header_filter 的阶段运行 WASM 代码,弥补了现有外部插件无法修改响应的不足。 此外,我们还支持在 WASM 里面通过 Apache APISIX 这个宿主进行 HTTP 通讯。借助这一功能,我们用 WASM 也重新实现了forward-auth插件。该插件的功能几乎和 Lua 版本一模一样,甚至连测试用例也是在 Lua 版本上改了下名字就能通过了。 Java Plugin Runner 最新版本发布 当然,我们也没有忘记针对现有的外部插件进行更新,本次 2.12.0 版本中,Apache APISIX 已允许外部插件获取请求体。 比如最近发布的 Java Plugin Runner 第二版就包含了这一功能。新版本的 Java Plugin Runner 还支持在运行时动态获取 APISIX 变量。 完善 更多细节 除了上述新功能和组件外,Apache APISIX 2.12.0 版本还更新了如下功能: gRPC-Web 的支持:继 gRPC 代理、HTTP 转 gRPC 之后,我们迎来了 gRPC 家族的第三个成员。现在 Apache APISIX 也支持代理 gRPC Web 协议了。 limit-count的增强:如今limit-count插件的计数器已经支持在请求间、路由间进行共享,可以说是相当灵活了。 更多关于 Apache APISIX 2.12.0 的更新细节,可以查看本次发布对应的 Change log。​​​​​​​ 下载 想要获取最新的 Apache APISIX 2.12.0 版本,可通过以下路径下载: 源代码:https://apisix.apache.org/downloads/ 二进制安装包:https://apisix.apache.org/zh/docs/apisix/how-to-build/

优秀的个人博客,低调大师

第三方API对接如何设计接口认证?

一、前言 在与第三方系统做接口对接时,往往需要考虑接口的安全性问题,本文主要分享几个常见的系统之间做接口对接时的认证方案。 二、认证方案 例如订单下单后通过 延时任务 对接 物流系统 这种 异步 的场景,都是属于系统与系统之间的相互交互,不存在用户操作;所以认证时需要的不是用户凭证而是系统凭证,通常包括 app_id 与 app_secrect。 app_id与app_secrect由接口提供方提供 2.1. Baic认证 这是一种较为简单的认证方式,客户端通过明文(Base64编码格式)传输用户名和密码到服务端进行认证。 通过在 Header 中添加key为 Authorization,值为 Basic 用户名:密码的base64编码,例如app_id为和app_secrect都为 zlt,然后对 zlt:zlt 字符进行base64编码,最终传值为: Authorization: Basic emx0OnpsdA== 2.1.1. 优点 简单,被广泛支持。 2.1.2. 缺点 安全性较低,需要配合HTTPS来保证信息传输的安全 虽然用户名和密码使用了Base64编码,但是很容易就可以解码。 无法防止 重放攻击 与 中间人攻击。 2.2. Token认证 使用 Oauth2.0 中的 客户端模式 进行Token认证,流程如下图所示: 使用Basic认证的方式获取access_token之后,再通过token来请求业务接口 2.2.1. 优点 安全性相对 Baic认证 有所提升,每次接口调用时都使用临时颁发的 access_token 来代替 用户名和密码 减少凭证泄漏的机率。 2.2.2. 缺点 依然存在 Baic认证 的安全问题。 2.3. 动态签名 在每次接口调用时都需要传输以下参数: app_id 应用id time 当前时间戳 nonce 随机数 sign 签名 其中sign签名的生成方式为:使用参数中的 app_id + time + nonce 并在最后追加 app_secrect 的字符串进行md5加密,并全部转换成大写。 如果需要实现参数的防篡改,只需把接口所有的请求参数都作为签名的生成参数即可 2.3.1. 优点 安全性最高 服务端使用相同的方式生成签名进行对比认证,无需在网络上传输 app_secrect。 可以防止 中间人攻击。 通过 time 参数判断请求的时间差是否在合理范围内,可防止 重放攻击。 通过 nonce 参数进行幂等性判断。 2.3.2. 缺点 不适用于前端应用使用,js源码会暴露签名的方式与app_secrect 扫码关注有惊喜!

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册