雅虎日本是一家雅虎和软银合资的日本互联网公司，是日本最受欢迎的门户网站之一。雅虎日本的互联网服务在日本市场占主导地位。
下图从三个维度显示了雅虎日本的经营规模。第一个是服务数量，雅虎日本提供上百种互联网服务；第二个是服务器数量，雅虎日本使用超过 150,000 台服务器（大多为裸机服务器）全天候支持这上百种互联网服务的正常运作；第三个是每月总页面浏览量，2017 年的数据显示，雅虎日本每月浏览量超过 700 亿。由此可见，雅虎日本的服务规模之大。
运营规模巨大对雅虎日本来说是个挑战。高性能和可扩展的服务才能满足海量用户的需求。同时还需要提供多租户支持来满足运营众多服务的需求。有时需要处理敏感消息或关键任务，因此持久性也很重要。此外，雅虎拥有众多的数据中心，对跨地域复制有强烈的需求。在诸多方面，我们面临着巨大挑战，希望找到一个稳定且可扩展的消息平台，能满足上述需求并大规模地运行服务，同时能确保数据的完整性。
为了解决这些挑战，我们开始调研各种消息平台。
首先，我们比较了 Apache Pulsar 和 Apache Kafka，这两个业界不同的消息系统，结果如下。
这两个系统最主要的不同在于数据分布。在数据负载均衡方面，Pulsar 比 Kafka 处理得更胜一筹。以下图为例，图中有 1 个分区，3 个存储节点，每个分区数据存储两个副本。Kafka 中，分区中的所有数据都保存在 leader broker（Broker 2）中，然后复制到另一个 follower broker（Broker 1）中。Broker 3 既不是 leader 也不是 follower，因此没有任何数据。在 Kafka 中，由于一个分区中的所有数据都由一个 broker 保存，因此分区的容量受 broker 的容量限制。一旦要扩展分区，就需要重新分布数据；否则就会出现负载不均衡的情况。而 Pulsar 中，分区中的数据被划分为粒度更细的单元，称为分片（segment）。它们均匀地分布和保存在 bookies 中，分区容量不受单个 bookie 节点容量的限制，扩展分区时不需要重新分布数据。因此，Pulsar 比 Kafka 更灵活，更容易扩展。
另一个区别是跨地域复制。Kafka 使用 MirrorMaker 来处理跨地域复制，但需要使用额外的机器来运行和管理 MirrorMaker。而 Pulsar 内置了跨地域复制功能，不需要额外部署跨地域复制组件。
使用 OpenMessaging Benchmark 可以很容易比较不同消息处理系统。据报道，Apache Pulsar 处理吞吐量和延迟的性能更好。图中蓝线代表 Pulsar，红线代表 Kafka。左图显示吞吐量，上方线条说明吞吐量更高。右图显示延迟，下方线条说明延迟更低。
雅虎日本如何用Pulsar构建日均千亿的消息平台？
这些对比说明 Apache Pulsar 比 Apache Kafka 更好，所以我们决定进一步研究 Apache Pulsar，并总结了 Pulsar 更适合我们的原因。
即使主题数量巨大，还要保证数据的可靠性，Apache Pulsar 也能实现高吞吐和低延迟。例如，Oath Inc. 每天要处理 230 万个 topic，1000 亿条消息。在这个巨大的体量下，要确保消息不能丢失且必须按顺序处理。Apache Pulsar 不仅能满足这些需求，还实现了 1,000,000 吞吐量（msg / s）和 5 ms 的延迟。
Apache Pulsar 扩展性很好。要实现扩容，只需添加服务器即可。Pulsar 的服务层和存储层是分开的，可以根据数据路径灵活地添加 broker 或 bookie。如果需要提升服务容量，添加 broker 即可。如果需要扩大存储容量，添加 bookie 即可。
多租户是指多种服务共用一个 Pulsar 系统。每个服务和应用程序作为 “租户” 使用 Pulsar。因此，不同的服务无需单独维护各自消息系统。Apache Pulsar 有不同的认证和授权机制，可保护消息不被拦截。可以配置认证和授权机制，并共享到命名空间或主题，从而保护消息。因此，可以在一个 Pulsar 系统上运行多种服务，有效降低维护和劳动力成本。
雅虎日本在多个数据中心运行很多服务。Pulsar 提供内置的跨地域复制功能，在数据中心之间复制消息，可以有效处理灾备，恢复数据，提高服务质量。更重要的是，跨地域复制是 Pulsar 的内置功能，方便启用和使用。
Pulsar Functions 是轻量级计算框架（如 AWS lambda 或 Google Cloud Functions），不需要外部系统（如 Apache Heron，Apache Storm，Apache Spark 或其他类似系统）。只需构造逻辑并部署至 Pulsar 集群。Pulsar Functions 支持 Java、Python 和 Go 语言。
Kubernetes 有众多用户，雅虎日本也是其中之一。在 Kubernetes 集群上部署 Pulsar 很容易。下图展示了 Pulsar 在 Kubernetes 引擎上的使用状态。
经过详细调研，我们发现 Apache Pulsar 不仅比 Apache Kafka 的性能更好，还能够满足我们企业运行的所有需求，在 Kubernetes 上容易部署，所以我们最终决定采用 Apache Pulsar 作为内部消息平台。
雅虎日本在生产环境中使用 Pulsar 已经好几年了。我来分享下 Apache Pulsar 在雅虎日本的应用场景。
下图是雅虎日本的系统构架。我们有两个数据中心：一个在东部，一个在西部。每个数据中心都有 broker、bookie、ZooKeeper 和 WebSocket 代理服务器。我们使用 Prometheus 收集指标，并通过 Grafana 将其可视化。
Prometheus 可以用来监控 topic、生产者和消费者的数量，如下图所示。
在雅虎日本，我们开发了一套工具，用来创建和管理租户、命名空间和主题。用户可以在 UI 界面自己创建租户和命名空间，并配置设置。目前，这个 UI 仅在雅虎日本内部使用，所以是日语的，没有开源。使用这个 UI，可以创建租户和命名空间，并查看 topic 的统计信息，如吞吐量、平均消息规模等。
我们把 Apache Pulsar 作为通知服务系统使用。各种内容文件（例如天气，地图或新闻数据）从合作伙伴公司推送到雅虎日本。服务需要了解这些更新的内容，所以服务把文件当作 topic。内容更新时会向 topic 发送通知。服务一旦收到通知，就会从文件服务器获取更新的内容文件。
我们使用 Apache Pulsar 构建异步工作队列。邮件索引工作繁重，所以异步执行。首先，Mail BE 服务器中的生产者在 Pulsar 中注册 job，消费者按照自己的节奏从 Pulsar 获取 job。如果索引失败，生产者会重新注册。
我们使用 Apache Pulsar 收集日志。雅虎日本几乎所有的服务和应用程序都运行 PaaS 平台（如 Heron）或 CaaS 平台（如 Kubernetes），我们想从中收集日志。首先，日志发布到 Pulsar 后会分成 topic。根据使用 Pulsar Functions 的最终目的地和服务，日志最终会发送到其他数据库或平台，例如 HBase、Prometheus 和 Twilio。下图是雅虎日本的日志收集架构。
Apache Pulsar 是一个快速、持久、可扩展的 pub-sub 消息系统，配备很多有用的内置功能，如跨地域复制、多租户、Pulsar Functions 等。
多年来，雅虎日本使用 Apache Pulsar，关注 Pulsar 社区的新闻，更新和活动，在应用场景中使用 Pulsar 新功能，Pulsar 的稳定性一直很好。
Pulsar 社区虽然年轻，但发展迅猛，在不同的应用场景下不断有新的案例落地。我们会持续关注并和 Apache Pulsar 社区深入合作，进一步完善、优化 Pulsar 的特性和功能。
以下是 Apache Pulsar 的相关信息:
Apache Pulsar: https://pulsar.apache.org/
联系: https://apache-pulsar.slack.com/ [email protected] [email protected]
在线视频:
https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321374.html
演示文稿:
https://conferences.oreilly.com/oscon/oscon-or-2018/public/schedule/detail/69704
Nozomi Kurihara, 雅虎日本消息平台团队经理、Apache Pulsar 项目 committer。负责创建基于 Apache Pulsar pub-sub 为中心的消息处理平台，该平台能够处理海量服务和应用程序流量。
作者 | Nozomi Kurihara
审校 | Jennifer + Sijie + Irene
编辑 | Irene
新福利:
从11月01日开始至12月06日截止，一共五周时间，每周五我会从公众号底部留言+转发+在看综合最多的读者中抽取一名读者，免费包邮送实体新书 《Flink入门与实战》 ，留言互动起来吧~
上周获奖名单：布拉没有格
1、 马蜂窝实时计算平台的演进
2、 Apache Spark 3.0 预览版正式发布，多项重大功能发布
过往记忆大数据微信群，请添加微信：fangzhen0219,备注【进群】