是时候基于云重新设计Kafka！AutoMQ如何实现Kafk

　　作者Tina
　　在过去的十年里，随着移动互联网和云计算的高速发展，我们成功地克服了基础设施方面的各种挑战。在这十年的历程中，我们深刻认识到传统的消息和流存储架构无法充分发挥出云计算带来的技术红利和成本优势，也无法应对迅速增长的技术挑战。因此，我们需要重新设计这一关键领域，以释放云基础设施的潜能。
　　Kafka和RocketMQ在众多企业中得到了广泛的应用，但也面临着巨大的技术挑战。这些挑战包括如何确保超大规模集群的可用性，如何避免运维操作中的故障，以及云服务提供商如何为数万家企业提供云上消息服务。早期，我们依靠手动参数调整来解决这些问题，后来逐渐积累了各种工具来实现自动化运维，但是距离大家畅想的终态仍有距离。
　　另一方面，技术不断在发展。2014年，AWS推出了Lambda服务，让开发者可以彻底摆脱服务器的运维，2018年，Google推出了Cloudrun，极大拓展了Serverless的场景，可以让任何基于HTTP的服务都能被GoogleCloud托管。ApacheRocketMQ的作者王小瑞，以及ApacheRocketMQ联合创始周新宇，曾在阿里巴巴负责了十年以上的消息中间件研发工作，他们于2018年开始推进阿里巴巴内部核心业务的云原生Serverless化，目标是如何让成千上万个应用不用关心线上机器容量，做到扩缩容全自动，甚至一分钟就能创建一个生产级可用的面向互联网的分布式应用。这也为他们带来了启发：RocketMQ和Kafka是否也有机会做到这样，像一个Lambda函数一样，不需要关心服务器运维。于是章文嵩博士和他们共同成立了一家新的公司，安托盟丘（杭州）科技有限公司（以下简称AutoMQ），专门致力于打造云原生的消息队列。
　　AutoMQ公司为Kafka和RocketMQ设计了全新架构，完全构建在云厂商的对象存储之上，带来了10倍的云账单节约，更是将最复杂的数据存储卸载到了云服务。据AutoMQ联合创始人章文嵩博士介绍，Snowflake是第一个将数仓完全构建在对象存储之上，带来了巨大的成本优势和每个用户独占计算资源的多租户隔离效果。而MQ这个领域是一个典型的分布式存储系统，越来越多的企业将MQ用在了核心业务的关键链路上，但是目前市面上还没有一款MQ产品像Snowflake一样彻底构建在云上，相信完全基于云设计的MQ会带来巨大的技术优势。
　　最近，由AutoMQ和InfoQ共同主办的《ApacheKafkaRocketMQ云原生创新论坛》将于11月4日在杭州举行。为此，InfoQ采访了AutoMQ的核心团队，以了解他们在ApacheKafka和ApacheRocketMQ领域的最新见解以及最前沿的架构设计理念。
　　InfoQ：在大数据以及AI时代需要什么样的流处理软件？
　　AutoMQ团队：大数据时代，企业数据的爆发式增长，对传统的流存储和流计算软件带来了巨大的挑战，这背后需要海量的算力和存力进行支撑，传统的IDC架构无法应对这一挑战。幸运的是，云计算天然具备这些属性，但用云并不是简单地将传统的软件架构Rehost到云上，其本质是将IDC架构平移上云，无法发挥出云基础设施的规模化优势，只有重塑软件的架构，面向云原生进行设计，才有机会将云的优势转换为生产力的优势。
　　对于AI，其对算力和存力的需求更是达到了巅峰，传统的软件架构绝对无法满足AI的需求，我们认为AI的基础就是云原生，只有将云原生红利释放给AI，才能催生出百花齐放的AI技术应用，才能将AI变得更加普惠。
　　综上所述，面向云原生重新设计流存储和流计算软件，释放基础设施的巨大潜力，向云计算要技术红利和成本红利，让云原生和AI相关的应用技术变得更加普惠，是大势所趋的。
　　InfoQ：AutoMQ为什么选择了Kafka、RocketMQ和RabbitMQ？还会兼容哪些消息系统？
　　AutoMQ团队：Kafka代表了流式存储的事实标准，并被众多开源项目如Flink、Spark、StarRocks等广泛集成，拥有最广泛的开发者群体，RocketMQ和RabbitMQ则在微服务和应用消息领域被广泛使用。他们都代表了Messaging和Streaming的开源生态。
　　RocketMQ经过阿里巴巴多年双十一的万亿级消息峰值验证，已经是互联网微服务架构的必选项，在国内有数十万企业部署在生产系统。
　　我们希望基于云重新设计这一关键领域，为这三个开源产品提供更好的云原生支持，以便更多的开发者能够受益。
　　InfoQ：关于选型，对比利用开源自建，用户什么时候该选择托管方案？
　　AutoMQ团队：对企业来说，成本和效率是首要考虑的因素。此外，如果涉及到闭源软件，可能会引发厂商锁定的问题。在当今，架构师通常更倾向于选择开源项目作为基础软件的首选。
　　总拥有成本TCO是用户选择的关键，这个产品自建需要的机器成本和人员维护成本以及对软件深入度不够带来的宕机风险综合成本决定了客户的选择，如果托管方案明显优于开源自建，那么用户选择托管方案是最合适的。
　　如果用户的业务非常关键，那么也不建议自行搭建，因为完全掌握一个开源软件达到满足业务匹配的可用性要求，付出的人员成本和时间成本都是非常高的。
　　开源软件永远无法达到终态，绝大部分开源软件开源的是核心代码，核心代码距离生产环境高可用的服务还有巨大的差距，这里需要大量的周边工具配套以及专业工程师的持续维护。而托管方案可以非常高效的完成这个工作。
　　InfoQ：以Kafka为核心，Confluent开启ProjectMetamorphosis计划重新设计了适用于云的ApacheKafka，同时，在Kafka最新（3。6）版本中，Confluent开始提供TieredStorage功能，可将ApacheKafka作为完全托管的服务，部署在用户选择的云中。那么ApacheKafka中的托管服务和AutoMQ托管解决方案之间的差异是什么？
　　AutoMQ团队：最大的差异是：彻底的云原生化。
　　我们理想中的云原生Kafka应该能做到计算、存储、网络按量付费，并且理论成本最优，系统可以随着业务负载自动调整机器数，整个过程对上下游完全透明。
　　要做到计算实例的按量付费，就必须从传统的使用Reserved实例变为Spot实例，这样才会真正达到按量付费的效果。
　　AutoMQ将对象存储作为了主存储来使用，而非TieredStorage，这样整个存储的复杂度就彻底卸载到了云厂商，几乎让Kafka集群，RocketMQ集群做到了无状态，即使使用Spot实例来部署Broker，也能在Spot实例被回收之前所有状态数据同步到对象存储，这样整个计算实例销毁无需数据再平衡，其他节点自动从对象存储接管宕机节点的分区，做到分区秒级被接管，扩缩容同理，分区数不因为增加节点而变化，数据不因为扩缩容产生热点，系统全自动在数秒钟达到最优状态。
　　AWS的S3背后有数百名工程师经过数年的不断优化，目前已经是世界上最便宜的存储之一，并且能保证超高可用性，同时跨AZ网络流量是免费的。其他云厂商的对象存储也同样投入巨大，我们相信彻底基于云厂商先进的IaaS架构重新设计的Kafka和RocketMQ能带来无与伦比的技术优势。
　　InfoQ：在成本管理方面，AutoMQ提供了哪些降本增效方案？能达到什么样的效果？
　　AutoMQ团队：我们了解到，基于当前的开源Kafka等技术架构，大部分企业进行降本增效的有效手段是进行取舍，比如牺牲数据存储时长来降低存储成本，或降低存储的副本数来优化整个IaaS层的成本。这些手段要么牺牲了业务的灵活性，要么牺牲了可用性或者可靠性，对业务的挑战是巨大的。
　　现在，AutoMQ通过寻找云上的最佳实践，来重新设计Kafka的架构，期望的目标是将成本做到云上理论最优，要完成这个目标我们主要的方案分为两个步骤。
　　第一步是面向云的计费项去重新设计整个分布式的架构，开源的ApacheKafka在生产环境的成本结构大致为网络：存储：计算5：3：2，对于这三类计费资源AutoMQforKafka的降本方案为：
　　网络：主要是在Kafka多副本且跨可用区场景带来的流量费，AutoMQ将数据可靠性问题转移给自带3副本的EBS和可靠性达11个9的S3，同时通过共享存储来解决可用性问题，避免引入多副本机制，通过云带来的技术红利解决可靠性和可用性问题。这一方案可以在消除复制带来流量费的同时，会同步节省存储和计算费用。
　　存储：将存储的每一个计费项参与到架构设计当中，以S3为主存，同时优化S3的API调用将存储成本降低一个数量级；以EBS为WAL，优化EBS的空间到10G内，完全的顺序写将IOPS优化至数百。
　　计算：将存算分离架构发挥到极致，将存储的复杂度卸载到云，将计算优化至无状态，从而能够最大程度地将Spot实例的成本优势发挥出来。
　　在面向计费项重新设计整个架构后，下一步是要兑现云最核心的优势按量付费，这要求整个架构是完全弹性的，通过极低成本完成ScaleOut和ScaleIn，对于EC2和EBS要最小化保有时间。这对于开源的Kafka来说是极为困难的，因为扩容意味着需要流量快速重平衡，缩容意味着要求数据能快速完成迁移，这些都是开源Kafka很难完成的任务。AutoMQ弹性的分布式架构能够将按量付费的技术红利充分释放给Kafka的用户，具体的架构详情将在11月4日的会议上进行分享。
　　InfoQ：在此之前的流平台，对于不同等级的数据量，比如PB、TB以及一些小企业的情况，其成本主要来自哪些地方？
　　AutoMQ团队：基本上，一个分布式的系统其对资源的消耗和数据规模是呈线性关系的，所以物理资源上的成本基本上是集中在计算、存储和网络上。
　　但除了资源成本，另一项无法忽视的成本是运维成本，它跟规模的关系将变得更加复杂，大规模的数据场景下，将会带来更多的运维挑战，比如识别性能瓶颈、快速解决容量问题、大规模的集群和数据治理、稳定性治理等。以我们了解到的情况来看，PB级别的数据量，一般需要一个5到10人的专业研发和运维团队来提供技术支持。在TB级别的系统上，人员成本占比会更高。
　　InfoQ：流处理的Serverless模式能带来哪些好处？
　　AutoMQ团队：Serverless模式最直观的好处就是成本优势，Serverless架构能够将计费资源转换成按量付费的模式，最小化计费粒度，比如将流存储依赖的计费资源全部变成Serverless模式后，成本至少下降一个数量级。
　　另一方面，Serverless模式将会加速技术的成熟，特别是流计算相对于批计算来讲，批计算因为是周期性地进行批处理，实际上是一种按量使用的模式，比如每天申请一批资源完成特定的计算任务，所以批计算相比流计算天然就具备成本优势。流计算是一种实时计算，需要时刻保有计算和存储资源，如果流计算依赖的技术栈完全是Serverless的，带来的成本优势将加速流计算的普及和成熟。
　　InfoQ：有观点说，基于容器的Serverless实现方式需要通过用户负载来进行动态资源调度，要高效利用资源并不容易。目前，AutoMQ的无服务实现方式是什么，怎么达到高效利用资源的？
　　AutoMQ团队：Serverless从来就不是一件容易的事情，AutoMQ团队除了有丰富的云计算商业化经验以外，也负责了阿里巴巴的在线业务Serverless化，这其中有几个主要的挑战为：
　　用户负载的不可预测性：理想情况下，将集群水位控制在100是最经济的方案，但在实践过程中，往往需要预留充足的水位来应对不可预测的流量。AutoMQ解决这个挑战的方案为充分利用基础云产品提供的Burstable的能力，比如EC2、EBS和网络，都会提供10x左右的Burst能力，虽然持续时间短，但会为弹性扩容提供宝贵的时间。甚至，对于EBS，完全可以通过一个API修改IOPS和吞吐上限即可完成扩容。
　　资源的碎片化：衡量一个调度和弹性平台的一个重要指标就是资源的碎片化，一个显而易见的事实是，一个集群成员的规格越大，整体产生的碎片化越严重，规格越小，越容易消除碎片。AutoMQ面向小规格进行设计，比如2C的机器单元，将CPU、内存、存储带宽、网络带宽都充分利用起来，非常有助于在各类弹性平台中大幅度减轻资源碎片化问题。
　　快速的冷启动：我们在解决阿里巴巴在线业务的Serverless问题当中，发现一个复杂的应用，启动时间可能是10分钟级，在如此慢的冷启动的前提下，Serverless难度将进一步被加大，不能快速ScaleOut，也就不敢随意地ScaleIn。彼时，我们的解决方式是快照恢复方法，通过对进程进行内存快照，在ScaleOut时快速Restore出来，大家可以发现，近两年业界很多函数计算平台比如Lambda，华为云的FunctionGraph都陆陆续续采取了类似的方案。但对于RocketMQ和Kafka这类存储软件来讲，最耗时的过程还是扩容后，流量能否快速迁移过来达到负载均衡的状态，对于Kafka，迁移分区是小时级别的。为了解决这个问题，AutoMQ的方案是从SharedNothing架构走向SharedStorage架构，当存储变得共享后，移动一个分区是秒级的，也意味着扩容时可以快速达到流量重平衡，缩容前可以快速将分区迁移走，极大地降低了Serverless实现的难度。
　　综上，AutoMQ通过充分利用云的Burst能力，云产品的API能力，小规格的部署能力，共享的存储能力来达到高效、经济地利用云资源的效果。
　　InfoQ：对于未来五年，你们有什么样的产品规划？
　　AutoMQ团队：云的普及和发展不仅为技术架构的变革提供了契机，同样也为产品创新提供了新的土壤和空间。众多产品思考和创新逐渐从不可能变成可能。
　　AutoMQ作为新一代云原生消息队列技术服务商，我们持续专注于挖掘云基础设施的技术红利，为客户提供低成本、高性能、高可靠的消息队列和流存储解决方案。
　　在未来，我们将关注以下几个方面：
　　成本经济性：正如上面降本增效的话题所述，AutoMQ会持续挖掘云基础设施的技术红利，结合云资源计费项粒度的技术架构调优，在架构弹性、资源调度、请求优化等方面继续突破，为企业客户提供极具成本竞争力的产品方案，帮助企业科学降本。
　　数据集成和价值挖掘：AutoMQ提供的新一代RocketMQ、Kafka消息流存储服务，使用对象存储作为主存储，所有业务数据原生存储在对象存储中，可以完美地和当下主流的数据湖、数据仓库等方案进行集成整合。这一天然优势可以消除ETL的架构复杂度和运维成本问题。
　　多云一致输出：多云和混合云架构在企业中越来越受欢迎。AutoMQCloud从第一天设计开始就坚持CloudAnywhere的理念，将云厂商底层基础设施的差异性屏蔽，为企业用户提供多云一致的消息队列和流存储服务，方便企业在多云、混合云场景下构建一致的容灾和数据集成架构。
　　专家经验产品化输出：AutoMQ研发团队积累了十多年的消息队列生产运维经验，我们一直在探索如何将消息队列的生产运维经验以产品化工具和服务的形态普惠开发者。近期发布的AutoMQCopilot产品就是这样的一款工具产品，未来我们会面向更多的开源消息队列产品提供类似的工具和服务。
　　活动推荐：
　　在云原生技术的浪潮中，我们如何更好地理解和应用ApacheKafka和ApacheRocketMQ的实际案例和最佳实践？11月4日，我们邀请你来参加“ApacheKafkaxRocketMQ云原生创新论坛”，本次云原生创新论坛将重点探讨它们在不同行业和领域的应用案例，以及如何充分利用这些技术来解决复杂的业务挑战，同时也会有基于云彻底重新设计的Kafka和RocketMQ技术方案分享。可扫描图片中的二维码或点击以下链接报名参加：https：www。huodongxing。comevent9725831485900
　　本文转载来源：
　　https：www。infoq。cnnews9U6Nue5fTLPRNCKXYJ8T