yzeng25 commented on code in PR #1741: URL: https://github.com/apache/apisix-website/pull/1741#discussion_r1420150839
########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 Review Comment: ```suggestion > 为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 <!--truncate--> ``` ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 + +综合考虑这几种思路，我们在资源准备充足的同时，通过性能优化，确保系统的稳定性和高可用性，并引导用户进行合理操作。 + +## 问题与目标 + +### 高速公路架构 + + + Review Comment: It is weird to have a section with no text, either try to write something here, or blend it into other sections, i.e. blend it into `### RPC 请求过程`. ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 Review Comment: ```suggestion * 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 * 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 * 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 ``` ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 + +综合考虑这几种思路，我们在资源准备充足的同时，通过性能优化，确保系统的稳定性和高可用性，并引导用户进行合理操作。 + +## 问题与目标 + +### 高速公路架构 + + + +### RPC 请求过程 + +在我们的架构中，例如在 A 省和 B 省之间，需要进行跨网的 RPC 请求。这一请求可能涉及不同省份的微服务架构。每个省份的微服务架构事实上是相同的一套代码，无论是在集群 A 还是集群 B 中，都有 APP1 和 APP2。区别在于，某些岛可能不需要 APP2，比如文件服务在三线城市是不需要的，因此不予部署。在存在跨网需求的情况下，例如需要调用短信服务，那么就是必需的。 + +在 APP1 调用 APP2 时，如果没有路由信息的正常情况下，通常会是本地集群的调用。但是，我们在 APP1 中引入了“高速公路”的 SDK，该 SDK 允许 APP1 在 Dubbo 调用时携带路由信息，而这些路由信息可能有多种方式。因此，我们可以指定请求要到达的地方，比如 B 省。 + +APP1 中的 SDK 会将流量切换到 A 集群的 Dubbo 网关，然后由 Dubbo 网关将 Dubbo 请求转换为 HTTP 请求，再转发到新型网络架构中的 APISIX，随后由 APISIX 将 HTTP 请求传递到目标服务。 + +APISIX 首先解析请求中的一些路由信息，发现需要转到 B 省，然后将请求发送到 B 省的 Dubbo 网关。此时，B 省的 Dubbo 网关获得路由信息、参数、请求、序列化协议等信息后，再次使用 Dubbo 的泛化调用，最终将请求真正发送到 B 省的 APP2 上。 + +这就是一次跨网的 RPC 请求过程。 + +### 为何需要 Dubbo 网关 + +在这一过程中，可能会引发一些问题，例如公司内部可能会对为何需要一个 Dubbo 网关提出疑问。Dubbo 网关的功能在于将协议数据转换成 HTTP，那是否可以省略 Dubbo 网关，直接将请求发送至中心网关呢？ + +关于为何需要 Dubbo 网关，有一些理由需要考虑。首先，Dubbo 网关的作用是将 Dubbo 协议的数据还原为 HTTP 协议。尽管在某些情况下可能会节省一个步骤，但在这一步骤中，有一些 IP 收敛和功能收敛需要完成。这些功能与第一个版本的特性有关。此外，Dubbo 网关的实现存在一些问题，它是一个 Java 实现 的 Spring Boot 程序，并且引入了 Dubbo SDK。当 APP 的请求切换过来时，在没有相应 provider 的情况下，Dubbo 默认返回"Service not found"，类似于 HTTP 的"404 not found"。 + +为了解决这个问题，我们增强了 Dubbo，对源码进行了定制化开发，即可以转发请求，并将其成果贡献给了 Dubbo 社区。 + +### 总体架构中的网关 + +总体架构中包括三个网关，其中包括中心网关和两个 Dubbo 网关。中心网关采用了 APISIX，在第一个版本中已经使用过。主要的使用场景是执行路由（反向代理），根据 HTTP Header 信息将请求转发至不同网络的集群。使用 APISIX 过程中，也遇到了 Dashboard 相关的一些问题，例如，将测试环境的路由配置导出到生产环境，Dashboard 会报错。总体来说，这里对APISIX 的使用，就是普通的网关场景。 + +## 跨网 RPC 性能分析 + + + +* 客户端：客户端已整合 Dubbo 的 SDK，该 SDK 的行为包括生成代理、方法调用、参数序列化以及发起网络请求等。当前情况下，这一组件难以更改，因为我们采用的是统一的 Dubbo，因此 SDK 的行为不会发生变化。 +* 本地网络：在本地集群中，存在一个切流量的动作，因此本地网络会涉及 Dubbo 的传输。这涉及 I/O 模型、Dubbo 协议、数据格式（如参数）等。Dubbo 使用了基于 Netty 的异步非阻塞模型的 I/O 模型，对于 Dubbo 来说，使用这种 I/O 模型本身是没有问题的，符合其性能要求。而 Dubbo 协议的数据包采用了简洁而灵活的结构，没有冗余的头部信息，而是根据需求灵活携带必要的数据，以二进制格式进行高效的编码和解码。 +* Dubbo 网关：在这一过程中，Dubbo 网关充当流量转发角色，不负责业务处理。在这个情境中，牵涉到消息接收的 I/O 模型：是选择阻塞式接收消息，还是采用异步方式呢？同时也牵涉到数据包的解析：这一过程会有一些消耗，因为 Dubbo 数据需要转化成 HTTP 数据，其中会涉及到一系列序列化和反序列化的动作；此外，还有自定义的扩展，即基于本地集群还包括一些公共特性，如限流、鉴权等。 +* 公网网络：网关请求处理完成后，将通过 HTTP 转发到 APISIX 的中心网关，转出去的时候通过了 HttpClient。因为 HttpClient 在默认情况下是阻塞式的，所以性能稍显不足。选择自研网关而非使用现有解决方案的原因是在第一个版本中，更注重如何迅速实现并投入使用，而性能优化则作为后续工作。这里的问题是，我们的 Dubbo 协议转换为 HTTP 的行为是自定义的，目前没有任何网关能够支持这种自定义行为。因此，我们采用基于 Netty 的 Java 应用进行自研。在这个公网端也涉及一些 I/O 模型、HTTP 协议、数据格式等问题。我们选择了APISIX来解决这些问题，因为它的性能相对较好。 +* 中心网关：在整个架构中，中心网关 APISIX 扮演着关键角色，特别是在公司级公共功能方面。它负责处理流量，具备高效的转发效率和公共扩展。在新型网络架构下，中心网关成为单点，因此我们需要关注单点故障等问题。我们目前的立场是将公共扩展看作公司级公共功能，可以在这一层面上进行一些扩展工作，如拦截流量并执行相应操作。 APISIX 插件式的特性使我们能够对其进行其他一些扩展，例如，我们在审计方面已经做了很多工作。在审计时，我们不鼓励无序的跨域调用，而是通过控制台注册信息（如应用名、责任人等）校验后，再进行审计。在中心网关中，我们也处理了单点故障的问题，进行了故障隔离和资源隔离。我们对稳定性和扩展性的要求高，而 APISIX 很好地满足了我们的需求。 +* 目标集群：中心网关请求转发后，与之前的本地网络相似。因为只是一个中点调用，形式有所不同而已。由于经过一系列操作，Dubbo 数据包此时已通过 HTTP 封装，解析出来后，并不能进行点对点调用，仍需使用 Dubbo 的泛化调用，需要了解接口名、参数等，然后进行调用，调用后再按原路返回。 Review Comment: unordered list items often come after a paragraph, you can consider add some text before line 104. ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 Review Comment: ```suggestion * 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 * 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 * 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 ``` ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 + +综合考虑这几种思路，我们在资源准备充足的同时，通过性能优化，确保系统的稳定性和高可用性，并引导用户进行合理操作。 + +## 问题与目标 + +### 高速公路架构 + + + Review Comment: It is weird to have a section with no text, either try to write something here, or blend it into other sections, i.e. blend it into `### RPC 请求过程`. ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 Review Comment: ```suggestion > 为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 <!--truncate--> ``` ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 + +综合考虑这几种思路，我们在资源准备充足的同时，通过性能优化，确保系统的稳定性和高可用性，并引导用户进行合理操作。 + +## 问题与目标 + +### 高速公路架构 + + + +### RPC 请求过程 + +在我们的架构中，例如在 A 省和 B 省之间，需要进行跨网的 RPC 请求。这一请求可能涉及不同省份的微服务架构。每个省份的微服务架构事实上是相同的一套代码，无论是在集群 A 还是集群 B 中，都有 APP1 和 APP2。区别在于，某些岛可能不需要 APP2，比如文件服务在三线城市是不需要的，因此不予部署。在存在跨网需求的情况下，例如需要调用短信服务，那么就是必需的。 + +在 APP1 调用 APP2 时，如果没有路由信息的正常情况下，通常会是本地集群的调用。但是，我们在 APP1 中引入了“高速公路”的 SDK，该 SDK 允许 APP1 在 Dubbo 调用时携带路由信息，而这些路由信息可能有多种方式。因此，我们可以指定请求要到达的地方，比如 B 省。 + +APP1 中的 SDK 会将流量切换到 A 集群的 Dubbo 网关，然后由 Dubbo 网关将 Dubbo 请求转换为 HTTP 请求，再转发到新型网络架构中的 APISIX，随后由 APISIX 将 HTTP 请求传递到目标服务。 + +APISIX 首先解析请求中的一些路由信息，发现需要转到 B 省，然后将请求发送到 B 省的 Dubbo 网关。此时，B 省的 Dubbo 网关获得路由信息、参数、请求、序列化协议等信息后，再次使用 Dubbo 的泛化调用，最终将请求真正发送到 B 省的 APP2 上。 + +这就是一次跨网的 RPC 请求过程。 + +### 为何需要 Dubbo 网关 + +在这一过程中，可能会引发一些问题，例如公司内部可能会对为何需要一个 Dubbo 网关提出疑问。Dubbo 网关的功能在于将协议数据转换成 HTTP，那是否可以省略 Dubbo 网关，直接将请求发送至中心网关呢？ + +关于为何需要 Dubbo 网关，有一些理由需要考虑。首先，Dubbo 网关的作用是将 Dubbo 协议的数据还原为 HTTP 协议。尽管在某些情况下可能会节省一个步骤，但在这一步骤中，有一些 IP 收敛和功能收敛需要完成。这些功能与第一个版本的特性有关。此外，Dubbo 网关的实现存在一些问题，它是一个 Java 实现 的 Spring Boot 程序，并且引入了 Dubbo SDK。当 APP 的请求切换过来时，在没有相应 provider 的情况下，Dubbo 默认返回"Service not found"，类似于 HTTP 的"404 not found"。 + +为了解决这个问题，我们增强了 Dubbo，对源码进行了定制化开发，即可以转发请求，并将其成果贡献给了 Dubbo 社区。 + +### 总体架构中的网关 + +总体架构中包括三个网关，其中包括中心网关和两个 Dubbo 网关。中心网关采用了 APISIX，在第一个版本中已经使用过。主要的使用场景是执行路由（反向代理），根据 HTTP Header 信息将请求转发至不同网络的集群。使用 APISIX 过程中，也遇到了 Dashboard 相关的一些问题，例如，将测试环境的路由配置导出到生产环境，Dashboard 会报错。总体来说，这里对APISIX 的使用，就是普通的网关场景。 + +## 跨网 RPC 性能分析 + + + +* 客户端：客户端已整合 Dubbo 的 SDK，该 SDK 的行为包括生成代理、方法调用、参数序列化以及发起网络请求等。当前情况下，这一组件难以更改，因为我们采用的是统一的 Dubbo，因此 SDK 的行为不会发生变化。 +* 本地网络：在本地集群中，存在一个切流量的动作，因此本地网络会涉及 Dubbo 的传输。这涉及 I/O 模型、Dubbo 协议、数据格式（如参数）等。Dubbo 使用了基于 Netty 的异步非阻塞模型的 I/O 模型，对于 Dubbo 来说，使用这种 I/O 模型本身是没有问题的，符合其性能要求。而 Dubbo 协议的数据包采用了简洁而灵活的结构，没有冗余的头部信息，而是根据需求灵活携带必要的数据，以二进制格式进行高效的编码和解码。 +* Dubbo 网关：在这一过程中，Dubbo 网关充当流量转发角色，不负责业务处理。在这个情境中，牵涉到消息接收的 I/O 模型：是选择阻塞式接收消息，还是采用异步方式呢？同时也牵涉到数据包的解析：这一过程会有一些消耗，因为 Dubbo 数据需要转化成 HTTP 数据，其中会涉及到一系列序列化和反序列化的动作；此外，还有自定义的扩展，即基于本地集群还包括一些公共特性，如限流、鉴权等。 +* 公网网络：网关请求处理完成后，将通过 HTTP 转发到 APISIX 的中心网关，转出去的时候通过了 HttpClient。因为 HttpClient 在默认情况下是阻塞式的，所以性能稍显不足。选择自研网关而非使用现有解决方案的原因是在第一个版本中，更注重如何迅速实现并投入使用，而性能优化则作为后续工作。这里的问题是，我们的 Dubbo 协议转换为 HTTP 的行为是自定义的，目前没有任何网关能够支持这种自定义行为。因此，我们采用基于 Netty 的 Java 应用进行自研。在这个公网端也涉及一些 I/O 模型、HTTP 协议、数据格式等问题。我们选择了APISIX来解决这些问题，因为它的性能相对较好。 +* 中心网关：在整个架构中，中心网关 APISIX 扮演着关键角色，特别是在公司级公共功能方面。它负责处理流量，具备高效的转发效率和公共扩展。在新型网络架构下，中心网关成为单点，因此我们需要关注单点故障等问题。我们目前的立场是将公共扩展看作公司级公共功能，可以在这一层面上进行一些扩展工作，如拦截流量并执行相应操作。 APISIX 插件式的特性使我们能够对其进行其他一些扩展，例如，我们在审计方面已经做了很多工作。在审计时，我们不鼓励无序的跨域调用，而是通过控制台注册信息（如应用名、责任人等）校验后，再进行审计。在中心网关中，我们也处理了单点故障的问题，进行了故障隔离和资源隔离。我们对稳定性和扩展性的要求高，而 APISIX 很好地满足了我们的需求。 +* 目标集群：中心网关请求转发后，与之前的本地网络相似。因为只是一个中点调用，形式有所不同而已。由于经过一系列操作，Dubbo 数据包此时已通过 HTTP 封装，解析出来后，并不能进行点对点调用，仍需使用 Dubbo 的泛化调用，需要了解接口名、参数等，然后进行调用，调用后再按原路返回。 + +## 优化目标：提高吞吐量 + + + +性能压测是在第一版架构上线之前进行的，目的是深入了解跨网的 RPC 架构可能存在的瓶颈。若没有进行性能压测，缺乏数据支撑，我们将无法确定系统的底线。因此，我们经过一系列性能压测，以更好地优化我们的系统。 + +压测脚本与请求量实际上存在关联，例如，请求的数据大小逐渐增大，从 2KB 到 8KB。在进行压测时，我们设定了一些前置条件，如当 CPU 占用率达到 80% 左右，磁盘开关达到 80% 左右时，即停止压测。这时，我们可以观察性能表现。通过设置前置条件和逐渐增加数据，我们能够查看最终的性能指标。我们发现，瓶颈主要存在于带宽，即在带宽差异的情况下，性能差异最为显著。尤其对于不同的岛端，由于每个岛端具有不同的带宽，因此需要与每个岛端的运维机构进行协调。例如，上海可能有 30 兆的带宽，而山西可能有 50 兆的带宽，显然，山西的表现更为出色。 + +为何我们认为带宽（吞吐量）是瓶颈呢？因为我们修改网关和 CPU 的参数重新进行压力测试，但是得到的结果和原本的相差不大，所以排除了这些可能的影响因素。而在网络上存在数据过载时，性能受到限制。结合前文分析，我们认为流量的瓶颈在于带宽（吞吐量）。 + +综合之前的分析，我们认为问题一是流量网关，问题二是需要优化 HTTP 协议。 + +## 网关优化实践 + +### 自研 Dubbo 网关的问题 + + + +* I/O 模式：将 Dubbo 转换为 HTTP 实际上是采用了一种隧道机制。由于网络的复杂性，我们选择使用 HTTP 来承载这个隧道，通过这个隧道将数据传输到目的地。一旦到达目的地，我们再解开。隧道机制的一个不太理想的方面是，在这个隧道中需要转换协议的数据，尤其是在到达 Dubbo 网关时。而我们自行编写的一些组件，性能可能也无法达到最佳水平。 +* 两次序列化：在进行两次序列化时，涉及一个 JavaBeanDescriptor 对象，这是 Dubbo 中的一个 API。在进行序列化和反序列化时，由于业务对象在参数中无法直接进行序列化，因此需要在 SDK 中进行封装，将 JavaBean 转换为 Dubbo 内部的一种结构，在到达目的地后再进行解封操作。这样的处理方式才能够确保参数中的业务对象能够顺利地进行序列化和反序列化。此外，还有一层问题是 Dubbo 本身采用的序列化方式，即使用 Hessian2。进行两次序列化时，使用 Hessian2 可能对性能造成相当大的消耗。 +* 其他业务扩展：Dubbo 网关需要一些业务扩展，不仅仅是在中心网关上，本地集群网关也是必要的。另外，我们还需要一些即插即用的功能，例如限流等。 + +目前，我们选择使用 APISIX 来替代自己研发的 Dubbo 网关。因为我们自行开发的网关存在一些潜在问题，所以我们并不打算在这方面投入过多资源，而是计划引入现成的专业解决方案并立即投入使用，以节省开发资源，提高效率。 + +### 选择 APISIX 的原因 + +* 社区活跃，代码质量高：APISIX 开源社区的活跃度极高，代码质量有一定保障。 +* 架构合理，高性能：APISIX 是基于高性能的 OpenResty 开发的，从架构和设计角度对性能追求极致，因此可以满足我们对网关性能的基本要求。 +* 高扩展性：APISIX 具有出色的扩展性，能够满足我们的自定义需求。简而言之，我们既希望享有类似 NGINX 的高性能，又希望可以根据需要扩展功能。 + +## 协议优化实践 + +协议方面，我们尝试使用了 Dubbo 协议作为隧道协议，替换掉了 HTTP 协议。 + + + +### 优点 + +* 使用 APISIX 网关，避免协议转化：由于我们的网关采用了 APISIX 网关，我希望 Dubbo能够直线转为 Dubbo，这样可以避免两次序列化，也能规避那些主设施的调用。像刚才提到的 HttpClient 计划，采用单线程同步调用的方式，要等待调用完成后才继续执行后续操作。在高并发情况下，这种方式是非常低效的。随着我们业务量的不断增加，之前使用的其他方案也逐渐显得不够用，因此需要进行更新。 +* 二进制协议：总体而言，二进制协议相较于文本更为出色，也是相对经典的一种协议。 +* 避免无效头部：HTTP 的各种客户端可能会携带一些多余的 Header 信息，而使用 Dubbo 协议能避免携带这些无效的冗余信息。 +* 长连接多路复用：APISIX 可以实现多路复用。长连接可以将很多请求一起发送，而HTTP 虽然可以将很多请求一直发出去，但必须等待一个请求回来后，才能继续接下来的请求。HTTP 和 Dubbo 在并发效率上会有一些差异。 +* 四层协议扩展框架：APISIX 实现了 xRPC 四层协议扩展框架，允许开发人员自定义特定于应用程序的协议。基于 xRPC 框架，APISIX 可以提供几种主要应用协议的代理实现，用户还可以基于该框架支持自己私有的基于 TCP 的应用协议，使其具有类似于 HTTP 协议代理的精确粒度和更高级别的 7 层控制。通过使用 APISIX 的 xRPC 扩展，我们成功地增加了对 Dubbo 协议的直接转发功能，从而实现了全链路 Dubbo 协议传输。 + +### 缺点 + +* 穿透性不足：Dubbo 协议存在一个明显的问题，即其穿透性不足。毕竟 Dubbo 是一种私有协议，而我们的网络可能会经过许多物理设备，除了软件层面的网关（APISIX/NGINX/WAF），还涉及一些物理设备，这实际上可能会遇到一些阻碍。 +* 必须读出全部内容：HTTP 协议可以只读取 Header 信息到网关内存，且 Body 以零拷贝的形式直接转发，但是 Dubbo 协议无法做到这一点。 Review Comment: ditto ########## blog/zh/blog/2023/12/08/zhengcaiyun-uses-apisix.md: ########## @@ -0,0 +1,239 @@ +--- +title: "政采云 APISIX 优化跨网 RPC 性能实践" +authors: + - name: 王晓彬 + title: Author + - name: Jing Yan + title: Technical Writer + url: https://github.com/JYan00 + image_url: https://github.com/JYan00.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 政采云 +description: 政采云借力 APISIX 显著提升了网关性能，减少了协议转换的成本，并实现了中间件层面的收敛。 +tags: [Case Studies] +image: https://static.apiseven.com/uploads/2023/12/08/XDJDiILW_Zheng.jpeg +--- + +> 作者：王晓彬，Apache Dubbo Commiter、政采云资深开发工程师。 +<!--truncate--> + +为解决数据跨网问题，政采云搭建了一条基于 Dubbo 的“高速公路”，同时采用了 APISIX 作为中心网关，为网络路由、公共特性提供支持。本文将重点介绍政采云“高速公路”工程建设中如何优化网关和协议的性能以应对挑战。 + +## 背景介绍 + + + +政采云平台是一个政府采购专属平台，为各级政府部门和国有企业提供支持。从网络架构的角度来看，政采云平台是一个集合了公有云、私有云和政务云的混合云网络。 + +例如，浙江政府部门在政采云平台上进行采购时，实际上是在云平台上进行操作。该云平台是部署在浙江的一个微服务网络体系，是公司自行部署和运维的平台。除了浙江，还有广西等六七个地区都在云平台上进行采购。 + +此外，我们还会为一些分支机构提供服务，例如设立在各个省份的分公司。这些分公司可能有着各自的需求，根据不同省份的行政区划部署同一套微服务框架，但部署在当地环境。同时，一些其他非区划机构，如银行、军队等可能也会选择私有部署。 + +以上的这些微服务，就构成了混合云网络的一部分。所以对于业务来说，跨网数据传输是一个常见的需求场景。 + +为了满足这种需求，政采云“高速公路”工程于 2022 年底启动，旨在整合现有的网络传输方案，提供一致、便捷和高速的跨网业务体验。随着跨网方案整合的推进，公司的跨网流量越来越多地流向了新型基础设施——政采云“高速公路”工程。 + +## “高速公路”工程 + +“高速公路”工程一共分为三个阶段。第一阶段是基于 Dubbo 的“高速公路”工程落地；第二阶段则将之前的一些方案整合到新方案中；第三阶段将解决前两个阶段产生的问题，并进行进一步的优化。 + +第一阶段基于 Dubbo 构建了一个新型的架构，其中心是 APISIX。每个节点代表一个岛端，即不同的省或其他区划。云平台其实也是一个特殊的岛端，我们的平台会涉及多个岛端，形成一个混合云网络。 + + + +为什么要采用这个星型的网络架构呢？因为跨网的需求从一开始就存在，在政采云创立初期，业务就会点对点跨网传输数据，然后逐渐形成了网状架构。我们之前有多个与跨网相关的项目或方案，有基础平台提供的，也有业务自行开发的。现在这个“高速公路”项目的目的，是将它们整合在一起，提供统一的技术底座，降低各自运维和跑各种流程的成本，让业务方能聚焦在自己的业务上，也能集成更多的公共特性。如果每个业务都自己开发，在功能上会有一些限制，因为它们只关注于各自特定的领域。与此相反，如果将业务开放供他人使用，又可能会面临多种问题，比如需要支持定制那些自己业务不关心的特性。 + +“高速公路”的星型架构也是整合的结果。在之前的网状结构中，每个岛段之间的互联需要经过一系列流程。比如，我们需要和山西和上海这两个省份的运维沟通交流，让他们开一些端口，基于他们的端口进行服务部署后，再实现网络交互。这样一来，网状结构的线很多，也很复杂。如果一共有 n 个岛，可能就有 n 个平方的线。而这个星型架构的好处在于它简洁，相较于之前的网状结构，避免了两两互联的复杂性。 + +## 挑战 + +“高速公路”方案得到了公司的大力支持，在 2023 年上半年通过新业务的试点后，下半年开始陆续迁移历史跨网方案的业务。从监控中，我们感受到了来自流量的压力。具体表现为： + +* 心跳应用告警频繁发生：我们在每个路段都部署了一个心跳应用，以确保高速公路的稳定性。这个应用是通用的，负责网络互通，一旦出现问题就会触发告警。举例来说，如果在某个时间段内请求变得缓慢，一次请求超过 1 秒，我们就会收到告警，从而意识到存在问题。而在监控中，心跳应用告警频繁发生。 +* 监控指标如响应时间（RT）和吞吐量下降：我们还使用了 Prometheus 的格式化界面 BRAF。在该界面上，一些关于响应量和吞吐量的曲线明显有下降的趋势。 + +这两个方面的压力随着我们历史方案切入“高速公路”后，随着流量的增加而逐渐显现。 + + + +为了确保业务的稳定性并提高用户体验，我们采取了各种优化措施。总体而言，我们主要探索了三种思路： + +* 资源优化：这种优化思路相对较简单，主要涉及资源的重新调配。具体措施包括对单点的中心网关和 Dubbo 网关进行资源隔离，以最小化故障对系统的影响。此外，通过直接增加 pod 、升级 CPU 等方式，也能有效缓解压力。这样可以确保在资源方面有足够的储备，以满足系统在高负载情况下的需求。然而，这种方法并不能从根本上解决问题，因为如果架构存在短板，某些资源上做不到能水平扩展，那么在一定条件下就会出现故障，有可能不能在短时间内解决。 +* 性能优化：这一思路需要在架构层面进行深入优化，以尽可能填补木桶模型的短板。这是非常重要的，因为只有通过性能的最大化利用，才能实现系统的水平扩展。 +* 最佳实践引导：每个框架都有一些缺陷或不合适的地方，我们需要引导用户，避免一些可能引起问题的操作。如果用户执意采取某些操作，我们也需要给出合理的建议。例如，基于跨网的 Dubbo 框架默认支持大流量但小请求的并发，基于 Dubbo 的高速公路也有相同的特性。如果用户基于 Dubbo 传输大文件，可能会给我们造成较大的压力，因此我们需要给出建议，让他们用其他的方法去传输。 + +综合考虑这几种思路，我们在资源准备充足的同时，通过性能优化，确保系统的稳定性和高可用性，并引导用户进行合理操作。 + +## 问题与目标 + +### 高速公路架构 + + + +### RPC 请求过程 + +在我们的架构中，例如在 A 省和 B 省之间，需要进行跨网的 RPC 请求。这一请求可能涉及不同省份的微服务架构。每个省份的微服务架构事实上是相同的一套代码，无论是在集群 A 还是集群 B 中，都有 APP1 和 APP2。区别在于，某些岛可能不需要 APP2，比如文件服务在三线城市是不需要的，因此不予部署。在存在跨网需求的情况下，例如需要调用短信服务，那么就是必需的。 + +在 APP1 调用 APP2 时，如果没有路由信息的正常情况下，通常会是本地集群的调用。但是，我们在 APP1 中引入了“高速公路”的 SDK，该 SDK 允许 APP1 在 Dubbo 调用时携带路由信息，而这些路由信息可能有多种方式。因此，我们可以指定请求要到达的地方，比如 B 省。 + +APP1 中的 SDK 会将流量切换到 A 集群的 Dubbo 网关，然后由 Dubbo 网关将 Dubbo 请求转换为 HTTP 请求，再转发到新型网络架构中的 APISIX，随后由 APISIX 将 HTTP 请求传递到目标服务。 + +APISIX 首先解析请求中的一些路由信息，发现需要转到 B 省，然后将请求发送到 B 省的 Dubbo 网关。此时，B 省的 Dubbo 网关获得路由信息、参数、请求、序列化协议等信息后，再次使用 Dubbo 的泛化调用，最终将请求真正发送到 B 省的 APP2 上。 + +这就是一次跨网的 RPC 请求过程。 + +### 为何需要 Dubbo 网关 + +在这一过程中，可能会引发一些问题，例如公司内部可能会对为何需要一个 Dubbo 网关提出疑问。Dubbo 网关的功能在于将协议数据转换成 HTTP，那是否可以省略 Dubbo 网关，直接将请求发送至中心网关呢？ + +关于为何需要 Dubbo 网关，有一些理由需要考虑。首先，Dubbo 网关的作用是将 Dubbo 协议的数据还原为 HTTP 协议。尽管在某些情况下可能会节省一个步骤，但在这一步骤中，有一些 IP 收敛和功能收敛需要完成。这些功能与第一个版本的特性有关。此外，Dubbo 网关的实现存在一些问题，它是一个 Java 实现 的 Spring Boot 程序，并且引入了 Dubbo SDK。当 APP 的请求切换过来时，在没有相应 provider 的情况下，Dubbo 默认返回"Service not found"，类似于 HTTP 的"404 not found"。 + +为了解决这个问题，我们增强了 Dubbo，对源码进行了定制化开发，即可以转发请求，并将其成果贡献给了 Dubbo 社区。 + +### 总体架构中的网关 + +总体架构中包括三个网关，其中包括中心网关和两个 Dubbo 网关。中心网关采用了 APISIX，在第一个版本中已经使用过。主要的使用场景是执行路由（反向代理），根据 HTTP Header 信息将请求转发至不同网络的集群。使用 APISIX 过程中，也遇到了 Dashboard 相关的一些问题，例如，将测试环境的路由配置导出到生产环境，Dashboard 会报错。总体来说，这里对APISIX 的使用，就是普通的网关场景。 + +## 跨网 RPC 性能分析 + + + +* 客户端：客户端已整合 Dubbo 的 SDK，该 SDK 的行为包括生成代理、方法调用、参数序列化以及发起网络请求等。当前情况下，这一组件难以更改，因为我们采用的是统一的 Dubbo，因此 SDK 的行为不会发生变化。 +* 本地网络：在本地集群中，存在一个切流量的动作，因此本地网络会涉及 Dubbo 的传输。这涉及 I/O 模型、Dubbo 协议、数据格式（如参数）等。Dubbo 使用了基于 Netty 的异步非阻塞模型的 I/O 模型，对于 Dubbo 来说，使用这种 I/O 模型本身是没有问题的，符合其性能要求。而 Dubbo 协议的数据包采用了简洁而灵活的结构，没有冗余的头部信息，而是根据需求灵活携带必要的数据，以二进制格式进行高效的编码和解码。 +* Dubbo 网关：在这一过程中，Dubbo 网关充当流量转发角色，不负责业务处理。在这个情境中，牵涉到消息接收的 I/O 模型：是选择阻塞式接收消息，还是采用异步方式呢？同时也牵涉到数据包的解析：这一过程会有一些消耗，因为 Dubbo 数据需要转化成 HTTP 数据，其中会涉及到一系列序列化和反序列化的动作；此外，还有自定义的扩展，即基于本地集群还包括一些公共特性，如限流、鉴权等。 +* 公网网络：网关请求处理完成后，将通过 HTTP 转发到 APISIX 的中心网关，转出去的时候通过了 HttpClient。因为 HttpClient 在默认情况下是阻塞式的，所以性能稍显不足。选择自研网关而非使用现有解决方案的原因是在第一个版本中，更注重如何迅速实现并投入使用，而性能优化则作为后续工作。这里的问题是，我们的 Dubbo 协议转换为 HTTP 的行为是自定义的，目前没有任何网关能够支持这种自定义行为。因此，我们采用基于 Netty 的 Java 应用进行自研。在这个公网端也涉及一些 I/O 模型、HTTP 协议、数据格式等问题。我们选择了APISIX来解决这些问题，因为它的性能相对较好。 +* 中心网关：在整个架构中，中心网关 APISIX 扮演着关键角色，特别是在公司级公共功能方面。它负责处理流量，具备高效的转发效率和公共扩展。在新型网络架构下，中心网关成为单点，因此我们需要关注单点故障等问题。我们目前的立场是将公共扩展看作公司级公共功能，可以在这一层面上进行一些扩展工作，如拦截流量并执行相应操作。 APISIX 插件式的特性使我们能够对其进行其他一些扩展，例如，我们在审计方面已经做了很多工作。在审计时，我们不鼓励无序的跨域调用，而是通过控制台注册信息（如应用名、责任人等）校验后，再进行审计。在中心网关中，我们也处理了单点故障的问题，进行了故障隔离和资源隔离。我们对稳定性和扩展性的要求高，而 APISIX 很好地满足了我们的需求。 +* 目标集群：中心网关请求转发后，与之前的本地网络相似。因为只是一个中点调用，形式有所不同而已。由于经过一系列操作，Dubbo 数据包此时已通过 HTTP 封装，解析出来后，并不能进行点对点调用，仍需使用 Dubbo 的泛化调用，需要了解接口名、参数等，然后进行调用，调用后再按原路返回。 + +## 优化目标：提高吞吐量 + + + +性能压测是在第一版架构上线之前进行的，目的是深入了解跨网的 RPC 架构可能存在的瓶颈。若没有进行性能压测，缺乏数据支撑，我们将无法确定系统的底线。因此，我们经过一系列性能压测，以更好地优化我们的系统。 + +压测脚本与请求量实际上存在关联，例如，请求的数据大小逐渐增大，从 2KB 到 8KB。在进行压测时，我们设定了一些前置条件，如当 CPU 占用率达到 80% 左右，磁盘开关达到 80% 左右时，即停止压测。这时，我们可以观察性能表现。通过设置前置条件和逐渐增加数据，我们能够查看最终的性能指标。我们发现，瓶颈主要存在于带宽，即在带宽差异的情况下，性能差异最为显著。尤其对于不同的岛端，由于每个岛端具有不同的带宽，因此需要与每个岛端的运维机构进行协调。例如，上海可能有 30 兆的带宽，而山西可能有 50 兆的带宽，显然，山西的表现更为出色。 + +为何我们认为带宽（吞吐量）是瓶颈呢？因为我们修改网关和 CPU 的参数重新进行压力测试，但是得到的结果和原本的相差不大，所以排除了这些可能的影响因素。而在网络上存在数据过载时，性能受到限制。结合前文分析，我们认为流量的瓶颈在于带宽（吞吐量）。 + +综合之前的分析，我们认为问题一是流量网关，问题二是需要优化 HTTP 协议。 + +## 网关优化实践 + +### 自研 Dubbo 网关的问题 + + + +* I/O 模式：将 Dubbo 转换为 HTTP 实际上是采用了一种隧道机制。由于网络的复杂性，我们选择使用 HTTP 来承载这个隧道，通过这个隧道将数据传输到目的地。一旦到达目的地，我们再解开。隧道机制的一个不太理想的方面是，在这个隧道中需要转换协议的数据，尤其是在到达 Dubbo 网关时。而我们自行编写的一些组件，性能可能也无法达到最佳水平。 +* 两次序列化：在进行两次序列化时，涉及一个 JavaBeanDescriptor 对象，这是 Dubbo 中的一个 API。在进行序列化和反序列化时，由于业务对象在参数中无法直接进行序列化，因此需要在 SDK 中进行封装，将 JavaBean 转换为 Dubbo 内部的一种结构，在到达目的地后再进行解封操作。这样的处理方式才能够确保参数中的业务对象能够顺利地进行序列化和反序列化。此外，还有一层问题是 Dubbo 本身采用的序列化方式，即使用 Hessian2。进行两次序列化时，使用 Hessian2 可能对性能造成相当大的消耗。 +* 其他业务扩展：Dubbo 网关需要一些业务扩展，不仅仅是在中心网关上，本地集群网关也是必要的。另外，我们还需要一些即插即用的功能，例如限流等。 Review Comment: ditto -- 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]
