This is an automated email from the ASF dual-hosted git repository.
juzhiyuan 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 9b4d667378c docs: update English grammar (#1169)
9b4d667378c is described below
commit 9b4d667378c1f8459353c41b2eb868434eac1ee3
Author: 琚致远 <[email protected]>
AuthorDate: Wed Jun 29 15:33:46 2022 +0800
docs: update English grammar (#1169)
---
.../blog/2021/06/28/why-we-need-Apache-APISIX.md | 105 +++++++++++----------
1 file changed, 53 insertions(+), 52 deletions(-)
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
index dab08f0985c..44593cdbbea 100644
--- a/website/blog/2021/06/28/why-we-need-Apache-APISIX.md
+++ b/website/blog/2021/06/28/why-we-need-Apache-APISIX.md
@@ -10,118 +10,119 @@ keywords:
- 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.
+- API Management
+description: This article describes the history of the open source API Gateway
Apache APISIX architecture's evolution and compares the advantages of the two
frameworks, Apache APISIX and Nginx.
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.
+> This article describes the history of the open source API Gateway Apache
APISIX architecture's evolution and compares the advantages of the two
frameworks, Apache APISIX and Nginx.
<!--truncate-->
-> Source: https://www.apiseven.com/zh/blog/why-we-need-Apache-APISIX
+> Source:
https://api7.ai/blog/why-do-you-need-apache-apisix-when-you-have-nginx-and-kong
-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".
+Hello everyone, I'm happy to share, "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.
+We are doing a replacement project for NGINX and Kong because of the
background of our backend architecture evolution. So 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 [...]
+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 then, I have become
increasingly interested in the open-source itself. Before 2015, I was mainly a
user of open-source software, then slowly became a community co-organizer, and
then later became a community leader.

-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 [...]
+I've been a teacher and, eventually, a community leader. In 2019, my partner
Ming Wen and I founded API7.ai Inc, an open source-based company. This company
carries a lot of unique ideas 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 tell others that my dream is to "engrave my name into the history
books," but the sad thing is that human beings no longer need history books.
-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.
+As a technology-driven company, technology has a big say there, and respect
for technology starts with respect for technical talents. So there is no 996,
no punching in and out, remote office, welcome 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.
+The topic of this talk needs some background, so let's start with the history
of backend architecture evolution. First, let's review this diagram, the right
part from top to bottom is not a specific data flow diagram. Instead, 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 and 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.
+I often ask 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 mesh will probably win. Even if it has many problems,
I believe we could solve them.

-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 [...]
+At the beginning of the venture, it was exciting to go through this diagram in
my head. We were able to see that as we gradually iterated on the backend
architecture, we introduced a variety of different components. For example,
when we got to SOA, a service-oriented architecture, we introduced reverse
proxy components, usually NGINX and HAProxy. When we iterated to microservice
architecture, we usually chose some more modern API gateway products, such as
Kong and Traefik. Of course, som [...]
-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.
+As the backend architecture continues to iterate and enters the Kubernetes
era, the traffic portal Ingress will use the official Kubernetes Ingress by
default, 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.
+Let's look at the left side of the more interesting JAVA. Spring Cloud's
built-in API gateway has experienced Zuul and Zuul2, which are still not good:
in performance and architecture, so Spring Cloud officially 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.
+Finally, the service mesh has formed a choice Istio (CP) and Envoy (DP) in the
bottom right part of the service mesh. Later we see the Alibaba open-source
MOSN, in a nutshell: the 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.
+Reviewing the previous architecture evolution diagram, I believe you 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?
+When we have few tools, we always compromise between functionality, dynamics,
performance, etc. Although 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.
+As you can see, these are NGINX drawbacks, such as NGINX's low activity
community:
-In addition, NGINX is weak in its own routing, for example, I want to do
canary release 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 canary release 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".
+- The NGINX repository in Github is only a mirror.
+- The GitHub Issue feature is disabled.
+- It is impossible to submit an issue.
+- The official team will not merge even if you submit a PR.
-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.
+In addition, NGINX is weak in its routing. For example, if I want to do a
canary release based on a request parameter such as id, you will find that
NGINX is entirely unable to achieve it. So we can see a lot of small
open-source projects. As long as the above canary release scenario is solved,
it can be an independent open source project. In addition, gRPC calls are
becoming increasingly popular in microservice calls, but NGINX support for it
is only "simple to use."
-The system is similar but there is no unified solution, which has been blank
for more than ten years.

+Finally, almost every Internet vendor has its own NGINX configuration system
team for the NGINX cluster management. Although the system is similar, there is
no unified solution. More than a decade has been blank.
-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 [...]
+[Kong](https://static.apiseven.com/202108/1646300936515-b20593d2-db75-49f1-869b-a0d5bc757eba.jpg)
+
+Before talking further about Kong, I would like to share with you what
cloud-native is. This word has existed for a long time, but there has been no
unified and clear definition until now. I synthesize several cloud vendors'
descriptions and outline two main cloud-native features: first, it should
support containers, and second, it should support flexible and scalable
deployment. I think Kong does not fully meet the second. For example, the
official central PostgreSQL relational database [...]
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.
+Finally, here is a summary of the problems with NGINX and Kong.
+- NGINX and Kong both have different application scenarios.
- NGINX lacks an official cluster management solution.
+- Kong's control plane is not entirely cloud-native architecture.
-- 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.
+Before introducing the open-source API Gateway Apache APISIX, we must thank
the two products above for thinking on the shoulders of giants, giving 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.
+The left and right of this diagram are DP (Data Plane) and CP (Control Plane),
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.
+In this architecture, you can't find a single point. Therefore, any abnormal
downtime of any of the services here will not affect APISIX's ability to
provide services to the public. Furthermore, when every point in the overall
architecture supports high availability, the high stability of the user's
production system is effortless.

-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 [...]
+The above picture is a diagram of the APISIX Ecosystem, from which you can see
what currently supports peripheral ecologies. On the left side are the
supported protocols. You can see the standard Layer 7 protocols such as
HTTP(S), HTTP2, Dubbo, QUIC, IoT protocol MQTT, and the Layer 4 protocols such
as TCP/UDP. On the right are some open source or SaaS services such as Apache
SkyWalking, Prometheus, HashiCorp Vault, etc. Below are some common OS
environments, cloud vendors, and hardware [...]

-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 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, Ke Holdings Inc already used the API Management
Platform APISIX project in product [...]

-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 [...]
+According to this Contributor Over Time graph, 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 phenomenal 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, such
as checking monthly [...]
-APISIX is still number one in these ways
+[APISIX
Advantages](https://static.apiseven.com/202108/1646300936531-618d6784-b8a6-4dbd-ae46-3d62b6ccabe2.jpg)
-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.
+After our actual customer visits, the feature of supporting multiple languages
is essential. After all, many companies have their standard technology stacks,
and many are blank for NGINX C and Lua. APISIX officially supported multiple
languages a few days ago, 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's entire dynamic and high performance are inseparable from the
surrounding ecology's high quality. Other peripheral libraries, such as
jsonschema, ipmatcher, etc., are better than open-source API Gateways.

-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.
+APISIX support for multi-language features has been put into the open-source
project. Interested users 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.
+After 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.
+I think the first three (foundation project, security, stability) are the most
important. As a foundation project, it no longer belongs to a person or a
company but is the property of all humankind, and we can use it forever. The
security and stability of APISIX are due to its cornerstone, NGINX, which has
become the most popular and widely used web server, and its heritage is still
awe-inspiring.
High performance, dynamics, and an active community are the trump cards of
APISIX, and they have formed a healthy interaction.
@@ -131,21 +132,21 @@ If one sentence sums up the pride of APISIX, I think it
is:**APISIX, the most ac
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.
+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. When it evolves into
Ingress, Service Mesh, etc., it is the external service that works with APISIX
and 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 canary release scenario of
moduloing based on request id can be easily done in APISIX using fine-grained
routing.
+For traditional LB and API Gateway scenarios, APISIX has the advantage of
going from static to all dynamic, with no more reloads, as many tech companies
start with a half-hour NGINX reload. The aforementioned canary release scenario
of modulating based on request-id can be quickly 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.
+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.
+Service mesh, it is necessary to talk to you about it. What is the most likely
mainstream server-side architecture in the next five or ten years? I would
choose the service mesh.

@@ -155,24 +156,24 @@ 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.
+Because APISIX is an Apache Foundation project, it is no longer the property
of individuals or companies but all humanity. This gives everyone 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.
+The default configuration center for the open-source version of APISIX is
etcd. While it is still the best choice, we often hear about support for other
configuration centers when talking to users 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.
+APISIX is already on the road to the 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.
+Unification itself is not the goal, but the benefits after unification are 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.
+- Development role: based on standardized APISIX plugin 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/join#join-the-slack-channel),
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.
+Last but not least is the APISIX [Slack
channel](https://apisix.apache.org/docs/general/join#join-the-slack-channel),
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)
+Click [here](https://www.bilibili.com/video/BV1w54y1V73Z) to watch the
recording video.