Apache APISIX 在移动云的应用

ApacheCon Asia 2021 在北京时间 8 月 6 日正式开始，在 ASF 中有多个项目与 API、微服务相关，好比 Apache APISIX、Apache Dubbo 等。在 ApacheCon Asia 2021 —— API / 微服务专题中，你们不只能够了解有关 API、微服务的前沿技术，也会学习到这些 Apache 项目的最佳实践，来自中国移动云能力中心的陈焱山将在大会上分享《Apache APISIX 在移动云对象存储 EOS 的应用与实践》。

最近，咱们有幸采访了中国移动云能力中心的陈焱山，在采访中咱们了解到中国移动公有云建设发展演进历程，明白了为何移动云为何选择 Apache APISIX 做为负载均衡网关，而且知晓移动云后续的发展规划。

中国移动云能力中心，对外也称“中移（苏州）软件技术有限公司”，是中国移动通讯集团 2014 年注资成立的全资子公司，公司定位为云设施构建者、云服务提供者、云生态汇聚者，三年内推进中国移动云业务市场份额进入国内云服务商第一阵营。自 2019 年中国移动启动“云改”战略以来，做为助力中国移动 5G+AICDE 战略落地的基石，移动云通过长足发展，已完成覆盖全国的“N+31+X”总体资源布局。同时，移动云积极打造“云网、云数、云边、云智” 差别化特点优点，在业务体量、产品种类、可售资源等方面均实现飞跃式提高。“移动云”品牌也充分发挥了云网一体、贴身服务、随心定制、安全可控的优点，打造 5G 时代“你身边的智慧云”，为行业数字化转型发展提供“强引擎”。

Q：很是高兴今天能跟陈焱山老师进行交流，能够麻烦您作下自我介绍，简单陈述下您如今的工做内容吗？

你们好，我叫陈焱山，目前就任于中国移动云能力中心 IaaS 产品部，主要负责分布式对象存储软件的总体架构设计与开发工做，负责对象存储、API 网关的技术选型与方案落地实践工做。在分布式存储领域这块仍是有比较丰富的经验的，深度参与了移动云的建设发展历程。

当前，我主要关注于对象存储在交互编排、流量治理等方面的能力，促进咱们第四代对象存储产品进一步实现架构升级。同时，咱们也但愿可以基于 Ingress Controller 的能力，来实现统一流量访问入口，并包括灰度发布、流量管控等功能。这些是咱们当前正在作的一些工做。

Q：您说的这些内容多少都与 Apache APISIX 有关联，您在今年 ApacheCon 亚洲大会上也有一场分享，想问下您会带来哪些精彩分享?

首先，我会给你们介绍一下咱们移动云对象存储产品 EOS 的总体发展和演进过程，同时重点介绍咱们是如何基于 Apache APISIX 实现对象存储流量治理的，作了哪些工做，又是如何进行实践。最后对咱们将来的架构演进作了一些规划说明。咱们对象存储的总体演进过程主要经历了以下四个阶段，对于 Apache APISIX 引入主要是从第三代开始引入的，确实给咱们产品在架构上带来不少便利。

• 第一代：从 2008 年开始投入自研，同年发布了咱们的第一代对象对象存储产品；
• 第二代：主要基于开源 Ceph 实现深度定制，实现了接口的标准化，支持 AWS 的 S3 标准接口和 Openstack 的 Swift 接口协议，同时丰富了大量的功能特性；
• 第三代：主要解决内部一些专业公司海量数据上云需求。在第三代产品中，咱们在性能上实现了一个新的跨越，单一存储桶同时支持百 PB 容量和百亿对象规模，入口带宽达到 Tb/s 级。同时，咱们还引入了不少子模块，包括七层流量治理以及可观测系统。七层流量治理模块是基于 Apache APISIX 实现的，主要用于实现业务流量的分离治理；可观测系统则主要是实现了数据的采集、告警以及日志分析功能。
• 第四代：也是全新一代架构，支持跨区域全局纠删功能，支持 AZ/Region 级容灾。在流量治理方面，支持基于 Apache APISIX 实现的跨地域请求调度能力，支撑极致的业务连续性；同时系统可观测性进一步提高，落地了集中化日志分析系统。在可维护性上首次引入了自动驾驶服务和交付编排服务，可以自动有效收敛故障范围，减轻运维压力，实现故障隔离和自愈能力。

Q：从您的讲述中能够感觉到，这个系统不只很是庞大，并且还很是重要。对于这样重要的系统，为何会选择 Apache APISIX？主要出于哪些方面的考虑呢？

是的，在技术选型初期咱们也调研过不少的 API 网关，包括 Nginx 等，不过咱们最终仍是选择了 Apache APISIX。Apache APISIX 不只可以知足当前的业务要求，同时还能在系统可用性、可维护性上为咱们提供比较多的思路和选择，跟咱们的总体产品演进规划和技术栈比较吻合。归结起来选择 Apache APISIX 主要基于如下几点：

第一，内部驱动产品架构优化须要，促使咱们开始在一些技术架构上寻找更高的突破点

在 2019 年的时候，中国移动从集团层面提出了“云改”战略转型，随后咱们云能也就成了整个移动在云改转型上的战略支撑点。这也促使咱们要在产品系统架构上作进一步的优化，可以知足将来 3~5 年以上的发展须要。不只须要在功能和性能上进行提高，并且须要在可维护性、可观测性等方面上来引入更多的组件，来保证咱们系统的稳定运行，提供可持续的、有保证的 SLA 服务等级。

第二，基于自身业务实现须要，同时 Apache APISIX 功能插件全面，业务场景匹配度高

由于自身业务对网关能力的须要，咱们经过对自有业务需求进行详细梳理分析，这其中就包括精细化路由、内/外网隔离以及访问控制，自动熔断保护，跨 AZ 请求调度等场景。同时，“运维友好”，这方面 Apache APISIX 作得很是好。

你们都知道，Apache APISIX 可以友好对接 Prometheus，前面我提到的可观测系统，它就是基于 Prometheus + Grafana + Loki 来实现的，因此之因此选择 Apache APISIX，很重要的一点是它能与咱们现有的技术栈完美结合，这些都是咱们比较看重的。

此外另外还有一个关键点，这也是 Apache APISIX 与其余网关产品的重要区别 —— 全动态加载，由于咱们更但愿全部的插件、路由都可以动态的扩展，这些是 Nginx这样的产品所不具有的。举一个简单的应用场景的例子：前面我有提到过咱们有一个子系统叫自动驾驶 Manager，当我后端的索引存储空间不足时，咱们就是经过 Manager 自动使能一条默认高优先级的路由，禁用 PUT 和 POST 等功能，从而实现自动后端保护。

第三，对社区开源文化的认同感

和其余网关产品不一样，Apache APISIX 是 Apache 开源顶级项目，孵化时间也是最短的，足见项目的成功，产品已经被不少企业应用于生产环境下。此外不得不说社区也是十分活跃的，代码贡献者和使用者都很是多，与社区的沟通交流方式也不少样化，好比 maillist，issues，QQ群，微信群，线上线下的 Meetup，沟通起来十分便捷且迅速有效。社区大佬也十分友好，乐于回复你们的提问。因此咱们对 Apache APISIX 社区的将来也是很是看好的。

另外，Apache APISIX 的全产品线作得也很是好，包括 K8s Ingress Controller，以及 Service Mesh 等，虽然这些技术栈咱们当前还用不到，但我以为社区在产品定位、发展方向上都是很是清晰的，这也给了咱们更充分的信心。

Q：就像您说的，其实 Apache APISIX 不只是但愿可以知足用户当前的需求和架构的设计，咱们更但愿可以知足你们 3~5 年，甚至更长时期的架构变迁。* 如今 Apache APISIX 有跑在中国移动的一些业务系统上吗？*

有的。从咱们的第三代对象存储产品开始，咱们除了解决容量、性能以及扩容性的问题以外，咱们还利用 Apache APISIX 来解决咱们七层流量治理的需求。第三代对象存储从它的研发历程来看，先后加起来还不到半年的时间，并可以在 2020 年 7 月的时候在移动云十期中完成上线运行，主要服务于内部的一些专业公司数据上云的需求。主要是存储用户的一些摄像监控数据，因此对带宽的要求仍是比较高的。目前总体投入生产运行已经有一年多了，从接入层到后端服务的运行状况仍是很是平稳的，几乎没有出过什么问题。

Q：在使用 Apache APISIX 的时候会作一些二次开发吗？另外，这些二次开发的成果是否有计划回归到社区呢？

二次开发是有的，并且还有很多。

针对一些通用的功能，咱们也会把他们贡献给社区。但咱们的一些开发内容都是为了知足一些特定业务场景，好比跨 AZ 请求调度。该功能主要是面向咱们第四代对象存储，它是一个全局跨域的版本，支持 AZ 级容灾，因此对业务的连续性要求很是高。为了解决请求调度的一些需求，咱们在 Apache APISIX 上写了一个 Plugin，而后去运行。

经过这个 Plugin 的请求，首先会选择本节点上游去处理；若是本节点上游出现问题，就会转向到本 AZ 内的其余一些上游去进行处理。若是本 AZ 全部上游都出现故障的时候，那就直接采用跨 AZ 的请求调度处理机制。这样一来，咱们整个业务请求的过程当中，即便出现 AZ 级的故障，请求仍是可以被正常处理。换句话说，咱们利用 Apache APISIX 作了一部分 “多活” 架构的实现。

Q：除了 Apache APISIX 现有的功能以外，大家后续还会有一些什么样的计划吗？

我以为后续的话，咱们应该主要会围绕这几个方面开展。

第一，容器化编排和统一入口 由于咱们如今主要在开发第四代对象存储，咱们正在作的事情就是实现全部组件的容器化部署编排。这中间既有数据面也有控制面，控制面咱们已是 K8s 化了，当前正在作数据面组件的容器化部署编排工做。对于外部访问需求，咱们也在采用 Ingress Controller 来统一访问入口。

第二，将更多的功能前置到网关层面来处理 前面我有提到，在咱们的控制面有多个子系统，后续咱们但愿把流量治理与一些自动驾驶、可观测子系统可以更多的去融合起来，经过实现故障自愈、故障隔离等功能，从而保证产品对外的访问能力，这也就要求咱们匹配更多的业务场景能力。

另外，咱们如今的网关接入层主要是实现了流量转发控制功能，而原来后端的认证、鉴权的那套逻辑是由业务逻辑层处理的，后续会考虑把这一部份内容统一前置到网关层面来处理。在数据迁移这块，因为历史遗留问题比较多，迁移过程还不能影响业务的连续性，不过咱们也已经有了基于 Apache APISIX 的可行方案。

第三，社区代码贡献上要加大 咱们也会在这块加大人员投入，与社区有着更积极的互动，参与到社区的开发当中，为社区的发展作一些回馈，这也有利于打磨咱们的产品。

第四，推进内部技术栈的统一 目前在咱们内部还存在多种技术栈并行的状况，同时也有多个团队在使用 Apache APISIX 网关，后期咱们也将经过沟通，梳理业务模型，实现技术栈的统一，避免重复造轮子的状况发生，最终实现技术栈的统一，造成统一基座能力。

Q：再次感谢陈老师，看来 Apache APISIX 在中国移动后面应该能够适用更多的场景，发挥的更多做用了。咱们也十分期待陈老师在 ApacheCon Asia 2021 上的分享《APISIX 在移动云对象存储 EOS 的应用与实践》。

咱们也期待，Apache APISIX 可让更多的企业受益！欢迎观看咱们往期的企业案例文章

• 基于Apache APISIX，新浪微博API网关的定制化开发之路

• 360：Apache APISIX 在基础运维平台项目中的实践

  关于 Apache APISIX

  Apache APISIX 是一个动态、实时、高性能的开源 API 网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。Apache APISIX 能够帮忙企业快速、安全的处理 API 和微服务流量，包括网关、Kubernetes Ingress 和服务网格等。 全球已有数百家企业使用 Apache APISIX 处理关键业务流量，涵盖金融、互联网、制造、零售、运营商等等，好比美国航空航天局（NASA）、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康、奈雪的茶等。 200 余位贡献者，一同缔造了 Apache APISIX 这个世界上最活跃的开源网关项目。聪明的开发者们！快来加入这个活跃而多样化的社区，一块儿来给这个世界带来更多美好的东西吧！

  • Apache APISIX GitHub：github.com/apache/apis…
  • Apache APISIX 官网：apisix.apache.org/
  • Apache APISIX 文档：apisix.apache.org/zh/docs/api…