You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by ju...@apache.org on 2021/11/10 04:07:05 UTC
[apisix-website] 01/01: fix: use lowercase filename
This is an automated email from the ASF dual-hosted git repository.
juzhiyuan pushed a commit to branch fix-filename-sensitive
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
commit c01af8a3c4f1e242101b99070dda4c8b6d6f07d0
Author: juzhiyuan <ju...@apache.org>
AuthorDate: Wed Nov 10 12:05:51 2021 +0800
fix: use lowercase filename
---
...of-apache-apisix-ingress-controller-released.md | 104 +++++++++
.../21/use-Java-to-write-Apache-APISIX-plugins.md | 4 +-
... => use-java-to-write-apache-apisix-plugins.md} | 4 +-
.../blog/2021/06/28/why-we-need-apache-apisix.md | 181 ++++++++++++++++
...of-apache-apisix-ingress-controller-released.md | 104 +++++++++
.../21/use-java-to-write-apache-apisix-plugins.md | 241 +++++++++++++++++++++
.../2021/06/28/why-we-need-apache-apisix.md | 176 +++++++++++++++
7 files changed, 810 insertions(+), 4 deletions(-)
diff --git a/website/blog/2021/06/18/first-ga-version-v1.0-of-apache-apisix-ingress-controller-released.md b/website/blog/2021/06/18/first-ga-version-v1.0-of-apache-apisix-ingress-controller-released.md
new file mode 100644
index 0000000..4a319cc
--- /dev/null
+++ b/website/blog/2021/06/18/first-ga-version-v1.0-of-apache-apisix-ingress-controller-released.md
@@ -0,0 +1,104 @@
+---
+title: The first GA release of Apache APISIX Ingress Controller v1.0 is now available!
+author: Jintao Zhang
+authorURL: "https://github.com/tao12345666333"
+authorImageURL: "https://avatars.githubusercontent.com/u/3264292?v=4"
+keywords:
+- APISIX
+- Apache APISIX
+- Ingress Controller
+description: Apache APISIX Ingress Controller v1.0 has been released, supporting the use of custom resources including ApisixRoute and ApisixUpstream, as well as Kubernetes native Ingress resources to control external traffic access to services deployed in Kubernetes.
+tags: [Release]
+---
+
+> Apache APISIX Ingress Controller v1.0 has been released, supporting the use of custom resources including `ApisixRoute`, `ApisixUpstream`, and Kubernetes native Ingress resources to control external traffic access to services deployed in Kubernetes. services deployed in Kubernetes.
+
+<!--truncate-->
+
+## About Apache APISIX Ingress Controller
+
+The Apache APISIX Ingress Controller is a cloud-native Ingress Controller implementation that uses Apache APISIX as a data plane to carry traffic and extends Kubernetes using CRD.
+
+<!--truncate-->
+
+Supports controlling external traffic access to services deployed in Kubernetes using custom resources including ApisixRoute, ApisixUpstream, and Kubernetes-native Ingress resources.
+
+The overall architecture is as follows.
+
+
+
+## v1.0 latest features
+
+### Add ApisixConsumer custom resource to make configuration authentication more convenient
+
+In the previous version, if you want to configure keyAuth or basicAuth, you need to manually call Apache APISIX admin api to create consumer configuration.
+
+In v1.0, we added the `ApisixConsumer` resource, which allows users to define consumer resources and configure authentication for ApisixRoute in a more native way.
+
+For example, a keyAuth resource is defined with the following configuration.
+
+```yaml
+apiVersion: apisix.apache.org/v2alpha1
+kind: ApisixConsumer
+metadata:
+ name: keyauth
+spec:
+ authParameter:
+ keyAuth:
+ value:
+ key: API
+```
+
+In ApisixRoute you only need to add the corresponding type of `authentication` configuration.
+
+```yaml
+apiVersion: apisix.apache.org/v2alpha1
+kind: ApisixRoute
+metadata:
+ name: httpbin-route
+spec:
+ http:
+ ...
+ authentication:
+ enable: true
+ type: keyAuth
+```
+
+### Adding mTLS support to ApisixTls
+
+In v1.0 we also added mTLS support for ApisixTls custom resources, just add the client configuration to the ApisixTls resource configuration, e.g.
+
+```yaml
+apiVersion: apisix.apache.org/v1
+kind: ApisixTls
+metadata:
+ name: sample-tls
+spec:
+ ...
+ client:
+ ... client: caSecret:
+ name: client-ca-secret
+ namespace: default
+````
+
+### Added more annotations to the native Ingress resource to enrich its functionality
+
+- `k8s.apisix.apache.org/blocklist-source-range` to restrict the source IP.
+- `k8s.apisix.apache.org/rewrite-target` and `k8s.apisix.apache.org/rewrite-target-regex` to perform target rewrite operations.
+- `k8s.apisix.apache.org/http-to-https` to perform HTTP to HTTPS forced redirects.
+
+See the project [CHANGELOG](https://github.com/apache/apisix-ingress-controller/blob/master/CHANGELOG.md) for more feature changes.
+
+## Why use APISIX Ingress Controller
+
+Apache APISIX Ingress Controller uses Apache APISIX as its data plane to carry business traffic, so it inherits the following advantages from Apache APISIX.
+
+- **High Performance & Stability**: Apache APISIX is a cloud-native high-performance dynamic API gateway that has been used in many enterprise large-scale traffic scenarios, and its performance and stability have been tested for a long time.
+- **Rich ecology**: Apache APISIX is currently the most active open source gateway project, as the top project of Apache, both the community activity and its plug-in ecology are very rich, can meet the user's multiple use scenarios and needs.
+
+In addition, because APISIX Ingress Controller also has the following unique advantages.
+
+- **Good compatibility**: supports multiple Ingress resource versions and works fine in different Kubernetes versions.
+- **Dynamic updates**: Both Ingress resources and configuration updates such as certificates are hot loaded without reload, ensuring smooth business operation.
+- **Flexible Scalability**: Since APISIX Ingress Controller adopts the architecture of separate control plane and data plane, the data plane cluster of Apache APISIX can be scaled up separately without scaling up Apache APISIX Ingress Controller.
+- **Operation and Maintenance Friendly**: Under the current architecture, users can choose to deploy the dataplane Apache APISIX cluster in a Kubernetes cluster or in a physical machine environment as the case may be. And Apache APISIX Ingress Controller failure will not have any impact on business traffic.
diff --git a/website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md b/website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md
index 90d6fab..481d2c0 100644
--- a/website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md
+++ b/website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md
@@ -18,7 +18,7 @@ tags: [Practical Case]
## Introduction
-### Why Apache APISIX Supports Writing Plugins in Multiple Programming Languages?
+### Why Apache APISIX Supports Writing Plugins in Multiple Programming Languages
Apache APISIX has been supporting customized plugins since the day it was born. But it only supported plugins written in Lua. As a result, developers need to have Lua and OpenResty-related development skills to actually write their own plugins. However, Lua and OpenResty are relatively less popular languages with fewer developers compared to Java and Go. Besides, learning Lua and OpenResty from scratch requires a lot of time and effort.
@@ -73,7 +73,7 @@ If you are using IDEA for development, the configured environment variables are
apisix-java-plugin-runner is equivalent to the server side and will actively create the `/tmp/runner.sock` file at startup and communicate with Apache APISIX on this file for Unix Domain Socket.
-## How to Develop a Java Plugin for Apache APISIX?
+## How to Develop a Java Plugin for Apache APISIX
### Scenario
diff --git a/website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md b/website/blog/2021/06/21/use-java-to-write-apache-apisix-plugins.md
similarity index 99%
copy from website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md
copy to website/blog/2021/06/21/use-java-to-write-apache-apisix-plugins.md
index 90d6fab..481d2c0 100644
--- a/website/blog/2021/06/21/use-Java-to-write-Apache-APISIX-plugins.md
+++ b/website/blog/2021/06/21/use-java-to-write-apache-apisix-plugins.md
@@ -18,7 +18,7 @@ tags: [Practical Case]
## Introduction
-### Why Apache APISIX Supports Writing Plugins in Multiple Programming Languages?
+### Why Apache APISIX Supports Writing Plugins in Multiple Programming Languages
Apache APISIX has been supporting customized plugins since the day it was born. But it only supported plugins written in Lua. As a result, developers need to have Lua and OpenResty-related development skills to actually write their own plugins. However, Lua and OpenResty are relatively less popular languages with fewer developers compared to Java and Go. Besides, learning Lua and OpenResty from scratch requires a lot of time and effort.
@@ -73,7 +73,7 @@ If you are using IDEA for development, the configured environment variables are
apisix-java-plugin-runner is equivalent to the server side and will actively create the `/tmp/runner.sock` file at startup and communicate with Apache APISIX on this file for Unix Domain Socket.
-## How to Develop a Java Plugin for Apache APISIX?
+## How to Develop a Java Plugin for Apache APISIX
### Scenario
diff --git a/website/blog/2021/06/28/why-we-need-apache-apisix.md b/website/blog/2021/06/28/why-we-need-apache-apisix.md
new file mode 100644
index 0000000..1b2542e
--- /dev/null
+++ b/website/blog/2021/06/28/why-we-need-apache-apisix.md
@@ -0,0 +1,181 @@
+---
+title: Why do you need Apache APISIX when you have NGINX and Kong?
+author: Yuansheng Wang
+authorURL: "https://github.com/membphis"
+authorImageURL: "https://avatars.githubusercontent.com/u/6814606?v=4"
+keywords:
+- APISIX
+- Kong
+- Nginx
+- API Gateway
+- Open Source
+description: This article describes the evolution of the Apache APISIX architecture and compares what the advantages of the two frameworks, Apache APISIX and Nginx, are.
+tags: [Technology]
+---
+
+> This article describes the history of the evolution of the Apache APISIX architecture and compares what the advantages of the two frameworks, Apache APISIX and Nginx, are.
+
+<!--truncate-->
+
+> Source: https://www.apiseven.com/zh/blog/why-we-need-Apache-APISIX
+
+Hello everyone, I'm happy to share a topic that I'm excited about, "Why do you need Apache APISIX when you have NGINX and Kong".
+
+
+
+The reason why we are doing a replacement project for NGINX and Kong is actually related to the background of our backend architecture evolution, and I will start by sharing with you the backend architecture evolution process, which is very important.
+
+I'll start by sharing with you the evolution of the backend architecture, which is very important.
+
+
+First of all, I would like to introduce myself, my name is Yuansheng Wang. I wrote an e-book called "OpenResty Best Practices" in 2015 and formed a community of over 10,000 people through this book. Since that time, I have become more and more interested in open source itself. Before 2015, I was basically mainly a user of open source software, then slowly became a co-organizer of the community, and then later became a community leader. Simple, because the book is written by you, others e [...]
+
+
+
+I've been a teacher and eventually a community leader. In 2019, I founded Shenzhen Tributary Technology Company with my partner Ming Wen, which is an open source-based commercialization company. This company carries a lot of personal ideals for both of us, and we can also say that we are doing the ideals of every ordinary programmer, not wanting to be mediocre 996, I often say to others that my dream is to "engrave my name into the history books", the sad thing is that human beings no lo [...]
+
+The sad thing is that mankind doesn't need a history anymore.
+
+
+This is our team, we mainly collaborate remotely, and it's harder to get everyone together. When there were only five or six people in the early stages of the company, it was relatively easy to get the team together, but it hasn't been together since this year, and this is the most together we've had so far this year (but there are still a few students who didn't make it together).
+
+As a technology-driven business company, technology has a very big say in our company, and respect for technology starts with respect for technical talents. There is no 996, no punching in and out, remote office, welcome interested students to contact us, look forward to dreaming and ideal you to join our company.
+
+We are looking forward to your dream and ideal to join us.
+
+
+The topic of this talk needs some background, so let's start with the history of back-end architecture evolution. First, let's review this diagram, the right part from top to bottom it is not a specific data flow diagram, it is the history of our backend architecture evolution. Spring Cloud architecture mainly serves JAVA language developers, Kubernetes is a container orchestration to support any language, as well as the recent community hot topic service grid.
+
+I often say to colleagues, let's look at the next five years, or even ten years later, which architecture is the ultimate solution? From the current information, the service grid will probably win. Even if it still has many problems, I believe they can be solved.
+
+
+
+At the beginning of the venture, it was particularly interesting to go through this diagram in my head. We were able to see that as we gradually iterated on the back-end architecture, we introduced a variety of different components. For example, when we got to SOA, which is a service-oriented architecture, we introduced reverse proxy components, usually NGINX and HAProxy, and when we iterated to microservice architecture, we usually chose some more modern API gateway products, such as Ko [...]
+
+As the backend architecture continues to iterate and enters the Kubernetes era, the traffic portal Ingress will use the official Kubernetes Ingress by default, which is based on the NGINX local configuration file. Some companies in China are also using Traefik as Ingress, which has a lot to do with the large base of Golang developers in China.
+
+Let's look at the left side of the more interesting JAVA, Spring Cloud built-in API gateway has experienced ZUUL, ZUUL2, but still not good, performance, architecture official are not satisfied, so Spring Cloud official launched a new project Spring Cloud Gateway, the final formation of the family bucket solution.
+
+Finally, the bottom right part of the service grid, for the service grid has formed a choice istio (CP) + envoy (DP). Later we see the Alibaba open source mosn, in a nutshell: Golang version of envoy.
+
+
+
+Reviewing the previous architecture evolution diagram, I believe many students have found out where the problem is. From top to bottom, from left to right, for different scenarios, we finally "reasonably" introduced various components to solve our problems, the architect's rule of survival: choose the most suitable at the moment.
+
+When we have few tools at hand, we always have to compromise between functionality, dynamics, performance, etc. We have long been accustomed to and even numb to the rapid development of IT technology, are they still the most appropriate solution today?
+
+
+
+As you can see, these are NGINX drawbacks, such as NGINX's low activity community. While we could invest more resources at the corporate level, his community is really unfriendly, and how unfriendly is it? As you can see in the picture above, the NGINX repository in Github is only a mirror, the issue function is closed, it is impossible to submit an issue, and even if you submit a PR the official will not merge it.
+
+In addition, NGINX is weak in its own routing, for example, I want to do grayscale based on a request parameter such as id, you will find that NGINX is completely unable to achieve. So we can see a lot of small open source systems, as long as the above grayscale scenario is solved, it can be an independent open source project. In addition, gRPC calls are becoming more and more popular in microservice calls, but NGINX support for it is only "simple to use".
+
+Finally, the NGINX cluster management, almost every Internet vendor has its own NGINX configuration management system, although the system is similar but there is no unified solution, more than a decade has been blank.
+
+The system is similar but there is no unified solution, which has been blank for more than ten years. 
+
+Before talking further about Kong, I would like to talk to you about what is cloud-native. This term has been around for a long time, but there is no unified and clear definition until now. I synthesize several cloud vendors' definitions and outline two main cloud-native features: first, it should support containers, and second, it should support elastic and scalable deployment. I think Kong does not fully meet the second, the official main PostgreSQL relational database is a single poin [...]
+
+The architecture is hard to choose.
+
+
+
+Finally, a brief summary of the problems with NGINX and Kong.
+
+- NGINX and Kong both have their own different application scenarios.
+
+- NGINX lacks an official cluster management solution.
+
+- Kong's control plane is not completely cloud-native architecture.
+
+Before introducing APISIX, it is necessary to thank the two predecessors for thinking on the shoulders of giants, which really gives us a higher starting point from the beginning.
+
+
+
+The left and right of this diagram are DP (Data Plane) and CP (Control Plane), which are the same as the familiar backend service system. APISIX did not try to build something new by itself from the first day of the architecture, so we chose the most mature etcd for the configuration center.
+
+In this architecture, you can't find a single point. Any abnormal downtime of any of the services here will not affect APISIX's ability to provide services to the public. When every point in the overall architecture supports high availability, the high stability of the user's production system is very easy to achieve.
+
+
+
+This is a diagram of the APISIX eco, from which you can see exactly what peripheral ecologies are currently supported. On the left side are the supported protocols, you can see the common Layer 7 protocols such as HTTP(S), HTTP2, Dubbo, QUIC and IoT protocol MQTT, and the Layer 4 protocols such as TCP/UDP. On the right are some open source or SaaS services such as SkyWalking, Prometheus, Vault, etc. Below are some of the more common OS environments, cloud vendors and hardware environment [...]
+
+
+
+To give you a brief report on the current state of APISIX, APISIX has become the most active open source API gateway project in the world in the two years since it became open source, and this state has been going on for more than a year. Remember the bottom sentence, APISIX has been **production available, with better features, performance, and architecture across the board than Kong**. In September 2019 Shell has already used the APISIX project in production environments.
+
+
+
+To briefly explain this graph, you can call it a contributor growth curve. The horizontal coordinate is the timeline and the vertical coordinate is the total number of contributors. We can see that APISIX and Kong are two relatively more active projects. APISIX has been growing at a very good rate since the first day of open source, and is growing at nearly twice the rate of Kong, which shows how popular APISIX is. Of course there are many other ways to evaluate the activity of a project [...]
+
+APISIX is still number one in these ways
+
+After our actual customer visits, the feature of supporting multiple languages is very necessary. After all, for many companies, they have their own familiar technology stacks, and many companies are blank for NGINX C and Lua. APISIX has officially announced multilingual support a few days ago, and currently supports Java, and will gradually support Golang, Rust, NodeJS and other languages.
+
+APISIX's full dynamic and high performance is actually inseparable from the high quality of the surrounding ecology. Other peripheral libraries such as jsonschema, ipmatcher, etc. are several orders of magnitude better than similar open source projects.
+
+
+
+APISIX support for multi-language features have been put into the open source project, interested students are welcome to follow and participate at any time. The advantage of this implementation is that it is simple and universal, and everyone can natively use their familiar language.
+
+
+
+After all this talk, what are the advantages of APISIX for you? See the image above.
+
+The first three (foundation project, security, stability) I think are the most important. As a foundation project, it no longer belongs to a person or a company, but is the property of all mankind, and we can use it forever. The security and stability of APISIX is due to its cornerstone, NGINX, which has become the most popular and widely used web server, and its heritage is still very impressive.
+
+High performance, dynamics, and an active community are the trump cards of APISIX, and they have formed a healthy interaction.
+
+If one sentence sums up the pride of APISIX, I think it is:**APISIX, the most active API gateway project in the world**. With this consensus, we tilt more resources to the community, and we believe the community will make APISIX grow soundly and healthily.
+
+
+
+The APISIX goal: **Unified Proxy Infrastructure**.
+
+You may be wondering if APISIX is going to support so many scenarios. Here I will explain briefly that the core of APISIX is a high-performance proxy service that does not bind any environment properties itself. When it evolves into Ingress, Service Grid, etc., it is the external service that works with APISIX, and it is the external program that changes rather than APISIX itself, and we will explain how APISIX supports these scenarios step by step.
+
+
+
+For traditional LB and API Gateway scenarios, APISIX has the advantage of going from static to all dynamic, no more reloads, as many tech companies start with a half hour NGINX reload. The aforementioned grayscale scenario of moduloing based on request id can be easily done in APISIX using fine-grained routing.
+
+
+
+
+
+APISIX Ingress Controller solves all the problems mentioned above, and inherits all the advantages of APISIX, in addition to supporting native k8s CRD for easy migration.
+
+
+
+Service mesh, it is necessary to talk to you about it. In the next five or ten years, what is the most likely mainstream server-side architecture? If I were to answer, I would choose the service mesh.
+
+
+
+The diagram on the right shows the internal architecture of APISIX Mesh.
+
+
+
+After talking so much about the present of APISIX, let's also talk about the future of APISIX.
+
+Because APISIX is currently an Apache Foundation project, it is no longer the property of individuals or companies, but of all humanity. This gives every one of you in the community the right to decide which direction it will go.
+
+The default configuration center for the open source version of APISIX is etcd, and while it is still the best choice, we still often hear about support for other configuration centers when we talk to users, more often than not because etcd is so new that it is not on the list of supported products in the company's existing operations and maintenance products. So we plan to make APISIX work with other configuration centers.
+
+
+
+APISIX is already on the road to full traffic data plane, and I believe we all ask questions such as: Why do we need to unify traffic forwarding? Does unification bring value to the enterprise? What are the benefits to the technical staff? With these questions in mind, let's look at the following diagram.
+
+
+
+Unification itself is not the goal, but the benefits after unification is the logic behind our pursuit, and several different perspectives are given below to elaborate separately.
+
+- Operation and maintenance role: use the same operation and maintenance tools to collect logs, metrics, etc., and reuse existing accumulations.
+
+- Development role: based on standardized APISIX plug-in development, the capabilities can be easily reused, and the accumulated experience can be applied to different product lines such as LB, API Gateway, K8s Ingress, etc.
+
+- Company value: Unify technology stack, reduce company operation cost, reduce the difficulty of transitioning to microservices and cloud-native, and accelerate enterprise digital transformation.
+
+
+
+Last but not least is the APISIX [Slack channel](https://apisix.apache.org/docs/general/community#slack), any questions can be left here or on [Github issue](https://github.com/apache/apisix/issues), there will be someone to respond quickly, thanks again.
+
+Click to watch the [video](https://www.bilibili.com/video/BV1w54y1V73Z?p=1&share_medium=android&share_plat=android&share_source=COPY&share_tag=s_i×tamp=1621812452&unique_k=PEusrt)
diff --git a/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/18/first-ga-version-v1.0-of-apache-apisix-ingress-controller-released.md b/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/18/first-ga-version-v1.0-of-apache-apisix-ingress-controller-released.md
new file mode 100644
index 0000000..d8f674b
--- /dev/null
+++ b/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/18/first-ga-version-v1.0-of-apache-apisix-ingress-controller-released.md
@@ -0,0 +1,104 @@
+---
+title: "Apache APISIX Ingress Controller 首个 GA 版本 v1.0 正式发布！"
+author: "张晋涛"
+authorURL: "https://github.com/tao12345666333"
+authorImageURL: "https://avatars.githubusercontent.com/u/3264292?v=4"
+keywords:
+- APISIX
+- Apache APISIX
+- Ingress Controller
+description: Apache APISIX Ingress Controller v1.0 正式发布，可支持使用包括 ApisixRoute 和 ApisixUpstream 等自定义资源，以及 Kubernetes 原生 Ingress 资源等控制外部流量访问部署在 Kubernetes 中的服务。
+tags: [Release]
+---
+
+> Apache APISIX Ingress Controller v1.0 正式发布，可支持使用包括 `ApisixRoute`、`ApisixUpstream` 等自定义资源，以及 Kubernetes 原生 Ingress 资源等控制外部流量访问部署在 Kubernetes 中的服务。
+
+<!--truncate-->
+
+## 关于 Apache APISIX Ingress Controller
+
+Apache APISIX Ingress Controller 是一个使用 Apache APISIX 作为数据面承载流量的云原生 Ingress Controller 实现，采用 CRD 的方式对 Kubernetes 进行了扩展。
+
+<!--truncate-->
+
+可支持使用包括 ApisixRoute、ApisixUpstream 等自定义资源，以及 Kubernetes 原生 Ingress 资源等控制外部流量访问部署在 Kubernetes 中的服务。
+
+整体架构如下：
+
+
+
+## v1.0 最新特性
+
+### 增加 ApisixConsumer 自定义资源使配置认证更方便
+
+在之前的版本中，如果想要配置 keyAuth 或者 basicAuth 需要手动去调用 Apache APISIX 的 admin api 创建 consumer 配置。
+
+在 v1.0 版本中，我们增加了 `ApisixConsumer` 资源，用户可以使用更原生的方式来定义 consumer 资源及为 ApisixRoute 配置认证。
+
+例如通过以下配置定义一个 keyAuth 资源：
+
+```yaml
+apiVersion: apisix.apache.org/v2alpha1
+kind: ApisixConsumer
+metadata:
+ name: keyauth
+spec:
+ authParameter:
+ keyAuth:
+ value:
+ key: API
+```
+
+在 ApisixRoute 中只需要增加对应类型的 `authentication` 配置即可。
+
+```yaml
+apiVersion: apisix.apache.org/v2alpha1
+kind: ApisixRoute
+metadata:
+ name: httpbin-route
+spec:
+ http:
+ ...
+ authentication:
+ enable: true
+ type: keyAuth
+```
+
+### 为 ApisixTls 增加 mTLS 支持
+
+在 v1.0 版本中我们也为 ApisixTls 自定义资源增加了 mTLS 的支持，只需要在 ApisixTls 资源的配置中增加 client 配置即可，例如：
+
+```yaml
+apiVersion: apisix.apache.org/v1
+kind: ApisixTls
+metadata:
+ name: sample-tls
+spec:
+ ...
+ client:
+ caSecret:
+ name: client-ca-secret
+ namespace: default
+```
+
+### 为原生 Ingress 资源增加了更多 annotation 来丰富其功能
+
+- `k8s.apisix.apache.org/blocklist-source-range` 可对来源 IP 进行限制；
+- `k8s.apisix.apache.org/rewrite-target` 和 `k8s.apisix.apache.org/rewrite-target-regex` 可进行 target 的 rewrite 操作；
+- `k8s.apisix.apache.org/http-to-https` 可进行 HTTP 到 HTTPS 的强制重定向；
+
+更多特性变更请参考项目 [CHANGELOG](https://github.com/apache/apisix-ingress-controller/blob/master/CHANGELOG.md) 。
+
+## 为什么使用 APISIX Ingress Controller
+
+Apache APISIX Ingress Controller 使用 Apache APISIX 作为其数据面承载业务流量，所以其从 Apache APISIX 继承了如下优势：
+
+- **高性能 & 稳定性**：Apache APISIX 是一款云原生高性能动态 API 网关，已在众多企业大规模流量场景下使用，其性能及稳定性久经考验。
+- **生态丰富**：Apache APISIX 是当前最活跃的开源网关项目，作为 Apache 顶级项目，无论是社区活跃度还是其插件生态都非常丰富，可满足用户的多种使用场景和需求；
+
+此外，由于 APISIX Ingress Controller 还具备如下独有的优势：
+
+- **兼容性好**：支持多个 Ingress 资源版本，在不同的 Kubernetes 版本中均可正常工作；
+- **动态更新**：无论是 Ingress 资源或是证书等配置的更新，均已实现热加载，无需 reload，保障业务平稳运行；
+- **扩容灵活**：由于 APISIX Ingress Controller 采用控制面和数据面分离的架构，所以在扩容时，可以单独扩容 Apache APISIX 这个数据面集群，而无须对 Apache APISIX Ingress Controller 进行扩容；
+- **运维友好**：在当前架构下，用户可按实际情况选择将数据面 Apache APISIX 集群部署在 Kubernetes 集群中，或是部署在物理机环境。且 Apache APISIX Ingress Controller 故障不会对业务流量造成任何影响。
diff --git a/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/21/use-java-to-write-apache-apisix-plugins.md b/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/21/use-java-to-write-apache-apisix-plugins.md
new file mode 100644
index 0000000..6f803f8
--- /dev/null
+++ b/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/21/use-java-to-write-apache-apisix-plugins.md
@@ -0,0 +1,241 @@
+---
+title: "使用 Java 编写 Apache APISIX 插件"
+author: "屠正松"
+authorURL: "https://github.com/tzssangglass"
+authorImageURL: "https://avatars.githubusercontent.com/u/30819887?v=4"
+keywords:
+- APISIX
+- Apache APISIX
+- Java
+- 插件
+description: Apache APISIX 支持多语言编写插件了！不会 Lua 也没关系，现在可以用你熟悉的语言编写插件，文末还有视频教程。
+tags: [Practical Case]
+---
+
+> Apache APISIX 支持多语言编写插件了！不会 Lua 也没关系，现在可以用你熟悉的语言编写插件，文末还有视频教程。
+
+<!--truncate-->
+Apache APISIX 支持多语言编写插件了！不会 Lua 也没关系，现在可以用你熟悉的语言编写插件，文末还有**视频教程**。
+
+## 1. 简介
+
+### 1.1 为什么 Apache APISIX 要支持多语言编写插件
+
+在支持多语言编程插件前，Apache APISIX 只支持使用 Lua 语言编写插件，需要开发者掌握 Lua 和 OpenResty 相关的开发能力。然而相对于主流开发语言 Java、Go 来说，Lua 和 OpenResty 属于相对小众的技术，开发者很少。如果从头开始学习 Lua 和 OpenResty，需要付出相当多的时间和精力。
+
+开发团队在进行技术选型的时候，最重要的考量就是所选技术是否与本团队技术栈相匹配，然而小众的技术栈就限制了 Apache APISIX 在更广阔的场景下进行技术落地。
+
+现在 Apache APISIX 支持多语言开发插件，**更重要的是支持语言所在的开发生态圈，使用者可以使用自己熟悉的技术栈来开发 Apache APISIX**。以支持 Java 为例，使用者不仅可以使用 Java 语言编写插件，还可以融入 Spring Cloud 生态圈，广泛使用生态圈内的各种技术组件。
+
+### 1.2 Apache APISIX 多语言支持架构图
+
+
+
+上图左边是 Apache APISIX 的工作流程，右边的 plugin runner 是指插件运行器，泛指多语言支持的项目。本文档下面提到的 apisix-java-plugin-runner 项目就是支持 Java 语言的 plugin runner。
+
+当你在 Apache APISIX 中配置一个 plugin runner 时，Apache APISIX 会启动一个子进程运行 plugin runner，该子进程与 Apache APISIX 进程属于同一个用户。当我们重启或重新加载 Apache APISIX 时，plugin runner 也将被重启。
+
+如果你为一个给定的路由配置了 ext-plugin-* 插件，命中该路由的请求将触发 Apache APISIX，通过 unix socket 向 plugin runner 执行 RPC 调用。调用细分为两个阶段：
+
+- ext-plugin-pre-req: 在执行 Apache APISIX 内置插件(Lua 语言插件)之前
+- ext-plugin-post-req: 在执行 Apache APISIX 内置插件(Lua 语言插件)之后
+
+根据需要配置 plugin runner 的执行时机。
+
+plugin runner 会处理 RPC 调用，在其内部创建一个模拟请求，然后运行多语言编写的插件，并将结果返回给 Apache APISIX。
+
+多语言插件的执行顺序是在 ext-plugin-* 插件配置项中定义的。像其他插件一样，它们可以被启用并在运行中重新定义。
+
+## 2. 搭建开发环境
+
+首先需要搭建 Apache APISIX 的运行环境或者开发环境，参考 [构建 Apache APISIX](https://github.com/apache/apisix/blob/master/docs/zh/latest/how-to-build.md)，以及 Java 项目的开发环境，参考 [构建 apisix-java-plugin-runner](https://github.com/apache/apisix-java-plugin-runner/blob/main/docs/development.md)。
+
+**注意**：Apache APISIX 和 apisix-java-plugin-runner 需要位于同一实例上。
+
+## 3. 进入调试模式
+
+### 3.1 设置 Apache APISIX 进入调试模式
+
+这里是指让 Apache APISIX 以调试的方式运行外部插件，在 `config.yaml` 中增加以下配置
+
+```text
+ext-plugin:
+ path_for_test: /tmp/runner.sock
+```
+
+这个配置的意思是，Apache APISIX 相当于 client 端，会监听位于 `/tmp/runner.sock` 位置上的 Unxi Domain Socket 链接。
+
+### 3.2 设置 apisix-java-plugin-runner 进入调试模式
+
+在启动 `Main class(org.apache.apisix.plugin.runner.PluginRunnerApplication)`之前，需要配置用户级的环境变量 `APISIX_LISTEN_ADDRESS=unix:/tmp/runner.sock` 和 `APISIX_CONF_EXPIRE_TIME=3600`。
+
+如果你是使用 IDEA 进行开发，那么配置好的环境变量示意如下：
+
+
+
+apisix-java-plugin-runner 相当于 server 端，在启动时会主动创建 `/tmp/runner.sock` 文件，并在这个文件上与 Apache APISIX 进行 Unix Domain Socket 通信。
+
+## 4. 开发
+
+### 4.1 场景
+
+我们以一个场景来代入开发过程：需要验证请求 header 中 token 的有效性，验证 token 的方式是用请求中携带 token 作为参数，访问 SSO 固定的接口，如果 token 验证通过则放行请求，验证失败则阻止请求。
+
+### 4.2 配置 Apache APISIX
+
+先给插件命名为 `TokenValidator`，然后设计属性，为了尽可能做到动态配置，属性设计如下
+
+```json
+{
+ "validate_header": "token",
+ "validate_url": "https://www.sso.foo.com/token/validate",
+ "rejected_code": "403"
+}
+```
+
+启动 Apache APISIX，然后新增一条路由配置，指定该路由需要调用 apisix-java-plugin-runner 的 `TokenValidator` 插件，示例如下
+
+```shell
+curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
+{
+ "uri":"/get",
+ "plugins":{
+ "ext-plugin-pre-req":{
+ "conf":[
+ {
+ "name":"TokenValidator",
+ "value":"{\"validate_header\":\"token\",\"validate_url\":\"https://www.sso.foo.com/token/validate\",\"rejected_code\":\"403\"}"
+ }
+ ]
+ }
+ },
+ "upstream":{
+ "nodes":{
+ "httpbin.org:80":1
+ },
+ "type":"roundrobin"
+ }
+}
+```
+
+需要注意的是，`TokenValidator` 的属性需要经过 json 转义，作为 string 类型进行配置。
+
+（这里上游地址配置为 httpbin.org，方便调试）
+
+### 4.3 开发 Java 插件
+
+在 runner-plugin/src/main/java/org/apache/apisix/plugin/runner/filter 目录下，新增 `TokenValidatr.java`，代码初始骨架如下
+
+```Java
+package org.apache.apisix.plugin.runner.filter;
+
+import org.apache.apisix.plugin.runner.HttpRequest;
+import org.apache.apisix.plugin.runner.HttpResponse;
+import org.springframework.stereotype.Component;
+import reactor.core.publisher.Mono;
+
+
+@Component
+public class TokenValidator implements PluginFilter {
+
+ @Override
+ public String name() {
+ return "TokenValidator";
+ }
+
+ @Override
+ public Mono<Void> filter(HttpRequest request, HttpResponse response, PluginFilterChain chain) {
+ return chain.filter(request, response);
+ }
+}
+```
+
+需要继承 `PluginFilter`接口，重写 `name` 和 `filter`函数。
+
+重写 `name` 的返回值，和前面配置 APISIX 的路由属性中 "name" 保持一致。
+
+完整代码如下：
+
+```Java
+package org.apache.apisix.plugin.runner.filter;
+
+import com.google.gson.Gson;
+import org.apache.apisix.plugin.runner.HttpRequest;
+import org.apache.apisix.plugin.runner.HttpResponse;
+import org.springframework.stereotype.Component;
+import reactor.core.publisher.Mono;
+
+import java.util.HashMap;
+import java.util.Map;
+
+@Component
+public class TokenValidator implements PluginFilter {
+
+ @Override
+ public String name() {
+ return "TokenValidator";
+ }
+
+ @Override
+ public Mono<Void> filter(HttpRequest request, HttpResponse response, PluginFilterChain chain) {
+ // parse `conf` to json
+ String configStr = request.getConfig(this);
+ Gson gson = new Gson();
+ Map<String, Object> conf = new HashMap<>();
+ conf = gson.fromJson(configStr, conf.getClass());
+
+ // get configuration parameters
+ String token = request.getHeader((String) conf.get("validate_header"));
+ String validate_url = (String) conf.get("validate_url");
+ boolean flag = validate(token, validate_url);
+
+ // token verification results
+ if (!flag) {
+ String rejected_code = (String) conf.get("rejected_code");
+ response.setStatusCode(Integer.parseInt(rejected_code));
+ return chain.filter(request, response);
+ }
+
+ return chain.filter(request, response);
+ }
+
+ private Boolean validate(String token, String validate_url) {
+ //TODO: improve the validation process
+ return true;
+ }
+}
+```
+
+### 4.4 测试
+
+在 Apache APISIX 上配置的上游服务是 httpbin.org，可以访问 Apache APISIX，触发路由，让 Apache APISIX 调用 apisix-java-plugin-runner 去执行 TokenValidator 插件，测试一下 Java 插件效果。
+
+```shell
+curl -H 'token: 123456' 127.0.0.1:9080/get
+{
+ "args": {},
+ "headers": {
+ "Accept": "/",
+ "Host": "127.0.0.1",
+ "Token": "123456",
+ "User-Agent": "curl/7.71.1",
+ "X-Amzn-Trace-Id": "Root=1-60cb0424-02b5bf804cfeab5252392f96",
+ "X-Forwarded-Host": "127.0.0.1"
+ },
+ "origin": "127.0.0.1",
+ "url": "http://127.0.0.1/get"
+}
+```
+
+## 5. 部署
+
+插件开发完成后，部署操作可以参考 [部署 apisix-java-plugin-runner](https://github.com/apache/apisix-java-plugin-runner/blob/main/docs/how-it-works.md#run)。
+
+## 6. 视频教程
+
+<iframe
+ height="350"
+ width="600"
+ src="https://api7-website-1301662268.file.myqcloud.com/2021-06-21-use-Java-to-write-Apache-APISIX-plugins.mp4"
+ frameborder="0">
+</iframe>
diff --git a/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/28/why-we-need-apache-apisix.md b/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/28/why-we-need-apache-apisix.md
new file mode 100644
index 0000000..b397eff
--- /dev/null
+++ b/website/i18n/zh/docusaurus-plugin-content-blog/2021/06/28/why-we-need-apache-apisix.md
@@ -0,0 +1,176 @@
+---
+title: "有了 NGINX 和 Kong，为什么还需要 Apache APISIX"
+author: "王院生"
+authorURL: "https://github.com/membphis"
+authorImageURL: "https://avatars.githubusercontent.com/u/6814606?v=4"
+keywords:
+- APISIX
+- Kong
+- Nginx
+- API 网关
+- 开源
+description: 本文介绍了 Apache APISIX 架构演进历史，对比 Nginx 和 Kong 这两个框架 Apache APISIX 的优势是什么。
+tags: [Technology]
+---
+
+> 本文介绍了 Apache APISIX 架构演进历史，对比 Nginx 和 Kong 这两个框架 Apache APISIX 的优势是什么。
+
+<!--truncate-->
+
+> Source: https://www.apiseven.com/zh/blog/why-we-need-Apache-APISIX
+
+大家好，非常开心给大家分享一个让我激动的主题《有了 NGINX 和 Kong，为什么还需要 Apache APISIX》。
+
+
+
+之所以我们要做 NGINX 和 Kong 的替代项目，实际和我们后端架构演变史大背景息息相关，我会先和大家一起分享后端架构演变过程，这非常重要。
+
+
+
+首先做下自我介绍，本人叫王院生。和这次大会主办者净超一样我们都做社区很久，我在 2015 年写了一本电子书叫《OpenResty 最佳实践》，通过这本书结成了一个超万人社区。从那个时候开始个人对开源本身越发感兴趣，2015 年以前我基本上主要是开源软件的使用者，然后慢慢变成社区的一个协办者，再往后变成社区领导者，也许你会问为什么？很简单，因为这本书是你写的，别人遇到各种各样的问题，有高级的也有比较普通的，问得多了我就逐步成为老师并最终成了社区领导者，像那句名言“走的人多了，也变成了路”。
+
+
+
+2019 年我与合伙人温铭一起创办了深圳支流科技公司，它是一家以开源为依托的商业化公司。这家公司承载了我俩很多个人理想，也可以说是在做每一位普通程序员的理想，不想庸庸碌碌 996，我经常对别人说我的梦想就是“把我的名字刻入史册”，悲催的是人类已经不需要史册了。
+
+
+
+这是我们团队，大家主要是远程协作，所有人聚在一起比较难。公司早期阶段只有五六个人时，还能比较容易的把团队聚起来，但从今年之后就一直没聚齐过，这是我们今年到目前以来最齐的一次（但依然有几位同学没能一起）。
+
+作为一家技术说了算的商业公司，技术在我司有非常大的话语权，尊重技术从尊重技术人才开始。没有 996 ，没有上班打卡，远程办公，欢迎感兴趣的同学联系我们，期待有梦想、有理想的你加入我司。
+
+
+
+这次演讲主题需要一些背景，我们先说说后端架构演变史。先跟大家回顾一下这张图，右图部分从上到下它不是具体数据流程图，它是我们后端架构演变史。从最传统的单体大应用，然后变成面向服务架构(SOA)，然后是微服务，分别出现了 Spring Cloud 和 Kubernetes。Spring Cloud 架构主要服务 JAVA 语言开发者，Kubernetes 是容器编排支持任何语言，以及最近社区比较热的话题服务网格。
+
+我经常跟公司同事说，咱们展望未来五年，甚至是十年之后，哪个架构是最终极方案？从目前信息看，服务网格会大概率胜出。即使当下它还有很多问题，但我相信这些问题都能被解决。
+
+
+
+在创业之初，在脑子里过这张图的时候特别有意思。我们能够看到，随着我们后端架构的逐步迭代，我们引入了各种不同组件。比如到了 SOA 也就是面向服务的架构，引入反向代理组件，选型通常是 NGINX，HAProxy。迭代到微服务架构后，通常会选择一些更现代的 API 网关产品，比如 Kong、Traefik ，当然也有一些用户因为惯性习惯，还会继续选择使用 NGINX，虽然它有能力弱、使用不方便等缺点，但胜在稳定、可靠。说句题外话，从全球市场占有率看，NGINX 成为占有率最高的 Web Server 是在 2019 年 4 月份，感兴趣的同学可以到看下最新的 netcraft 报告 April 2021 Web Server Survey。
+
+随着后端架构持续迭代，进入到了 Kubernetes 时代后，流量出入口 Ingress 大家默认会使用官方的 Kubernetes Ingress，这个项目是基于 NGINX 本地配置文件。在国内也有一些公司在使用 Traefik 作为 Ingress，这与国内 Golang 开发者基数比较大有很大关系。
+
+我们再看看左侧比较有意思的 JAVA ，Spring Cloud 内置 API 网关先后经历了 ZUUL、ZUUL2，但还是不好用，性能、架构官方都不满意，所以 Spring Cloud 官方发起了新项目 Spring Cloud Gateway，最终形成全家桶解决方案。
+
+最后说说右下角部分的服务网格，对于服务网格已经形成一种选择就是 istio(CP) + envoy(DP)。后面我们又看到了阿里巴巴开源的 mosn，一句话概括：Golang 版本的 envoy。
+
+
+
+回顾前面的架构演变图，相信很多同学都已经发现问题在哪里。从上到下，从左到右，针对不同场景，我们最终“合理”的引入了各种组件来分别解决我们的问题，架构师生存法则：选择当下最适合的。
+
+当我们趁手工具不多，在功能、动态、性能等之间我们总是要妥协放弃一些，大家早已习惯甚至麻木。IT 技术发展迅速，时至今日它们是否还是最合适方案？5G、物联网等发展迅速，如何弹性扩缩容、动态统一管理等新问题，逼着我们重新思考。
+
+
+
+如图这些都是 NGINX 缺点，比如 NGINX 的低活跃度社区。虽然我们可以在公司层面投入更多资源，但他的社区是真不友好，不友好到什么程度呢？上面这张图可以看得到，NGINX 在 Github 的仓库只是镜像，issue 功能是关闭的，想提交 issue 不可能了，即使你提交 PR 官方也是不会合并的。
+
+除此之外 NGINX 自身路由比较弱，比如说我要根据某个请求参数比如 id 取模运算做灰度，你会发现 NGINX 完全无法实现。所以我们能看到很多小的开源系统，只要解决了上面的灰度场景，就可以是个独立开源项目。此外 gRPC 调用在微服务调用中越来越流行，但 NGINX 对它的支持只能是“简单能用”。
+
+最后就是 NGINX 集群统一管理，几乎每家互联网厂商都有自己的 NGINX 配置管理系统，系统虽然大同小异但就是没有统一方案，十几年了一直空白。
+
+
+
+在进一步聊 Kong 之前，想和大家聊一下什么是云原生。这个名词从诞生到现在很久，但到现在没有统一明确的定义。我综合几家云厂商定义，概括云原生特征主要有两点：第一要支持容器，第二要支持弹性伸缩部署。我认为 Kong 不完全满足第二条，官方主推的 PostgreSQL 关系型数据库是单点，无法支持弹性扩缩容，是它架构选型硬伤。
+
+
+
+最后简单总结一下 NGINX 和 Kong 的问题：
+
+- NGINX 和 Kong 都有各自不同应用场景；
+
+- NGINX 缺少官方集群统一管理方案；
+
+- Kong 的控制面不是完全云原生架构。
+
+在介绍 APISIX 之前，还是有必要先感谢两位前辈，站在巨人肩膀思考，确实让我们从一开始就有更高起点。APISIX 已经两岁多，请看架构图：
+
+
+
+这张图的左右分别是 DP（Data Plane）和 CP（Control Plane），跟大家所熟悉的后端服务体系一样。APISIX 从架构第一天就没有想去自己造新东西，所以关于配置中心选择了当下最成熟的 etcd。
+
+在这个架构里面，你找不到一个单点。这里的任何一个服务出现异常宕机等事故，都不会影响 APISIX 正常对外提供服务的能力。当整体架构中的每一个点都支持高可用时，用户生产系统的高稳定性就非常容易实现。
+
+
+
+这是 APISIX 的生态图，从该图可以准确看到目前都支持了哪些周边生态。左侧是支持的协议，可以看到常见的 7 层协议有 HTTP(S)、HTTP2、Dubbo、QUIC 和物联网协议 MQTT 等，4 层协议有 TCP/UDP 。右侧部分则是一些开源或者 SaaS 服务，比如 SkyWalking、Prometheus 、Vault 等。下面就是一些比较常见的操作系统环境、云厂商和硬件环境，作为一家全球化公司，我们也支持 ARM64 等更丰富的平台。
+
+
+
+给大家简单地汇报一下 APISIX 当前状态，APISIX 从开源到现在两年的时间，APISIX 已经成为了全世界最活跃的开源 API 网关项目，而且这个状态已经持续了一年多。请记住最下面一句话，APISIX 已经**生产可用，功能、性能、架构全面优于 Kong**。在 2019 年 9 月份贝壳找房就已经把 APISIX 项目用到生产环境。
+
+
+
+简单解释一下这张图，可以叫它贡献者增长曲线。横坐标是时间线，纵坐标是贡献者总数。能够看到 APISIX 和 Kong 这两个项目相对更活跃，APISIX 的增长速度从开源第一天就保持着非常不错的增长率，在接近 Kong 两倍的速度成长，可见 APISIX 受欢迎程度。当然评价一个项目活跃度还有很多其他方法，比如查看每月活跃 issue、PR 总数等方式，很开心的和大家说，这些方式看 APISIX 的活跃度依然第一。
+
+
+
+经过我们实际的客户走访，支持多语言这个特性是非常有必要的。毕竟对于很多公司而言，都有自己熟悉的技术栈，很多公司对 NGINX C 和 Lua 这两个技术栈是空白。前些日子 APISIX 已经正式宣布支持多语言，目前已经支持了 Java 语言，后续也将逐步支持 Golang 、Rust、NodeJS 等语言。
+
+APISIX 的全动态、高性能，其实和高质量的周边生态是分不开的。APISIX 的路由使用我司主导并开源的项目叫 resty-radixtree ，简单来说它使用 radixtree 方式完成路由匹配，匹配效率相比竞品提升了一到两个数量级。其他还有 jsonschema、ipmatcher 等周边库，它们都比同类开源项目性能强几个数量级。
+
+
+
+APISIX 支持多语言的特性，已经放到开源项目，欢迎感兴趣的同学可以随时关注并参与。这个实现方案的优势是简单、通用，大家可以原生的使用自己熟悉语言。
+
+
+
+聊了这么多，给大家介绍下 APISIX 有哪些优势？请看上图。
+
+前面三个（基金会项目、安全、稳定）我觉得是最重要的，作为基金会项目，它已经不属于某个人或某家公司，而是全人类的财产，我们可以永远使用它。与之相对应的是商业公司开源项目，它可以随时修改开源项目 License，大家最近都听过类似的消息。APISIX 的安全和稳定得益于它的基石 NGINX，能够成为目前最流行、使用量最广的 web server，底蕴还是很厉害的。
+
+高性能、动态、社区活跃是 APISIX 的王牌，它们已经形成了良性互动。
+
+如果一句话概括 APISIX 的自豪，我认为是：**APISIX，全世界最活跃的 API 网关项目**。在此共识下，我们把更多资源倾斜给社区，我们相信社区会让 APISIX 稳健健康成长。
+
+
+
+看到这张图台下的你估计一下子就明白了 APISIX 要干什么。APISIX 目标：**统一代理基础设施**。
+
+也许台下的你这里会有疑问：APISIX 要支持这么多场景，是否会让 APISIX 变得四不像？这里我简单解释一下，APISIX 的核心是高性能代理服务，自身不绑定任何环境属性。当它演变为 Ingress、服务网格等产品，都是外部服务与 APISIX 配合，变化的是外部程序而不是 APISIX 自身，后面逐步为大家说明 APISIX 是如何具体支持这些场景。
+
+
+
+针对传统的 LB 和 API Gateway 场景，APISIX 比较大的优势就是从静态变成全部动态，再也不需要 reload，要知道很多科技公司的 NGINX reload 是半小时起步。前面提到的根据请求 id 取模运算灰度场景，在 APISIX 里使用精细化路由可以很容易完成。
+
+
+
+
+
+APISIX Ingress Controller 则完整解决了上面提到的所有问题，继承了 APISIX 的所有优势，此外还支持原生 k8s CRD ，方便用户迁移。
+
+
+
+服务网格，这里面有必要跟大家重点聊聊。未来五年或者十年之后，最有可能主流的服务端架构是什么？如果让我回答，我选择服务网格。
+
+
+
+右图部分就是 APISIX Mesh 的内部架构图。
+
+
+
+聊了这么多 APISIX 的当下，也和大家聊聊 APISIX 的未来。
+
+因为 APISIX 目前是 Apache 基金会项目，所以它已经不再属于个人或公司，而是全人类共享财产。这样社区中的每一个你，都有权利决定他往哪个方向发展。
+
+开源版本 APISIX 目前默认搭配的配置中心是 etcd ，虽然目前它依旧是最好的选择，但我们在和用户沟通时依然经常会听到是否支持其他配置中心，比较常见的原因是 etcd 这个产品太新了，公司现有运维产品支持列表中没有它。所以我们计划让 APISIX 可以与其他配置中心协作。
+
+
+
+APISIX 已经走在全流量数据面这条路上，相信大家都会问一些问题，比如：为什么要统一流量转发？统一是否给企业带来价值？对技术人员有什么收益？带着这些问题，我们看下图：
+
+
+
+统一本身不是目标，统一之后的收益才是我们追求的背后逻辑，下面分别给出几个不同角度来分别阐述。
+
+- 运维角色：使用相同的运维工具收集日志、Metric 指标等，复用已有积累；
+
+- 开发角色：基于标准化的 APISIX 插件开发，能力可以方便复用，并且积累的经验可以应用到 LB、API Gateway、K8s Ingress 等不同产品线；
+
+- 公司价值：统一技术栈，降低公司运营成本，降低过渡到微服务、云原生的难度，加速企业数字化转型。
+
+
+
+最后是 APISIX 的 QQ 群，有任何问题都可以在这里或者 [Github issue](https://github.com/apache/apisix/issues) 留言，会有专人快速响应，再次感谢大家。
+
+点击观看[视频](https://www.bilibili.com/video/BV1w54y1V73Z?p=1&share_medium=android&share_plat=android&share_source=COPY&share_tag=s_i×tamp=1621812452&unique_k=PEusrt)