You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by yo...@apache.org on 2022/12/23 01:42:43 UTC
[apisix-website] branch master updated: add four blogs and update two old blogs tags (#1453)
This is an automated email from the ASF dual-hosted git repository.
young pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new 2c616d69dff add four blogs and update two old blogs tags (#1453)
2c616d69dff is described below
commit 2c616d69dff0e8fe673f17d525525379dee7adc3
Author: 长龙 <36...@qq.com>
AuthorDate: Fri Dec 23 09:42:37 2022 +0800
add four blogs and update two old blogs tags (#1453)
---
blog/zh/blog/2022/12/07/junrunrenli-with-apisix.md | 2 +-
.../blog/2022/12/09/insigma-with-apache-apisix.md | 2 +-
.../zh/blog/2022/12/16/amazonlambda-with-apisix.md | 81 +++++++
.../12/19/apisix-ingress-better-than-traefik.md | 148 +++++++++++++
blog/zh/blog/2022/12/19/auth-apisix-gateway.md | 241 +++++++++++++++++++++
blog/zh/blog/2022/12/22/weekly-report-1218.md | 99 +++++++++
6 files changed, 571 insertions(+), 2 deletions(-)
diff --git a/blog/zh/blog/2022/12/07/junrunrenli-with-apisix.md b/blog/zh/blog/2022/12/07/junrunrenli-with-apisix.md
index c2f70afda03..9aab5e53c0c 100644
--- a/blog/zh/blog/2022/12/07/junrunrenli-with-apisix.md
+++ b/blog/zh/blog/2022/12/07/junrunrenli-with-apisix.md
@@ -7,7 +7,7 @@ keywords:
- APISIX
- 君润人力
description: 本文从君润人力业务快速扩张的背景入手，重点介绍开源 API 网关 APISIX 对其自研平台系统架构的多样化应用场景支持。
-tags: [Usercase]
+tags: [Case Studies]
image: https://static.apiseven.com/2022/12/06/638ef9ee2c067.png
---
diff --git a/blog/zh/blog/2022/12/09/insigma-with-apache-apisix.md b/blog/zh/blog/2022/12/09/insigma-with-apache-apisix.md
index 158b0bb95a3..31172bc44f3 100644
--- a/blog/zh/blog/2022/12/09/insigma-with-apache-apisix.md
+++ b/blog/zh/blog/2022/12/09/insigma-with-apache-apisix.md
@@ -7,7 +7,7 @@ keywords:
- APISIX
- 浙大网新
description: 在城市智能交通的覆盖范围下，很多场景对于流量处理和系统稳定性都要求极高。为了应对这种城市级别的数字智能要求，网新电气基于 APISIX 进行了网关层面的迭代。
-tags: [Usercase]
+tags: [Case Studies]
---
> 在城市智能交通的覆盖范围下，很多场景对于流量处理和系统稳定性都要求极高。为了应对这种城市级别的数字智能要求，网新电气基于 APISIX 进行了网关层面的迭代。
diff --git a/blog/zh/blog/2022/12/16/amazonlambda-with-apisix.md b/blog/zh/blog/2022/12/16/amazonlambda-with-apisix.md
new file mode 100644
index 00000000000..ff8370c8c04
--- /dev/null
+++ b/blog/zh/blog/2022/12/16/amazonlambda-with-apisix.md
@@ -0,0 +1,81 @@
+---
+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 插件，具体如下表所示。
+
+| 插件名称 | 描述 |
+| :--------: | :------------ |
+| [serverless](https://apisix.apache.org/docs/apisix/plugins/serverless/) | 用户可以通过 Serverless 插件上传自定义的 Lua 脚本，并根据配置中的 phase 来指定代码运行阶段。例如在 access 阶段对请求进行访问控制，在 header filter，body filter 阶段，对响应头或响应体进行修改，或者在 log 阶段打印个性化日志等。另外，由于 Serverless 插件是热加载的，因此我们不需要重新启动 Apache APISIX 便可立即生效。 |
+| [Azure Function](https://apisix.apache.org/docs/apisix/plugins/azure-functions/) | 用于将 Azure Serverless Function 作为动态上游集成至 APISIX，从而实现将访问指定 URI 的请求代理到 Microsoft Azure 云服务。启用 azure-functions 插件后，该插件会终止对已配置 URI 的请求，并代表客户端向 Azure Functions 发起一个新的请求。该新请求中携带了之前配置的授权详细信息，包括请求头、请求体和参数（以上参数都是从原始请求中传递的）。之后便会通过 azure-functions 插件，将带有响应头、状态码和响应体的信息返回给使用 APISIX 发起请求的客户端。 |
+| [OpenWhisk](https://apisix.apache.org/docs/apisix/plugins/openwhisk/)| 用于将开源的分布式无服务器平台 Apache OpenWhisk 作为动态上游集成至 APISIX。启用 openwhisk 插件后，该插件会终止对已配置 URI 的请求，并代表客户端向 OpenWhisk 的 API Host 端点发起一个新的请求，然后 openwhisk 插件会将响应信息返回至客户端。 |
+|[OpenFunction](https://apisix.apache.org/docs/apisix/plugins/openfunction/) | 用于将开源的分布式无服务器平台 CNCF OpenFunction 作为动态上游集成至 APISIX。启用 openfunction 插件后，该插件会终止对已配置 URI 的请求，并代表客户端向 OpenFunction 的 function 发起一个新的请求，然后 openfunction 插件会将响应信息返回至客户端。 |
+
+
+
+## **总结**
+
+近年来，随着微服务架构的出现，很多企业都开始将业务架构迁移到云端，不少云服务提供商也在推出 Serverless 相关的产品，基于 Serverless 的开发已经成为一种十分便利的开发模式。
+
+本文通过介绍了 Serverless 的相关内容，引出了一个好的网关在 Serverless 架构下的重要性。而 APISIX 就是这样的一个网关，当然本文并未在具体使用细节上进行更丰富的描述，仅仅简单介绍了 APISIX 中的 Serverless 类型的插件 。如果你对这类插件的使用感兴趣，也欢迎在社区中进行更丰富的实践与讨论。
diff --git a/blog/zh/blog/2022/12/19/apisix-ingress-better-than-traefik.md b/blog/zh/blog/2022/12/19/apisix-ingress-better-than-traefik.md
new file mode 100644
index 00000000000..9e8c1d2cdf4
--- /dev/null
+++ b/blog/zh/blog/2022/12/19/apisix-ingress-better-than-traefik.md
@@ -0,0 +1,148 @@
+---
+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
+```
+
+当前的协议多种多样，以下简单汇总了两个项目对协议的支持，仅供参考。
+
+| 协议 | 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)。
+
+此外，Apache APISIX 社区非常活跃，在 GitHub 和 Slack 等频道上都会快速响应。也期待各位在社区积极进行反馈与讨论。
+
+## 总结
+
+本文从协议支持、可扩展性和生态等方面对比了 Apache APISIX Ingress 和 Traefik。从内容中也可以看到，APISIX Ingress 在可扩展性和生态集成方面有一定的优势，用户可以更容易地对 APISIX Ingress 进行扩展，以及与一些基础组件进行集成。
+
+希望本文可以为正在选型 Kubernetes Ingress Controller 产品的用户提供一些帮助。
diff --git a/blog/zh/blog/2022/12/19/auth-apisix-gateway.md b/blog/zh/blog/2022/12/19/auth-apisix-gateway.md
new file mode 100644
index 00000000000..1aec67d494a
--- /dev/null
+++ b/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` 插件去实现一个访问控制机制。
+
+```bash
+curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: your-API-key' -X POST -i -d '
+{
+ "uri": "/api/v1/users/admin",
+ "plugins": {
+ "key-auth": {},
+ "consumer-restriction": {
+ "whitelist": [
+ "Rose",
+ "Peter
+ ]
+ }
+ },
+ "upstream": {
+ ...
+ },
+}'
+```
+
+上述配置中，通过 `key-auth` 和 `consumer-restriction` 两个插件限制了：`/api/v1/users/admin` 路由需要通过 key auth 认证，并且仅 Rose 和 Peter 可以访问。
+
+### **限流限速**
+
+前面我们介绍了可以通过在 Consumer 中配置认证插件将用户凭证与消费者进行关联，事实 APISIX Consumer 对象不仅仅可以挂载认证类型的插件，而是可以像路由和 Service 一样，挂载任意插件。
+
+以限流场景举例，在实际应用中，限流策略往往不是一成不变而是"千人千面"，不同服务等级的调用方拥有不同的 API 限流策略是非常常见的需求，这样的需求是无法通过在路由上挂载限流插件进行解决的。为此，我们可以在消费者上挂载限流插件，并且为每一个消费者指定不同的限流策略。
+
+```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": "jack"
+ },
+ "limit-count": {
+ "count": 200,
+ "time_window": 60,
+ "rejected_code": 503,
+ "key": "$consumer_name",
+ }
+}'
+
+curl http://127.0.0.1:9180/apisix/admin/consumers -H 'X-API-KEY: your-API-key' -X PUT -i -d '
+{
+ "username": "rose",
+ "plugins": {
+ "key-auth": {
+ "key": "rose"
+ },
+ "limit-count": {
+ "count": 1000,
+ "time_window": 60,
+ "rejected_code": 503,
+ "key": "$consumer_name",
+ }
+}'
+```
+
+通过上方的配置，我们为 jack 和 rose 分别指定了不同的限流策略。Rose 在 60 秒内拥有更多的请求次数配额 1000，而 Jack 只有 200 配额。
+
+## **总结**
+
+认证鉴权作为 API 网关不可或缺的能力，已然成为用户在选型 API 网关时考量的重要因素之一。
+
+本文中介绍的开源网关 Apache APISIX，覆盖了所有主流的认证方式，可以满足企业用户对于认证鉴权的需求。同时 APISIX 还拥有其他以下优势：
+
+* 丰富的、开箱即用的认证插件；
+* 同时支持内置、外置认证方式，用户可以自由选择；
+* 支持二次开发，方便对接自定义鉴权中心。
+
+这些优势都可以帮助企业更轻松的落地网关层面的认证鉴权，加强 API 安全。
diff --git a/blog/zh/blog/2022/12/22/weekly-report-1218.md b/blog/zh/blog/2022/12/22/weekly-report-1218.md
new file mode 100644
index 00000000000..8cd4fe69952
--- /dev/null
+++ b/blog/zh/blog/2022/12/22/weekly-report-1218.md
@@ -0,0 +1,99 @@
+---
+title: "社区双周报 (12.05 - 12.18)"
+keywords:
+- Apache APISIX
+- API 网关
+- 社区周报
+- 贡献者
+description: 云原生 API 网关 Apache APISIX 近两周新增了国密密码套件，域名解析优化，Admin API 通过 gRPC 协议链接 ectd 等新功能。
+tags: [Community]
+image: https://static.apiseven.com/2022/12/22/63a40d559fbf7.png
+---
+
+> 从 12 月 5 日开始已有 27 位开发者为 Apache APISIX 提交了 68 个 commit。感谢以下小伙伴为 Apache APISIX 添砖加瓦（排名不分先后），是你们的无私付出，让 Apache APISIX 变得更好！
+
+<!--truncate-->
+
+## 导语
+
+Apache APISIX 从开源第一天就以社区方式成长，迅速成为全世界最活跃的开源 API 网关项目。这些成就，离不开社区小伙伴们的共同奋斗。
+
+“独行者速，众行者远”。Apache APISIX 社区周报希望可以帮助社区小伙伴们更好地掌握 Apache APISIX 社区的进展，方便大家参与到 Apache APISIX 社区中来。
+
+我们还整理了一些适合新来社区的小伙伴们参加的 issue！感兴趣的同学们，走过路过不要错过！
+
+## 贡献者统计
+
+
+
+
+
+## Good first issue
+
+### Issue #1522
+
+**链接**：https://github.com/apache/apisix-ingress-controller/issues/1522
+
+**问题描述**：在 APISIX Ingress 的官网文档内，涉及到一些基础组成要素的内容中，多个文档之间存在不同步/不一致的问题。
+
+### Issue #1547
+
+**链接**：https://github.com/apache/apisix-ingress-controller/issues/1547
+
+**问题描述**：正常情况下，CHANGELOG 文件应该由 release-tools 自动生成。而在最近的情况中，make update-all 指令可以修改 CHANGELOG 文件，这个问题需要修复。
+
+## 近期功能特性亮点
+
+### Apache APISIX
+
+- [新增 `inspect` 插件](https://github.com/apache/apisix/pull/8400)（贡献者：[kingluo](https://github.com/kingluo)）
+
+- [新增支持 Consul 作为服务发现模式](https://github.com/apache/apisix/pull/8380)（贡献者：[Fabriceli](https://github.com/Fabriceli)）
+
+- [支持 `prometheus` 插件在特权进程中计算指标](https://github.com/apache/apisix/pull/8434)（贡献者：[tzssangglass](https://github.com/tzssangglass)）
+
+- [支持通过 gRPC 同步数据](https://github.com/apache/apisix/pull/8450)（贡献者：[spacewander](https://github.com/spacewander)）
+
+- [file-logger 插件支持记录响应体内容](https://github.com/apache/apisix/pull/8414)（贡献者：[pixeldin](https://github.com/pixeldin)）
+
+- [支持在 Stream 子系统中解析域名](https://github.com/apache/apisix/pull/8500)（贡献者：[tzssangglass](https://github.com/tzssangglass)）
+
+### Apache APISIX Ingress
+
+- [为 Ingress 资源添加了新的 Annotation 来支持 response-rewrite 插件](https://github.com/apache/apisix-ingress-controller/pull/1487)（贡献者：[An-DJ](https://github.com/An-DJ)）
+
+- [Ingress: 修正了数万 namespace 场景下，初始化耗时的问题](https://github.com/apache/apisix-ingress-controller/pull/1386)（贡献者：[shareinto](https://github.com/shareinto)）
+
+- [Ingress：允许代理的外部服务可直接指定 Port](https://github.com/apache/apisix-ingress-controller/pull/1500)（贡献者：[Gallardot](https://github.com/Gallardot)）
+
+Apache APISIX 的项目官网和 Github 上的 Issue 上已经积累了比较丰富的文档教程和使用经验，如果您遇到问题可以翻阅文档，用关键词在 Issue 中搜索，也可以参与 Issue 上的讨论，提出自己的想法和实践经验。
+
+## 近期博文推荐
+
+- [聚焦人机交互智能应用领域，APISIX 在希沃网关的应用与实践](https://apisix.apache.org/zh/blog/2022/12/13/seewo-with-apache-apisix/)
+
+ 随着技术的飞速发展，在人际交互智能领域，业务需求也对架构迭代有了更高的要求。为了应对日趋成熟及快速增长的业务现状，希沃又是如何在网关层面进行跟进的呢？
+
+- [智慧交通系统网新电气，如何基于 APISIX 迭代数字智联平台](https://apisix.apache.org/zh/blog/2022/12/09/insigma-with-apache-apisix/)
+
+ 在城市智能交通的覆盖范围下，很多场景对于流量处理和系统稳定性都要求极高。为了应对这种城市级别的数字智能要求，网新电气基于 APISIX 进行了网关层面的迭代。
+
+- [Apache APISIX 玩转 Tongsuo 国密插件](https://apisix.apache.org/zh/blog/2022/12/08/apisix-support-tongsuo/)
+
+ 本文通过解读国密的相关内容与标准，呈现了当下国内技术环境中对于国密功能支持的现状。并从 API 网关 Apache APISIX 的角度，带来有关国密的探索与功能呈现。
+
+- [APISIX 在君润人力云原生平台的架构实践](https://apisix.apache.org/zh/blog/2022/12/07/junrunrenli-with-apisix/)
+
+ 本文从君润人力业务快速扩张的背景入手，重点介绍开源 API 网关 APISIX 对其自研平台系统架构的多样化应用场景支持。
+
+- [译文 | A poor man's API](https://apisix.apache.org/zh/blog/2022/12/a-poor-man%E2%80%98s-api/)
+
+ 本文将展示如何在不编写任何代码的情况下，简单实现一个 API 实践。
+
+- [APISIX Ingress 是如何支持上千个 Pod 副本的应用](https://apisix.apache.org/zh/blog/2022/11/25/how-apisix-support-1000-pods/)
+
+ 本文通过介绍 Kubernetes 中上千个 Pod 副本应用场景的解析，提出技术实现的困难。介绍 APISIX Ingress 是如何解决这一难题的。
+
+- [微服务中的服务发现是什么](https://apisix.apache.org/zh/blog/2022/11/10/what-is-service-in-microservice-discovery/)
+
+ 本文通过服务发现的相关背景和 APISIX 对于服务发现的应用与实践，来介绍微服务中的服务发现内容。