首页 文章 精选 留言 我的

精选列表

搜索[AI原生],共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/

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

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

Apache APISIX 2.10.0 已发布,这是一个动态、实时、高性能的 API 网关,提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。从其主要功能和特点角度来看,Apache APISIX 可以替代 Nginx 来处理南北流量,也可以扮演 Istio 控制平面和 Envoy 数据平面的角色来处理东西向流量。 主要更新内容 将 'enable_debug' 表单 config.yaml 移动到 debug.yaml 在 nginx.conf 中使用新名称自定义 lua_shared_dict 取消对 shell 脚本安装的支持 添加动态调试模式 允许向 APISIX 的方法注入逻辑 允许配置回退 SNI 在 ip 匹配中支持 CIDR 允许路由从服务继承主机 支持配置节点监听地址 为 hmac auth 插件添加验证请求正文 支持镜像请求 sample_ratio 添加黑名单和消息 添加集群名称支持 添加 required_acks 选项 添加不区分大小写的开关 正确匹配主机和路径 区分具有相同名称但在不同组或命名空间中的服务 请求失败时继续处理其他服务 以不区分大小写的方式匹配 sni 不应覆盖默认的 keepalive 值 在服务发现中优先选择 SRV 延迟后重试连接 避免在域的 IP 更改时复制不需要的数据 当 plugin_config 改变时恢复插件 详情请查看更新公告

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

Gubernator —— 分布式、高性能、云原生限速微服务

Gubernator 作为微服务的主要特性是,它为进入系统的许多请求创建了一个同步点。在几微秒内接收到的请求可以被优化并协调成批,从而减少服务在重载下使用的总带宽和往返延迟。多个服务都运行在单个主机上,并且所有服务都在各自的进程中运行相同的库,但它们没有此功能。 Gubernator 的特性 Gubernator 在整个集群中均匀地分布速率限制请求,这样用户就可以添加更多的节点来扩展系统。 Gubernator 不依赖于 Memcache 或 Redis 等外部缓存,因此部署时不存在服务依赖。这使得在诸如 kubernetes 或 nomad 的编排系统中能动态增长或缩小集群。 Gubernator 在磁盘上不保存状态,它的配置是由客户机根据每个请求传递给它的。 Gubernator 提供了对其 API 的 GRPC 和 HTTP 访问。可以根据需要限制速率的陪伴服务运行,也可以作为独立的服务运行。 可以用作库来实现特定领域的限速服务。 支持对高吞吐量环境进行定制化的一致速率限制服务。 Gubernator 是俄语中 governor 的英文发音,听起来也很酷。 示例配置: rate_limits: # Scopes the request to a specific rate limit - name: requests_per_sec # A unique_key that identifies this instance of a rate limit request unique_key: account_id=123|source_ip=172.0.0.1 # The number of hits we are requesting hits: 1 # The total number of requests allowed for this rate limit limit: 100 # The duration of the rate limit in milliseconds duration: 1000 # The algorithm used to calculate the rate limit # 0 = Token Bucket # 1 = Leaky Bucket algorithm: 0 # The behavior of the rate limit in gubernator. # 0 = BATCHING (Enables batching of requests to peers) # 1 = NO_BATCHING (Disables batching) # 2 = GLOBAL (Enable global caching for this rate limit) Gubernator 是无状态的,因为它不需要磁盘空间来操作。不需要任何配置或缓存数据同步到磁盘,这是因为对 Gubernator 的每个请求都包含速率限制的配置。 首先,你可能认为这对每个请求都是不必要的开销。然而,实际上,速率限制配置仅由 4 个 64 位整数组成。配置由限制、持续时间、算法和行为组成 (有关工作原理的详细信息,请参阅下面)。正是由于这种简单的配置,Gubernator 可以用来提供客户端可以使用的各种速率限制用例。其中一些用例如下: 入口限制:典型的基于 HTTP 的 402 多请求类型限制。 流量减少:当 API 处于不佳状态时,只拒绝新的或未经身份验证的请求。 出口限制:用数百万条消息轰炸外部 SMTP 服务器并非易事。 队列处理:知道何时可以立即处理请求,或者应该按照接收请求的顺序排队和处理请求。 API 容量管理:对一个集合 API 系统能够处理的请求总数设置全局限制。拒绝或对违反系统正常操作能力的请求进行排队。 除了上面提到的用例,无配置设计对微服务的设计和部署有重要的影响: 部署时不用配置同步。当使用 Gubernator 的服务被部署时,不用预先部署到 Gubernator 的速率限制配置。 使用 Gubernator 的服务拥有其问题空间的速率极限域模型。这使得 Gubernator 无法获得领域特定的知识,因此 Gubernator 可以专注于它最擅长的事情——速率限制! 在这些问题之外,下面就从 Gubernator 的工作原理开始,讨论更多关于 Gubernator 的内容。 Gubernator 的工作原理 Gubernator 被设计成一个分布式的对等点集群,它利用了内存中所有当前活动速率限制的缓存,因为不用将数据同步到磁盘。由于大多数基于网络的速率限制持续时间只有几秒钟,因此在重启或计划停机期间丢失内存缓存并不是什么大问题。对于 Gubernator,我们选择性能而不是精度,因为在缓存丢失的情况下,一小部分流量在短时间内 (通常是几秒钟) 超过请求是可以接受的。 当向 Gubernator 发出速率限制请求时,将键入该请求并应用一致的哈希算法来确定哪个对等点将是速率限制请求的所有者。为速率限制选择单个所有者可以使计数的原子增量非常快,并且避免了在对等集群中一致地分布计数所涉及的复杂性和延迟。 尽管简单且性能良好,但是这种设计可能会受到一大堆请求的影响,因为一个协调器可能要处理成千上万个请求,而且速度有限。 为了解决这个问题,客户机可以请求 Behaviour=BATCHING,它允许对等点在指定的窗口内接受多个请求 (缺省值为 500 微秒),并将请求批处理为单个对等点请求,从而极大地减少了通过网络向单个 Gubernator 对等点发送请求的总数。 为了确保集群中的每个对等点准确地计算速率限制键的正确散列,必须以及时和一致的方式将集群中的对等点列表分发给集群中的每个对等点。目前,Gubernator 支持使用 etcd 或 kubernetes 端点 API 来发现 Gubernator 对等点。 Gubernator 操作 当客户机或服务向 Gubernator 发出请求时,客户机将为每个请求提供速率限制配置。然后,速率限制配置与当前速率限制状态一起存储在速率限制所有者的本地缓存中。存储在本地缓存中的速率限制及其配置仅在速率限制配置的指定持续时间内存在。 在持续时间过期之后,如果在此期间没有再次请求速率限制,则从缓存中删除它。对相同名称和 unique_key 对的后续请求将在缓存中重新创建配置和速率限制,这个循环将重复。另一方面,具有不同配置的后续请求将覆盖以前的配置并立即应用新配置。 由于 Gubernator 速率限制是由集群中的单个对等点哈希和处理的,所以适用于数据中心中的每个请求的速率限制将导致单个对等点处理整个数据中心的速率限制请求。 例如,考虑 name=requests_per_datacenter 和 unique_id=us-east-1 的速率限制。现在,假设对每个进入 us-east-1 数据中心的 HTTP 请求都使用这个速率限制向 Gubernator 发出请求。这可能是每秒数十万个请求,甚至可能是数百万个请求,这些请求都由集群中的一个对等点哈希并处理。由于这个潜在的可伸缩性问题,Gubernator 引入了一个名为 GLOBAL 的可配置 behavior。 当速率限制配置为 behavior=GLOBAL 时,从客户机接收到的速率限制请求将不会转发给拥有它的对等方。相反,它将从接收请求的对等方处理的内部缓存中得到响应。Hits 速率限制的点击率将由接收对等点批量处理,并异步发送到拥有该点击率的对等点,在该对等点上,点击率将被总计并得出 OVER_LIMIT。然后,拥有节点的节点有责任用速率限制的当前状态更新集群中的每个节点,这样,节点内部缓存就会定期从所有者那里获得最新速率限制状态的更新。 Global Behavior 的其他影响 由于 Hits 是批量处理并异步转发给拥有它的对等点的,所以对客户机的即时响应将不包括最精确的 remaining 计数。只有在对所有者对等点的异步调用完成并且拥有对等点有时间更新集群中的所有对等点之后,该计数才会得到更新。因此,使用 GLOBAL 允许更大的集群规模,但要以一致性为代价。如果集群足够大,使用 GLOBAL 可以增加每速率限制请求的通信量。 GLOBAL 应该只用于与传统的非 GLOBAL 行为不兼容的高容量速率限制。 Gubernator 性能 在我们的生产环境中,每向我们的 API 发送一个请求,我们就向 Gubernator 发送两个速率限制请求来评估速率限制;一个用于对 HTTP 请求进行评级,另一个用于对用户在特定时间内也可以发送电子邮件的收件人数量进行评级。在这种设置下,一个 Gubernator 节点每秒处理超过 2000 个请求,大多数批量响应在 1 毫秒内返回。 转发给拥有节点的对等请求通常在 30 微秒内响应。 NOTE The above graphs only report the slowest request within the 1 second sample time. So you are seeing the slowest requests that Gubernator fields to clients. 由于许多面向公众的 API 都是用 python 编写的,所以我们在一个节点上运行许多 python 解释器实例。这些 python 实例将本地请求转发给 Gubernator 实例,然后 Gubernator 实例将请求批处理并转发给拥有节点的节点。 Gubernator 允许用户选择非批处理行为,这将进一步减少客户机速率限制请求的延迟。但是,由于吞吐量需求,我们的生产环境使用默认的 500 微秒窗口使用 Behaviour=BATCHING。在生产中,我们观察到在 API 使用高峰期间,批处理大小为 1000。其他不具有相同高流量需求的用户可以禁用批处理,并以吞吐量为代价降低延迟。 Gubernator 开发库 如果使用 Golang,可以使用 Gubernator 作为开发库。这对你希望在顶部实现一个公司特有模型的速率限制服务时非常有用。我们在 Mailgun 内部有一项名为“ratelimits”的服务,专门跟踪每个账户的限额。通过这种方式,你可以利用 Gubernator 的强大功能和速度,同时可以分层业务逻辑,并将特定领域的问题集成到速率限制服务中。 性能表现: 下面是一个单节点每秒 2000 个请求的测试结果: 转发给拥有节点的对等请求通常在30微秒内响应

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

Mozilla 自研翻译工具,Firefox 终于获得原生翻译功能

Mozilla 的 Firefox 浏览器是全球最知名的浏览器之一,此前该浏览器一直没有自带的翻译工具,用户需要通过安装 Google 翻译等扩展程序来实现网页翻译功能。 Project Bergamot 是 Mozilla 的翻译工具研发项目,自从 2019 年 10 月该项目被披露以来,Mozilla 一直在开发这个 Firefox 翻译功能。第一个可供用户使用的 Firefox 翻译工具在上个月以浏览器扩展形式发布。本月早些时候,第二个版本也发布了,并将该工具正式命名为 Firefox Translations。 Firefox Translations 的翻译功能全程在系统本地完成,这是该翻译工具与目前市面主流解决方案完全不同的一点(例如:Chrome 浏览器的 Google Translate 翻译在云端完成)。 近日,Mozilla 正式宣布已经将这一隐私友好型的翻译工具整合到最新的 Firefox Nightly 版本中了。该功能默认状态下并未被启用,用户需要手动开启。Firefox Translations 暂时只支持英语和西班牙语等少数几种语言,Mozilla 承诺将在未来支持更多语言的翻译。 如何启用 Firefox Translation 在 Firefox 地址栏中加载 about:config; 搜索 extensions.translations.disabled; 将该偏好设置为 FALSE,以启用 Firefox 的翻译功能; 重新启动浏览器; 使用内置翻译功能 启用该功能之后,当用户访问一个受支持语言的网站时,Firefox 会在顶部显示一个小翻译栏,这个翻译栏与 Chrome 浏览器上的 Google 翻译工具栏十分相似,用户可以设定现在是否翻译、翻译语言和未来是否自动翻译。

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

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

Apache APISIX 2.6.0 已发布,这是一个动态、实时、高性能的 API 网关,提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。从其主要功能和特点角度来看,Apache APISIX 可以替代 Nginx 来处理南北流量,也可以扮演 Istio 控制平面和 Envoy 数据平面的角色来处理东西向流量。 下面继续看看新版本的主要变化。 Release Notes 新功能:APISIX 现在支持使用其他语言编写自定义插件 APISIX 现在支持通过 Lua 语言编写插件,在代理请求的过程中执行自定义的逻辑,诸如调用 webhook 通知外部系统、执行特殊的鉴权逻辑等等。但是有些情况下开发者可能会想要采用 Lua 以外的语言来编写插件。 比如开发者不熟悉 Lua,想要用自己熟悉的语言来编写插件;或者第三方团队只提供了 Java SDK,没有办法在 Lua 插件里面使用。 从 2.6 版本开始,借助 plugin runner,APISIX 支持运行非 Lua 语言编写的插件。架构图如下: APISIX 会以 sidecar 的形式运行 plugin runner。 它们两者之间采用 RPC 进行通讯,APISIX 负责发送请求数据和配置,plugin runner 负责加载用户的自定义插件,处理这些数据并告诉 APISIX 怎么处理这些请求。目前支持在代理请求到上游之前,执行非 Lua 语言编写的逻辑。后续将会支持用非 Lua 语言改写响应。 APISIX 现在放置了两个入口给 plugin runner 发送 RPC。一个是 ext-plugin-pre-req,另一个是 ext-plugin-post-req。前者会在执行 Lua 插件逻辑前运行,后者会在执行完 Lua 插件且在代理请求到上游之前运行。这两个入口都是可以在路由级别上动态开关的。 假设我们对于某些请求开启了 ext-plugin-pre-req,且 plugin runner 里面加载了 validator 和 rewrite 两个插件,那么每个匹配的请求,它都会触发对 plugin runner 的 RPC 调用,先执行 plugin runner 里面的 validator 和 rewrite,然后把执行的结果返回给 APISIX。APISIX 可以根据结果来判断是否要继续执行请求,还是拒绝掉请求。如果继续执行,会运行 APISIX 内置的 Lua 插件,比如限流限速等等。如果开启的是 ext-plugin-post-req,则正好相反。 据介绍,Java 和 Go 的 plugin runner 已在开发中。预计本周内 Java 版的 plugin runner 将会可用,Go 版的 plugin runner 将于六月份完成。 安全提升:修改 Prometheus 默认端口,不再暴露到数据面的端口上 之前默认情况下 Prometheus 的数据会暴露在数据面的端口上,虽然可以通过配置 plugin interceptor 来限制 IP 访问,但是还是存在默认不安全的问题。所以从 2.6 开始,专门采用一个新端口来暴露指标,而且默认只监听 127.0.0.1 . 在 2.6 之前,Prometheus 采集 APISIX 的指标时访问的是数据面的端口(默认 9080 端口)。 新端口是 9091 端口,且只监听 127.0.0.1,你需要修改监听地址为你的服务器的内网地址,并加上防火墙规则确保只有 Prometheus 才能访问。 支持:生态完整支持 Nacos 服务发现 APISIX 添加了对 Nacos 服务发现功能的支持。 用户只需开启 Nacos 服务发现功能,并在上游配置中设置服务名称,APISIX 就会在后台定期根据服务名称获取 Nacos 中对应服务的实例地址。这样一来,无需在 APISIX 里面配置具体的上游节点地址,只需要在 Nacos 里面配置即可。 目前 APISIX 内置的服务发现功能已支持下列外部服务: DNS Consul KV mode Eureka Nacos 支持:配置 IPv6 的 DNS resolver 之前配置 APISIX 的 DNS resolver 时,只能配置 IPv4 服务器。从 2.6 版本之后,我们加上了对 IPv6 DNS 服务器的支持。 现在配置 DNS resolver 的时候,可以写上 IPv6 的服务器地址了。 下载 下载 Apache APISIX 2.6.0-Release 源代码及二进制安装包,请访问下载页面。 https://apisix.apache.org/downloads/ 文档更新 在本次发布过程中,新的使用文档也在持续更新和发布。 https://apisix.apache.org/docs/apisix/getting-started/ 更详细的内容可以参考 2.6 版本的 Changelog 和 GitHub 上 Apache APISIX 的提交记录。 最后,官方计划将于 6 月下旬发布 APISIX 的 2.7 版本。

资源下载

更多资源
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文件系统,支持十年生命周期更新。

用户登录
用户注册