43 未来：消息队列的技术架构会如何演进？
你好，我是文强。
到了本节课，我们就讲完了架构升级篇的内容，同时本专栏中纯技术的讲解也已经结束了。接下来我们开始经验总结篇的内容，主要分享我个人在消息队列方面的一些思考，包括未来发展、商业化、运维运营，以及消息队列领域的研发人员如何提升技术能力和产品视野这五个方面。每一讲的内容都将围绕一个问题展开，内容相对精简。
这节课我们就来梳理下消息队列的未来发展情况。
在业界的一些技术分享中，大家普遍会认为消息队列后面会往云原生、容器化、Serverless、Service Mesh 等等方向发展。技术理念听起来很高大上，也很符合当前技术的发展潮流。但不知道你有没有深入思考过，为什么是这几个方向，而不是其他方向呢？这几个方向的原始驱动力是什么？
价值导向的演化
在我看来，任何一个商业化的产品中，只有围绕“价值”出发，才能理清楚问题的本质。就是说做这个事情能带来什么价值，给用户、给平台带来什么价值。所以想要知道消息队列未来会如何发展，就需要先知道用户和平台要的是什么。
从用户的角度看，需求是很朴素的，用户对消息队列的诉求可以总结为三个词：省钱、能用、好用。无非就是花最少的钱，用最好的服务。而平台的要求就更简单了，就一个词：赚钱。就是从用户那里赚更多的钱。听起来是冲突的，有GAP点，怎么解决呢？
这就需要用技术来解决，即用技术来实现一个既能让平台赚钱，又能让用户省钱、好用且能用的消息队列。通过技术上的一些架构升级、代码优化、运维运营等手段，来提高单位资源（CPU、内存）可提供的服务能力，从而在同等资源配置下，能够提供更好、更优质的服务，达到双赢的效果。
那从技术落地的角度，围绕着这个目标，未来应该往哪些方向发展呢？我们来看一下。
五个发展方向
要达到这个目的，结合我们前面所讲的技术点，我们可以从融合型、多协议、Serverless、架构简单、云原生五个方面来做拆解。
融合型
在前面我们讲到过，消息队列从使用场景和功能的角度分为了消息和流两个方向，分别有各自代表的消息队列。对企业来说，一般都需要同时使用消息和流两个方向的消息引擎。此时遇到的问题是，学习、使用、运维多款消息引擎的成本过高。上节课我们讲到的消息中台，它所提供的统一的消息服务，就是为了解决这个问题。
因此，如果有一款消息引擎能够同时满足消息和流两个场景，就能很好地解决这个问题。这就是我认为的第一个发展方向，融合型的消息队列。那什么叫融合呢？
“融合”这个词参考的是数据库领域。数据库领域因为场景丰富，有各种方向的数据库产品，比如OLAP、OLTP等等。数据库领域为了创造能满足多种场景的数据库，提出了融合数据库的概念。意思就是这个数据库能同时满足多个场景，而不仅仅局限于某个场景。
从具体的功能点来看，融合型的消息队列应该同时具备流方向的高性能、高吞吐，消息方向的丰富功能、高可靠性、低延时、可追溯等等。
多协议
多协议是指未来的消息队列可以适配现有的多种协议。这个价值在于能够满足存量用户的需求，存量用户无需改造就可以直接使用。
我们需要认识到，引入一款新的协议，不管是私有协议还是公有标准协议，被用户接受并大规模使用都是非常难的。因为这涉及到业务侧 SDK 的变更以及业务逻辑的改动，这一点成本非常高，改动也很困难。
而从业界现状来看，当前存量的这些消息队列基本能满足需求，也都做得不错，并不存在非换不可的理由。因此，多协议适配的关键就在于跳过市场培育，减少教育用户的成本。只要在性能、稳定性、成本方面做好，就不会缺少用户。
Serverless
Serverless 这个词很高大上，简单理解就是集群需要具备即时扩缩容的能力。我们在第38讲讲过，它核心解决的是成本问题。
从用户的角度看，自建消息队列或者购买云消息队列 PaaS 产品时，困扰他们最大的问题就是容量评估和突发/闲置时的扩缩容。大部分用户对资源容量的评估都非常不精准，那么为了稳定性，就会倾向于申请更多的资源，从而造成很大的浪费，导致成本居高不下。
这样做的主要原因是消息队列是有状态的服务，扩缩容时需要迁移数据，而迁移时间不可控。因此，运维人员就会冗余更多的资源，避免业务突发导致系统出现问题。所以说，如果消息队列底层架构具备随时扩缩容的能力，就可以大大降低用户的运维成本和投入的资源成本。
从平台的角度看，提升产品竞争力的核心操作就是优化成本结构。让同样的资源提供更强的服务，那么在提供同样的服务时，成本自然就会比自建或友商更低。
而优化成本结构最主要的手段就是提高集群的利用率。但是提高利用率后，会遇到和用户一样的问题，如何应对突发？关键就是弹性扩缩容的能力。
但从技术上看，当前很多消息队列的底层架构都无法做到真正的弹性。所以，如果消息队列的底层架构能够做到真正的弹性，包括计算层和存储层的弹性，也就是实现消息队列的 Serverless化，那么就可以给用户和平台带来极高的价值。
云原生
有的人对云原生的理解，可能等同于 Kubernetes 和容器化，这是不太准确的。在我看来，云原生的意思是，在系统架构设计时就考虑利用云的各种优势特性，让系统更具竞争力。竞争力可以是成本更低、扩容更快、稳定性更高等等。
上面这句话不太好理解，这里我们可以通过容器、虚拟云盘、对象存储三个云计算中的基础产品，来说明一下什么叫做消息队列的云原生。
容器指自建或云上K8s集群/容器服务。现在很多主流消息队列都可以容器化部署，但并不能说是能在容器中运行了。关键是消息队列能利用到容器带来的好处。那容器的好处是什么呢？容器的好处就是轻量、扩缩容快，能够自动快速地创建出资源。
但是我们前面讲过，作为一个有状态的服务，光是把服务启动起来是不行的，还得把服务迁移过去，才能承担流量。所以消息队列容器化除了能够部署在容器中以外，还得从架构上考虑当拉起新的容器节点后，新节点如何快速承载流量。这就是我们说的快速扩缩容的能力。
虚拟云盘指云上的硬盘，它的特性是底层本身是多副本存储的。所以相对物理硬盘，它最大的特点是数据不会丢失，但是单位成本更高。所以基于数据不会丢失的特性，在架构设计的时候，就可以思考是否在消息队列层移除副本概念，从而降低系统架构的复杂度以及成本。
对象存储是云上的文件存储服务，它最大的特性就是存储成本低。就是说，相对本地盘、云盘存储，成本会便宜很多。所以为了优化成本结构，提高竞争力，我们就可以基于对象存储来设计存储层，从而降低存储成本。
所以说，在设计架构的时候考虑云上的这些基础产品，利用好它们的优势，设计出有竞争力的架构，这才是我理解的云原生架构。
架构简单
架构简单这个词经常被忽略，我个人认为是非常重要的。当我们在内核中堆叠功能、添加特性的时候，系统架构就会膨胀。比如我们在前面课程中讲到的存算分离、分层存储、多协议兼容、集群容灾等等特性，当增加这些特性时，系统就会不自觉变得复杂。所以我们要有意识地控制系统的复杂度，从编码技巧、架构设计的角度尽量让系统更加简化、简洁。
上面这句话有点空，没有具体的落地措施，我可以进一步再说说。这里我想表达的是，设计架构时需要保证简洁的理念，不要追求奇技淫巧，追求复杂度和高大上，前面其实讲过挺多了。就比如我们在第15讲和第16讲讲集群构建时，集群的元数据有基于第三方组件来存储和集群内部自实现存储两种方案，从架构简洁的角度看，我就会建议你使用第二种方案。
这里我们总结几个简单架构的好处。
- 内核的开发工作量更少。
- 集群更稳定，问题更少。因为架构更简洁，出问题的概率就越低。
- 部署时需要的资源更少，成本更低。
- 研发运维人员的学习成本更低。
- 可以部署在更多的场景，比如边缘计算、小型机房等等。
所以总结来看，架构简单的最大好处就是可以降低成本。
通过上述这五个发展方向，你会发现，它们都是围绕着“价值”这个词推导出来的。未来的消息队列，技术方向可能会有调整，但是从核心来说，是不会变的，就是能产生什么价值。
接下来，我想带你简单设想一下未来的消息队列可能是什么样子的。
融合型消息队列的设想
基于价值和成本思维，我希望有一个融合型消息队列，它能同时满足消息和流两个方向。架构图如下：
这个架构由三台 Broker 组成，没有依赖第三方组件。从上到下分为接入层、协议适配层、计算层、存储层四个部分。希望满足的是：
- 架构简单。比如不依赖第三方组件来完成集群构建和元数据存储，达到只有一台节点也可以启动服务。此时这个消息队列就可以部署在小规格的节点、边缘计算场景等。
- 多协议。即在网络层适配多种存量协议，比如MQTT、AMQP这种标准协议，用来满足现有业务接入的需求。使用者根据需要去启用相关协议来支持服务，从而满足同时使用多款消息队列的业务团队，达到一个企业只需要部署一款消息队列服务的效果。
- 计算层独立。即在计算层实现各种消息队列的功能，比如顺序消息、延时消息、事务消息等等。跟协议层进行联动，从而兼容现在各种主流消息队列，达到功能复用，满足各种消息队列的需求。
- 存储层插件化。默认情况下是本地存储的模型，如果需要可以配置开启存算分离或分层存储的特性架构，用来满足不同场景对存储性能和成本的要求。
这是一个很宏大的设想，从落地的角度看，开发难度高、成本高、周期长。但我觉得从终态来讲，从用户的诉求出发来设想消息队列的未来是没问题的。用户未来需要的是一个内核高度稳定、支持多协议、架构简单且有弹性、学习&部署&运维成本低的消息队列。
总结
对于技术发展的思考，因为站的角度、过往经历、业务需要的不同，每个人的观点会有一些不同。所以这节课仅供参考，你也可以说说你的想法，我们交流探讨。
从消息队列发展的角度，我觉得目前的趋势都是围绕着云原生来演进的。因为随着云技术的发展，比如云盘、对象存储、容器、安全等技术的发展，基于这些产品设计架构和基于物理机来设计架构，思路存在很大的不同。所以，在思考未来技术演进时，我建议你多去理解理解云计算相关的技术或者应用场景。
从价值思维出发，我认为融合型、多协议、Serverless、架构简单、云原生这五个方向是用户需要的，且能带来真正的价值。
从落地的角度，我们得认可构想和落地复杂度之间是存在巨大鸿沟的。所以我们应该从终态去设想，一步一步去落地。要避免落地时高屋建瓴，摊子铺得太大。用户的诉求是非常朴素的，他们要的就是省钱、能用、好用。其中，能用、好用是前提，没有这两点，省钱也是没用的。所以说内核的稳定是非常重要的，不可忽略。
思考题
- 你觉得消息队列未来的发展方向是怎样的？
- 在融合型消息队列的设想中，你觉得它还需要具备哪些能力？
期待你的分享，如果觉得有收获，也欢迎你把这节课分享给身边的朋友。我们下节课再见！
上节课思考闭环
在消息中台的接入层，你认为需要支持多协议的接入层吗？从工作量和业务侧需求的角度来看，你是怎么思考这个问题的。
从个人角度来看，消息中台支持多协议的必要性不强，最多支持一种企业内部用得最多的消息队列协议就可以。
1. 从投入的角度看，支持多协议的开发成本太高了，会消耗大量的研发人力，并且投入周期长。
2. 从稳定性的角度看，多协议会导致业务侧直接使用开源的SDK，平台侧无法控制业务侧的使用方式，从而无法统一收拢、规避和降低风险。
3. 从长期维护的角度看，多协议长期维护和配套设施建设的成本就很高。
4. 从业务的角度来看，业务其实不一定需要这么多协议。而且，如果不限制业务的使用姿势和规范，还可能会带来一些未知的稳定性问题，所以我们往往还要限制使用多种协议，这是很有必要的。
- Geek_ec80d2 👍（0） 💬（1）
从客户需求的角度来说，是既要，也要，还要的态度。 客户的贪婪及厂家的功能贪多，会导致软件功能的膨胀，架构的复杂，稳定性的下降等。这个就注定后端不可能简单。很多产品就是这样一步一步变复杂和臃肿的。所以架构简单和功能齐全本身就是矛盾的。 其实还有一种可能的发展思路，就是软件分工的细化。比如把很复杂的功能分为多个更加专业的软件去实现，这样的解耦，更有利于后续的灵活更换和升级。
2023-09-27 - 怀揣梦想的学渣 👍（0） 💬（0）
我对软件上云及容器化部署的理解，主要是为了规避单机化部署的风险，当前无论是超融合还是多台物理机集群，但凡要业务经过等保及其他安全审核，都要面对长期的相对频繁的补丁更新，对业务稳定性是风险引入，若容器化部署，底层随便动，容器动态切换物理机运行，不会因为物理机的补丁更新产生业务影响。
2024-11-18 - jackfan 👍（0） 💬（0）
虚拟云盘指云上的硬盘，它的特性是底层本身是多副本存储的。所以相对物理硬盘，它最大的特点是数据不会丢失，但是单位成本更高。所以基于数据不会丢失的特性，在架构设计的时候，就可以思考是否在消息队列层移除副本概念，从而降低系统架构的复杂度以及成本。 这里说的基于不丢失的特性移除副本；但是这个不丢失的特性 应该是副本赋予的。如果移除副本 这个不丢失的特性还会存在吗？
2024-03-20