API7 ⽹关技术⽩⽪书由、上游、证书、全局插件、消 费者等资源的管理。 控制⾯板 3. 为了简化⽹关管理,管理员可以通过Dashboard控制⾯板以可视化形式操作⽹关,⽀持监控分析、⽇ 志审计、多租⼾管理、多集群切换、多⼯作分区等能⼒。 1.1技术架构 数据平⾯ 1. 数据平⾯⽤于接收并处理调⽤⽅请求,使⽤Lua与Nginx动态控制请求流量。当请求进⼊时,将根据 预设路由规则进⾏匹配,匹 ⽤⼾与⻆⾊绑定,可实现针对某类⽤⼾细粒度的权限管控; • 多租⼾(多⼯作分区):⽀持基于⼯作分区隔离的多租⼾模型,管理员可创建不同的⼯作分区,并 指定哪些⽤⼾对⼯作分区有哪些资源的访问权限; • 多环境:⽀持多ETCD集群,集群之间数据不共享; • ⾝份验证:包含多种认证类插件,如basic-auth、jwt-auth、key-auth、wolf-rbac等。此外,借 助内置的HMAC插件,可使⽤AK/S 服务发现 和注册 默认ETCD,并⽀持ETCD集群 ✔ ✖ ✖ ✖ ❌ Consul ✔ ✖ ✖ ✖ ✅ Eureka ✔ ✖ ✔ ✖ ✅ Nacos ✔ ✖ ✖ ✖ ✅ Redis ✔ ✖ ✖ ✖ ❌ 限流/集群限流 ✔ ✔ ✖ ✖ ✅ 限速0 码力 | 19 页 | 1.12 MB | 1 年前3
Apache APISIX 在安信 PaaS 平台的应用一些思考 03 落地实践、用户反馈 独立集群:提供镜像,用户自主管理;学习成本高;运维成本高 共享集群:降低运维成本;故障风险扩大;用户信息安全 短小、精悍;匹配标准场景 非标准场景适配 worker_processes ingress做网关入口可能产生的问题 1、独立集群 or 共享集群 2、插件场景匹配 3、云原生环境下的问题 下一步 04 共享集群、API市场、请求数据分析... 资源共享、工作分区隔离 资源共享、工作分区隔离 中台系统的公共接口,比如日志平台、监控平台、告警平台等的对外接口 接口权限统一管理、流量控制 调用量、异常响应、延迟 Top N... 1、共享集群建设 2、API 市场 3、请求数据分析 4、APISIX-Ingress、APISIX+Istio 感谢聆听 THANKS0 码力 | 14 页 | 621.17 KB | 1 年前3
APISEVEN 和Kong EE 的性能评测pacheAPISIX来处理传统的南北流量,以及服务之间的东 西向流量。它也可以作为⼀个k8singresscontroller。 API7是APISIX的企业版,其功能包括多集群管理、多分区、权限管理、版本管理、审计、统计报告 等,满⾜企业⽤⼾的核⼼需求。 以下是API7基于ApacheAPISIX的技术架构(图1)。 图1.API7技术架构 API7是混合 loudFormation选项。 Kong可以作为⼀个单节点运⾏,也可以作为多节点集群。在集群中,负载均衡器(如开源的 NGINX)被⽤在边缘节点为客⼾端提供单个地址,并使⽤选定的策略(例如循环或加权)在Kong节 点之间分发请求。横向扩展Kong很简单。Kong是⽆状态的,所以向集群添加新节点需要将新节点指 向外部数据库(PostgreSQL或Cassandra), 3-GigaOmAPI负载测试设置 API压⼒测试 GigaOmAPIWorkloadFieldTest是⼀个简单的压⼒测试,⽤⼀连串相同的GET请求API或API管理 节点(或管理节点集群前的负载均衡器),每秒的请求数不变。 为了进⾏压⼒测试,我们使⽤了HTTP压⼒测试⼯具WRK21,这是Github上⼀个免费的压⼒测试套 件。WRK2⼯具返回每个测试的延迟分布和状0 码力 | 14 页 | 1.11 MB | 1 年前3
03-基于Apache APISIX的全流量API网关-温铭微服务和 API 网关的演进 从2014-2015年, 谷歌搜索引擎上"微服务"关键字的搜索趋势直线上 升 在单体架构上, 任一请求都会负载到整个的单体服务集群上 在微服务架构上, 对应请求会负载到对应的微服务子服务集群上 微服务的精细管理带来服务的弹性伸缩、开发团队变得敏捷、服务之 间隔离、降低故障率 但是同样的带来的一些问题: 接口之间通用的功能重复开发、膨胀的 服务数量、难以管理 的路由匹配,接受 nginx 的所有变量作为条件,并且支持自定义函数;其他网关都是 内置的几个条件; • Apache APISIX 使用 etcd 作为配置中心,没有单点,任意宕掉一台机 器,网关集群还能正常运行。其他基于 mysql,postgres 的网关都会有单点 问题 • Apache APISIX 的配置下发只要 1 毫秒就能达到所有网关节点,使用的是 etcd 的 watch;其他网关是0 码力 | 11 页 | 6.56 MB | 6 月前3
金卫-Apache APISIX 借助 Service Mesh 实现统一技术栈的全流量管理与基础设施整合成本高 性能损耗 资源的额外消耗 扩展难度高 理想的服务网格应该是什么样? 易于扩展 理想的服务网格 业务无感知 落地成本低 动态且增量配置 安全管控 可观测 流量精细化管理 跨集群部署 性能损耗低 资源消耗低 按需下发配置 理想的服务网格 整体使用体验上 • 学习和上手成本低 • 社区开放、活跃度高 且快速响应 理想的服务网格 控制面 • 易于上手 • 权限安全管控 • 覆盖Istio各类场景/配置 降低用户迁移成本 Apache APISIX Ingress 一种Kubernetes Ingress controller实现 Kubernetes集群南北向流量网关 控制面和数据面分离 https://github.com/apache/apisix-ingress-controller 总结 服务网格是未来 正在螺旋上升的状态 APISIX0 码力 | 34 页 | 3.50 MB | 6 月前3
Apache APISIX
微服务⽹关性能架构解析Gateway Admin APISIX Admin APISIX Gateway All In One 节点⽆无状态特性 • ⾼高可⽤用 • 弹性伸缩 • 分布式 • 集群 • 故障⾃自动转移 API ⽹网关基本架构 admin API router ??? plugins administrator client upstream Configuration 数据校验:开放标准、有⼀一定的⽣生态系统 • 学习竞对:从 Ganter 报告中获取前辈列列表,做分 析、⽐比较 Apache APISIX 技术选型 配置中⼼心 why etcd? • 集群⽀支持 • 历史+事务 • 低于毫秒的变化通知 Apache APISIX 技术选型 开发平台:Lua 或 Golang •OpenResty >= 1.15.8 •Tengine0 码力 | 41 页 | 15.62 MB | 1 年前3
从Apache APISIX 来看API 网关的演进每个微服务都要带 sidecar • 多次的流量转发,不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样? • 分久必合,抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关:全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任! Q&A0 码力 | 24 页 | 1.36 MB | 1 年前3
基于 Apache APISIX 的下一代微服务架构 -- 从 0 到 1:APISIX 的 Apache 之路每个微服务都要带 sidecar • 多次的流量转发,不适合对性能要求高的场景 • 不如 Nginx 稳定 下一代微服务会是怎样? • 分久必合,抛弃 sidecar • 走向中心节点或者集群的模式 • 也就是下一代网关:全动态、全协议支持、高性能、云原生友好 我希望 Apache APISIX 可以担此重任! Q&A0 码力 | 33 页 | 1.55 MB | 1 年前3
有了 NGINX 和 Kong,为什么还需要 Apache APISIX-王院生Gateway (1) • 基于 Nginx,⽀持 Nginx -> APISIX 灰度迁移 • 全动态,⽆需 reload • HTTP(S) 精细化路由 • 内置 40+ 插件,功能强⼤ • ⾃带集群⽅案和控制⾯ 云 原 ⽣ 社 区 M e e t u p 第 四 期 · ⼴ 州 站 LB / API Gateway (2) • 基⾦会项⽬,不⽤担⼼被商业公司锁定 • 全世界最活跃的 API0 码力 | 34 页 | 25.78 MB | 6 月前3
共 9 条
- 1













