SylviaBABY commented on code in PR #1169: URL: https://github.com/apache/apisix-website/pull/1169#discussion_r909268160
########## website/blog/2021/06/28/why-we-need-Apache-APISIX.md: ########## @@ -10,118 +10,117 @@ 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 encounter a variety of problems, there are advanced and more common, ask more I gradually became a teacher and eventually became a community leader, like the famous saying "walk more people, also become the road. +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 longer need the history books. +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 Kong and Traefik, and of course, some users would continue to use NGINX because of their habitual habits. Although it has weaknesses such as weaknesses and inconveniences, but it is stable and reliable. On a side note, from a global market share perspective, NGINX became the most dominant Web Server in April 2019. +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, some users would continue to use NGINX because of their regular habits. Although it has weaknesses and inconveniences, it is stable and reliable. On a side note, from a global market share perspective, NGINX became the most dominant Web Server in April 2019. -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: +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. +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." Review Comment: ```suggestion As you can see, these are NGINX drawbacks, such as NGINX's low activity community: - 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. 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." ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
