3.2.2 RGW 架构
对象存储 S3 为 AWS 早在 2006 年推出的 IaaS 服务，如今对象存储已经成为整个互联网行业非结构化数据存储的底座。Ceph 中的 RGW 服务实现了对 AWS S3 接口的兼容，Ceph RGW 经过 10 余年的发展，如今已经成为对 AWS S3 特性兼容最全面的开源实现。任何对对象存储实现感兴趣的人都能从了解 Ceph RGW 中受益。
RGW 最初叫 s3gw，由 Yehuda Sadeh 主导设计，在 Ceph 代码 git 仓库中可以追溯到的最早涉及 s3gw 的提交时间为 2009 年。遵从社区所追求的通用设计理念，s3gw 更名为RGW，后续也实现了对 OpenStack Swift 协议的兼容。
1. 实现架构
Ceph 本身采用分层的架构，RAODS 层中的 OSD 进程负责切片后对象数据和元数据的持久化存储，作为 RADOS 层客户端存在的 RGW 进程负责处理对象存储的业务逻辑。
本章节只分析 RGW 单个组件的架构，不再赘述 Ceph 存储系统的整体架构。
对象存储作为对外提供 HTTP（s）协议接入的服务，其逻辑有明显的分层架构设计思路。按照 HTTP（s）请求处理阶段，涉及的层有以下几个。
（1）负责解析和验证 HTTP（s）请求的协议解析层。
（2）负责对解析后的对象存储业务请求进行处理的业务逻辑层。
（3）负责对对象存储数据和元数据进行持久化存取的数据持久化层。
接下来逐层看看细节。
2. 协议解析层
协议解析层本质上就是 HTTP 服务器的实现，RGW 提供了灵活的插件式 HTTP 服务器实现，具备以下特性。
◆ 最早实现的兼容 FCGI 协议的 FCGI HTTP 服务器前端。
◆ 基于 C++ HTTP 服务端库 civetweb 实现的服务器前端。
◆ 基于 C++ boost HTTP 标准库 beast 实现的服务器前端，也是默认配置使用的 HTTP服务器。
协议解析层的主要工作内容就是解析对象存储的 HTTP 请求。对于请求认证需求，RGW 提供了以插件化方式实现的 AWS S3 v2/v4 类型认证以及通过外部 Keystone/LDAP组件进行认证两种方法。
在解析 HTTP 协议时，协议解析层会处理 Swift 和 S3 两种不同的对象存储“方言”，最终将 HTTP 请求统一抽象成对象存储的 Op（operation）。
3. 业务逻辑层
业务逻辑层负责对象存储 Op 的处理，RGW 为 Op 定义了统一的处理“工序”。
（1）init_processing ：初始化；
（2）verify_op_mask ：验证请求的读写掩码；
（3）verify_permission ：验证请求的权限；
（4）verify_params ：验证请求参数；
（5）pre_exec ：执行请求的预处理；
（6）execute ：处理请求；
（7）complete ：执行请求完成后的后续处理。
对象存储的业务复杂性导致每个 Op 在处理中都涉及如配额检查、权限控制、权限策略检查等业务逻辑的处理，在 RGW 中定义了 Service 组件来提供对象存储语义的调用接口。
对于需要多个 Service 组合构造的更复杂的对象存储语义，RGW 提供了 Control 这样的构造。
我们通过一个具体的例子来理解 RGW 业务逻辑模块化而引入的强大抽象：Service 组件和 Control 组件。
对于创建 User 的 Bucket 来说，涉及 User 和 Bucket 两个概念，对于 User 的操作抽象成单独的 User Service，Bucket 的操作抽象成单独的 Bucket Service。两个 Service 不需要知道彼此的存在，因此抽象出 Control 来提供更高层级的 API，Control 组件内部再调用 Service 提供的服务接口。
每个 Service 都有一个关联的 backend type，目前支持 SOBJ、OTP 类型，不同类型的 backend type 意味着不同的数据持久化方式。当前 RGW 需要的数据和元数据存储都是基于 RADOS 实现持久化的，后续持久化数据还可以保存到类似 MySQL 这样的关系型数据库当中。
在没有引入 Service 之前，在 RGW 中开发需要操作对象或者桶的特定功能时，通常是直接操作用来保存特定功能信息的 RAODS 对象（用户数据切片后的对象，也就是所谓第3章 接入层的 system-object，区别于用户可见的业务层面文件数据 rgw-object）。在引入 Service 之后，意味着通过为 Service 实现新的 backend type 存储类型，Ceph RGW 可以发展为和Minio 一样的项目，即成为一个与 Ceph RADOS 无关的独立对象存储网关，社区目前正在推进的 RGW 持久化后端存储插件化的改造（也就是 zipper 计划），正是为推动 RGW 发展，实现这一目标而开展的。
4. 数据持久化层
前文多次提到了 RADOS，RADOS 提供的数据存储接口是对象形式的。从用户的角度来讲，直接用 librados 就能使用“对象存储”。其实 RGW 中的“对象”和 RADOS 中的“对象”是两个概念。
首先来看对象存储服务，也就是 AWS S3 标准中的对象，它在 RGW 中简称 rgwobject，它的特点如下。
◆ rgw-object 可以非常大，比如单个 rgw-object 文件大小可以高达 5TB。
◆ rgw-object 是不可变的，即一旦写入，不可修改。
◆ 对同一桶中的 rgw-object，Ceph 维护了有序的索引。
◆ rgw-object 在权限控制上支持丰富的语义，如存储桶策略、ACL 等。
◆ rgw-object 通过 HTTP 协议访问。
而 Ceph RADOS 层的对象，简称 Object，它的特点如下。
◆ 有限的大小，比如默认配置下，其大小通常为 4MB。
◆ Object 是可变的，即写入后，允许修改。
◆ RADOS 不单独为 Object 维护有序索引。
◆ 不支持 Object 级别的 ACL 控制。
◆ Object 通过 socket 协议访问。
对比之后会发现，RGW 提供的 rgw-object 要比 RADOS 提供的 Object 的语义更加丰富。
RADOS 提 供 了 非 常 清 晰 的 访 问 接 口， 对 外 暴 露 Pool 和 Object， 以 及 Object 的OMAP 和 xattr。建立在 RADOS 之上的应用都要确定一个所谓的数据布局的问题，对于RGW 来说，就是如何将 rgw-object 映射到 RADOS 集群特定 Pool 的特定 Object。这部分关键的元数据被称为 manifest。
总结一下，RGW 在逻辑上需要持久化的数据分 3 类。
（1）Metadata，表示系统或者桶、对象的元数据，按照 Object OMAP 的形式保存。
（2）bucket index，保存存储桶中对象的列表，按照 Object OMAP 的形式保存。
（3）data，保存 rgw-object 的实际数据，按照 Object 数据的形式保存。
其中 Metadata 以单独的存储池进行存储，按照功能类别，Metadata 一部分是业务逻辑层中的 Service 组件和 Control 组件使用，另一部分则是保存系统运行需要的各类日志信息。这些存储池的名字空间如下。
◆ 业务逻辑类：
.rgw.meta:root、.rgw.meta:heap、.rgw.meta:users.keys、.rgw.meta:users.email、.rgw.meta:users.swift、.rgw.meta:users.uid、.rgw.meta:roles。
◆ 日志信息类：
.rgw.log:gc、.rgw.log:lc、.rgw.log:bl、.rgw.log、.rgw.log:intent、.rgw.log:usage。
