44 商业化：消息队列的商业化应该怎么做？

你好，我是文强。

这节课我们来聊聊消息队列的商业化。

从本质上看，我们企业内部的运维团队给业务侧提供基础服务，也属于商业化的一种，只是没有通过商业收入的形式来体现而已。而在云计算快速发展的今天，有很多To B的公司在做一些基础产品的交付，比如各大云厂商、各个垂直领域的服务提供商等等，甚至企业内部的运维团队也希望通过一些渠道把技术能力做一些商业化输出。

那么在日常工作中： To B 基础产品的商业化或消息队列的商业化要怎么做呢？都需要注意哪些事情？ 这两个问题经常被提及，接下来说说我的理解。

企业内部服务 vs 商业化产品

在业界，做商业化产品的技术和产品人员有一部分都是做企业内部服务出身的。但从落地来讲，做好企业内部服务和商业化产品有很大的区别。

关键就在于： 作为服务方的我们，思考问题的角度是不一样的。举例说明。

例1： 你发现某款消息队列的某个语言的SDK的兼容性不好，在某些异常的情况下会导致业务异常。

此时如果是企业内部的运维团队，一般会直接联系业务方切换 SDK，然后发布规定，业务侧以后不允许使用这个SDK，强调使用出问题后果自负就可以了。

而如果是商业化的产品，则有两种方式：一种处理方式跟上面差不多，就是在官网发出声明，说某个SDK存在风险，不建议使用。二是本着更加负责的态度，帮助用户解决这个问题，或者出一个健康检查机制，每日做风险告警。

例2： 我们在消费的时候，经常有消费堆积的情况，而在某些情况下，消费堆积会导致下游业务异常。

此时如果是企业内部的运维团队，就可以强制让每个业务团队给每个消费分组都配置上堆积告警，有堆积就告警，然后业务参与处理。因为是企业内部的合作，推进起来也会比较简单顺畅。

而如果是商业化产品，则不能使用这个策略。因为每个用户的情况不一样，有可能这个用户的某些消费分组是废弃的，或者一些消费分组就是允许堆积的。如果强制配置告警，则会产生很多误告警。

总结来说，对于企业内部服务，我们是有一定的规则制定权的，业务也会按照我们的规则来办事。而像消息队列这种开源产品，业界和社区已经有使用规则了，用户就会按照业界和社区的规则来使用。

所以针对商业化产品，在实际服务的场景中，我们就要充分考虑用户的使用背景和诉求，寻找合理的途径去帮用户解决问题，给他们的业务带来价值。甚至，即使用户的诉求不合理，我们也得通过合理的途径去满足，实现双赢。

接下来我们看看消息队列商业化产品的竞品是谁。

竞品是谁

这个问题看起来非常好回答，竞品不就是友商吗？比如各个消息队列领域垂直服务商、各个云服务厂商等等。

如果这样回答就有点浅了，从实际运营的角度看，竞品可以归为 友商竞品 和自建两大类。友商竞品就是刚刚说的同行，自建则是用户自己购买物理资源去搭建的消息队列服务。

这里有一个点需要关注，因为消息队列是一个基础的中间件产品，所以就会有一个现象： 用户不会因为消息队列产品便宜或者贵，而决策是否使用某个平台。

也就是说，用户使用某个平台，不是因为消息队列便宜才上的。而是因为更大的决策，比如使用这个云平台能整体节省多少成本。用户往往基于这个决策，结合业务整体上云的过程，去判断是否使用云上的消息队列。此时用户就会对比产品的功能、稳定性、性能、价格等等。如果合适，就用；如果不合适，就自建。

当然，现在很多企业都在追求跨云架构，所以很多企业都是跨云部署的。如果我们的价格比友商更便宜，用户也会考虑从友商迁移过来。

所以从用户视角来看，思考选型的路径就是： 先和友商对比，再和自建对比。 商业化的产品会有一些配套的成本，不过友商之间的技术方案都差不多，因此价格很难拉开差距。而消息队列是开源的，用户可以基于开源的内核搭建对应的服务，因此自建就只有资源成本了，且相对较低。

所以，从消息队列的角度出发， 自建才是商业化产品最大的敌人。这也促使我们提升技术，加强竞争力。

知己知彼，那么用户真正想要的是什么呢？

用户要什么

这个问题你可能会回答，价格、稳定性、性能、功能、服务态度等等。这些回答都很对，但是我想强调的是： 用户是多样的，用户的需求也是多样的，我们需要主动去识别用户的需求。

举个例子。在接触某个用户的过程中，他选择我们的理由是可以使整体成本大幅降低。但是有个背景，他们的消息队列规模占总成本的比例不高，但是熟悉的研发人员都离职了，迁移消息队列服务需要改业务代码。此时他们关注的点就是，能改就迁，不能改就不迁，成本不太关注。此时用户需要的就是能帮他改代码，并且迁移成功，这样可以降低他以后的维护成本。

不过，改代码是商业化产品的服务范畴吗？仁者见仁，智者见智，答案各不同。

这里我想表达的只是用户需求的多样化。而这个例子，其实也是一个特例，用户普遍还是关注 价格、稳定性、功能 这几个方面。经验来说，头部用户更关注价格，中长尾用户则优先关注稳定性和功能。这是因为头部用户大多有较强的研发能力，可以解决稳定性和功能的问题，而中长尾用户做不到这点。

或许你会说，这些事情不都是产品或者销售同学需要思考的吗？

当然不是，做商业化产品的研发人员也需要具备用户思维和产品思维。因为所有商业化的技术属性很强的基础产品，很多时候只有研发知道用户要什么，只有基于使用经验和技术理解，才能基于场景理解用户痛点。

接下来我们看看消息队列商业化的技术路线。

关于技术路线的思考

对于商业化的基础软件产品来说， 技术是底座、是核心，也是产品能否成功的关键因素。所以，技术路线的选择、落地的质量是关乎产品成败的。

这部分内容我将从方向和落地、开源或自研、生存或技术、共享或独占四个角度来聊聊我自己的理解。

方向和落地

从产品的角度，“技术”这两个字需要拆解为方向和落地这两个词，和我们经常听到的战略和战术意义是一样的。 在To B的商业化产品中，方向是比落地更重要的。

在做一些应用系统时，即使技术方向错了，大不了底层代码差一点，架构落后一点，可以通过各种手段，比如扩容资源来让业务正常运行。只要业务能用，投入人力慢慢重构和升级是可以接受的。这也是我们一直在说的，互联网的架构是升级出来的，而不是设计出来的。

但是做To B的商业化产品，这样是不行的。因为我们的用户是研发运维人员，只要我们的技术架构有缺陷，比如稳定性、性能、成本结构等等存在明显缺陷，它们就会立刻感知到，然后转友商、转自建。我们控制不了用户的行为，用户也不会接受我们的不足，等用户流失了，再想拉回来就难了。

所以成功的基础软件产品，第一步就是： 定好明确的方向，避免“一将无能累死三军”。随着开源软件技术的发展，以及国内计算机教育的普及，国内拥有很多优秀的研发人员，所以只要方向对，落地基本不会存在什么卡点。

开源或自研

我们前面讲过，消息队列产品一般是因为开源社区的兴盛，从而推出相应的商业化服务。所以在技术路线上，就会有基于开源或者自研两条路径。

这两者最大的区别在于： 开发难度和长期想象空间。

基于开源的路径，是指直接基于开源社区的内核来支持商业化的服务。通过在开源内核上的封装、二次开发、运营运维体系的搭建、功能增强来支持用户。这种方案的好处就是开发维护成本低，可以借助开源社区人力来发展产品。缺点就是一般成功的开源产品都会有对应的商业化公司，他们具有很大的话语权，可以决定社区技术的演进方向。此时如果我们基于开源内核来提供服务，那么长期来看瓶颈明显，基本竞争不过这些公司，也很难打造出差异化。而一旦要大改内核，就会偏离社区，出现无法跟进社区未来发展的问题。

基于自研的路径，顾名思义就是从头开发兼容社区组件的软件。比如重新写一个兼容Kafka 协议的新的Kafka。这种路径的优点就是架构和代码可控性高，只要做好协议兼容，就可以通过技术和架构设计上的优化来解决开源组件存在的设计缺陷和代码bug，从而做出差异化，做出比开源更有竞争力的产品。但是问题就是开发投入大，周期长，短时间内稳定性和兼容性很难和开源对齐。

看起来这两种方案优劣势都很明显，那么怎么选择呢？我们接着看。

生存或技术

上面两个技术路线中，隐含了一个比较关键的问题，那就是我们得先活下来，才能有更长期的发展。

作为一个商业化的产品，我们的目标肯定是赚钱。虽然肯定需要前期的投入，但是投入不能是无限期的。在一定的阶段后需要开始有收入，能够自给自足，造血来满足长期的发展。

所以在技术路线的选择上，作为技术决策者就应该有这么一个清楚的认知： 技术是为商业服务的，商业上成功 ， 技术上才算成功。所以讲到这里，你就应该很容易知道如何选择技术路线了。

我个人支持的是先走开源路径，在收入和用户都发展到一定的规模后，再考虑自研路径。当存活下来后，很多配套的东西，比如销售渠道、用户群体、运营运维体系都有了，能够收支平衡后，再走自研路线，发展长期竞争力，是更合理的。

有些技术人员可能会想，走开源路径技术难度低，无法体现自己的技术能力，需要自研更厉害一些的产品。这里就要再次回归到我们的观点，从用户和商业出发来思考问题。

我们刚刚一直在强调成本和价值。那么从商业化产品看，超卖这个词是绕不过去的。这个词从技术上翻译后，主要的技术路径就是资源是共享的还是独占的。

共享或独占

共享是指底层的物理资源上运行了多个用户的服务，这些服务共享底层的物理资源。独占是指物理资源上只有这个用户，资源是被这个用户独占的。

共享和独占主要有 资源超卖 和 资源隔离性 两点区别。很好理解，就不过多展开解释这两个词了。

共享形态，天然有做超卖的优势。就是说可以在共享物理资源放多个用户，通过调度，让多个用户的波峰波谷形成互补，从而提高资源利用率。从技术上来看，共享形态在消息队列中主要是以在内核中添加 Namespace 或 Tenant 的概念来实现的。这种技术形态在资源上没有做到强隔离，所以很难做到资源上不互相影响，可能会出现A用户流量上涨影响B用户的情况。

超卖的另外一个技术途径是容器化，就是在底层物理资源上运行多个容器，通过容器的细粒度资源分配和调度来提高底层资源的利用率。这种形态相当于容器是独占的，物理资源是共享的。在业界，容器化的共享形态也是一种比较推荐的方案，因为它具备很强的通用性、隔离性、资源复用性。

在消息队列中，容器化最大的瓶颈还是消息队列是有状态的服务，只有具备弹性扩缩容能力的消息队列集群，才能真正享受到容器化带来的好处，而这块是当前很多消息队列不具备的（原因可以回顾一下架构升级篇的内容）。

独占形态是比较难做超卖的。因为只有一个用户使用，它的流量趋势是固定的，比如夜间波谷、白天波峰，就得准备相对应的资源。在技术上能做的优化是，Serverless 形态的弹性资源调度，在波谷回收资源，在峰值提供资源。但是我们前面讲过，Serverless形态还不够成熟，还无法做到任意即时的弹性。但是好处就是不会有资源隔离性问题，不会出现A用户流量上涨影响B用户的情况。

为了优化成本结构，提高资源利用率，提高产品竞争力， 超卖是必须的，所以共享形态也是必须的，不能只卖独占资源。只卖独占资源的话，就容易陷入卖物理资源的逻辑里面，很难做出差异化。

最后我们来看看消息队列商业上的生态建设思路。消息队列只是单品，规模是有上限的。当做到一定的程度，消息队列的发展是会遇到瓶颈的。

做好生态建设

我们在第38～40讲讲到了数据集成和数据连接的概念。先来回顾一下下面这张图：

参考图示可知，消息队列处于数据流转技术架构的核心层，它起到的是缓存、缓冲的作用。所以说商业化的下一步，消息队列可以往数据连接集成去做。就是以消息队列为核心，去构建数据连接的生态，将各种数据导入到消息队列，再将各种数据导出消息队列。

在讲连接器的时候，我们讲到过业界主流消息队列都在做连接器，比如Kafka Connector、RocketMQ Connector、Pulsar IO等等。从这也可以看出，这些消息队列都在往这个方向发展。

总结来说，消息队列商业化的下一步就是做数据连接、集成、流数据处理，将消息队列从存储打造为一个流计算平台。

总结

这节课我主要想表达的就是，我们要站在用户和市场的角度去做产品，不应该只考虑技术。比如做企业内部服务，因为业务形态和用户群体都是单一的，满足他们是很简单的。但是一旦成为商业化的产品，那么用户的诉求就是多样的，不能一概而论。

在我看来，做好商业化的基础产品，需要做到四个方面。

产品思维：理解做内部运营产品和商业化产品的区别，真正站在用户和商业化产品的角度思考，思考用户需要什么。比如用户可能只需要一些基础的、技术复杂度不高的功能，而不是听起来很高大上的功能。
市场思维：站在市场的角度去理解，我们的竞品是谁，用户看重的是这些竞品的哪些特点，功能、性能、稳定性还是价格等等。因为用户群体的不断变化，市场的需求是一直在变的，切勿以纯技术思维来应对市场的变化。
成本思维：用户的需求有很多种，但是绕不开的就是价格，而价格的本质就是成本。控制成本的工作，主要是技术侧的工作。我们在架构设计、运维运营的时候，就需要时刻考虑成本，要有意识地优化架构、控制成本。
技术思维：技术是基础，也是核心。但是不一定是指架构能力、代码能力有多强，更重要的是，需要对自身的行业有足够的理解和判断能力。因为每一次技术方向决策错误，带来的成本都可能是不可承受的。

总结来说，做 To B 商业化的基础产品，还得多多考虑人的因素。技术竞争力是基础，也是核心，而产品化和搞定用户才是结果。

思考题

前面有个例子说，要帮用户改代码。那么从这就可以延伸出一个有意思的话题，“有人说商业化产品要跪着赚钱”，对于这个观点你怎么看呢？

期待你的分享，如果觉得有收获，也欢迎你把这节课分享给身边的朋友。我们下节课再见！

上节课思考闭环

1. 你觉得消息队列未来的发展方向是怎样的？

我给业界同行分享过一些发展趋势。从能力上看，高 SLA（高稳定性和可用性）、低成本、易用性、多样性和标准化是趋势。从技术上看，Kubernetes 化、Serverless 化、Service Mesh 化是趋势。

2. 在融合型消息队列的设想中，你觉得它还需要具备哪些能力？

自由讨论，我的答案已全部交付在文稿中。