上图展示了阿里云EBS（Elastic Block Storage）服务自2012年以来的发展时间线，概括了其三代产品的关键特性、技术集成及硬件升级的历程。
-
2012 - EBS1发布：
-
-
设计特点：EBS1标志着阿里云开始采用计算与存储分离的设计哲学。它通过直接映射虚拟磁盘(VDs)为后端存储服务器上的64MiB Ext4文件，并且每个VD由一个无状态的BlockServer独占管理，实现了快速开发和部署。然而，这种设计导致了空间放大和性能瓶颈。
-
-
2015 - EBS2引入：
-
-
技术革新：EBS2带来了两大重要变化：日志结构化设计和VD分段。采用了Pangu分布式文件系统作为存储后端，使得所有VD的写入变为顺序追加，从而能够透明地在后台垃圾回收(GC)期间进行数据压缩和纠删编码(EC)。同时，VD被划分为32GiB大小的段，使得VD与BlockServer的关联从VD级别细化到段级别，改善了空间效率和性能。
-
-
2016 - 背景EC/压缩：
-
-
效率提升：在EBS2中，开始在后台实施数据压缩和纠删编码，进一步提高了存储空间的使用效率。
-
-
2019 - EBS3发布：
-
-
网络流量优化：EBS3通过在线（前台）EC/压缩和基于FPGA的硬件压缩技术来减少网络流量放大问题。Fusion Write Engine (FWE)聚合来自不同段的写请求，以满足EC和压缩的需求，而FPGA则加速了计算密集型的压缩任务。EBS3显著降低了存储和网络的放大因子，同时保持了与EBS2相近的性能。
-
-
2020 - 前台EC/压缩：
-
-
实时处理：正式引入前台的EC和压缩，进一步优化了数据处理流程，减少了延迟。
-
-
2021 - 逻辑故障域定义：
-
-
可用性增强：定义了逻辑故障域，这有助于在发生故障时限制影响范围，提高系统整体的可用性。
-
-
2023 - ARM CPU部署：
-
-
硬件升级：开始部署基于ARM架构的CPU
-
-
2024 - Federdated BlockManager：
-
-
管理优化：引入Federdated BlockManager，对BlockServer的管理进行了更加高效和分布式的改进。
-
-
硬件与技术集成：
-
-
Luna+RDMA：采用Luna用户态TCP堆栈和远程直接内存访问(RDMA)技术，优化网络通信。
-
Persistent Memory in EBSX：在EBSX中使用持久性内存，为VD提供了更快的访问速度和更高的耐用性。
-
AutoPL：2021年引入的自动配置技术，用于自动化性能和容量的调整。
-
整个时间线体现了阿里云EBS从追求设计简单性到关注高性能、空间效率，再到优化网络流量的演进过程。通过不断的技术创新和硬件升级，EBS在提供高性能虚拟块存储服务的同时，也在不断提升资源的使用效率和系统的整体可靠性。
2.1 EBS1：初始阶段
EBS1是阿里云在采用计算与存储分离理念的初步尝试。它的设计初衷是追求简单快速开发部署。EBS1直接将虚拟机内的虚拟磁盘（VD）映射为后端存储服务器上的64MiB大小的Ext4文件序列，并采用无状态的BlockServer集群来专一管理每个VD。尽管EBS1在超过300个HDD支持的集群上成功部署，存储了数百PB的数据，但它也暴露出了严重的问题，如空间放大效应和性能瓶颈。
-
为了加快开发和部署的速度，EBS1设计之初就追求简洁明了，确保系统易于理解和实施，从而缩短从设计到上线的时间周期。
-
EBS采用原地更新模式，即将虚拟磁盘(VD)直接映射为一系列固定大小（64 MiB）的Ext4文件。这意味着写入数据时直接覆盖原有位置，而不是创建新的数据副本，这样的设计简化了数据管理流程，但可能会影响后续的空间效率和数据压缩实施。
-
在EBS的早期架构中，每个虚拟磁盘(VD)与一个特定的块服务器(blockserver)绑定，形成N(VDs)-to-1(blockserver)的关系。这种设计简化了资源分配逻辑，但可能导致热点问题，因为单一块服务器可能成为性能瓶颈。
-
计算集群与存储集群：系统分为两个主要部分，计算集群包含运行虚拟机(VM)和BlockClient的服务器，用于接收并处理VM的I/O请求；存储集群则包含了BlockServer和ChunkServer，负责实际的数据存储和管理。
-
数据流：当VM向其VD发出新的写请求时，BlockClient首先联系BlockManager确定处理该请求的BlockServer（步骤①），然后BlockClient将请求转发给BlockServer（步骤②）。BlockServer再请求ChunkManager决定数据应该写入的三个ChunkServer（步骤③），最后数据被写入相应ChunkServer（步骤④）。
-
块服务器与块管理器：BlockServer处理多个VD的I/O请求，而BlockManager维护VD的元数据，比如容量和快照版本信息。BlockManager可以在故障切换时重新分配VD到其他BlockServer。
-
数据分块与存储：VD的空间被分割成多个固定大小的块(Chunks)，每个Chunk大小为64 MiB，并以Ext4文件形式存储在ChunkServer上。每个Chunk在三个不同的ChunkServer上进行三重复制，以保障数据的可靠性。
EBS的初期架构设计强调快速部署和简单管理，通过直接映射VD到Ext4文件和单一BlockServer绑定来实现。虽然这种设计促进了快速开发和部署，但也存在一些局限，如性能瓶颈和空间利用率问题：
（1）N-to-1映射问题：每个虚拟磁盘（VD）仅绑定到一个块服务器（BlockServer），这种一对一的映射关系导致了单点热点问题。当某个BlockServer处理大量请求时，会成为性能瓶颈，限制了整个系统的扩展性和性能。
（2）原地更新限制：EBS1采用原地更新策略，直接在VD对应的Ext4文件中修改数据。这种方式阻碍了数据压缩和纠删编码（Erasure Coding, EC）的有效实施，因为压缩会非确定性地改变数据大小，而EC则有最小数据块大小的要求，这些因素共同降低了存储成本效率。
尽管存在上述局限性，EBS1自2012年发布以来，在数百个集群中部署，成功服务于超过1百万个VD，并存储了数百PB的数据，证明了其在实际应用中的有效性。EBS1作为初次尝试，尽管在简化部署和快速启动服务方面取得了成功，但也暴露了在性能扩展、存储效率和成本效益方面的局限性，这些在后续的EBS2和EBS3迭代中得到了改进。
2.2 EBS2：性能与空间效率提升
针对EBS1的局限性，EBS2引入了两大变革：日志结构化设计和VD分段。EBS2采用了Pangu分布式文件系统作为存储后端，将VD的所有写入操作转换为连续追加，这不仅保持了原有的三重复制机制，还在后台垃圾回收（GC）过程中透明地执行数据压缩和纠删编码（EC）。同时，VD被细分为更小的段（每个32GiB），使得VD与BlockServer之间的映射从VD级别细化到段级别。这些变化使空间效率由EBS1的3倍降低到了平均1.29倍，并且借助SSD，EBS2支持的VD可以达到1百万IOPS、4000MiB/s的吞吐量和微秒级别的延迟。然而，伴随而来的是网络流量放大问题。
EBS2的主要目标是实现高性能与高空间效率，提升存储服务的响应速度和数据处理能力，同时优化存储资源的使用，确保更高的存储密度和成本效益。
2.2.1 磁盘分段（Disk Segmentation）
EBS2在设计上着重于提升存储性能和空间效率，其中磁盘分段（Disk Segmentation）是一项关键创新，它通过精细的数据组织和管理策略，有效解决了EBS1存在的性能瓶颈和空间利用率问题。
-
EBS2将虚拟磁盘（VD）的逻辑地址空间划分为多个连续的段组（SegmentGroups），每个段组包含一系列数据扇区。每个VD不再由单一的BlockServer管理，而是被细分成多个段（Segment），每个段可以由不同的BlockServer服务。这种设计有助于分散I/O负载，避免单点过热，提高了系统的整体性能和弹性。
-
每个段组内部进一步组织为一系列的数据扇区（Data Sectors）。这种结构设计让数据在逻辑上得以有序组织，便于跟踪和管理，同时也为后续的数据处理操作提供了便利。
-
数据扇区按照循环分配（Round-Robin）的方式分配给各个段（Segments）。这意味着写入数据时，系统会轮流选择段来分配新的数据扇区，这样能有效分散写入压力，避免单个BlockServer成为性能瓶颈，提升整体系统的并行处理能力。循环分配策略和按需分配Segment的做法减少了存储空间的浪费，提高了空间使用率。结合后台的垃圾回收和数据压缩技术，进一步优化了存储成本。
-
在EBS2中，BlockServer的操作单元变更为更小的“Segment”级别。相比于EBS1中整个VD的粗粒度管理，这种改变允许更精细的资源分配和负载均衡，提高了I/O操作的响应速度和系统吞吐量。同时，由于每个Segment可以独立处理，故障恢复和数据迁移变得更加灵活和高效。
2.2.2 日志结构化块设备LSBD
Log-Structured Block Device (LSBD)是EBS2中引入的一项关键技术，它通过日志结构化的方式来优化存储性能和数据管理。BlockServer基于Pangu分布式文件系统（一个只追加的日志文件系统），所有VD的写请求被转换为顺序追加操作。这种设计不仅支持了高效的后台垃圾回收（GC），还使得数据压缩和纠删编码（EC）能在GC过程中透明进行，不会影响前端的I/O操作。
下面是关于LSBD几个核心组成部分的详细分析解读：
-
数据文件（DataFile）：在LSBD中，数据是以日志结构的形式组织存储的，每个数据文件（DataFile）由一系列固定格式的数据块组成，每个数据块包含实际数据（4KB）和一个头部信息（64B）。头部信息通常记录了数据的元数据，比如校验和、时间戳或者逻辑地址等，用于确保数据的完整性和定位。这种结构化方式使得数据写入变得连续且快速，因为新数据总是被追加到文件末尾，减少了碎片化问题。
-
事务文件（Txnfile）：事务文件（Txnfile）是为了加速故障恢复（failover）设计的。在EBS2系统中，Txnfile记录了最近发生的写操作信息，包括未完成的事务或正在处理的数据变更。一旦系统发生故障需要恢复，Txnfile能迅速定位到上次成功操作的状态，从而加速恢复过程，确保数据一致性。通过这种方式，EBS2提升了系统的可靠性和恢复速度。
-
内存索引映射（In-memory Index Map）：为了进一步加速读取操作，EBS2采用了内存中的索引映射（Index Map）。这个映射表存储了数据块逻辑地址与其在DataFile中物理位置的对应关系。由于查询操作直接在内存中进行，相比从磁盘读取索引信息，这大大缩短了查找时间，提高了读取性能。内存索引映射对于频繁随机读取的场景尤其有效，因为它能够快速定位到数据所在的具体位置，减少了磁盘I/O操作，提升了用户体验。
Log-Structured Block Device通过其独特的数据结构和管理机制，不仅优化了写入性能，减少了磁盘寻址延迟，还通过事务文件增强了系统的容错能力，以及利用内存索引映射加速了数据读取过程。这些设计共同提升了EBS2的整体性能，尤其是在处理大量、频繁变化的数据存储需求时，表现出色。
2.2.3 GC with EC/Compression
在EBS2的设计中，垃圾回收（GC）与纠错编码（EC）及数据压缩的整合是一个核心优化策略，旨在提升存储效率和性能。EBS2在后台执行垃圾回收时，将原始的三副本数据（REP.DataFiles）转换为经过EC编码和LZ4/ZSTD压缩的“EC.DataFiles”。这种做法减少了存储空间的需求，同时通过在线（前台）EC和硬件加速的压缩技术，减少了数据在网络中的传输量，进一步优化了空间效率和网络流量。
垃圾回收（GC）是在DataFiles这一层次上执行的。这意味着系统不是针对单个数据块进行清理，而是以包含多个数据块的集合（即DataFiles）为处理单位。这种操作方式可以减少管理开销，提高GC效率，同时确保了数据的连续性和完整性。
在GC过程中，原始的三副本（REP.DataFiles）数据会被转换为采用纠错编码（EC）和数据压缩算法（如LZ4或ZSTD）处理过的“EC.DataFiles”。具体而言，使用EC(8, 3)方案，意味着原始数据被编码成8份，其中任何3份即可恢复全部数据，这种编码方式大幅减少了存储空间的需求。同时，LZ4或ZSTD等高效压缩算法的应用进一步减小了数据体积，提升了存储利用率。
-
通过EC，原先的三副本冗余被更高效的编码方式取代，显著节省了存储空间。同时，数据压缩进一步减少了存储占用，这对于成本控制和大规模数据存储至关重要。
-
后台的GC、EC编码与压缩操作异步进行，不影响前端的I/O操作，保证了服务的高性能表现。
-
虽然减少了冗余副本数量，但EC编码依然保证了数据的高可用性，确保即使在部分硬件故障情况下也能恢复数据，提升了系统的可靠性。
在EBS2的部署情况分析中，EBS2实现了平均写入延迟仅为100微秒（μs），并且每个虚拟磁盘（VD）支持高达100万次IOPS。这些性能指标表明EBS2在低延迟和高并发处理方面表现卓越，能够满足高性能存储需求。系统部署跨越超过500个集群，为超过200万个VD提供服务，显示了其强大的扩展能力和广泛的业务覆盖范围。EBS2通过采用纠删编码（EC）技术，将原本的三副本存储（3x）降低到了更高效的冗余策略，平均数据冗余率降低到大约1.29倍。这意味着在保持数据可靠性的同时，显著减少了存储空间的需求。
-
未进行GC的数据：在EBS2的日常运行中，新写入的数据在未经过垃圾回收（Garbage Collection, GC）处理之前，暂时仍按照三副本存储，以确保即时的数据安全性。
-
经过GC的数据：在数据经过GC流程之后，老数据会被重组为EC编码形式，从而减少存储空间的需求。考虑到系统中同时存在未GC和已GC的数据，平均数据冗余率被计算为1.29，这表明在实际操作中，经过优化处理的数据比例较高，有效地平衡了存储效率和数据安全需求。
EBS2虽然在存储效率上有所提升，但伴随而来的是一些挑战，比如数据处理过程中可能存在的流量放大问题，最大可达4.69倍。这意味着尽管存储成本有所下降，但在数据迁移、备份或恢复等操作时，网络带宽需求可能会显著增加。
随着SSD（固态硬盘）成本的下降，云存储领域的关注点从存储空间的成本效益转向了对网络流量的敏感度。这要求存储解决方案在设计时不仅要考虑存储效率，还要优化数据传输效率，减少不必要的流量放大，以适应成本结构的变化。
EBS2在尝试实现在线EC（纠错编码）和压缩以进一步提升存储效率时，遇到了一些挑战，特别是与前台（Foreground）处理相关的难题：
前台在线EC/压缩指的是在数据写入过程中实时进行纠错编码和数据压缩，目的是减少存储空间占用并优化网络传输效率。这种策略理论上能立即减少存储需求和传输量，但实践中却遇到了障碍。
（1）碎片化请求妨碍在线Compress-EC实施：
-
-
请求尺寸问题：EBS2发现，近70%的写入请求大小小于16KB。而纠删编码（EC）通常要求原始数据块至少为16KB，以便生成有效的编码块。这导致小尺寸的数据块不能直接进行EC编码，需要等待合并到足够大的数据块后再进行处理。
-
延迟增加：等待数据块合并的过程会导致额外的延迟，这个延迟时间范围很广，从微秒级（10us）到毫秒级（100ms）不等。对于强调低延迟的应用来说，这是不可接受的。
-
（2）基于CPU的压缩效率低下：
-
-
处理时间：即使是16KB大小的数据块，使用CPU进行压缩也需要大约25微秒的时间。对于高并发写入场景，这会迅速累积，成为性能瓶颈。
-
资源竞争：CPU资源在进行数据压缩时的占用，会与其他系统任务产生竞争，进一步降低整体的处理吞吐量。特别是在云环境中，CPU是共享资源，高度的压缩任务可能会导致其他服务性能下降。
-
为了解决这些问题，后续可能的改进方向包括：
-
后台合并与预处理：开发更智能的数据合并策略，在后台自动聚合小块数据，减少等待时间，同时利用空闲时段进行压缩和编码，减轻对实时写入性能的影响。
-
硬件加速：采用专门的硬件加速器（如FPGA或ASIC）来执行压缩和EC计算，这些硬件设备能显著提高处理速度，减少CPU负担，进而减少延迟并提升整体吞吐量。
-
智能请求调度：优化请求调度算法，优先处理大尺寸数据块的写入请求，或在系统空闲时优先处理小尺寸数据块的合并与压缩任务，以此来平衡性能与存储效率。
2.3 EBS3：优化网络流量
EBS3在设计上针对前代面临的问题进行了重大改进，特别是在前台在线EC（纠错编码）和压缩方面。其设计目标和关键设计点旨在解决存储成本、流量消耗以及性能损失之间的平衡问题。
-
降低流量消耗和存储空间成本：EBS3的主要目标之一是减少存储数据所需的网络带宽和物理存储空间，从而降低运营成本。通过实现高效的在线数据压缩和纠错编码，能在不牺牲数据可靠性的前提下，大幅缩减数据体积。
-
无性能损失：在追求成本效益的同时，EBS3设计还强调维持甚至提升系统的I/O性能，确保用户不会感受到因数据处理流程增加而带来的任何延迟或吞吐量下降。
为了应对EBS2的网络流量放大问题，EBS3通过在线EC/压缩技术和定制FPGA硬件加速来降低这一影响。EBS3利用Fusion Write Engine（FWE）聚合来自不同段的写请求，以满足EC和压缩的尺寸要求，并将计算密集型的压缩任务卸载到FPGA上。
-
双路写路径（Bifurcated Write Path）：这一设计创新性地分离了数据的写入路径，使得小块数据可以直接写入并即时处理，而无需等待合并，从而减少了延迟。通过智能路由，系统可以高效地处理不同大小的数据请求，确保即使小尺寸请求也能快速完成EC和压缩处理。
-
融合写引擎（Fusion Write Engine）：这是一种高级的数据处理架构，能够动态地管理数据块的合并、EC编码和压缩操作。它确保了即使在高负载情况下，也能通过优化算法和流程，实现快速响应和高效数据处理，避免了传统方法中的等待合并导致的延迟问题。
-
基于FPGA的压缩卸载（FPGA-based Compression Offloading）：为了克服CPU资源竞争导致的性能瓶颈，EBS3利用FPGA来加速数据压缩过程。FPGA专为特定任务优化，能够比通用CPU更快地执行压缩算法，从而显著减少处理时间，释放CPU资源用于其他任务，确保系统整体性能。
FPGA卸载的延迟时间分布在29到65微秒（µs）之间，表明在处理数据压缩任务时，FPGA能够提供非常快速的响应。这显示出FPGA硬件加速在低延迟处理上的高效性。
-
与CPU比较的显著减少：尤其值得注意的是，当数据块大小为16KiB时，FPGA卸载的延迟时间比仅使用CPU压缩减少了78%。这意味着对于典型的数据块尺寸，FPGA在减少数据处理时间方面具有显著优势，这对于追求低延迟应用如实时数据处理和存储服务至关重要。
-
FPGA卸载的吞吐量表现：FPGA卸载方案实现了高达7.3 GiB/s的最大吞吐量，相较于仅使用CPU压缩的3.5 GiB/s，几乎翻了一倍。这表明在处理大量数据流时，FPGA能够提供更高的数据处理能力，从而提升系统的整体数据处理速度和容量。
这一系列措施将存储放大因子从1.29降低到0.77（压缩后），并将网络流量放大因子从4.69降低到1.59，同时保持了与EBS2相似的性能水平。
EBS3的部署规模庞大，超过100个集群服务于50万个虚拟磁盘（VDs），EBS3通过一系列精心设计的技术方案，不仅实现了存储成本和流量消耗的显著降低，而且在实际部署中证明了其在大规模环境下的高效能和稳定性，真正达到了设计之初的“无性能损失”目标。
为了验证不同架构的效果，聚焦于EBS1、EBS2和EBS3在不同工作负载下的吞吐量和延迟表现。评估使用了微观基准测试工具（通过FIO进行VD压力测试）和基于应用程序的宏观基准测试（使用RocksDB与YCSB、MySQL与Sysbench）来进行综合性能评价。
-
4 KiB随机读写测试：通过FIO工具施压，评估了各代EBS在随机4 KiB写入和读取操作下的吞吐量和IOPS。结果显示，EBS2和EBS3的吞吐量随着线程数（从1增加到16）的增加近乎线性增长，直到达到峰值。在8个线程时，EBS2和EBS3达到了每VD 4,000 MiB/s的吞吐量，即1百万IOPS，分别比EBS1提高了13倍和50倍的吞吐量和IOPS。
-
延迟变化：随着FIO任务数量的增加，EBS2和EBS3的延迟变化。在1到8个线程之间，两者的延迟保持稳定，仅在使用16个线程时，由于线程间竞争导致的瓶颈，延迟有轻微增加。
-
RocksDB与YCSB：使用默认配置的RocksDB与YCSB进行测试，对于写密集型工作负载（插入和更新），EBS2和EBS3相比EBS1分别实现了550%和573%的吞吐量提升。对于读密集型工作负载，吞吐量也增加了约470%。
-
MySQL与Sysbench：配置了特定参数的MySQL（InnoDB引擎）进行测试，oltp_insert工作负载下，EBS2和EBS3的吞吐量比EBS1提升了389%，而其他测试条件下，平均吞吐量提升约为350%。