You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2022/12/22 09:21:34 UTC
[GitHub] [apisix-website] SylviaBABY commented on a diff in pull request #1453: add four blogs and update two old blogs tags
SylviaBABY commented on code in PR #1453:
URL: https://github.com/apache/apisix-website/pull/1453#discussion_r1055250725
##########
blog/zh/blog/2022/12/19/amazonlambda-with-apisix copy.md:
##########
@@ -0,0 +1,150 @@
+---
+title: "为什么 APISIX Ingress 是比 Traefik 更好的选择？"
Review Comment:
this file name is same with lamda, need update
##########
blog/zh/blog/2022/12/16/amazonlambda-with-apisix.md:
##########
@@ -0,0 +1,70 @@
+---
+title: "当 Amazon Lambda 遇上 Apache APISIX 可以擦出什么火花？"
+author: "程小兰"
+url: "https://github.com/Hazel6869"
+image_url: "https://github.com/Hazel6869.png"
+keywords:
+- Amazon
+- Lambda
+- AWS
+- APISIX
+- Serverless
+description: 本文通过介绍了 Serverless 的相关内容，引出了一个好的网关在 Serverless 架构下的重要性。而 APISIX 就是这样的一个网关。
+tags: [Case Studies]
+---
+
+> 本文通过介绍了 Serverless 的相关内容，引出了一个好的网关在 Serverless 架构下的重要性。而 APISIX 就是这样的一个网关。
+
+<!--truncate-->
+
+> 作者程小兰，API7.ai 技术工程师
+
+## 什么是 Serverless
+
+Serverless 的基础概念是将运行服务所需的基础设施交由云服务提供商管理，以及一些自部署的 Serverless 平台，从而让使用 Serverless 的工程师可以专注于面向客户业务应用层的开发，而不需要在基础设施的构建、管理、扩容等任务上投入过多精力。
+
+目前，很多云服务提供商也在推出 Serverless 相关的产品。比如 Amazon Serverless 的核心是名为 [AWS Lambda](https://aws.amazon.com/lambda) 的计算服务。
+
+如下图所示，和传统的开发、编译、部署运行方式不同，使用 Amazon Serverless 计算服务 Lambda，仅需要上传源文件，选择执行环境并执行，便能得到运行结果。在该过程中，服务器部署、runtime 安装、编译等，都由 Amazon Serverless 计算平台管理执行。
+
+对工程师来说，只需要维护源代码和 Amazon Serverless 执行环境的相关配置即可。与此相关的技术还有 BaaS（Backend as a Service，后端即服务），是指我们无需编写或者管理所有服务端组件，把应用中的各个部分完全外包出去，而 Serverless 则是一种新的运行代码的托管环境。
+
+### **为什么需要 Serverless**
+
+对于开发人员而言，Serverless 可以对程序执行细节进行抽象，让业务开发工程师专注于代码本身。从上图的对比也可以看出，基于 Serverless 的开发，对于开发人员来说更友好。
+
+从成本角度来看，使用 Serverless 只需按照使用量付费；从服务性能角度来看， Serverless 可以自动响应任何规模的代码执行请求，可以通过调整函数内存大小优化代码执行时间和响应时间。
+
+### **使用 Serverless 时为什么需要一个网关？**
+
+虽然 Serverless 对于开发人员提供了非常大的优势，但 Serverless 服务的使用也存在一些问题。
+
+比如将函数 URL 硬编码到应用程序中；其次应用程序逻辑的授权和身份验证问题也比较繁琐；再者，更新云服务提供商的过程也是一个比较艰巨的工程。
+
+而网关可以天然地解决上述问题，通过二者配合的方式，Serverless 可以更好地解决上述问题。如下图所示，描述的是如何使用 Amazon Serverless 的相关服务迅速组装一个简单的 Web Service，网关将在授权等问题中发挥重要作用。
+
+这里以 Apache APISIX 为例，它为流行的云服务提供商（AWS、Azure）提供 Serverless 框架支持；可以定义一个路由去启用 Serverless 插件，而不是将函数 URL 硬编码到应用程序中；同时，为开发人员提供了热更新函数 URI 的灵活性，更新不同的 FaaS 云服务提供商也没有什么额外的麻烦；此外，这种方法也减轻了应用程序逻辑的授权和身份验证问题。
+
+## **Apache APISIX 与 Serverless**
+
+[Apache APISIX](https://apisix.apache.org/) 是 Apache 软件基金会下的云原生 API 网关，它兼具动态、实时、高性能等特点，提供了负载均衡、动态上游、灰度发布（金丝雀发布）、服务熔断、身份认证、可观测性等丰富的流量管理功能。
+
+我们可以使用 Apache APISIX 来处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。APISIX 通过插件来扩充生态，目前也内置了各类插件，覆盖了 API 网关的各种领域，如认证鉴权、安全、可观测性、流量管理、多协议接入等，当然，也包含很多 Serverless 相关插件。
+
+### **AWS Lambda 插件**
+
+`aws-lambda` 插件用于将 AWS Lambda 作为动态上游集成至 APISIX，从而实现将访问指定 URI 的请求代理到 AWS 云。用户使用该插件终止对已配置 URI 的请求，并代表客户端向 AWS Lambda Gateway URI 发起一个新的请求。
+
+这个新请求中携带了之前配置的授权详细信息，包括请求头、请求体和参数（以上参数都是从原始请求中传递的），之后 `aws-lambda` 插件会将带有响应头、状态码和响应体的响应信息返回给使用 APISIX 发起请求的客户端。该插件支持通过 AWS API key 和 AWS IAM secrets 进行授权。 插件细节可参考[官方文档](https://apisix.apache.org/zh/docs/apisix/plugins/aws-lambda)或者[博客](https://blog.bisakh.com/blog/aws-lambda-apisix)。
+
+### **Serverless 相关插件汇总**
+
+除了 Amazon Lambda，Apache APISIX 目前还支持与 Azure Function、Lua 函数和 Apache OpenWhisk 等 Serverless 相关生态的集成，从而提供了相应的 Serverless 插件，具体如下表所示。
+
+表格 还在加载中，请等待加载完成后再尝试复制
Review Comment:
this part should be form or form image
##########
blog/zh/blog/2022/12/19/auth-apisix-gateway.md:
##########
@@ -0,0 +1,241 @@
+---
+title: "认证鉴权对于 API 网关的重要性"
+author: "钱勇"
+authorUrl: "https://github.com/nic-6443"
+authorImageURL: "https://avatars.githubusercontent.com/u/22141303?v=4"
+keywords:
+- Apache APISIX
+- auth
+- Gateway API
+description: 认证鉴权作为 API 网关不可或缺的能力，已然成为用户在选型 API 网关时考量的重要因素之一。
+tags: [Ecosystem]
+---
+
+> 认证鉴权作为 API 网关不可或缺的能力，已然成为用户在选型 API 网关时考量的重要因素之一。
+
+<!--truncate-->
+
+> 作者钱勇，API7.ai 开发工程师，Apache APISIX Committer
+
+在当下云原生越发成熟的环境下，API 网关最核心的功能可以概括为：连接 API 消费者和 API 提供者。
+
+实际场景中，除去少部分允许匿名访问的 API 外，提供者往往都会对消费者有所限制，比如只有符合条件的消费者才可以对 API 进行访问。其次，提供者对于不同的消费者的访问策略可能并不相同，例如 A、B 消费者都可以访问 `/send_mail` API，但每分钟的调用频次需要区分计算。
+
+从以上两点可以看出在 API 网关层面鉴别和验证 API 消费者的身份至关重要。本文将介绍云原生开源 API 网关 Apache APISIX 如何实现对于消费者的认证，以及目前被企业广泛采用的认证方式。进一步介绍 APISIX 的用户认证体系是如何与其他安全特性联动使用，从而进一步提升 API 网关的安全防护能力。
+
+
+
+## **Apache APISIX 的认证鉴权**
+
+Apache APISIX 是一个动态、实时、高性能的 API 网关，提供负载均衡、动态上游、灰度发布、精细化路由、限流限速、服务降级、服务熔断、身份认证、可观测性等数百项功能。在认证鉴权方面，APISIX 也是提供了非常多且方便的途径。
+
+传统的 HTTP 代理往往只能基于请求域名、客户端 IP 等粗粒度手段对请求方进行识别，这对于一款 API 网关来说是远远不够的，我们需要有更丰富的认证方式来解决越来越复杂的业务需求。而 APISIX 区分于传统代理的一大优势就是灵活的插件扩展能力，这其中就包括一套用于用户认证的插件集合，这些插件根据实现方式的不同可以分为两大类。
+
+第一种是对接外部认证服务，委托其进行认证。
+
+
+
+第二种则是在网关内部认证，配合 APISIX 设计的 Consumer 对象进行认证。
+
+
+
+下面将会依次介绍这两种认证方式。
+
+### **对接外部认证服务**
+
+在企业采用 API 网关之前，系统中往往已经部署了独立的认证服务，此时我们要如何将 APISIX 与已有的认证服务进行对接呢？APISIX 提供了这样一系列插件，它们的工作原理就是通过对接各种外部的认证服务，委托它们完成认证。
+
+例如，我们可以使用 `openid-connect` 插件对接任意支持 OIDC 协议的认证服务，下面是一段对接到 Keycloak 服务的样例配置：
+
+```bash
+curl http://127.0.0.1:9180/apisix/admin/routes -H "X-Api-Key: your-API-key" -XPOST -d '
+{
+ "uri":"/*",
+ "plugins":{
+ "openid-connect":{
+ "client_id":"apisix", // keycloak 创建 client 时生成
+ "client_secret":"d5c42c50-3e71-4bbe-aa9e-31083ab29da4",
+ "discovery":"http://keycloak:8080/auth/realms/apisix_test_realm/.well-known/openid-configuration", // keycloak OpenID Endpoint
+ "scope":"openid profile",
+ "bearer_only":false,
+ "realm":"apisix_test_realm",
+ "introspection_endpoint_auth_method":"client_secret_post",
+ "redirect_uri":"http://127.0.0.1:9080/"
+ }
+ },
+ "upstream":{
+ ...
+ }
+}'
+```
+
+### **网关内部认证**
+
+#### **Consumer**
+
+
+
+当来自多渠道的请求到达 API 网关后，网关需要识别出这些调用方。为此，Apache APISIX 提出了 Consumer 概念，用来代表某类服务的调用方。
+
+Consumer 对象需要配置认证插件进行使用，以最简单的 `key-auth` 插件为例：
+
+```bash
+curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
+{
+ "username": "jack",
+ "plugins": {
+ "key-auth": {
+ "key": "auth-jack"
+ }
+}'
+```
+
+以上配置表示当请求中携带指定的 key（auth-jack）时，当前请求将会与 jack 这个消费者进行关联。可以看到，Consumer 上配置的认证插件实际上就是一个指定认证机制下的身份凭证，在 `key-auth` 插件中，key 即是标识某个消费者的凭证，类似的还有 `basic-auth` 插件的用户名与密码等等。
+
+#### **为路由配置认证插件**
+
+当我们通过 Consumer 将凭证信息与具体的消费者进行关联后，还需要在相应的路由上开启认证插件：
+
+```bash
+curl http://127.0.0.1:9180/apisix/admin/routes/orders -H 'X-API-KEY: your-API-key' -X PUT -i -d '
+{
+ "uri": "/orders",
+ "plugins": {
+ "key-auth": {
+ "header": "Authorization"
+ }
+ }
+}'
+```
+
+以上配置表示在 `/orders` 这个路由上开启 `key-auth` 插件，验证效果如下：
+
+```bash
+curl http://127.0.0.1:9080/orders -H 'Authorization: auth-jack' -i
+
+HTTP/1.1 200 OK
+...
+
+curl http://127.0.0.1:9080/orders -H 'Authorization: wrong-key' -i
+
+HTTP/1.1 401 Unauthorized
+...
+{"message":"Invalid API key in request"}
+```
+
+当来自用户的请求命中这条路由时，APISIX 会尝试通过 `Authorization` 头部拿到用户提供的 Key。如果无法获取或者获取到的 Key 是不合法的，那么该请求将会被网关直接拒绝，从而保护上游服务。
+
+可以看到以上两种认证方式中，认证插件都处于整个体系中的核心地位，它的丰富度将直接影响着 API 网关用户对于认证方式的选择空间。
+
+## **APISIX 支持的认证方式**
+
+认证鉴权作为计算机世界从第一天起就存在的基础机制，经过这么多年的迭代，已经发展成为一个非常多样化的领域。而 APISIX 的插件机制极大地降低了实现各种认证方式的开发成本，以下是部分 APISIX 已经支持的主流认证方式。
+
+### **Key Auth**
+
+Key Auth 是目前 APISIX 所支持的认证方式中，使用起来最简单的。但 `key-auth` 插件在实际环境中有着非常丰富的应用场景，例如：收费软件中的 License、开放 API 平台中的用于标识开发者的 token 等等，都可以非常轻松地使用 `key-auth` 来实现。并且基于 APISIX 全动态的配置下发能力，Key 可以被迅速创建、吊销，而且实时生效。
+
+### **Basic Auth**
+
+Basic Auth 是基于用户名、密码进行认证的方式，常用于网页登录场景，例如：网站的管理后台需要管理员登录后才可以使用，那么我们可以使用 Basic Auth 方式进行认证。
+
+### **LDAP**
+
+LDAP（Lightweight Directory Access Protocol）是一种基于X.500 标准的轻量级文件访问协议，通过IP 协议提供访问控制和维护分布式信息的目录信息，借助于 LDAP ，运维人员可以细粒度地控制用户对资源的访问权限。通过 APISIX 的 `ldap-auth` 插件，可以轻松对接实现了 LDAP 协议的平台，例如微软的 Active Direcory，或者 Linux 平台的 OpenLDAP Server，从而能够精细化地控制 Consumer 对具体路由的访问权限。
+
+### **OIDC**
+
+OpenID 是一个去中心化的网上身份认证系统。对于支持 OpenID 的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为 OpenID 身份提供者（identity provider, IdP）的网站上注册账号，而后就可以用这个账号登录所有对接了该提供者的应用，例如：可以通过知名的 Google 或者 Facebook 服务的账号来认证我们自身系统的用户。
+
+针对 OIDC，APISIX 提供了 `openid-connect` 插件，可以用于对接支持了 OIDC 协议的认证服务。
+
+### **Forward Auth**
+
+当 APISIX 的标准认证插件无法满足你当前需求时，或者当前系统中已经部署了专门的并且是非标准协议的认证服务，此时你可以考虑使用 `forward-auth` 插件。使用该插件可以将用户的请求通过 HTTP 形式转发至认证服务中，并在认证服务响应非正常状态（错误码非 20x）时，返回自定义报错或者将用户重定向至认证页面。
+
+借助 `forward-auth` 插件的能力，可以非常巧妙地将认证与授权逻辑转移到专门的、非标准协议的外部服务中。
+
+## **“认证+任意功能”，APISIX 助力 API 安全**
+
+用户认证只是 APISIX 保障 API 安全的第一步，将认证能力与其他安全类型插件的有机结合将会进一步放大网关的安全能力。
+
+### **ACL 访问控制**
+
+在一个复杂的后端系统中，可能会存在部分 API 的安全限制是高于其他 API 的，这种限制不仅需要拦截匿名用户，而且需要对认证用户进行限制，例如：只允许白名单用户访问用户管理 API。
+
+
+
+此时我们可以使用 APISIX 提供的 `consumer-restriction` 插件去实现一个访问控制机制。
+
+```plain
Review Comment:
```suggestion
```shell
```
##########
blog/zh/blog/2022/12/19/amazonlambda-with-apisix copy.md:
##########
@@ -0,0 +1,150 @@
+---
+title: "为什么 APISIX Ingress 是比 Traefik 更好的选择？"
+author: "张晋涛"
+authorURL: "https://github.com/tao12345666333"
+authorImageURL: "https://github.com/tao12345666333.png"
+keywords:
+- Apache APISIX
+- Ingress
+- Ingress controller
+- Gateway API
+- Traefik
+description: 本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
+tags: [Ecosystem]
+---
+
+> 本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
+
+<!--truncate-->
+
+> 作者张晋涛，API7.ai 云原生专家，Apache APISIX Committer、Kubernetes Ingress Nginx Reviewer
+
+## Apache APISIX Ingress
+
+[Apache APISIX Ingress](https://github.com/apache/apisix-ingress-controller/) 是一个使用 Apache APISIX 作为数据面的 Kubernetes Ingress controller 实现。
+
+目前，它支持多种规则的配置方式，包括 Ingress、APISIX Ingress CRD （自定义资源）以及 Gateway API。
+
+其整体采用数据面与控制面分离的架构，由 Apache APISIX 承载实际的业务流量。因此大大提升了整体的安全性，极大避免了由于数据面被攻击而导致 Kubernetes 集群被攻击的可能。
+
+
+
+## Traefik
+
+Traefik 是由 Traefik Labs 开源的一款反向代理和负载均衡器。它在 Kubernetes 中支持多种规则的配置方式，包括 Ingress、Traefik IngressRoute（自定义资源）和 Gateway API。
+
+Traefik 是一个统一的二进制文件，控制面和数据面的代理逻辑均绑定在一起。因此，如果受到攻击或者有远程执行的安全漏洞被利用，极有可能存在 Kubernetes 集群被攻击的情况。
+
+
+
+## APISIX Ingress vs Traefik
+
+接下来我将从以下几个维度对 Apache APISIX Ingress 和 Traefik 进行一些对比，方便大家在选型时对产品有更多的认知。
+
+### 协议支持
+
+作为网关，最为核心的能力便是要能够正确的代理流量。作为 Kubernetes 集群的入口网关，主要处理如下两部分的流量：即 **Client 到网关的流量**和**网关与 Upstream 的流量**。如下所示：
+
+```bash
+Client <----> Ingress <----> Upstream Service
+```
+
+当前的协议多种多样，以下简单汇总了两个项目对协议的支持，仅供参考。
+
+（如 md 文件可引用下方格式）
+
+| 协议 | APISIX Ingress | Traefik |
+| :--------: | :------------: | :-----: |
+| HTTP/HTTPS | 支持 | 支持 |
+| HTTP/2 | 支持 | 支持 |
+| HTTP/3 | 不支持 | 支持 |
+| TCP | 支持 | 支持 |
+| UDP | 支持 | 支持 |
+| WebSocket | 支持 | 支持 |
+| Dubbo | 支持 | 不支持 |
+
+此外，无论是 APISIX Ingress 还是 Traefik，均可通过 HTTP/2 或者 TCP 代理等方式支持 gRPC、MQTT 等协议，故而未在上述表格中列出。
+
+从协议支持的角度来看，APISIX Ingress 和 Traefik 各有优势。此外，APISIX 对于 HTTP/3 的支持正在规划中，后续也可随时关注社区动态。
+
+### 可扩展性
+
+由于业务需求多种多样，所以可扩展性也是进行技术选型的一个主要指标。APISIX Ingress 和 Traefik 均提供了一些扩展方式，我们将分别进行介绍。
+
+#### APISIX Ingress
+
+在 APISIX Ingress 中进行功能扩展，主要是通过开发自定义插件来完成。当前，APISIX Ingress 主要支持如下几种插件的开发方式：
+
+* 通过 Lua 进行插件的开发：这种方式相对简单，并且几乎没有性能损耗；
+* 通过 Plugin Runner 开发：这种模式下支持 JAVA/Python/Go 等多种计算语言进行开发，方便用户利用现有的业务逻辑，同时无需学习新语言；
+* 通过 WASM 进行插件插件：这种模式下，可以使用任何支持构建出 WASM 的语言进行插件开发；
+
+此外，还可以通过 Serverless 插件来直接编排 Lua 代码，满足业务需求。
+
+当然，如果你有 Lua 模块的开发经验，也可以直接编写 Lua 模块，然后进行加载即可，只需在配置文件中增加如下内容即可：
+
+```yaml
+apisix:
+...
+extra_lua_path: "/path/to/example/?.lua"
+```
+
+具体关于插件的的开发步骤和使用，请参考 [Apache APISIX 的插件开发文档](https://apisix.apache.org/docs/apisix/plugin-develop/)。
+
+#### Traefik
+
+Traefik 也提供了相关插件机制用于功能扩展。但是 Traefik 是由 Go 进行开发的，因此它的插件也需要用 Go 进行开发。
+
+在开发完成后，就可以在 Traefik 的配置中添加如下内容进行引用了（需注意，插件的名字需要与包名保持一致）。例如：
+
+```yaml
+experimental:
+localPlugins:
+example:
+moduleName: github.com/traefik/pluginproviderdemo
+```
+
+总体来看，APISIX Ingress 提供了更多种的扩展方式，可以根据实际情况进行灵活选择。可以根据自己喜欢或擅长的工具即可，更容易实现与现有业务集成。而 Traefik 目前则只支持通过 Go 语言进行开发，选择较少。
+
+### 生态
+
+在进行技术选型时候，除了考虑一些性能表现，还需要对产品的整个生态支持进行考察。比如项目所使用的协议、项目归属以及与现有基础设施是否可以整合等等。下方简单整理了几个角度进行呈现（包含了控制面和数据面）。
+
+| 对比维度 | APISIX Ingress | Traefik |
+| :-------: | :----------------------: | :----------: |
+| 归属 | Apache 软件基金会（ASF） | Traefik Labs |
+| 协议 | Apache 2.0 | MIT |
+| 诞生时间 | 2019 年 6 月 | 2015 年 8 月 |
+| consul | 支持 | 支持 |
+| nacos | 支持 | 不支持 |
+| Eureka | 支持 | 不支持 |
+| etcd | 支持 | 支持 |
+| zookeeper | 支持 | 支持 |
+| DNS | 支持 | 不支持 |
+
+此外，这两个项目都非常积极与一些周边项目进行了集成与合作。比如 Rancher、KubeSphere 等。
+
+从生态合作角度来看，APISIX Ingress 比 Traefik 提供了更为广泛的集成能力，尤其是与基础组件。因此在进行技术选型时，可以结合当前自己所用的基础组件的情况进行权衡。
+
+## 来自用户的声音
+
+在今年，我们也看到了很多来自用户的声音，他们开始在业务架构中用上了 APISIX Ingress。比如 [地平线使用 APISIX Ingress 替换了 Traefik](https://www.apiseven.com/usercase/apisix-ingress-with-horizon-ai)，主要是考虑如下方面：
Review Comment:
```suggestion
在今年，我们也看到了很多来自用户的声音，他们开始在业务架构中用上了 APISIX Ingress。比如[地平线使用 APISIX Ingress 替换了 Traefik](https://www.apiseven.com/usercase/apisix-ingress-with-horizon-ai)，主要是考虑如下方面：
```
##########
blog/zh/blog/2022/12/19/amazonlambda-with-apisix copy.md:
##########
@@ -0,0 +1,150 @@
+---
+title: "为什么 APISIX Ingress 是比 Traefik 更好的选择？"
+author: "张晋涛"
+authorURL: "https://github.com/tao12345666333"
+authorImageURL: "https://github.com/tao12345666333.png"
+keywords:
+- Apache APISIX
+- Ingress
+- Ingress controller
+- Gateway API
+- Traefik
+description: 本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
+tags: [Ecosystem]
+---
+
+> 本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
+
+<!--truncate-->
+
+> 作者张晋涛，API7.ai 云原生专家，Apache APISIX Committer、Kubernetes Ingress Nginx Reviewer
+
+## Apache APISIX Ingress
+
+[Apache APISIX Ingress](https://github.com/apache/apisix-ingress-controller/) 是一个使用 Apache APISIX 作为数据面的 Kubernetes Ingress controller 实现。
+
+目前，它支持多种规则的配置方式，包括 Ingress、APISIX Ingress CRD （自定义资源）以及 Gateway API。
+
+其整体采用数据面与控制面分离的架构，由 Apache APISIX 承载实际的业务流量。因此大大提升了整体的安全性，极大避免了由于数据面被攻击而导致 Kubernetes 集群被攻击的可能。
+
+
+
+## Traefik
+
+Traefik 是由 Traefik Labs 开源的一款反向代理和负载均衡器。它在 Kubernetes 中支持多种规则的配置方式，包括 Ingress、Traefik IngressRoute（自定义资源）和 Gateway API。
+
+Traefik 是一个统一的二进制文件，控制面和数据面的代理逻辑均绑定在一起。因此，如果受到攻击或者有远程执行的安全漏洞被利用，极有可能存在 Kubernetes 集群被攻击的情况。
+
+
+
+## APISIX Ingress vs Traefik
+
+接下来我将从以下几个维度对 Apache APISIX Ingress 和 Traefik 进行一些对比，方便大家在选型时对产品有更多的认知。
+
+### 协议支持
+
+作为网关，最为核心的能力便是要能够正确的代理流量。作为 Kubernetes 集群的入口网关，主要处理如下两部分的流量：即 **Client 到网关的流量**和**网关与 Upstream 的流量**。如下所示：
+
+```bash
+Client <----> Ingress <----> Upstream Service
+```
+
+当前的协议多种多样，以下简单汇总了两个项目对协议的支持，仅供参考。
+
+（如 md 文件可引用下方格式）
+
+| 协议 | APISIX Ingress | Traefik |
+| :--------: | :------------: | :-----: |
+| HTTP/HTTPS | 支持 | 支持 |
+| HTTP/2 | 支持 | 支持 |
+| HTTP/3 | 不支持 | 支持 |
+| TCP | 支持 | 支持 |
+| UDP | 支持 | 支持 |
+| WebSocket | 支持 | 支持 |
+| Dubbo | 支持 | 不支持 |
+
+此外，无论是 APISIX Ingress 还是 Traefik，均可通过 HTTP/2 或者 TCP 代理等方式支持 gRPC、MQTT 等协议，故而未在上述表格中列出。
+
+从协议支持的角度来看，APISIX Ingress 和 Traefik 各有优势。此外，APISIX 对于 HTTP/3 的支持正在规划中，后续也可随时关注社区动态。
+
+### 可扩展性
+
+由于业务需求多种多样，所以可扩展性也是进行技术选型的一个主要指标。APISIX Ingress 和 Traefik 均提供了一些扩展方式，我们将分别进行介绍。
+
+#### APISIX Ingress
+
+在 APISIX Ingress 中进行功能扩展，主要是通过开发自定义插件来完成。当前，APISIX Ingress 主要支持如下几种插件的开发方式：
+
+* 通过 Lua 进行插件的开发：这种方式相对简单，并且几乎没有性能损耗；
+* 通过 Plugin Runner 开发：这种模式下支持 JAVA/Python/Go 等多种计算语言进行开发，方便用户利用现有的业务逻辑，同时无需学习新语言；
+* 通过 WASM 进行插件插件：这种模式下，可以使用任何支持构建出 WASM 的语言进行插件开发；
+
+此外，还可以通过 Serverless 插件来直接编排 Lua 代码，满足业务需求。
+
+当然，如果你有 Lua 模块的开发经验，也可以直接编写 Lua 模块，然后进行加载即可，只需在配置文件中增加如下内容即可：
+
+```yaml
+apisix:
+...
+extra_lua_path: "/path/to/example/?.lua"
+```
+
+具体关于插件的的开发步骤和使用，请参考 [Apache APISIX 的插件开发文档](https://apisix.apache.org/docs/apisix/plugin-develop/)。
+
+#### Traefik
+
+Traefik 也提供了相关插件机制用于功能扩展。但是 Traefik 是由 Go 进行开发的，因此它的插件也需要用 Go 进行开发。
+
+在开发完成后，就可以在 Traefik 的配置中添加如下内容进行引用了（需注意，插件的名字需要与包名保持一致）。例如：
+
+```yaml
+experimental:
+localPlugins:
+example:
+moduleName: github.com/traefik/pluginproviderdemo
+```
+
+总体来看，APISIX Ingress 提供了更多种的扩展方式，可以根据实际情况进行灵活选择。可以根据自己喜欢或擅长的工具即可，更容易实现与现有业务集成。而 Traefik 目前则只支持通过 Go 语言进行开发，选择较少。
+
+### 生态
+
+在进行技术选型时候，除了考虑一些性能表现，还需要对产品的整个生态支持进行考察。比如项目所使用的协议、项目归属以及与现有基础设施是否可以整合等等。下方简单整理了几个角度进行呈现（包含了控制面和数据面）。
+
+| 对比维度 | APISIX Ingress | Traefik |
+| :-------: | :----------------------: | :----------: |
+| 归属 | Apache 软件基金会（ASF） | Traefik Labs |
+| 协议 | Apache 2.0 | MIT |
+| 诞生时间 | 2019 年 6 月 | 2015 年 8 月 |
+| consul | 支持 | 支持 |
+| nacos | 支持 | 不支持 |
+| Eureka | 支持 | 不支持 |
+| etcd | 支持 | 支持 |
+| zookeeper | 支持 | 支持 |
+| DNS | 支持 | 不支持 |
+
+此外，这两个项目都非常积极与一些周边项目进行了集成与合作。比如 Rancher、KubeSphere 等。
+
+从生态合作角度来看，APISIX Ingress 比 Traefik 提供了更为广泛的集成能力，尤其是与基础组件。因此在进行技术选型时，可以结合当前自己所用的基础组件的情况进行权衡。
+
+## 来自用户的声音
+
+在今年，我们也看到了很多来自用户的声音，他们开始在业务架构中用上了 APISIX Ingress。比如 [地平线使用 APISIX Ingress 替换了 Traefik](https://www.apiseven.com/usercase/apisix-ingress-with-horizon-ai)，主要是考虑如下方面：
+
+* 通过 Annotation 增加的配置不易重用；
+* Traefik 中默认的行为与 NGINX 中不同，用户在使用时候会产生困惑；
+
+在切换为 Apache APISIX Ingress 后，得益于 APISIX Ingress 丰富的插件生态，绝大多数需求均可通过内置插件满足。并且插件的配置可直接通过 APISIX Ingress 的 ApisixRoute 资源进行定义，比较直观。也可以通过 ApisixPluginConfig 进行插件模板的配置，在其他的 ApisixRoute 资源中进行引用。
+
+
+
+APISIX Ingress 的数据面性能更佳，能高效地应对日益增长的业务流量，而不会陷入性能瓶颈。
+
+除地平线以外，包括 [少年得到](http://www.igetcool.com/)，[观为智慧](http://www.gwwisdom.com/) 等公司也都使用 APISIX Ingress 替换了 Traefik，更多用户案例请参考 [用户案例](https://www.apiseven.com/usercases)。
Review Comment:
```suggestion
除地平线以外，包括[少年得到](http://www.igetcool.com/)，[观为智慧](http://www.gwwisdom.com/)等公司也都使用 APISIX Ingress 替换了 Traefik，更多用户案例请参考[用户案例](https://www.apiseven.com/usercases)。
```
##########
blog/zh/blog/2022/12/19/amazonlambda-with-apisix copy.md:
##########
@@ -0,0 +1,150 @@
+---
+title: "为什么 APISIX Ingress 是比 Traefik 更好的选择？"
+author: "张晋涛"
+authorURL: "https://github.com/tao12345666333"
+authorImageURL: "https://github.com/tao12345666333.png"
+keywords:
+- Apache APISIX
+- Ingress
+- Ingress controller
+- Gateway API
+- Traefik
+description: 本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
+tags: [Ecosystem]
+---
+
+> 本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
+
+<!--truncate-->
+
+> 作者张晋涛，API7.ai 云原生专家，Apache APISIX Committer、Kubernetes Ingress Nginx Reviewer
+
+## Apache APISIX Ingress
+
+[Apache APISIX Ingress](https://github.com/apache/apisix-ingress-controller/) 是一个使用 Apache APISIX 作为数据面的 Kubernetes Ingress controller 实现。
+
+目前，它支持多种规则的配置方式，包括 Ingress、APISIX Ingress CRD （自定义资源）以及 Gateway API。
+
+其整体采用数据面与控制面分离的架构，由 Apache APISIX 承载实际的业务流量。因此大大提升了整体的安全性，极大避免了由于数据面被攻击而导致 Kubernetes 集群被攻击的可能。
+
+
+
+## Traefik
+
+Traefik 是由 Traefik Labs 开源的一款反向代理和负载均衡器。它在 Kubernetes 中支持多种规则的配置方式，包括 Ingress、Traefik IngressRoute（自定义资源）和 Gateway API。
+
+Traefik 是一个统一的二进制文件，控制面和数据面的代理逻辑均绑定在一起。因此，如果受到攻击或者有远程执行的安全漏洞被利用，极有可能存在 Kubernetes 集群被攻击的情况。
+
+
+
+## APISIX Ingress vs Traefik
+
+接下来我将从以下几个维度对 Apache APISIX Ingress 和 Traefik 进行一些对比，方便大家在选型时对产品有更多的认知。
+
+### 协议支持
+
+作为网关，最为核心的能力便是要能够正确的代理流量。作为 Kubernetes 集群的入口网关，主要处理如下两部分的流量：即 **Client 到网关的流量**和**网关与 Upstream 的流量**。如下所示：
+
+```bash
+Client <----> Ingress <----> Upstream Service
+```
+
+当前的协议多种多样，以下简单汇总了两个项目对协议的支持，仅供参考。
+
+（如 md 文件可引用下方格式）
Review Comment:
delete this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org