文|有风
编辑|有风
现在企业搞微服务通信、实时数据分析，几乎没人离得开ApacheKafka。
这东西从2011年开源到现在，早就成了分布式消息领域的"事实标准"。
不管是银行的交易系统实时对账，还是电商平台的推荐算法，背后都有它在默默扛着消息传输的活儿。
不过最近几年情况有点变化，企业们都忙着把系统搬到云上，Kafka这套老架构开始有点跟不上趟了。
原来在本地数据中心玩得转的"存算一体"，到了云上反而成了麻烦制造者。
展开剩余85%传统Kafka的"老毛病"，存算一体为啥在云上玩不转？
Kafka刚出来那会，存算一体是个挺聪明的设计。
2010年代初网络带宽有限，把消息存储和计算节点绑在一起，能减少数据传输。
那时候大家都在本地机房部署，服务器硬盘够大，这么玩没问题。
但到了云上就不一样了，你想扩存储？不行，得连计算资源一起买，想加计算节点？存储又跟着浪费。
就像租房时房东非要你把床和衣柜捆在一起租，哪怕你只需要大点的衣柜，也得被迫扛个更大的床，这不折腾人嘛。
跨可用区部署更头疼，Kafka为了高可用，数据得复制到不同可用区。
传统架构下，生产者发消息到主节点，主节点再复制到其他可用区的从节点，光是这来回复制的流量成本，就能让财务部门肉疼。
有企业朋友吐槽，有时候跨区流量费比服务器本身还贵。
企业上云是大趋势，谁也挡不住。
但传统Kafka这种"存储计算绑定"的老架构，就像给云原生穿小鞋，跑不快还难受。
大家都在找新出路，这时候DisklessKafka架构突然冒了出来。
Diskless架构，把Kafka从"硬盘依赖"里解放出来
Diskless，翻译过来就是"无盘"。
核心思路特简单，把消息存储和计算节点彻底分开。
计算节点（也就是Broker）变成无状态的，只负责处理消息转发、请求响应，真正的消息数据，全存到对象存储（比如AWSS3、阿里云OSS）里去。
这招直接解决了传统架构的老大难问题，存储不够了？单独扩对象存储就行，不用动计算节点。
计算资源紧张了？加几台Broker，存储那边一点不受影响。
弹性伸缩这块，直接上了个大台阶。
成本也降得明显，对象存储比云服务器的本地硬盘便宜多了，而且能按需付费。
原来存10T数据可能要10台服务器的硬盘，现在丢对象存储里，成本能砍一半都不止。
但得说清楚，这和Kafka之前搞的分层存储（KIP-405）不是一回事。
分层存储是把老数据挪到远程存储，新数据还得放本地硬盘，相当于给老房子加个储藏室，东西还是得先堆客厅。
Diskless是彻底不要本地硬盘，所有数据直接进对象存储，等于直接住个没有客厅只有储藏室的新家，思路完全不同。
现在市面上做DisklessKafka的不少，WarpStream、BufStream各有各的招，Aiven这些商业公司也在推类似方案。
但要说开源又能直接用于生产环境的，AutoMQ算是独一份。
AutoMQ的实践，怎么让无盘架构既好用又靠谱？
做技术方案最怕的就是"为了创新而创新"，最后用户用不起来。
AutoMQ聪明的地方在于，它没另起炉灶搞一套新协议，而是100%兼容Kafka的现有协议。
企业原来怎么用Kafka，现在用AutoMQ就怎么用，代码不用改一行，这对企业来说太重要了，谁乐意折腾业务系统改造啊。
性能这块也得解决，消息都放对象存储，延迟会不会太高？
AutoMQ搞了个三层架构，内存缓冲区先兜住消息，然后通过类似数据库的预写日志（WAL）保证数据不丢，最后异步批量刷到对象存储。
就像你先把零钱放钱包，满了再存银行，既方便拿又安全。
跨可用区流量成本也优化了，它会让同个可用区的Broker代理写入数据，生产者不用直接跨区发消息，流量费一下子就降下来了。
有朋友算过，用这套方案，跨区流量能减少70%以上，这可不是小数目。
元数据管理用的是Kafka最新的KRaft协议，把分区和Leader的映射关系、数据在对象存储的位置这些关键信息管好。
元数据模型做得特别精简，所以整个系统跑起来很轻快，不像有些方案搞一堆协调器组件，越搞越复杂。
从存算一体到存算分离，Kafka这步转型其实是云原生时代的必然。
传统架构在本地数据中心的土壤里长得挺好，但到了云上就得换个活法。
AutoMQ的实践证明，只要找对方向，把兼容性、性能、成本这几点平衡好，无盘架构完全能扛起企业级应用的大旗。
现在越来越多企业开始试Diskless架构，社区里讨论也越来越热。
估计要不了几年，无盘会成为Kafka在云上的主流玩法。
对还在被传统架构折腾的企业来说，AutoMQ这种"拿来就能用"的方案，确实是个不错的选择。
毕竟技术最终还是要服务业务，好用、靠谱比啥都强。
发布于：江西省