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 我的项目地址：https://github.com/apache/apisix
• Apache APISIX 官网：https://apisix.apache.org/