|
人员不仅要关注基准测试结果、产品支持的特性，还要从长远角度考虑新技术的可靠性，新技术能够为企业带来哪些竞争优势，以及是否可以缩短上市时间、节约开销。
我是 Big Data Institute 的常务董事，技术评估是我的一项主要工作。我们帮助企业根据业务需求选择并落地最合适的技术。我们不与供应商合作，因此客户尤为看中我们能够客观地评估不同的技术。
在本文中，我将从 CTO 的视角出发，对比 Apache Pulsar 和 Apache Kafka。只进行理论上的对比空洞无效，也不能帮助我们作出决策，实际用例才真正值得参考。所以，在本文中，我会通过一些常见的实际使用场景来对比 Pulsar 和 Kafka，即 简单消息使用场景、复杂消息使用场景和高级消息使用场景 。在这些实际使用场景下，Pulsar 和 Kafka 的表现能够帮助我们更好地理解二者的性能和优势，进而作出决策。
简单消息使用场景
假设有一个企业，之前从未使用过消息系统，现在需要通过一个简单的消息系统，将消息从位置 A 发送到位置 B，但不需要复制消息。
数据架构师团队在深入研究 Pulsar 和 Kafka 的业务案例后，得出如下结论：在这一使用场景中，Pulsar 和 Kafka 都没有绝对优势。并且，他们认为在短时间内，该使用场景基本不会发生改变。
对于类似这样的简单消息使用场景而言，我也赞同 Pulsar 和 Kafka 都没有绝对优势。仅从技术角度出发，Pulsar 和 Kafka 这一回合打成平局，那么我们只能考虑成本。二者的运营成本、员工培训成本分别是多少？我打算根据 Kafka 或 Pulsar 的服务提供商的收费标准进行对比。 对比开销时，选好服务提供商也可以在一定程度上减少运营成本和员工培训成本 。Kafka 的云服务提供商，我参考了使用 Kafka API（Azure） [1] 的 Confluent Cloud [2] 、 MSK（AWS） [3] 和 Event Hubs [4] 。Pulsar 的云服务提供商，我选择 StreamNative Cloud [5] 。
对比结果
出于稳妥考虑，我们决定选择 Kafka API。目前，已有多种技术支持非 Kafka broker 使用 Kafka API 或传输协议。使用 Kafka API，非 Kafka broker 可通过添加新库支持 Kafka 的传输协议，保证对 Kafka API 的兼容性，从而最大化技术选择的多样性。例如，可以通过修改 Kafka API 的实现重新编译或通过 Pulsar broker 解析 Kafka 的协议（KOP），将 Pulsar 用作 Kafka 的后端。
我们在对比单位成本后，选择了 成本效益高 的一方。Kafka API 可以保证后端质量，用户在后端之间的数据移动不会受到影响，有效规避风险。即使社区不活跃，技术热度不高，我们的使用也不会受到影响。
复杂消息使用场景
假设一个公司需要 复杂消息系统 。由于需要处理世界各地的数据，必须支持跨地域复制。该企业一直在使用消息系统，因此对实时系统的复杂性有一定的了解，也发现了当前消息系统的不足之处。因此该企业对消息系统的要求是能够处理高级的消息传递和复杂的消息特性。
数据架构师团队和股东以及业务部门详细讨论了当前和未来需求。最后得出的结论是，Pulsar 和 Kafka 各有优势。同时，他们认为随着时间的推移，该使用场景和数据量都会有所增长。
在这种情况下，Pulsar 和 Kafka 难分胜负。要想作出正确决策，必须深入研究二者的使用场景。
（编辑：葫芦岛站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
