3.2.6 未来展望
1. RGW 优势
Ceph 的 RGW 在不断引入新功能的情况下，经历几次大规模的重构，整个架构设计分层清晰、责任明确，保证了整个 RGW 的可演进。RGW 当前的架构也充分考虑了非功能性的需求。
RGW 通过引入 beast HTTP 服务器前端以及使用 librados 异步 API，逐渐向读写路径异步化的方向演进。
在可观测性方面，RGW 也是在多个层面提供了支持。对于集中状态收集方面，得益于和 Ceph MGR 组件的集成，RGW 支持上报状态信息到 MGR 中，为之后进一步导出观测指标到 MGR 提供了支撑。
在运行时状态统计方面，RGW 提供了 admin socket 支持，支持单个 RGW 实例导出运行时的各类统计结果。
对于在线的请求跟踪分析方面，RGW 也集成了基于 Jaeger 的分布式请求跟踪。
在可管理性方面，RGW 支持命令行管理工具 radosgw-admin 和 HTTP 协议的管理API。Ceph 社区也在呼吁 radosgw-admin 集成到 Ceph 管理命令中，进一步简化用户使用方式。
在功能扩展性方面，RGW 支持 Lua scripting，可进行自定义的处理。这很容易让人联想到 Nginx 社区和 OpenResty 社区，期待 RGW 的功能扩展性能催生出对象存储的OpenResty。
2. RGW 劣势
RGW 扩展性得益于 HTTP 协议的无状态，因此基于 RGW 的对象存储的扩展性约束主要来自于 RADOS 层。目前 RGW 还没有解决好单个存储类别下的容量扩展性问题，具体来说就是一个存储桶中的对象只能保存在单个 RADOS 集群中，单个 RADOS 集群容量是单个桶支撑容量的上限。大部分用户选择通过业务改造，使用多个存储桶来规避单个RADOS 集群的容量上限。
除了容量扩展性之外，社区版本存在元数据扩展性问题，也就是单桶能容纳的对象个数受限于单个 RADOS 集群的限制。
单桶元数据管理还存在可用性缺陷。在保存元数据的 RAODS 集群中，存在 OSD 异常下线后，恢复业务压力对读写请求造成严重影响，继而造成恢复期间请求错误率飙升、请求时延剧烈抖动的问题。问题的根本原因在于索引信息以 RADOS OMAP 接口的形式保存，而对象的 OMAP 不支持异步恢复。大部分用户选择创建无索引类型的存储桶来规避存储桶索引的问题。
Ceph RGW 的多数据中心冗余方案历经多年的发展，虽然已经演进到 V2 版本，但效果距离商用仍有距离，主要是因为 RPO/RTO 存在达标缺陷和成本缺陷。对于成本缺陷来说，RGW 多数据中心的痛点主要在于采用了两中心全量镜像的方式，在 PB 规模下的成本基本是不可接受的。对于 RPO/RTO 达标缺陷来说，RGW 多数据中心采用异步复制的方式，无法为多站点业务提供 RPO 为零的保证。正是这两点缺陷，限制了 RGW 在 PB 规模并且高 SLA 要求的对象存储场景上的落地。
3. 小结
虽然，我们在使用过程中发现了 RGW 有诸多待改进之处，但这依然不影响 RGW 是目前特性最丰富的优秀对象存储开源实现。相信上述提及的问题被更多的使用者发现，并且得到社区的重视之后，一定会得到解决。
与此同时，RGW 的诸多与时俱进的新兴特性不仅是对 RGW 架构演进能力的例证，同时也彰显了整个 RGW 社区的活力和创新性，因此我们有理由相信 RGW 一定会越来越好。
