本文将从云原生时代的机遇和挑战说起,介绍一个全新的开源高性能云原生 API 网关——Apache APISIX,探讨如何解决云原生时代 API 网关所面临的一些痛点,最后介绍该开源项目未来的规划。
很多应用和服务都在向微服务、容器化迁移,形成新的云原生时代。云原生是下一个 5-10 年的技术颠覆,重写了传统企业的技术架构,例如云原生中的 Kubernetes 颠覆了传统操作系统,所有的“主机”(node 上的容器)由 Kubernetes 来控制和编排,非常适用于公有云、私有云、混合云等各种环境。云原生体系的特点之一就是由各种开源项目组成,不同于以往的商业闭源项目,缓解了收费贵等问题,加速了技术落地。现代公司的技术是非常重要的组成部分,在一个商业竞争激烈的时代,公司愈早的占据技术顶峰愈是能够占据商业顶峰。网关作为云原生入口,是掌握云原生的一个必经之地,是开启“财富”的关键钥匙。
从 2014-2015 年,谷歌搜索引擎上“微服务”关键字的搜索趋势呈直线上升。
在单体架构上,任一请求都会负载到整个的单体服务集群上。
在微服务架构上,对应请求会负载到微服务中对应的的子服务集群上。
使用微服务进行精细管理后,服务的弹性伸缩、开发团队变得敏捷、服务之间隔离、降低故障率;在流量变动的时候,只需要对有可能变动流量的服务进行对应资源的扩缩容即可,这样可以很明显的节省服务器成本以及更高的承受度;在业务变动的时候,只需要对有可能变动业务的服务进行对应业务模块的变动即可,这样可以很明显的节省人力成本以及更高的控制力;在出现故障时不会导致整体服务不可用。
但是落地微服务同样的带来了一些问题,比如接口之间通用的功能重复开发、膨胀的服务数量、难以管理。通常的解决方案便是使用 API 网关对其进行管理。
使用 API 网关进行管理,通常的做法是将微服务框架中功能型的功能统一放到网关上,例如可观测性 metrics、应用性能 apm tracing、限速、身份认证、日志等等。
灰度发布也叫金丝雀发布,起源是,矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度高。灰度发布会将流量按比例划分给已经上线的版本(比如1.0,占比90%)以及正在上线的版本(比如1.01,占比10%),若观测没有问题,逐步调整二者的流量占比直到流量完全切到1.01版本。Apache APISIX 内置的灰度发布支持读取到的 HTTP 请求参数中包含了 Nginx 的所有变量,可以依据变量进行灰度,甚至支持 LUA 代码去运算处理请求的请求体、请求参数。
如图所示,当 Invoices 服务出现大量常见错误达到配置的熔断阈值就可以直接熔断不接收请求了。
| 作用在传统API网关领域的功能 | 作用在云原生API网关领域的功能 | | ------------------------------------------------------------ | ------------------------------------------------------------ | | 让 API 请求更安全、更高效的得到处理;覆盖 Nginx 的所有功能:反向代理、负载均衡;动态上游、动态 SSL 证书、动态限流限速;主动/被动健康检查、服务熔断 | 对接 Prometheus、Zipkin、Skywalking;gRPC 代理和协议转换 (REST <-> gRPC);身份认证:OpenID Relying Party、OP(Auth0、okta……)高性能、无状态、随意扩容和缩容动态配置,不用 reload 服务支持多云、混合云容器优先,Kubernetes 友好 |
API 生命周期指的是从 API 的设计到 API 的文档和他的 SDK 以及他的 API 的上线之类,甚至还包括 API 的市场等等一整套的解决方案,网关在其中是核心角色。
在上半象限都是一些巨头公司,例如 google、IBM 等等,都是公有云的闭源项目,具有领导地位,跟各自产品深度绑定在一起。在下半象限都是援建者,都是开源项目,例如: Kong,挑战着闭源项目, 随着时间的推移我们发现——软件在吞噬世界、开源软件在吞噬软件。以下是近几年发生的很多 API 网关厂商相关的收购案例:
说明 API 网关在云原生时代依然扮演者重要的角色
API 网关的数据面和控制面分离。控制面不仅能控制 Apache APISIX 还能控制其他组件;数据面不仅仅能被我的控制面控制,还能被其他组件所控制
通过插件机制来方便二次开发和运维。拿 Envoy 来说,Envoy 的插件是使用 C++ 编写的,C++ 本身就具有很大的复杂性;再来对比下 Kong,Kong 开发一个 IP 黑白名单插件需要写 300+ 行代码,并且插件配置解析、插件逻辑等代码分布在 3-4 个文件中;而 Apache APISIX 开发同样功能的插件只需要一个文件并且只需要70行代码。
默认高可用,没有单点故障。因为使用了 ETCD 来存储和分发路由数据
安全和稳定第一。Apache APISIX 基于 Nginx 实现,支持mTLS 认证以及敏感信息加密加盐 (salt) 保存。为什么选择 Nginx 呢?它是基于 C 语言开发的程序,性能优化到极致,Nginx 的底层开发做的非常好,并且在大规模适用上得到充分有效的验证,从性能角度上是最佳选择
高性能。Apache APISIX 基于 Nginx 的网络层,其单核心 QPS 1.5 万,延迟低于 0.7 毫秒。
运维友好。它支持 Prometheus、SkyWalking 动态追踪、流量复制、故障注入等功能
Apache APISIX 架构如图,其主要分为数据面和控制面。
因为 Apache APISIX 使用了 ETCD 作为配置中心,在对应其他组件时会非常方便,可以把 ETCD 直接就当做服务注册发现中心来使用(服务注册、发现),当然同时也支持 Consul、Eureka、Nacos 等服务注册中心。
Apache 只是使用了 Nginx 的网络库而并没有使用路由库,重写优化了路由算法。
基于已有插件的基础上,通过在界面上拖拖拽拽就可以生成一个全新的插件。
通过插件编排的方式可以把 Apache APISIX 的四十多个插件的上下游关系全部串联起来形成一个新的插件。
当前,Kong支持 Go 编写的插件,Envoy支持 Lua、WASM 编写的 filter。那么,Apache APISIX 的使用者为什么要“写”插件?我们认为运维、PM 也可以直接通过浏览器页面创造一个自己的插件。
为了支持插件编排,Apache APISIX 一方面需要实现微插件、低代码,同时需要底层架构和插件足够灵活。
有对比才更有说服力,Apache APISIX 和 Kong 都是基于 Openresty/LuaJIT 实现的高性能 API 网关,让我们来对比下他们的异同。
因此我们发现Apache APISIX的分布式可靠性强,路由支持丰富,配置变更生效时间快,网关处理速度快, 资源消耗率低,混沌测试支持度高,监控系统(如SkyWalking)支持度高,插件变动动态化程度高以及二次开发难度低。
Nginx 是一款轻量级 Web 服务器、反向代理服务器,由于它的内存占用少、启动极快、高并发能力强,故其在互联网项目中得到广泛应用,距今已经有十多年的历史。但 Nginx 在步入云原生时代后遇到了更多的挑战:
如果你还在被 Nginx 或者 Nginx Ingress 的 reload 性能问题所折磨,又或者对 Kong 的转发能力并不满意,欢迎大家使用 Apache APISIX
作者:温铭,来自一家在远程工作方式下商业化开源项目的创业公司(支流科技),担任 CEO 兼联合创始人,与支流科技 (Apache APISIX) 类似的公司有 Confluent(Kafka 产品)、PinCap(TiDB产品),支流科技是 linux 基金会白银会员、Linux 微服务 TARS 基金会创始会员。Apache 顶级项目 APISIX 的 PMC 主席。Skywalking 开源项目的贡献者 (committer)。在创业之前,在360做企业安全,360开源委员会的发起人,腾讯的 TVP,TARS 基金会的 TOC 成员,在安全领域有四十多个专利。最近三年全职在做服务端的开源项目开发。在极客时间专栏著有OpenResty从入门到实战。
原文地址: https:// cloudnative.to/blog/ful l-traffic-api-gateway-based-on-apache-apisix/