背景阐明
中国移动云能力核心作为中国移动云设施构建者、云服务提供者以及云生态汇聚者，承当了挪动云的 技术研发、布局建设、经营保护、单干引入、销售撑持、反对上云 六大工作职责。
截至 2020 年 10 月，全国共计建成 25 个私有云节点，省份覆盖率超过 80%。其中对象存储 EOS 作为底层基础设施能力之一，已在所有资源池中进行了部署建设，整体可用规模达到 EB 级。
挪动云对象存储至今已经验了四代倒退历程变迁。从自研开发起手，通过性能扩大、深度定制、性能晋升到最新一代领有跨区域全局纠删架构，实现了异地多活容灾成果。纵观下来，堪称是提高飞速。
在云对象存储技术选型初期，咱们调研过很多的 API 网关，包含 Nginx、Apache APISIX 等，最终还是抉择了 Apache APISIX。Apache APISIX 不仅可能满足以后的业务要求，同时还能在零碎可用性、可维护性上为咱们产品提供了比拟多的思路和抉择，与后续整体产品演进布局和技术栈比拟吻合。
为什么抉择 Apache APISIX 作为网关
为什么摈弃 Nginx？
理由一：综合能力欠缺
Apache APISIX 作为一个微服务网关，与其余 API 网关相比，它的上游路由插件是全动静的，批改配置不须要重启。同时插件反对热加载，能够随时插拔、批改插件。尤其是业务连续性要求十分高的场景，这些能力都是 Nginx 不具备的。
理由二：配置不灵便
家喻户晓，像 Nginx 所有的性能都是基于配置文件来实现的，因此像 Proxy 存在路由上游的证书不能动静加载。Apache APISIX 反对全平台、多协定、全动静、精细化路由、平安防护，而且运维敌对，能够对接 Prometheus、SkyWalking 等，有高度扩大能力，这些都是理论生产中须要的能力。
在技术选型时为什么咱们最终抉择 Apache APISIX？
理由一：基于产品架构的须要
前边提到过目前对象存储曾经经验了四代倒退历程。随着产品性能的丰盛、整个架构集群规模变大，就须要有更多管制面策略，包含流量治理、服务治理等策略来保障整个零碎的稳固运行。
理由二：细粒度业务性能的实现
Apache APISIX 的个性、性能插件、自定义开发性能，都能够在后续的开发过程中满足咱们的业务需要。
理由三：SLA 服务等级保障
个别 SLA 服务等级的可用性强调两个指标：零碎均匀无故障工夫和零碎均匀故障修复工夫。如何无效拉长零碎均匀无故障工夫？如何无效放大零碎均匀故障修复工夫？这两个问题是咱们重点思考的。而 Apache APISIX 在故障隔离和自愈方面都有着不错的流量治理和服务治理相干能力。
在 Apache APISIX 的数据面咱们改了些什么？
改良一：内外网申请拆散拜访
目前咱们的业务模型有两个域名，内网域名和外网域名。内网域名的拜访是资源池东西向的拜访，如资源池外部虚拟机、利用平台类的产品等。外网域名，相当于是纯公网的拜访，比方：公网的私有云、toC 和 toB 的客户，通过 satellite 或者物理专线拜访对象存储。
咱们通过接入 Apache APISIX 实现了内外网域名的多域名证书配置，并提供了加密拜访性能，同时实现了 SSL 证书动静加载的性能实现。对于 24 小时不间断的业务，可能动静更新 SSL 证书是十分重要的。
改良二：申请熔断爱护
在这里首先给大家简略形容一下目前接入 Apache APISIX 后的对象存储 EOS 节点治理。整个对象存储分为数据立体和管制立体。数据立体次要承载整个业务的 I/O 流。业务数据是从 Apache APISIX 的 7 层流量治理模块作为入口，通过 Apache APISIX 后端上游的 Accesser，实现业务接口解决的次要模块。
管制立体次要有几大服务，包含主动驾驶服务 Manager、可观测零碎 Observer 和混沌工程故障注入模块 Checker。还有额定的整体交互编排零碎 Orchestrator 和灰度公布平台 Publisher。
为了实现申请熔断爱护，数据面在接入 Apache APISIX 后就实现了申请染指的解决能力。而管制面端的可观测零碎次要是基于 Prometheus 搭建的，进行指标收集与告警，最终实现后端整体的熔断爱护。
改良三：自定义 constant key 实现全局限流
limit-conn key 这个插件次要是反对 remote\_addr、server\_addr、X-Forwarded-For、X-Real-IP，但不能对南北向网关的流量做全局限流。
为了匹配咱们的业务需要，通过自定义一个 constant 常量作为 imit-conn key 范畴，上图右侧即是接入 Apache APISIX 后批改过的配置，通过 constant 常量 key 实现全局限流的性能。
改良四：新增性能个性开关
- 开关 1：长期敞开某个对象存储性能
在网关层通过接入 Apache APISIX，兼容了 S3 接口标准，防止对后端服务的接入层、长久化层 的资源节约。
- 开关 2：反对 GET 申请优先级最高
实现了在反对 GET 申请优先的状况下，在取回用户数据时 GET 申请优先级最高，高于 PUT、DELETE 等申请。
- 开关 3：对 Ordered List 申请返回 501 Not Implemented
在对象存储中个别会有对桶的 Ordered List 的性能需要。第三、四代挪动云对象存储面向的都是百亿文件对象，如果仍旧应用 Ordered List，一方面申请拜访后端响应的工夫会特地长，另一方面会占用较多资源，对后端的稳定性提出较大的挑战。
所以接入 Apache APISIX 后将间接在网关层面进行拒绝请求，并返回 501 Not Implemented 的状态码。
改良五：实现通明降级 / 扩容 / 配置变更
联合 Apache APISIX 7 层治理能力，咱们对上游组件和整个 I/O 门路上要害组件进行了降级、扩容和配置变更，通过动静扩容、动静降级等操作来管制后端权重，进行后续申请解决。
改良六：实现申请日志跟踪剖析
基于 access.log 实现了日志集中收集的治理形式，把 Apache APISIX 的 log 和其余过程的 log 都收集起来，而后进行综合的剖析。
上图右侧的配置项是应用了 Apache APISIX 的 request-id 插件。每个申请在通过 Apache APISIX 时都会被调配一个 request-id，被用于业务逻辑解决层（Accesser）和数据长久化层，进而在 Loki 官网面板上过滤出不同组件的日志工夫戳，有助于后续应用 AI 实现一些自动化的剖析。
改良七：跨 AZ 申请调度性能
目前负载平衡的后端是基于 Apache APISIX 实现的七层流量治理层，通过等 ECMP + BGP 路由实现多活的能力。咱们定义了三种流量类型，每个 Apache APISIX 节点收到业务流量时只打到本节点的上游服务去解决（level0，紫线），相似 SideCar 模式。
如果一个节点的上游呈现问题，就会被转发到同 AZ 的其余上游节点进行解决（绿线）。如果所有上游节点全副挂掉，则会基于 Apache APISIX 实现申请跨 AZ 的调用能力（level2，红线），把申请写入到其余 AZ 中，最终实现跨 AZ 的申请调度。
将来布局
将来挪动云对象存储将会全面拥抱云原生，并逐渐实现以下打算：
- 整合数据面性能，最终实现全面的容器化部署编排
- 陆续接入基于 Apache APISIX 的 Ingress Controller，通过 Apache APISIX 来对立拜访入口
- 增强与主动驾驶 Manager、可观测性零碎 Observer 子系统的交融能力，进一步实现故障的隔离与自愈
- 将对象存储 S3 方面的认证能力移入到接口层。更好地实现对立鉴权认证以及平安拜访，达到爱护后端的成果
对于作者
作者陈焱山，来自中国移动云能力核心。从事分布式存储软件开发及架构方案设计工作，深度参加挪动云的建设，在分布式对象存储畛域有丰盛的实战经验。
对于 Apache APISIX
Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。Apache APISIX 能够帮忙企业疾速、平安的解决 API 和微服务流量，包含网关、Kubernetes Ingress 和服务网格等。
- Apache APISIX GitHub：https://github.com/apache/apisix
- Apache APISIX 官网：https://apisix.apache.org/
- Apache APISIX 文档：https://apisix.apache.org/zh/…