9000字干货：从消息流平台Serverless之路，看Serverless标准演进

最初的架构是一个共享集群的模式，所有业务都跑在一个公共的集群上，不同的业务按不同Topic进行隔离。

这种模式的优点是构建复杂度较低，资源提前部署，使用者不感知底层节点，只关注业务Topic，起步成本较低。

然而，随着用户和业务的快速增长，云上集群的压力也越来越大，尤其在一些大流量、大数据量的场景下，这种共享集群的模式开始显得力不从心。同时，由于资源共享带来的爆炸半径大、资源抢占、扰邻的问题，也使得其在面对多用户、高负载场景时，存在一定的局限性。

因此，为了更好地适应云上大业务量的场景，我们演进出了独立集群的架构，即每个租户的集群都是独占的，使用独立的计算和存储资源部署，网络上也是独立的VPC。可靠性上，支持计算节点在AZ级和物理机级的反亲和部署，保证单物理机故障、单AZ故障时，集群依然可用，并且单集群故障或异常，不会影响其他集群，也不会有集群间的资源争抢和扰邻问题。

在这种架构模式下，用户需要提前评估业务量，创建特定规模的集群。然而，业务总是在变化的，每个业务在不同时间阶段也可能有不同的性能容量诉求，创建新的集群往往意味着业务的拆分，需要进行业务改造，在生产环境中往往是成本很高，或者是难以接受的。

因此，也对单集群的扩展能力提出了要求，这种扩展主要体现在存储、计算和带宽上。

消息流平台本质上也是一种存储服务平台，要满足不断变化的存储诉求，就需要支持存储空间的动态扩展。

基于LVM技术，在需要扩容存储空间时，创建指定大小的云盘，挂载到对应的计算节点，并加入对应的逻辑卷组，扩充到逻辑卷中，达到存储空间的动态扩容，上层业务逻辑不用感知底层的多块云盘。对于计算和带宽资源，我们则是通过扩大节点规格和增加节点数来达到扩容的目的。

这种单租架构也是业界比较常采用的一种方式，然而这种架构模式没有实现完全的Serverless化，也存在着一些不足，主要体现在存储、计算和带宽资源的弹性和成本上。

目前主流实现下，在集群扩容时，新节点由于没有分片的分布，无法承接流量，均衡负载，需要进行分片的迁移，而迁移会因为数据复制而带来迁移时间长、占用资源的问题，虽然可以通过限制迁移的带宽和设定在低峰时间进行迁移，一定程度上减小迁移带来的业务冲击，但对于高负载下紧急扩容场景，迁移时间长和业务冲击的问题依然难以避免。对于存储资源，业务需要按最大存储空间诉求来预留存储容量，导致存储空间的利用率不高，会有一定的存储资源浪费。

面对这些问题，我们在不断思考、探索的过程中，也逐渐演进出了新的数据流处理平台架构。

而分片迁移的过程需要同步历史数据，该过程会导致额外的带宽占用，导致原有节点负载加重，影响业务。

需要迁移数据是因为计算和数据是绑定的，每个节点只能访问本节点的数据。那么，我们如果可以将数据访问解绑，就可以不迁移数据，消除数据迁移带来的诸多问题。

计算和存储分离，能够使得业务扩展更灵活，计算的扩展不需要迁移数据，但伴随而来，是更复杂的部署架构和基础设施资源，对于云上多租、大业务量等场景，更适合存算分离模式，而在小型化部署等轻量化场景，更适合存算一体的模式。

因此，一个更普适的架构，应该是存储计算可分可合，逻辑上独立，物理部署上同时兼容两种模式。我们基于这种思想，也进行了一系列的实践。将存储与上层队列模型进行了解耦，彻底消除了存储介质、存储位置及存储方式与队列模型的耦合关系，通过面向应用的逻辑数据映射访问存储。

消息流数据往往是一种过程性数据，数据追加写入，读取也主要集中在刚写入的数据。基于这种特点，我们首先实现了一种逻辑存储方式，在迁移分片时，只做逻辑上的迁移，物理数据在不同节点存储，通过元数据实现逻辑存储和物理存储的映射。

前面提到，消息是一种流式的数据，通常情况下，生产的消息都会被及时消费，也就是只需要访问本地的数据，并不会产生时延的增加，并且随着新数据的不断产生和历史数据的清理，分片的数据分布会逐渐趋近于目标节点，达到就近访问的效果。

通过这种逻辑存储方式，避免了在分区迁移时进行数据同步带来的资源开销，从实测的结果看，能做到秒级的迁移，并且不会增加原有节点的负载，让扩缩容和迁移过程更平顺。

这种方式一定程度上解决了分区迁移过程中的数据同步问题，但在物理部署上依然是存储计算绑定的，对于存储成本高、利用率低等问题，依然没有得到很好的解决。

在业界，我们看到一些消息流服务也在做相关的尝试，但是对部署架构、存储方式有着强烈耦合，带来了较大的运维成本。

我们看到，造成这些问题的关键在于存储介质、部署和计算依然存在一定的耦合，因此需要做更彻底的分离。

我们知道，在存储体系中，存储介质、访问时延、成本是互相平衡的，如下图所示，越接近CPU的存储介质，时延越低，相应的，容量也越小，单位容量的成本也越高。

因此，不同类型的存储介质适合存储不同类型的数据，访问频繁、时延低的数据适合放在高性能、低容量的存储，访问不频繁、数据量大、需要长时间存储的数据，适合放在低性能、大容量的存储中。

在存储领域，业界已有对冷热数据分离的相关实践。对冷热数据的划分，主要根据其访问的频率，高频访问的为热数据，低频的为冷数据，其次是根据最近访问原则，长久未访问的数据也会被判定为冷数据。

AWS根据数据访问的频率，将频繁访问的在线类数据划分为热数据，非频繁访问的离线类数据划分为冷数据，在Redshift架构中，则是将冷热数据进行了分离存储，本地缓存的热数据使用SSD存储，而冷数据则通过S3进行存储，以提高存储效率，优化成本。

我们看消息流数据的特点：生产是追加式的，消费场景绝大多数都是及时消费，在金融、消息回溯等场景，可能需要访问历史的数据，这部分历史数据的特点是数据量大，但访问相对不频繁。因此，从读写和存储的生命周期，将数据分为热、温、冷三种：

•热数据：实时读写的缓存数据，这部分数据既是最近访问的，又是近期会频繁访问的，这种访问趋势在流场景是可以预测的，这类数据通常数据量不会很大，但对访问时延、吞吐要求较高；

•温数据：在消息积压场景，数据会在写入后一段时间才内读取，访问频率和实时性相对热数据更低，但其访问依然是可预见的，且对访问性能也有较高的要求，适合高性能、小容量的存储；

•冷数据：已经消费过的历史数据，只在消息回溯等场景再次访问，访问频率低，适合存储在大容量、低成本的对象存储中。

我们根据消息流数据的分布特点，采用分级存储的架构，将冷热数据分别存储在大容量的远端存储和低时延的本地存储，达到存算分离、成本优化的效果。

华为云消息流平台在分级存储架构上的实践，采用块存储作为本地存储，对象存储作为远端存储。对象存储的特点是存储容量大，相比本地块存储具有成本上的优势，并且支持按需使用。

目前，AWS的S3服务也推出了高性能的单AZ版，在Serverless化大背景下，对象存储正在逐渐成为一种标准存储解决方案。而在读写性能上，块存储具有更好的时延表现。

因此，我们使用了本地块存储和远端对象存储相结合的方式，本地块存储保证了数据实时写入的低时延，对象存储则保存不常访问但数据量庞大的冷数据，达到性能和成本的平衡。

同时，大多业务场景中，流量都是波动的，本地块存储可以作为远端存储的缓冲，起到为磁盘IO“削峰填谷”的效果，消除对象存储瞬时性能的不足带来的影响。

根据前面对消息流数据冷热特征的分析，我们在消息生产时，先写入pagecache，再同步或异步地刷到本地数据段，异步地将数据段上传到对象存储中，并更新元数据。

对于冷数据往对象存储中卸载的过程，我们的设计是，从时间和空间两个维度出发，存储时间达到阈值，或超出存储容量阈值的数据，这部分数据已经不是访问的热点了，对访问的时延要求也没有那么高，可以由远端存储来承载，会被异步卸载到对象存储中。

消费消息时，根据需要拉取的数据位点，判断目标数据是否在本地存储，如果本地存储命中，则直接从本地存储获取数据，这种情况通常发生在及时消费的场景，往往在pagecache中就能命中，也就不需要产生真正的磁盘IO。当目标数据不在本地时，会尝试从远端存储进行拉取。

一种直观的想法是从远端把数据文件下载到本地磁盘，再从本地磁盘进行读取。

然而这种方式下，会因为IO串扰而导致严重的性能问题。我们知道，流式存储在实时消费场景吞吐很高，其中一个重要原因，就是消费的数据，在pagecache中能命中，也就是我们所说的热数据，直接从pagecache获取数据，无需缓慢的IO操作，如果出现大量的冷数据访问，数据已经从pagecache中被逐出，需要从磁盘中读取，就会导致磁盘IO，时延上升，并且pagecache中的热数据被冷数据逐出，导致及时消费的流量也需要从磁盘中读取，pagecache“失效”，也就是缓存污染问题。

如果我们把数据文件从远端下载到本地存储，再从本地存储进行读取，那么缓存污染问题依然存在，更加拖慢了访问的延迟，同时，因为多了从远端下载数据到本地的过程，增加了IO带宽的开销，每份数据要进行两次磁盘IO，导致额外的资源开销和时延开销，也增加了本地块存储的空间使用，在发生大量随机读时，会导致大量下载数据文件，使原本轻量的本地块存储变得不堪重负。

前面提到，消息流数据是流式的、过程性的数据，在访问冷数据时也具有这种特点，一段数据通常不会在较长一段时间内被反复访问，也就是通常不会有相对固定的热点数据，或者说热点数据是在持续变化的。

基于这种特点，我们实现了基于内存的远端数据访问机制，通过应用层内存池技术，对内存空间进行管理，将缓存的数据分为多个slice，和真实的数据段进行映射，数据访问不需要额外的磁盘IO，带宽占用更小、时延更低。而且实现了冷热数据的IO隔离，解决了pagecache污染的问题，吞吐能力提升20%以上。同时能够避免因大量随机读而导致大量下载数据文件，优化本地块存储空间，降低存储成本。

由于消息的访问通常是顺序的，因此对于即将访问的数据位置，通常是可预测的，可以通过提前预读下一块数据，提升数据从远端加载的整体性能，减小读取卡顿。

在缓存管理模块中，存在一个预加载水位，当某个slice的访问位点达到预加载水位时，缓存管理模块开始加载下一个或多个slice，该过程是异步执行的，并不会阻塞当前的读取操作。这样，当访问到下一个slice时，数据已经提前完成了加载，避免了因从远端加载而产生的卡顿。

目前业界主流的消息流平台，用户需要提前购买指定大小的磁盘容量，并持续关注磁盘容量使用率的监控，在容量不足时提前进行容量扩容，否则可能因为磁盘写满而影响业务。

在实际的生产环境中，业务量并不是一直稳定不变的，很多业务都存在业务高峰和低谷，如双11的流量突增等，相应的，对磁盘容量的需求也可能有较大的波动，在这种模式下，业务通常需要按业务量峰值来评估磁盘使用量，并预留资源，这就直接导致了在非业务高峰时期的资源的浪费。

据估算，目前业界消息流平台的存储使用率平均在20%-30%左右。

在分级存储架构下，由于大量的数据都被卸载到了远端对象存储，对于业务层而言，是一个统一的存储池，而且支持存储空间的按需使用和超长时间存储，无需预留存储空间，无需进行磁盘的扩容和缩容，消除存储空间使用率不高带来的成本浪费，提升资源利用率，结合线上统计数据，可以提升3-5倍的存储使用率。

同时，华为云对象存储服务通过存储介质的慢盘/坏道检测、AZ内设备和数据冗余、AZ之间数据容灾、跨区域复制等技术方案，提供针对介质、服务器、机柜、数据中心和区域的多级可靠性保障。其数据持久性高达99.9999999999%（12个9），可用性高达99.995%，远高于传统架构。

基于这种数据的高可靠和高可用，业务层在卸载数据时，只需保留主副本，减少了多副本对存储空间的额外开销。以三副本为例，在相同业务量下，可以减少约2/3的存储空间，结合存储按需使用带来的存储使用率提升，综合存储效率提升10-15倍。

在这种分级存储架构下，由于Broker本地只有有限的一小部分温数据，使得Broker变得更“轻量”，在进行集群扩缩容时，只需迁移Broker本地的一小部分的数据，大大降低了迁移过程中数据同步带来的负载影响，并且大幅缩短迁移时间。

这里我们会发现，在迁移过程中，同步的这部分数据，最终也会被卸载到远端存储，那么如果我们直接卸载到远端，就可以省去这部分的数据同步，通过远端存储来达到数据的“同步”。

这里我们用到了前面提到的逻辑存储的思想，将分级存储和逻辑存储结合，在分区迁移时，新的Broker只同步增量的数据，当需要发生主备切换时，原主会进行数据文件的切割，并将分段的数据文件卸载到远端存储，当卸载完成后，进行主备切换，切换过程在秒级完成，无需同步历史数据，10GB数据的节点，可在1min内完成卸载和主备切换。在高负载场景下也能实现高效、平滑的扩容。

对于故障的场景，基于引擎自身的主备能力，能做到秒级的感知、切换，配合客户端的重试机制，能做到业务不中断的故障自愈。对于部分节点故障导致的负载加重问题，由于计算节点没有历史数据，可以通过快速扩容节点和分区迁移，实现负载的均衡。

传统的消息流平台售卖方式，是基于实例集群的规格，用户需要知道每种规格对应的性能，需要评估节点规格、节点数量等，而用户关注更多的是能力，业务需要多少吞吐、多少TPS。我们在新的架构中，提供按性能指标售卖的模式，如TPS等，让用户根据性能指标选择所需的规格，回归业务本身，而无需关注底层资源，这也是Serverless化理念所倡导的。

计费主要分为计算部分、存储部分和增值服务部分。计算部分的计费模式为基础带宽/TPS + 弹性流量。当流量/TPS超出基础规格范围时，我们将允许一定比例的超限使用，即弹性流量，超出部分独立计费，避免流量突增场景对业务的影响，用户也无需为临时性的流量突增而扩大集群规格，减少资源的浪费。

通过这种模式，帮助用户更合理地使用服务资源，优化成本；存储部分支持按需使用，即根据实际使用的存储空间进行计费，不再需要进行存储的扩缩容；增值服务部分主要包含基本的消息收发之外的一些增量能力，如可观测日志功能、超出规格范围的topic数、数据同步等。

在这种分层存储的架构下，我们需要考虑每一层的稳定性，并提供相应的可观测和恢复能力。例如，我们会实时监控对象存储层的访问状态，当对象存储层出现访问异常时，能够快速感知，并自动调整块存储资源，避免IO受阻。

另外，传统的运维方式对运维人员的经验有较强的依赖，当线上业务运行产生异常时，往往需要运维人员后台排查，效率较低。目前，业界已有一些自动诊断的实践，这些诊断主要是对一些观测结果和异常项的汇总，如CPU使用率过高等，对于一些相对复杂的异常场景，如频繁rebalance导致消费延迟等，无法直接得出产生异常的原因和指导性的建议。

针对这些问题，我们基于长期以来积累的运维经验和可观测手段，实现了一键智能诊断的能力，在基础观测指标的基础上，做更深入的自动化业务分析，给用户呈现导致异常的原因和优化建议。

华为云消息流平台将基于共享存储池，构建高性能、高可靠的统一存储层，应用层无需感知多级存储概念，专注于业务逻辑，减少数据在多级存储之间转移带来的带宽开销，进一步优化成本。

同时，结合华为云底层硬件加速能力，将部分计算逻辑卸载到硬件中执行，降低CPU/IO开销，避免因大量CPU计算导致资源争抢、线程阻塞等问题，有效降低时延，实现十倍性能提升。

将状态从计算层完全抽离，消除副本概念，通过统一的接入层，在所有计算节点上负载均衡，扩缩容无需迁移分片。同时基于华为云Serverless底座，将计算节点轻量化，实现计算节点秒级扩缩。同时，支持存储计算“可分可合”的灵活架构，支持小型化场景部署。

在业务波动等场景，根据业务实时负载，自动感知，自动弹性扩缩，做到计算能力的按需使用。借助快速发展的AI能力，自动分析历史业务变化趋势，自动调整资源分配，做到精细化的资源控制。

在保障业务稳定的同时，也能进一步优化成本。同时，通过AI自动分析集群异常和不恰当的使用方式，实现自动运维、无人运维，能够“自动驾驶”的消息流平台。