You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2021/11/09 06:25:31 UTC
[GitHub] [apisix-website] yzeng25 commented on a change in pull request #710: docs: add EN version of usercases
yzeng25 commented on a change in pull request #710:
URL: https://github.com/apache/apisix-website/pull/710#discussion_r745307297
##########
File path: website/blog/2021/09/28/WPS-usercase.md
##########
@@ -1,122 +1,122 @@
---
-title: "百万级 QPS 业务新宠，金山办公携手 Apache APISIX 打造网关实践新体验"
-author: 张强
+title: "In Mega QPS business, WPS has teamed up with Apache APISIX to create a new gateway experience"
+author: Qiang Zhang
keywords:
- Apache APISIX
-- API 网关
-- 金山办公
+- API Gateway
- WPS
-description: 本文介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+description: In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
tags: [User Case]
---
-> 本文由金山办公中台部门 SRE 网络负责人张强介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+> In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
<!--truncate-->
-## 背景介绍
+## Background
-金山办公是目前国内最大的办公软件厂商，旗下产品涉及 WPS、金山文档、稻壳等。在业务层面上由数千个业务以容器化部署在内部云原生平台，目前 [Apache APISIX](https://apisix.apache.org/) 在金山办公主要负责为中台部门业务（百万级 QPS ）提供相关网关服务。
+WPS is currently the largest domestic office software manufacturers, its products include WPS Office, Kdocs, Docer and so on. At the business level, deployed by thousands of businesses in a container on an internal cloud native platform, [Apache APISIX](https://apisix.apache.org/) at WPS is currently responsible for providing gateway services to the mid-stage business (Mega QPS) .
-## 金山办公的网关演进
+## Gateway Evolution in WPS
-在 1.0 阶段时，我们对于 API Gateway 的特性没有什么强需求，只是想解决运维问题，所以基于 OpenResty 与 Lua 进行了自研，实现了动态 Upstream、黑名单、waf 等功能。
-虽然自研成功，但在功能上却遗留了一些问题，比如：
+In phase 1.0, we didn’t have a strong requirement for API Gateway features, we just wanted to solve the operations problem, so we did our own research based on OpenResty and Lua to implement dynamic Upstream, blacklist, WAF and so on. Although self-developed, but left some problems in the function, such as:
-- 动态化只做到到 Upstream 维度
-- 需要 Reload 才能带出新域名
-- 底层设计简单，功能扩展能力不强
+- It’s only as dynamic as the Upstream dimension
+- Need to Reload to bring out the new domain name
+- The bottom design is simple, the function expansion ability is not strong
-后续我们对 API Gateway 功能有了强需求后，开始去调研相关的开源网关产品。
+Following the strong demand for API Gateway functionality, we began to investigate the related open source Gateway products.
-## 为什么选择了 Apache APISIX
+## Why Apache APISIX？
-实际上 2019 年年底开始调研网关产品时，Kong 算是一个比较流行的选择。
+In fact, when the research on gateway products began in late 2019, Kong was one of the more popular choices.
-但后续经过测试发现，Kong 的性能不太能满足我们的需求，同时我们认为 Kong 的架构不是很优秀：因为其配置中心选用 PostgreSQL，所以 Kong 只能利用非事件驱动去更新路由，依赖每个节点去刷新路由。
+However, subsequent tests showed that Kong’s performance was not quite up to our expectations, and we didn’t think that Kong’s architecture was very good: its configuration center used PostgreSQL, so Kong can only use the non-event driver to update the route, relying on each node to refresh the route.
-进一步调研时，我们发现了 [Apache APISIX](https://github.com/apache/apisix)。首先 Apache APISIX 的性能比 Kong 强，在 Apache APISIX 的 GitHub Readme 中有个非常详细的对比图，列出了两者的[性能测试差距](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01)，这与我们自己测试下来的数据基本一致。
+On further investigation, we discovered [Apache APISIX](https://github.com/apache/apisix). First of all, Apache APISIX performs better than Kong, and there’s a very detailed graph in Apache APISIX’s GitHub Readme that shows the [performance test gaps](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01), which are basically consistent with the data we’ve tested ourselves.
-
+
-在架构方面，Apache APISIX 的 etcd 配置对我们而言是一项更优的选择。
+In terms of architecture, Apache APISIX’s ETCD configuration is a better choice for us.
-
+
-当然，最主要的原因是我们觉得社区也很重要。社区如果活跃，在版本更新迭代、问题解决和功能优化上的速度就会很快。从 GitHub 和平时的邮件反馈中我们看到了 Apache APISIX 社区的活跃，为产品功能和稳定性提供了强有力的保证。
+The main reason, of course, is that we feel that community is also important. If the community is active, it will be able to update iterations, troubleshoot problems, and optimize functionality quickly. From GitHub and regular email feedback we can see that the Apache APISIX community is active, providing a strong guarantee of product functionality and stability.
-## 网关平滑迁移经验分享
+## Experience of Gateway Smooth Migration
-大部分朋友在开始接触 Apache APISIX 时，都会用 CLI 去生成配置并起实例。但在我们做平滑迁移的过程中，并没有使用 CLI 去生成配置。
+When most of my friends started working with Apache APISIX, they used the CLI to generate configurations and instances. However, during our smooth migration, we did not use the CLI to generate the configuration.
-主要原因是 Apache APISIX 在 OpenResty 中会生效一些 Phase，比如初始化 init、init_worker、HTTP 和 Upstream 相关 Phase 等。对应到 Apache APISIX 的配置后我们发现，这些都可以脱离 CLI 而存在。
+The main reason is that Apache APISIX does some Phase in OpenResty, such as initializing the init, init_worker, HTTP, and Upstream related phases.
-所以基于上述原因，我们最终采取了如下行动进行平滑迁移：
+Corresponding to the Apache APISIX configuration, we found that these can be separated from the CLI and exist.
Review comment:
```suggestion
Corresponding to the Apache APISIX configuration, we found that these can be migrated from the CLI smoothly.
```
##########
File path: website/blog/2021/09/28/WPS-usercase.md
##########
@@ -1,122 +1,122 @@
---
-title: "百万级 QPS 业务新宠，金山办公携手 Apache APISIX 打造网关实践新体验"
-author: 张强
+title: "In Mega QPS business, WPS has teamed up with Apache APISIX to create a new gateway experience"
+author: Qiang Zhang
keywords:
- Apache APISIX
-- API 网关
-- 金山办公
+- API Gateway
- WPS
-description: 本文介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+description: In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
tags: [User Case]
---
-> 本文由金山办公中台部门 SRE 网络负责人张强介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+> In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
<!--truncate-->
-## 背景介绍
+## Background
-金山办公是目前国内最大的办公软件厂商，旗下产品涉及 WPS、金山文档、稻壳等。在业务层面上由数千个业务以容器化部署在内部云原生平台，目前 [Apache APISIX](https://apisix.apache.org/) 在金山办公主要负责为中台部门业务（百万级 QPS ）提供相关网关服务。
+WPS is currently the largest domestic office software manufacturers, its products include WPS Office, Kdocs, Docer and so on. At the business level, deployed by thousands of businesses in a container on an internal cloud native platform, [Apache APISIX](https://apisix.apache.org/) at WPS is currently responsible for providing gateway services to the mid-stage business (Mega QPS) .
-## 金山办公的网关演进
+## Gateway Evolution in WPS
-在 1.0 阶段时，我们对于 API Gateway 的特性没有什么强需求，只是想解决运维问题，所以基于 OpenResty 与 Lua 进行了自研，实现了动态 Upstream、黑名单、waf 等功能。
-虽然自研成功，但在功能上却遗留了一些问题，比如：
+In phase 1.0, we didn’t have a strong requirement for API Gateway features, we just wanted to solve the operations problem, so we did our own research based on OpenResty and Lua to implement dynamic Upstream, blacklist, WAF and so on. Although self-developed, but left some problems in the function, such as:
-- 动态化只做到到 Upstream 维度
-- 需要 Reload 才能带出新域名
-- 底层设计简单，功能扩展能力不强
+- It’s only as dynamic as the Upstream dimension
+- Need to Reload to bring out the new domain name
+- The bottom design is simple, the function expansion ability is not strong
-后续我们对 API Gateway 功能有了强需求后，开始去调研相关的开源网关产品。
+Following the strong demand for API Gateway functionality, we began to investigate the related open source Gateway products.
-## 为什么选择了 Apache APISIX
+## Why Apache APISIX？
-实际上 2019 年年底开始调研网关产品时，Kong 算是一个比较流行的选择。
+In fact, when the research on gateway products began in late 2019, Kong was one of the more popular choices.
-但后续经过测试发现，Kong 的性能不太能满足我们的需求，同时我们认为 Kong 的架构不是很优秀：因为其配置中心选用 PostgreSQL，所以 Kong 只能利用非事件驱动去更新路由，依赖每个节点去刷新路由。
+However, subsequent tests showed that Kong’s performance was not quite up to our expectations, and we didn’t think that Kong’s architecture was very good: its configuration center used PostgreSQL, so Kong can only use the non-event driver to update the route, relying on each node to refresh the route.
-进一步调研时，我们发现了 [Apache APISIX](https://github.com/apache/apisix)。首先 Apache APISIX 的性能比 Kong 强，在 Apache APISIX 的 GitHub Readme 中有个非常详细的对比图，列出了两者的[性能测试差距](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01)，这与我们自己测试下来的数据基本一致。
+On further investigation, we discovered [Apache APISIX](https://github.com/apache/apisix). First of all, Apache APISIX performs better than Kong, and there’s a very detailed graph in Apache APISIX’s GitHub Readme that shows the [performance test gaps](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01), which are basically consistent with the data we’ve tested ourselves.
Review comment:
```suggestion
On further investigation, we discovered [Apache APISIX](https://github.com/apache/apisix). First of all, Apache APISIX performs better than Kong, and there’s a very detailed graph in Apache APISIX’s GitHub Readme that shows the [Performance of Apache APISIX Compared to Kong](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01), which are basically consistent with the data we’ve tested ourselves.
```
##########
File path: website/blog/2021/09/28/WPS-usercase.md
##########
@@ -1,122 +1,122 @@
---
-title: "百万级 QPS 业务新宠，金山办公携手 Apache APISIX 打造网关实践新体验"
-author: 张强
+title: "In Mega QPS business, WPS has teamed up with Apache APISIX to create a new gateway experience"
+author: Qiang Zhang
keywords:
- Apache APISIX
-- API 网关
-- 金山办公
+- API Gateway
- WPS
-description: 本文介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+description: In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
tags: [User Case]
---
-> 本文由金山办公中台部门 SRE 网络负责人张强介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+> In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
<!--truncate-->
-## 背景介绍
+## Background
-金山办公是目前国内最大的办公软件厂商，旗下产品涉及 WPS、金山文档、稻壳等。在业务层面上由数千个业务以容器化部署在内部云原生平台，目前 [Apache APISIX](https://apisix.apache.org/) 在金山办公主要负责为中台部门业务（百万级 QPS ）提供相关网关服务。
+WPS is currently the largest domestic office software manufacturers, its products include WPS Office, Kdocs, Docer and so on. At the business level, deployed by thousands of businesses in a container on an internal cloud native platform, [Apache APISIX](https://apisix.apache.org/) at WPS is currently responsible for providing gateway services to the mid-stage business (Mega QPS) .
-## 金山办公的网关演进
+## Gateway Evolution in WPS
-在 1.0 阶段时，我们对于 API Gateway 的特性没有什么强需求，只是想解决运维问题，所以基于 OpenResty 与 Lua 进行了自研，实现了动态 Upstream、黑名单、waf 等功能。
-虽然自研成功，但在功能上却遗留了一些问题，比如：
+In phase 1.0, we didn’t have a strong requirement for API Gateway features, we just wanted to solve the operations problem, so we did our own research based on OpenResty and Lua to implement dynamic Upstream, blacklist, WAF and so on. Although self-developed, but left some problems in the function, such as:
-- 动态化只做到到 Upstream 维度
-- 需要 Reload 才能带出新域名
-- 底层设计简单，功能扩展能力不强
+- It’s only as dynamic as the Upstream dimension
+- Need to Reload to bring out the new domain name
+- The bottom design is simple, the function expansion ability is not strong
-后续我们对 API Gateway 功能有了强需求后，开始去调研相关的开源网关产品。
+Following the strong demand for API Gateway functionality, we began to investigate the related open source Gateway products.
-## 为什么选择了 Apache APISIX
+## Why Apache APISIX？
-实际上 2019 年年底开始调研网关产品时，Kong 算是一个比较流行的选择。
+In fact, when the research on gateway products began in late 2019, Kong was one of the more popular choices.
-但后续经过测试发现，Kong 的性能不太能满足我们的需求，同时我们认为 Kong 的架构不是很优秀：因为其配置中心选用 PostgreSQL，所以 Kong 只能利用非事件驱动去更新路由，依赖每个节点去刷新路由。
+However, subsequent tests showed that Kong’s performance was not quite up to our expectations, and we didn’t think that Kong’s architecture was very good: its configuration center used PostgreSQL, so Kong can only use the non-event driver to update the route, relying on each node to refresh the route.
-进一步调研时，我们发现了 [Apache APISIX](https://github.com/apache/apisix)。首先 Apache APISIX 的性能比 Kong 强，在 Apache APISIX 的 GitHub Readme 中有个非常详细的对比图，列出了两者的[性能测试差距](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01)，这与我们自己测试下来的数据基本一致。
+On further investigation, we discovered [Apache APISIX](https://github.com/apache/apisix). First of all, Apache APISIX performs better than Kong, and there’s a very detailed graph in Apache APISIX’s GitHub Readme that shows the [performance test gaps](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01), which are basically consistent with the data we’ve tested ourselves.
-
+
-在架构方面，Apache APISIX 的 etcd 配置对我们而言是一项更优的选择。
+In terms of architecture, Apache APISIX’s ETCD configuration is a better choice for us.
-
+
-当然，最主要的原因是我们觉得社区也很重要。社区如果活跃，在版本更新迭代、问题解决和功能优化上的速度就会很快。从 GitHub 和平时的邮件反馈中我们看到了 Apache APISIX 社区的活跃，为产品功能和稳定性提供了强有力的保证。
+The main reason, of course, is that we feel that community is also important. If the community is active, it will be able to update iterations, troubleshoot problems, and optimize functionality quickly. From GitHub and regular email feedback we can see that the Apache APISIX community is active, providing a strong guarantee of product functionality and stability.
-## 网关平滑迁移经验分享
+## Experience of Gateway Smooth Migration
-大部分朋友在开始接触 Apache APISIX 时，都会用 CLI 去生成配置并起实例。但在我们做平滑迁移的过程中，并没有使用 CLI 去生成配置。
+When most of my friends started working with Apache APISIX, they used the CLI to generate configurations and instances. However, during our smooth migration, we did not use the CLI to generate the configuration.
-主要原因是 Apache APISIX 在 OpenResty 中会生效一些 Phase，比如初始化 init、init_worker、HTTP 和 Upstream 相关 Phase 等。对应到 Apache APISIX 的配置后我们发现，这些都可以脱离 CLI 而存在。
+The main reason is that Apache APISIX does some Phase in OpenResty, such as initializing the init, init_worker, HTTP, and Upstream related phases.
-所以基于上述原因，我们最终采取了如下行动进行平滑迁移：
+Corresponding to the Apache APISIX configuration, we found that these can be separated from the CLI and exist.
-- 不使用 Apache APISIX 的 CLI 生成配置
-- 引入 Apache APISIX 的 Package Path 并将 Apache APISIX 作为 Default Server
-- 保留其它静态配置中的域名，由于新域名未在静态配置中，将 Fallback 到 Apache APISIX
-- 最终将静态配置逐渐迁移到 Apache APISIX 中
+So for these reasons, we ended up doing the following smooth migration:
-当然，除了上述方法，我们也给大家推荐一种「轻混模式」，即使用静态配置配合 Apache APISIX 作为 Location，引入前边提到的一些 Phase 或 Lua 代码进行配置即可。这样做可以在静态配置中引入一些特殊配置，实现动态化等效果。
+- CLI generation configuration without Apache APISIX
+- Introduce a Package Path for Apache APISIX and make Apache APISIX the Default Server
+- KEEP domain names in other static configurations, and because the new domain name is not in the static configuration, Fallback to Apache APISIX
+- Eventually the static configuration was migrated gradually to Apache APISIX
-## 基于 Apache APISIX 的 Shared State 改进
+Of course, in addition to the above, we recommend a “Light-mixing mode” that uses static configuration with Apache APISIX as Location, with some of the Phase or Lua code mentioned earlier. Doing so allows you to introduce special configurations into your static configuration, make it dynamic, etc. .
-首先在我个人看来，「转发效率一定不是问题，而 Shared State 是影响稳定性的最大因素」，为什么这么说？
+## Shared State Improvement Based on Apache APISIX
-因为转发效率可以通过横向扩容去解决，但 Shared State 是所有的节点共享的，所以是至关重要的模块。
+First of all, in my opinion, “The Shared State is the biggest factor in the stability of the feed, which is definitely not an issue.”Why?
-所以在使用 Apache APISIX 后，我们主要针对 Shared State 层面进行了一些调整与优化。
+Because forwarding efficiency can be addressed by scaling laterally, the Shared State is a critical module because it is Shared by all nodes.
-### 优化一：多台机器监听下的 etcd 架构优化
+So after using Apache APISIX, we made a few tweaks and optimizations to focus on the Shared State layer.
-一般公司网关架构中，都会涉及多台机器，有的可能多至几百台，同时每台机器还要顾及 worker 数量。所以当多台机器监控相同 Key 时，etcd 的压力就会比较大，因为 etcd 的其中一个机制是为了保证数据一致性，需要所有事件返回给监听请求后才能处理新请求，当发送缓冲满了后就会丢弃请求。所以当多台机器同时监听时就会导致 etcd 超时运行，提示 Overload 报错等状况。
+### Optimization 1: Optimization of ETCD Architecture with Multiple Machines Listening
-针对上述问题，我们使用了自研的 etcd Proxy。之前 Apache APISIX 与 etcd 的连接关系如下图左侧所示，每个节点均与 etcd 连接。所以作为一个大规模入口时，连接数量会特别大，对 etcd 造成压力。
+In a typical corporate gateway architecture, multiple machines are involved, some as many as a few hundred, and each machine has to take into account the number of workers. So when multiple machines monitor the same Key, the pressure on the ETCD is greater, because one of the ETCD mechanisms is to ensure data consistency, requiring all events to be returned to the listening request before new requests can be processed, the request is discarded when the send buffer is full. So when multiple machines listen at the same time will cause the ETCD to run overtime, Overload error, and so on.
+
+To solve the above problem, we use our own ETCD Proxy. The previous connection between Apache APISIX and ETCD is shown on the left side of the figure below, with each node connected to the ETCD. So as a large-scale entry, the number of connections can be particularly large, putting pressure on the ETCD.
-既然是监听相同的 Key，我们做了一个代理来进行统一监听，当有结果反馈时，再返回给 Apache APISIX。具体架构如上图右侧所示，在 Apache APISIX 和 etcd 中间放置了 etcd Proxy 组件来监控 Key 值的变化。
+Since we are listening to the same Key, we make a proxy to do a uniform listening and return the results to Apache APISIX when there is feedback. As shown on the right side of the image above, the ETCD Proxy component is placed between Apache APISIX and ETCD to monitor changes in Key values.
-### 优化二：解决路由生效过程中的性能问题
+### Optimization 2: Solving the Performance Problem During Routing Validation
Review comment:
```suggestion
### Improvement 2: Solving the Performance Problem During Routing Validation
```
##########
File path: website/package.json
##########
@@ -50,5 +50,6 @@
},
"resolutions": {
"styled-components": "^5"
- }
+ },
+ "version": "0.0.0"
Review comment:
I think this change was not your intention. Please change it back to what it was before.
##########
File path: website/blog/2021/09/24/youpaicloud-usercase.md
##########
@@ -1,160 +1,159 @@
---
-title: "Apache APISIX Ingress 为何成为又拍云打造容器网关的新选择？"
-author: "陈卓"
+title: "Why is Apache APISIX Ingress a new option for building container gateways into the UPYUN?"
+author: "Zhuo Chen"
keywords:
- Apache APISIX
- Apache APISIX Ingress
-- 又拍云
-- 容器网关
-description: 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
+- UPYUN
+- Container gateway
+description: This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use.
tags: [User Case]
---
-> 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
-> 作者陈卓，又拍云开发工程师，负责云存储、云处理和网关应用开发。
+> This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use. Chen Zhuo, a cloud development engineer, is responsible for cloud storage, cloud processing, and gateway application development.
<!--truncate-->
-## 项目背景介绍
+## Background
-目前市面上可执行 Ingress 的产品项目逐渐丰富了起来，可选择的范围也扩大了很多。这些产品按照架构大概可分为两类，一类像 k8s Ingress、Apache APISIX Ingress，他们是基于 Nginx、OpenResty 等传统代理器，使用 k8s-Client 和 Golang 去做 Controller。还有一类新兴的用 Golang 语言去实现代理和控制器功能，比如 Traefik。
+The range of Ingress products on the market has grown and the range of options has expanded considerably. These products fall into roughly two architectural categories. One, like K8s Ingress and Apache APISIX Ingress, are based on traditional agents such as Nginx and OpenResty, and use k8s-Client and Golang to do Controller. There is also an emerging class of agents and controllers using the Golang language, such as Traefik.
-又拍云最开始包括现在的大部分业务仍在使用 Ingress-Nginx，整体架构如下。
+Ingress-Nginx is still used by most businesses in UPYUN, including today’s, and the overall architecture is as follows.
-
+
-下层为数据面 OpenResty。上层 Controller 主要是监听 APIServer 的资源变化，并生成 nginx.conf 配置文件，然后 Reload OpenResty。如果 POD IP 发生变化，可直接通过 HTTP 接口传输给 OpenResty Lua 代码去实现上游 Upstream node 替换。
+The lower layer is data surface OpenResty. The upper Controller listens primarily for resource changes from APIServer and generates `nginx.conf` configuration file, and then Reload OpenResty. If the POD IP changes, the Upstream Upstream node replacement can be transmitted directly to the OpenResty Lua code via the HTTP interface.
-Ingress-Nginx 的扩展能力主要通过 Annotations 去实现，配置文件本身的语法和路由规则都比较简单。可以按照需求进行相关指令配置，同时也支持可拓展 Lua 插件，提高了定制化功能的可操作性。
+The extensibility of Ingress-Nginx is achieved mainly through Annotations, and the configuration file itself has simple syntax and routing rules. Lua can be configured on demand, and the extension of the Lua plug in improves Operability of customization.
-
+
-但 Ingress-Nginx 它也有一些缺点，比如：
+But Ingress-Nginx has some drawbacks, such as:
-- 开发插件时组件依赖复杂，移植性差
-- 语义能力弱
-- 任何一条 Ingress 的修改都需要 Reload，对长链接不友好
+- The development of plug-ins depends on complex components, poor portability
+- Weak semantic ability
+- Any change to Ingress requires Reload, which is unfriendly to long links
-在维护现有逻辑时，上述问题造成了一定程度的困扰，所以我们开始寻找相关容器网关替代品。
+These issues caused some confusion in maintaining the existing logic, so we started looking for alternatives to the relevant container gateways.
-## 调研阶段
+## Research Phase
-在替代 Ingress-Nginx 的选择中，我们主要考量了 Traefik 和 Apache APISIX Ingress。
+In choosing an alternative to Ingress-Nginx, we focused on Traefik and Apache APISIX Ingress.
-Traefik 是云原生模式，配置文件极其简单，采用分布式配置，同时支持多种自动配置发现。不仅支持 k8s、etcd，Golang 的生态语言支持比较好，且开发成本较低，迭代和测试能力较好。但是在其他层面略显不足，比如：
+Traefik is native to the cloud, with extremely simple configuration files, a distributed configuration, and support for a variety of automated configuration discovery. Not only support K8s, ETCD, Golang eco-language support is better, and the development cost is lower, iteration and testing ability is better. But it falls short at other levels, such as:
-- 扩展能力弱
-- 不支持 Reload
-- 性能和功能上不如 Nginx（虽然消耗也较低）
+- Weak expansibility
+- Reload is not supported
+- Not as good as Nginx in terms of performance and functionality (though it’s also less expensive)
-它不像 Nginx 有丰富的插件和指令，通过增加一条指令即可解决一个问题，在线上部署时，可能还需在 Traefik 前搭配一个 Nginx。
+Unlike Nginx, which is rich in plugins and instructions, you can solve a problem by adding an instruction, and you may need to pair an Nginx with Traefik when you deploy online.
-综上所述，虽然在操作性上 Traefik 优势尽显，但在扩展能力和运维效率上有所顾虑，最终没有选择 Traefik。
+In summary, although the operational advantages of Traefik, but in the expansion of capacity and operational efficiency concerns, and ultimately did not choose Traefik.
Review comment:
```suggestion
In summary, although Traefik has advantages on operations, we are worried about its drawbacks on extension and operational efficiency, so we did not choose Traefik.
```
##########
File path: website/blog/2021/09/24/youpaicloud-usercase.md
##########
@@ -1,160 +1,159 @@
---
-title: "Apache APISIX Ingress 为何成为又拍云打造容器网关的新选择？"
-author: "陈卓"
+title: "Why is Apache APISIX Ingress a new option for building container gateways into the UPYUN?"
+author: "Zhuo Chen"
keywords:
- Apache APISIX
- Apache APISIX Ingress
-- 又拍云
-- 容器网关
-description: 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
+- UPYUN
+- Container gateway
+description: This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use.
tags: [User Case]
---
-> 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
-> 作者陈卓，又拍云开发工程师，负责云存储、云处理和网关应用开发。
+> This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use. Chen Zhuo, a cloud development engineer, is responsible for cloud storage, cloud processing, and gateway application development.
<!--truncate-->
-## 项目背景介绍
+## Background
-目前市面上可执行 Ingress 的产品项目逐渐丰富了起来，可选择的范围也扩大了很多。这些产品按照架构大概可分为两类，一类像 k8s Ingress、Apache APISIX Ingress，他们是基于 Nginx、OpenResty 等传统代理器，使用 k8s-Client 和 Golang 去做 Controller。还有一类新兴的用 Golang 语言去实现代理和控制器功能，比如 Traefik。
+The range of Ingress products on the market has grown and the range of options has expanded considerably. These products fall into roughly two architectural categories. One, like K8s Ingress and Apache APISIX Ingress, are based on traditional agents such as Nginx and OpenResty, and use k8s-Client and Golang to do Controller. There is also an emerging class of agents and controllers using the Golang language, such as Traefik.
-又拍云最开始包括现在的大部分业务仍在使用 Ingress-Nginx，整体架构如下。
+Ingress-Nginx is still used by most businesses in UPYUN, including today’s, and the overall architecture is as follows.
-
+
-下层为数据面 OpenResty。上层 Controller 主要是监听 APIServer 的资源变化，并生成 nginx.conf 配置文件，然后 Reload OpenResty。如果 POD IP 发生变化，可直接通过 HTTP 接口传输给 OpenResty Lua 代码去实现上游 Upstream node 替换。
+The lower layer is data surface OpenResty. The upper Controller listens primarily for resource changes from APIServer and generates `nginx.conf` configuration file, and then Reload OpenResty. If the POD IP changes, the Upstream Upstream node replacement can be transmitted directly to the OpenResty Lua code via the HTTP interface.
Review comment:
```suggestion
The lower layer is data plane OpenResty. The upper Controller listens primarily for resource changes from APIServer and generates `nginx.conf` configuration file, and then Reload OpenResty. If the POD IP changes, the Upstream Upstream node replacement can be transmitted directly to the OpenResty Lua code via the HTTP interface.
```
##########
File path: website/package.json
##########
@@ -50,5 +50,6 @@
},
"resolutions": {
"styled-components": "^5"
- }
+ },
+ "version": "0.0.0"
Review comment:
```suggestion
}
```
##########
File path: website/blog/2021/09/28/WPS-usercase.md
##########
@@ -1,122 +1,122 @@
---
-title: "百万级 QPS 业务新宠，金山办公携手 Apache APISIX 打造网关实践新体验"
-author: 张强
+title: "In Mega QPS business, WPS has teamed up with Apache APISIX to create a new gateway experience"
+author: Qiang Zhang
keywords:
- Apache APISIX
-- API 网关
-- 金山办公
+- API Gateway
- WPS
-description: 本文介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+description: In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
tags: [User Case]
---
-> 本文由金山办公中台部门 SRE 网络负责人张强介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+> In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
<!--truncate-->
-## 背景介绍
+## Background
-金山办公是目前国内最大的办公软件厂商，旗下产品涉及 WPS、金山文档、稻壳等。在业务层面上由数千个业务以容器化部署在内部云原生平台，目前 [Apache APISIX](https://apisix.apache.org/) 在金山办公主要负责为中台部门业务（百万级 QPS ）提供相关网关服务。
+WPS is currently the largest domestic office software manufacturers, its products include WPS Office, Kdocs, Docer and so on. At the business level, deployed by thousands of businesses in a container on an internal cloud native platform, [Apache APISIX](https://apisix.apache.org/) at WPS is currently responsible for providing gateway services to the mid-stage business (Mega QPS) .
-## 金山办公的网关演进
+## Gateway Evolution in WPS
-在 1.0 阶段时，我们对于 API Gateway 的特性没有什么强需求，只是想解决运维问题，所以基于 OpenResty 与 Lua 进行了自研，实现了动态 Upstream、黑名单、waf 等功能。
-虽然自研成功，但在功能上却遗留了一些问题，比如：
+In phase 1.0, we didn’t have a strong requirement for API Gateway features, we just wanted to solve the operations problem, so we did our own research based on OpenResty and Lua to implement dynamic Upstream, blacklist, WAF and so on. Although self-developed, but left some problems in the function, such as:
-- 动态化只做到到 Upstream 维度
-- 需要 Reload 才能带出新域名
-- 底层设计简单，功能扩展能力不强
+- It’s only as dynamic as the Upstream dimension
+- Need to Reload to bring out the new domain name
+- The bottom design is simple, the function expansion ability is not strong
-后续我们对 API Gateway 功能有了强需求后，开始去调研相关的开源网关产品。
+Following the strong demand for API Gateway functionality, we began to investigate the related open source Gateway products.
-## 为什么选择了 Apache APISIX
+## Why Apache APISIX？
-实际上 2019 年年底开始调研网关产品时，Kong 算是一个比较流行的选择。
+In fact, when the research on gateway products began in late 2019, Kong was one of the more popular choices.
-但后续经过测试发现，Kong 的性能不太能满足我们的需求，同时我们认为 Kong 的架构不是很优秀：因为其配置中心选用 PostgreSQL，所以 Kong 只能利用非事件驱动去更新路由，依赖每个节点去刷新路由。
+However, subsequent tests showed that Kong’s performance was not quite up to our expectations, and we didn’t think that Kong’s architecture was very good: its configuration center used PostgreSQL, so Kong can only use the non-event driver to update the route, relying on each node to refresh the route.
-进一步调研时，我们发现了 [Apache APISIX](https://github.com/apache/apisix)。首先 Apache APISIX 的性能比 Kong 强，在 Apache APISIX 的 GitHub Readme 中有个非常详细的对比图，列出了两者的[性能测试差距](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01)，这与我们自己测试下来的数据基本一致。
+On further investigation, we discovered [Apache APISIX](https://github.com/apache/apisix). First of all, Apache APISIX performs better than Kong, and there’s a very detailed graph in Apache APISIX’s GitHub Readme that shows the [performance test gaps](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01), which are basically consistent with the data we’ve tested ourselves.
-
+
-在架构方面，Apache APISIX 的 etcd 配置对我们而言是一项更优的选择。
+In terms of architecture, Apache APISIX’s ETCD configuration is a better choice for us.
-
+
-当然，最主要的原因是我们觉得社区也很重要。社区如果活跃，在版本更新迭代、问题解决和功能优化上的速度就会很快。从 GitHub 和平时的邮件反馈中我们看到了 Apache APISIX 社区的活跃，为产品功能和稳定性提供了强有力的保证。
+The main reason, of course, is that we feel that community is also important. If the community is active, it will be able to update iterations, troubleshoot problems, and optimize functionality quickly. From GitHub and regular email feedback we can see that the Apache APISIX community is active, providing a strong guarantee of product functionality and stability.
-## 网关平滑迁移经验分享
+## Experience of Gateway Smooth Migration
-大部分朋友在开始接触 Apache APISIX 时，都会用 CLI 去生成配置并起实例。但在我们做平滑迁移的过程中，并没有使用 CLI 去生成配置。
+When most of my friends started working with Apache APISIX, they used the CLI to generate configurations and instances. However, during our smooth migration, we did not use the CLI to generate the configuration.
-主要原因是 Apache APISIX 在 OpenResty 中会生效一些 Phase，比如初始化 init、init_worker、HTTP 和 Upstream 相关 Phase 等。对应到 Apache APISIX 的配置后我们发现，这些都可以脱离 CLI 而存在。
+The main reason is that Apache APISIX does some Phase in OpenResty, such as initializing the init, init_worker, HTTP, and Upstream related phases.
-所以基于上述原因，我们最终采取了如下行动进行平滑迁移：
+Corresponding to the Apache APISIX configuration, we found that these can be separated from the CLI and exist.
-- 不使用 Apache APISIX 的 CLI 生成配置
-- 引入 Apache APISIX 的 Package Path 并将 Apache APISIX 作为 Default Server
-- 保留其它静态配置中的域名，由于新域名未在静态配置中，将 Fallback 到 Apache APISIX
-- 最终将静态配置逐渐迁移到 Apache APISIX 中
+So for these reasons, we ended up doing the following smooth migration:
-当然，除了上述方法，我们也给大家推荐一种「轻混模式」，即使用静态配置配合 Apache APISIX 作为 Location，引入前边提到的一些 Phase 或 Lua 代码进行配置即可。这样做可以在静态配置中引入一些特殊配置，实现动态化等效果。
+- CLI generation configuration without Apache APISIX
+- Introduce a Package Path for Apache APISIX and make Apache APISIX the Default Server
+- KEEP domain names in other static configurations, and because the new domain name is not in the static configuration, Fallback to Apache APISIX
+- Eventually the static configuration was migrated gradually to Apache APISIX
-## 基于 Apache APISIX 的 Shared State 改进
+Of course, in addition to the above, we recommend a “Light-mixing mode” that uses static configuration with Apache APISIX as Location, with some of the Phase or Lua code mentioned earlier. Doing so allows you to introduce special configurations into your static configuration, make it dynamic, etc. .
-首先在我个人看来，「转发效率一定不是问题，而 Shared State 是影响稳定性的最大因素」，为什么这么说？
+## Shared State Improvement Based on Apache APISIX
Review comment:
```suggestion
## Shared State Improvements Based on Apache APISIX
```
##########
File path: website/blog/2021/09/28/WPS-usercase.md
##########
@@ -1,122 +1,122 @@
---
-title: "百万级 QPS 业务新宠，金山办公携手 Apache APISIX 打造网关实践新体验"
-author: 张强
+title: "In Mega QPS business, WPS has teamed up with Apache APISIX to create a new gateway experience"
Review comment:
```suggestion
title: "WPS has teamed up with Apache APISIX to create a new gateway experience"
```
##########
File path: website/blog/2021/09/28/WPS-usercase.md
##########
@@ -1,122 +1,122 @@
---
-title: "百万级 QPS 业务新宠，金山办公携手 Apache APISIX 打造网关实践新体验"
-author: 张强
+title: "In Mega QPS business, WPS has teamed up with Apache APISIX to create a new gateway experience"
+author: Qiang Zhang
keywords:
- Apache APISIX
-- API 网关
-- 金山办公
+- API Gateway
- WPS
-description: 本文介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+description: In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
tags: [User Case]
---
-> 本文由金山办公中台部门 SRE 网络负责人张强介绍了金山办公如何使用 Apache APISIX 应对百万级 QPS 业务，同时基于 Apache APISIX 更新与改进网关实践层面的内容。
+> In this article, Zhang Qiang, head of SRE network in WPS, explains how WPS can use Apache APISIX to handle Mega QPS, and update and improve gateway practices based on Apache APISIX.
<!--truncate-->
-## 背景介绍
+## Background
-金山办公是目前国内最大的办公软件厂商，旗下产品涉及 WPS、金山文档、稻壳等。在业务层面上由数千个业务以容器化部署在内部云原生平台，目前 [Apache APISIX](https://apisix.apache.org/) 在金山办公主要负责为中台部门业务（百万级 QPS ）提供相关网关服务。
+WPS is currently the largest domestic office software manufacturers, its products include WPS Office, Kdocs, Docer and so on. At the business level, deployed by thousands of businesses in a container on an internal cloud native platform, [Apache APISIX](https://apisix.apache.org/) at WPS is currently responsible for providing gateway services to the mid-stage business (Mega QPS) .
-## 金山办公的网关演进
+## Gateway Evolution in WPS
-在 1.0 阶段时，我们对于 API Gateway 的特性没有什么强需求，只是想解决运维问题，所以基于 OpenResty 与 Lua 进行了自研，实现了动态 Upstream、黑名单、waf 等功能。
-虽然自研成功，但在功能上却遗留了一些问题，比如：
+In phase 1.0, we didn’t have a strong requirement for API Gateway features, we just wanted to solve the operations problem, so we did our own research based on OpenResty and Lua to implement dynamic Upstream, blacklist, WAF and so on. Although self-developed, but left some problems in the function, such as:
-- 动态化只做到到 Upstream 维度
-- 需要 Reload 才能带出新域名
-- 底层设计简单，功能扩展能力不强
+- It’s only as dynamic as the Upstream dimension
+- Need to Reload to bring out the new domain name
+- The bottom design is simple, the function expansion ability is not strong
-后续我们对 API Gateway 功能有了强需求后，开始去调研相关的开源网关产品。
+Following the strong demand for API Gateway functionality, we began to investigate the related open source Gateway products.
-## 为什么选择了 Apache APISIX
+## Why Apache APISIX？
-实际上 2019 年年底开始调研网关产品时，Kong 算是一个比较流行的选择。
+In fact, when the research on gateway products began in late 2019, Kong was one of the more popular choices.
-但后续经过测试发现，Kong 的性能不太能满足我们的需求，同时我们认为 Kong 的架构不是很优秀：因为其配置中心选用 PostgreSQL，所以 Kong 只能利用非事件驱动去更新路由，依赖每个节点去刷新路由。
+However, subsequent tests showed that Kong’s performance was not quite up to our expectations, and we didn’t think that Kong’s architecture was very good: its configuration center used PostgreSQL, so Kong can only use the non-event driver to update the route, relying on each node to refresh the route.
-进一步调研时，我们发现了 [Apache APISIX](https://github.com/apache/apisix)。首先 Apache APISIX 的性能比 Kong 强，在 Apache APISIX 的 GitHub Readme 中有个非常详细的对比图，列出了两者的[性能测试差距](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01)，这与我们自己测试下来的数据基本一致。
+On further investigation, we discovered [Apache APISIX](https://github.com/apache/apisix). First of all, Apache APISIX performs better than Kong, and there’s a very detailed graph in Apache APISIX’s GitHub Readme that shows the [performance test gaps](https://gist.github.com/membphis/137db97a4bf64d3653aa42f3e016bd01), which are basically consistent with the data we’ve tested ourselves.
-
+
-在架构方面，Apache APISIX 的 etcd 配置对我们而言是一项更优的选择。
+In terms of architecture, Apache APISIX’s ETCD configuration is a better choice for us.
-
+
-当然，最主要的原因是我们觉得社区也很重要。社区如果活跃，在版本更新迭代、问题解决和功能优化上的速度就会很快。从 GitHub 和平时的邮件反馈中我们看到了 Apache APISIX 社区的活跃，为产品功能和稳定性提供了强有力的保证。
+The main reason, of course, is that we feel that community is also important. If the community is active, it will be able to update iterations, troubleshoot problems, and optimize functionality quickly. From GitHub and regular email feedback we can see that the Apache APISIX community is active, providing a strong guarantee of product functionality and stability.
-## 网关平滑迁移经验分享
+## Experience of Gateway Smooth Migration
-大部分朋友在开始接触 Apache APISIX 时，都会用 CLI 去生成配置并起实例。但在我们做平滑迁移的过程中，并没有使用 CLI 去生成配置。
+When most of my friends started working with Apache APISIX, they used the CLI to generate configurations and instances. However, during our smooth migration, we did not use the CLI to generate the configuration.
-主要原因是 Apache APISIX 在 OpenResty 中会生效一些 Phase，比如初始化 init、init_worker、HTTP 和 Upstream 相关 Phase 等。对应到 Apache APISIX 的配置后我们发现，这些都可以脱离 CLI 而存在。
+The main reason is that Apache APISIX does some Phase in OpenResty, such as initializing the init, init_worker, HTTP, and Upstream related phases.
-所以基于上述原因，我们最终采取了如下行动进行平滑迁移：
+Corresponding to the Apache APISIX configuration, we found that these can be separated from the CLI and exist.
-- 不使用 Apache APISIX 的 CLI 生成配置
-- 引入 Apache APISIX 的 Package Path 并将 Apache APISIX 作为 Default Server
-- 保留其它静态配置中的域名，由于新域名未在静态配置中，将 Fallback 到 Apache APISIX
-- 最终将静态配置逐渐迁移到 Apache APISIX 中
+So for these reasons, we ended up doing the following smooth migration:
-当然，除了上述方法，我们也给大家推荐一种「轻混模式」，即使用静态配置配合 Apache APISIX 作为 Location，引入前边提到的一些 Phase 或 Lua 代码进行配置即可。这样做可以在静态配置中引入一些特殊配置，实现动态化等效果。
+- CLI generation configuration without Apache APISIX
+- Introduce a Package Path for Apache APISIX and make Apache APISIX the Default Server
+- KEEP domain names in other static configurations, and because the new domain name is not in the static configuration, Fallback to Apache APISIX
+- Eventually the static configuration was migrated gradually to Apache APISIX
-## 基于 Apache APISIX 的 Shared State 改进
+Of course, in addition to the above, we recommend a “Light-mixing mode” that uses static configuration with Apache APISIX as Location, with some of the Phase or Lua code mentioned earlier. Doing so allows you to introduce special configurations into your static configuration, make it dynamic, etc. .
-首先在我个人看来，「转发效率一定不是问题，而 Shared State 是影响稳定性的最大因素」，为什么这么说？
+## Shared State Improvement Based on Apache APISIX
-因为转发效率可以通过横向扩容去解决，但 Shared State 是所有的节点共享的，所以是至关重要的模块。
+First of all, in my opinion, “The Shared State is the biggest factor in the stability of the feed, which is definitely not an issue.”Why?
-所以在使用 Apache APISIX 后，我们主要针对 Shared State 层面进行了一些调整与优化。
+Because forwarding efficiency can be addressed by scaling laterally, the Shared State is a critical module because it is Shared by all nodes.
-### 优化一：多台机器监听下的 etcd 架构优化
+So after using Apache APISIX, we made a few tweaks and optimizations to focus on the Shared State layer.
-一般公司网关架构中，都会涉及多台机器，有的可能多至几百台，同时每台机器还要顾及 worker 数量。所以当多台机器监控相同 Key 时，etcd 的压力就会比较大，因为 etcd 的其中一个机制是为了保证数据一致性，需要所有事件返回给监听请求后才能处理新请求，当发送缓冲满了后就会丢弃请求。所以当多台机器同时监听时就会导致 etcd 超时运行，提示 Overload 报错等状况。
+### Optimization 1: Optimization of ETCD Architecture with Multiple Machines Listening
Review comment:
```suggestion
### Improvement 1: Optimize ETCD Architecture with Multiple Machines Listening
```
##########
File path: website/blog/2021/09/24/youpaicloud-usercase.md
##########
@@ -1,160 +1,159 @@
---
-title: "Apache APISIX Ingress 为何成为又拍云打造容器网关的新选择？"
-author: "陈卓"
+title: "Why is Apache APISIX Ingress a new option for building container gateways into the UPYUN?"
+author: "Zhuo Chen"
keywords:
- Apache APISIX
- Apache APISIX Ingress
-- 又拍云
-- 容器网关
-description: 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
+- UPYUN
+- Container gateway
+description: This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use.
tags: [User Case]
---
-> 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
-> 作者陈卓，又拍云开发工程师，负责云存储、云处理和网关应用开发。
+> This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use. Chen Zhuo, a cloud development engineer, is responsible for cloud storage, cloud processing, and gateway application development.
<!--truncate-->
-## 项目背景介绍
+## Background
-目前市面上可执行 Ingress 的产品项目逐渐丰富了起来，可选择的范围也扩大了很多。这些产品按照架构大概可分为两类，一类像 k8s Ingress、Apache APISIX Ingress，他们是基于 Nginx、OpenResty 等传统代理器，使用 k8s-Client 和 Golang 去做 Controller。还有一类新兴的用 Golang 语言去实现代理和控制器功能，比如 Traefik。
+The range of Ingress products on the market has grown and the range of options has expanded considerably. These products fall into roughly two architectural categories. One, like K8s Ingress and Apache APISIX Ingress, are based on traditional agents such as Nginx and OpenResty, and use k8s-Client and Golang to do Controller. There is also an emerging class of agents and controllers using the Golang language, such as Traefik.
-又拍云最开始包括现在的大部分业务仍在使用 Ingress-Nginx，整体架构如下。
+Ingress-Nginx is still used by most businesses in UPYUN, including today’s, and the overall architecture is as follows.
Review comment:
```suggestion
Ingress-Nginx is still used by most businesses in UPYUN, including today’s, and the overall architecture is as follows.
```
```suggestion
Ingress-Nginx is still used by most businesses in UPYUN, and the overall architecture is as follows.
```
##########
File path: website/blog/2021/09/24/youpaicloud-usercase.md
##########
@@ -1,160 +1,159 @@
---
-title: "Apache APISIX Ingress 为何成为又拍云打造容器网关的新选择？"
-author: "陈卓"
+title: "Why is Apache APISIX Ingress a new option for building container gateways into the UPYUN?"
+author: "Zhuo Chen"
keywords:
- Apache APISIX
- Apache APISIX Ingress
-- 又拍云
-- 容器网关
-description: 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
+- UPYUN
+- Container gateway
+description: This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use.
tags: [User Case]
---
-> 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
-> 作者陈卓，又拍云开发工程师，负责云存储、云处理和网关应用开发。
+> This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use. Chen Zhuo, a cloud development engineer, is responsible for cloud storage, cloud processing, and gateway application development.
<!--truncate-->
-## 项目背景介绍
+## Background
-目前市面上可执行 Ingress 的产品项目逐渐丰富了起来，可选择的范围也扩大了很多。这些产品按照架构大概可分为两类，一类像 k8s Ingress、Apache APISIX Ingress，他们是基于 Nginx、OpenResty 等传统代理器，使用 k8s-Client 和 Golang 去做 Controller。还有一类新兴的用 Golang 语言去实现代理和控制器功能，比如 Traefik。
+The range of Ingress products on the market has grown and the range of options has expanded considerably. These products fall into roughly two architectural categories. One, like K8s Ingress and Apache APISIX Ingress, are based on traditional agents such as Nginx and OpenResty, and use k8s-Client and Golang to do Controller. There is also an emerging class of agents and controllers using the Golang language, such as Traefik.
-又拍云最开始包括现在的大部分业务仍在使用 Ingress-Nginx，整体架构如下。
+Ingress-Nginx is still used by most businesses in UPYUN, including today’s, and the overall architecture is as follows.
-
+
-下层为数据面 OpenResty。上层 Controller 主要是监听 APIServer 的资源变化，并生成 nginx.conf 配置文件，然后 Reload OpenResty。如果 POD IP 发生变化，可直接通过 HTTP 接口传输给 OpenResty Lua 代码去实现上游 Upstream node 替换。
+The lower layer is data surface OpenResty. The upper Controller listens primarily for resource changes from APIServer and generates `nginx.conf` configuration file, and then Reload OpenResty. If the POD IP changes, the Upstream Upstream node replacement can be transmitted directly to the OpenResty Lua code via the HTTP interface.
-Ingress-Nginx 的扩展能力主要通过 Annotations 去实现，配置文件本身的语法和路由规则都比较简单。可以按照需求进行相关指令配置，同时也支持可拓展 Lua 插件，提高了定制化功能的可操作性。
+The extensibility of Ingress-Nginx is achieved mainly through Annotations, and the configuration file itself has simple syntax and routing rules. Lua can be configured on demand, and the extension of the Lua plug in improves Operability of customization.
-
+
-但 Ingress-Nginx 它也有一些缺点，比如：
+But Ingress-Nginx has some drawbacks, such as:
-- 开发插件时组件依赖复杂，移植性差
-- 语义能力弱
-- 任何一条 Ingress 的修改都需要 Reload，对长链接不友好
+- The development of plug-ins depends on complex components, poor portability
+- Weak semantic ability
+- Any change to Ingress requires Reload, which is unfriendly to long links
-在维护现有逻辑时，上述问题造成了一定程度的困扰，所以我们开始寻找相关容器网关替代品。
+These issues caused some confusion in maintaining the existing logic, so we started looking for alternatives to the relevant container gateways.
-## 调研阶段
+## Research Phase
-在替代 Ingress-Nginx 的选择中，我们主要考量了 Traefik 和 Apache APISIX Ingress。
+In choosing an alternative to Ingress-Nginx, we focused on Traefik and Apache APISIX Ingress.
-Traefik 是云原生模式，配置文件极其简单，采用分布式配置，同时支持多种自动配置发现。不仅支持 k8s、etcd，Golang 的生态语言支持比较好，且开发成本较低，迭代和测试能力较好。但是在其他层面略显不足，比如：
+Traefik is native to the cloud, with extremely simple configuration files, a distributed configuration, and support for a variety of automated configuration discovery. Not only support K8s, ETCD, Golang eco-language support is better, and the development cost is lower, iteration and testing ability is better. But it falls short at other levels, such as:
Review comment:
```suggestion
Traefik is cloud-native, with extremely simple configuration files, a distributed configuration, and support for a variety of automated configuration discovery. Not only support K8s, ETCD, Golang eco-language support is better, and the development cost is lower, iteration and testing ability is better. But it falls short at other levels, such as:
```
##########
File path: website/blog/2021/09/24/youpaicloud-usercase.md
##########
@@ -1,160 +1,159 @@
---
-title: "Apache APISIX Ingress 为何成为又拍云打造容器网关的新选择？"
-author: "陈卓"
+title: "Why is Apache APISIX Ingress a new option for building container gateways into the UPYUN?"
+author: "Zhuo Chen"
keywords:
- Apache APISIX
- Apache APISIX Ingress
-- 又拍云
-- 容器网关
-description: 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
+- UPYUN
+- Container gateway
+description: This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use.
tags: [User Case]
---
-> 本文介绍了又拍云选择 Apache APISIX Ingress 后所带来公司内部网关架构的更新与调整，同时分享了在使用过程中的一些实践场景介绍。
-> 作者陈卓，又拍云开发工程师，负责云存储、云处理和网关应用开发。
+> This article describes the update and adjustment of UPYUN's internal gateway architecture after you selected Apache Apisix Ingress, and shares some of the practice scenarios in use. Chen Zhuo, a cloud development engineer, is responsible for cloud storage, cloud processing, and gateway application development.
<!--truncate-->
-## 项目背景介绍
+## Background
-目前市面上可执行 Ingress 的产品项目逐渐丰富了起来，可选择的范围也扩大了很多。这些产品按照架构大概可分为两类，一类像 k8s Ingress、Apache APISIX Ingress，他们是基于 Nginx、OpenResty 等传统代理器，使用 k8s-Client 和 Golang 去做 Controller。还有一类新兴的用 Golang 语言去实现代理和控制器功能，比如 Traefik。
+The range of Ingress products on the market has grown and the range of options has expanded considerably. These products fall into roughly two architectural categories. One, like K8s Ingress and Apache APISIX Ingress, are based on traditional agents such as Nginx and OpenResty, and use k8s-Client and Golang to do Controller. There is also an emerging class of agents and controllers using the Golang language, such as Traefik.
-又拍云最开始包括现在的大部分业务仍在使用 Ingress-Nginx，整体架构如下。
+Ingress-Nginx is still used by most businesses in UPYUN, including today’s, and the overall architecture is as follows.
-
+
-下层为数据面 OpenResty。上层 Controller 主要是监听 APIServer 的资源变化，并生成 nginx.conf 配置文件，然后 Reload OpenResty。如果 POD IP 发生变化，可直接通过 HTTP 接口传输给 OpenResty Lua 代码去实现上游 Upstream node 替换。
+The lower layer is data surface OpenResty. The upper Controller listens primarily for resource changes from APIServer and generates `nginx.conf` configuration file, and then Reload OpenResty. If the POD IP changes, the Upstream Upstream node replacement can be transmitted directly to the OpenResty Lua code via the HTTP interface.
-Ingress-Nginx 的扩展能力主要通过 Annotations 去实现，配置文件本身的语法和路由规则都比较简单。可以按照需求进行相关指令配置，同时也支持可拓展 Lua 插件，提高了定制化功能的可操作性。
+The extensibility of Ingress-Nginx is achieved mainly through Annotations, and the configuration file itself has simple syntax and routing rules. Lua can be configured on demand, and the extension of the Lua plug in improves Operability of customization.
-
+
-但 Ingress-Nginx 它也有一些缺点，比如：
+But Ingress-Nginx has some drawbacks, such as:
-- 开发插件时组件依赖复杂，移植性差
-- 语义能力弱
-- 任何一条 Ingress 的修改都需要 Reload，对长链接不友好
+- The development of plug-ins depends on complex components, poor portability
+- Weak semantic ability
+- Any change to Ingress requires Reload, which is unfriendly to long links
-在维护现有逻辑时，上述问题造成了一定程度的困扰，所以我们开始寻找相关容器网关替代品。
+These issues caused some confusion in maintaining the existing logic, so we started looking for alternatives to the relevant container gateways.
-## 调研阶段
+## Research Phase
-在替代 Ingress-Nginx 的选择中，我们主要考量了 Traefik 和 Apache APISIX Ingress。
+In choosing an alternative to Ingress-Nginx, we focused on Traefik and Apache APISIX Ingress.
-Traefik 是云原生模式，配置文件极其简单，采用分布式配置，同时支持多种自动配置发现。不仅支持 k8s、etcd，Golang 的生态语言支持比较好，且开发成本较低，迭代和测试能力较好。但是在其他层面略显不足，比如：
+Traefik is native to the cloud, with extremely simple configuration files, a distributed configuration, and support for a variety of automated configuration discovery. Not only support K8s, ETCD, Golang eco-language support is better, and the development cost is lower, iteration and testing ability is better. But it falls short at other levels, such as:
-- 扩展能力弱
-- 不支持 Reload
-- 性能和功能上不如 Nginx（虽然消耗也较低）
+- Weak expansibility
+- Reload is not supported
+- Not as good as Nginx in terms of performance and functionality (though it’s also less expensive)
-它不像 Nginx 有丰富的插件和指令，通过增加一条指令即可解决一个问题，在线上部署时，可能还需在 Traefik 前搭配一个 Nginx。
+Unlike Nginx, which is rich in plugins and instructions, you can solve a problem by adding an instruction, and you may need to pair an Nginx with Traefik when you deploy online.
-综上所述，虽然在操作性上 Traefik 优势尽显，但在扩展能力和运维效率上有所顾虑，最终没有选择 Traefik。
+In summary, although the operational advantages of Traefik, but in the expansion of capacity and operational efficiency concerns, and ultimately did not choose Traefik.
-## 为什么选择 Apache APISIX Ingress
+## Why Apache APISIX Ingress
-### 内部原因
+### Internal Cause
-在公司内部的多个数据中心上目前都存有 Apache APISIX 的网关集群，这些是之前从 Kong 上替换过来的。后来基于 Apache APISIX 的插件系统我们开发了一些内部插件，比如内部权限系统校验、精准速率限制等。
+Apache APISIX’s cluster of gateways, which were previously replaced from Kong, is currently hosted in multiple data centers within the company. Later, based on the Apache APISIX plug-in system, we developed some internal plug-in, such as internal permission system check, precision rate limit and so on.
-### 效率维护层面
+### Efficiency Maintenance Level
Review comment:
```suggestion
### Efficiency of Maintenance
```
##########
File path: website/blog/2021/09/18/xiaodian-usercase.md
##########
@@ -1,144 +1,143 @@
---
-title: "Apache APISIX 助力便利充电创领者小电，实现云原生方案"
-author: "孙冉"
+title: "Apache APISIX helps DIAN to facilitate cloud native solution"
+author: "Ran Sun"
keywords:
- Apache APISIX
-- 小电
-- 云原生
-- 容器化
-description: 本文介绍了国内便利充电创领者——小电通过应用 Apache APISIX，进行公司产品架构的云原生项目搭建的相关背景和实践介绍
+- DIAN
+- Cloud Native
+- container
+description: This article introduces the background and practice of using Apache APISIX to build the cloud native project in DIAN.
tags: [User Case]
---
-> 本文介绍了国内便利充电创领者——小电通过应用 Apache APISIX，进行公司产品架构的云原生项目搭建的相关背景和实践介绍
-> 作者孙冉，运维专家。目前就职于小电平台架构部，主要负责 K8s 集群和 API 网关的相关部署。
+> This article introduces the background and practice of using Apache APISIX to build the cloud native project in DIAN. The author is Sun ran, an expert in operation and maintenance. Currently working in DIAN, mainly responsible for the deployment of K8s cluster and API Gateway.
<!--truncate-->
-## 业务背景
+## Background
-小电作为国内共享充电宝服务平台，目前还处于初创阶段。从运维体系、测试环境等方面来讲，当下产品的业务主要面临了以下几个问题：
+As a domestic service platform for sharing chargers, DIAN is still in its initial stage. From the aspects of operation and maintenance system, test environment and so on, the business of the current product mainly faces the following problems:
-- VM 传统模式部署，利用率低且不易扩展
-- 开发测试资源抢占
-- 多套独立的测试环境（k8s），每次部署维护步骤重复效率低
-- 使用 Nginx 配置管理，运维成本极高
+- Traditional VM mode deployment, low utilization and not easy to expand
+Development test resource preemption
Review comment:
```suggestion
- Sharing resources among Developers and QAs are difficult.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org