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