作者介绍：Yh， 2010年加入腾讯，有12年的存储经验，在弹性块存储技术方面经验丰富，本文将其在TEG TALK上的分享内容进行整理，干货满满，内容包含腾讯云云硬盘产品（CBS）的后台系统的演进历程、核心技术以及大道至简的方法论。
什么是云硬盘？
云硬盘，Cloud Block Service，简单来讲就是云上的硬盘。
云硬盘提供硬盘所有的能力：就像大家个人电脑中的硬盘，可以创建文件系统，可以存电影，可以读写文件；甚至更多：因为云硬盘的数据存在云端，可以充分发挥云的能力，提供更丰富的功能，例如：快照，可以把云硬盘某一时刻的数据做快照，当数据发生异常是，用户可以任意的将数据回滚到这些快照时刻。
用户只需要在腾讯云上购买一台云主机，就可以方便的使用腾讯云硬盘。
如何实现云硬盘（弹性块存储）系统？
CBS云硬盘起初是依赖腾讯已有的3个分布式系统：TFS提供冷数据存储、TSSD提供热数据存储和CKV提供分布式锁，用这三个分布式系统做简化整合从而产生了CBS 存储后台。
其实最开始CBS是将这3个分布式存储系统拼凑在一起，并在前端封装一个iSCSI的块存储服务，这就是CBS1.0。
但是这个1.0的产品依赖3个庞大的分布式系统，IO链、运维支撑链太长，系统臃肿，可用性极差；所以又把这3个分布式系统在代码层面做了简化整合，从而产生了CBS2.0。
CBS2.0的架构是怎样的？
首先，CBS2.0前端是一个接入集群：
Client，即客户端，让服务器呈现一块硬盘；Proxy，即块设备的后台接入层，前端的云硬盘通过它才能将数据放到云端；Client和Proxy专业名次叫iSCSI initiator和iSCSI target，就像大家比较熟悉的CS结构一样；Master，集群总控节点，控制和协调整个集群的工作。
同时后端是一个分布式存储集群：
就像经典的分布式存储系统架构，首先接入模块Access提供接入访问服务；存储模块Chunk负责数据存储；同样它也是一个分布式系统，同样也有一个总控节点，就是Master。
CBS2.0系统的运营状况怎样？
目前CBS2.0的系统在线上已经安全运行了很久；为数十万商业客户提供服务；几十万块云硬盘在线上安全运营；存储规模百PB级别。
大家可能对这个规模没有概念，打个比方，如果把存储的数据用书本记录下来的话，那将耗尽地球上的森林。这个规模还在快速增长。
腾讯云硬盘提供3种规格的产品：HDD介质的普通云硬盘、HDD+SSD混合介质的高效云硬盘和高性能的SSD云硬盘；产品可靠性达到8个9的级别，在业界处于领先地位。
CBS2.0的运营过程中的难题？
首先是成本问题：成本是永恒的主题，特别是互联网海量存储中，任何的成本优化都会带来巨大的经济收益，特别是规模快速增长阶段的腾讯云硬盘。
还有一个问题是高性能场景的使用性问题：在前边的架构图里可以看到，腾讯云硬盘的数据请求从用户到数据落地存储，经过了两个集群、四个层次，每一层的网络延时在几十个微秒级别，而这和作为高性能场景的存储介质SSD的操作时延在一个数量级，所以数据在访问路径上的耗时占比就太大了。
如何去解决这些问题？
契合文章的主体：大道至简，做减法，简化系统，去掉接入层。
具体来说：上图左边是CBS2.0，也就是当前系统上规模运营的系统。它由接入系统和存储系统两个分布式集群组成；而腾讯云硬盘是个存储系统，接入是为了支撑存储的存在而存在的。
所以最直接的想法，把接入层去掉，简化成两层架构，只保留Client客户端在主机上呈现硬盘设备，Chunk模块提供数据落地存储，Master总控节点负责整集群的管理。
上图就是两层架构实现的CBS3.0的软件逻辑架构，和物理架构的三个节点对应：
Driver，对应物理架构中的Client模块，在软件实现上称为Driver。
Chunk，提供3副本存储的存储引擎。
Master，总控节点，多机互备提供高可用性。
两层架构的CBS3.0的技术难题？
一、数据组织：数据按什么样的数据结构存在后台分布式系统中。
二、数据路由：怎么确定数据存放的位置。
三、路由同步：路由信息怎么在集群节点之间同步。
四、数据多副本：作为一个高可靠性的存储系统，CBS三副本数据存储在不同机架的服务器上。
五、故障恢复：海量存储中，硬件故障是一种常态，怎么在故障中快速恢复服务和数据。
六、数据迁移：设备异常时或者集群扩容时，怎么讲数据从一个服务器迁移到另一个服务器。
这些都是分布式存储系统设计中经常碰到的难题，而和两层分布式架构关系最紧密的是前三条，所以重点介绍：数据组织、数据路由和路由同步。
数据组织：
先看看数据组织中最基础的问题：数据怎么分片，或者说数据的分片粒度应该多大。
如果数据分片粒度太小会那么路由信息太大，导致路由同步时机群的负担太大，特别是在两层分布式架构中，路由需要同步给成千上万的Client节点，过大的路由信息对总控节点崩溃。
反过来如果数据分片太大，因为每个数据分片是分配给一个用户使用的，如果用户只写入4K数据，而分配一个1M的数据分片，那会造成存储系统空间的浪费，导致空间利用率低。
为了解决这个矛盾，CBS在数据组织上引入了虚拟分区Partition的概念。在物理上硬盘被分为多了固定大小的Block，物理上每个Block属于一个硬盘，而在逻辑上又将多个Block组织为一个Partition，Block和硬盘的关系是固定的，但是Block和Partition的关系只是为了完成特定的功能需求而存在的。
数据路由：
基于Partition的数据组织方式，数据怎么路由呢？即数据怎么定位到存储的位置呢？
当前端数据访问时，它携带diskid、blockid或者说lba、snap id（快照id号），CBS系统将这3个参数通过一致性哈希，计算出对应的Partition；而Partition和物理服务器、物理硬盘的对应关系是在集群初始化的时候配置的，这样前端的数据请求就路由到了需要存储的物理位置，这就是CBS基于虚拟分区Partition的数据路由方式。
路由同步：
在两层架构中，没有接入节点，实际上会导致所有的Client节点都会成为接入节点，因为每一个Client都需要有路由信息进行数据访问；而接入节点成千上万，需要总控节点和成千上万的Client去同步巨大的信息，实际上总控节点会被压垮。
为了解决这个问题，CBS参考了一种懒汉做事的方法：尽量少做事、晚做事、非做不可的时候再去做。
在CBS架构中：Master是个懒人，当Master总控节点发生路由变更的时候，本来需要将路由信息推送到所有的Driver模块，但是因为Master是个懒人，它只简单的把路由信息推送到Chunk模块；Chunk也是个懒人，Chunk收到路由推送之后，它也只是简单的将路由信息存到了本地；Driver发起数据访问的时候，Chunik检测IO中携带的路由版本和Chunk本身的路由版本是否一致；如果不一致，Chunk通知Driver需要路由更新，Chunk虽然懒，但很负责；Driver收到存储节点的通知，它尝试从存储节点Chunk更新路由；如果Chunk因为宕机或其他异常不能及时响应Driver的更新请求，Driver就向Master发起路由更新请求，Master具有最高的权威，它将正确的路由信息反馈给你Driver，最终完成路由同步；整个路由推送处处体现懒人风格，谁都尽量少做事、晚做事、非做不可的时候再去做，当然懒人没问题，但一定要是一个负责人的懒人。
王银虎团队给这种懒人风格的路由推送算法起了个名字：lazy路由同步或者叫惰性路由同步。
用虚拟分区Partition的方式进行数据组织和路由，用lazy路由同步的算法进行路由同步，从而解决了两层架构中最关键的数据组织、数据路由、路由同步问题。
两层架构的效果怎么样？
两层架构的CBS3.0已经上线，上线后普通云硬盘的成本降低46%；两层架构的CBS3.0提供了一个统一的平台，不仅支持通用的普通云硬盘，也支持高性能场景的高效云硬盘和SSD云硬盘。
业界对比
CBS在自身发展的同时，也在紧跟业界发展动态，例如目前开源里比较流行的ceph。
CBS和ceph都是两层架构的实现。但是CBS在性能方面要远高于ceph。
CBS支持精细化运维，CBS有完善的监控告警系统，但CBS只提供了一个简单的通用运维系统，如果使用ceph，需要在运维系统方面有巨大的投入。
CBS在可控性方面也要远高于ceph，例如数据安全可控性，CBS在任何场景下都不能丢数据，数据安全是一种信仰，但是ceph在某些特定的故障场景，数据安全是没有办法保证的。
当然ceph也有很多值得我们借鉴的东西：例如CBS是块存储平台（目前已经支持文件存储），而ceph一开始就是作为统一存储平台设计的，同时支持块存储、文件存储和对象存储；CBS的是镜像多副本存储，但是ceph在支持镜像多副本的同时，还支持纠删码，特别是一些成本特别敏感的应用场景是很有优势的。
总结
CBS的发展历程就是一个“简”的过程；在最新的两层架构设计中，体会到以简致胜的真谛，不做过度设计，提供用户真正需要的功能；所谓大道至简，简化系统架构，提供高性能、高可靠性、易用的服务，和用户创造共赢。
