雅虎日本是一家雅虎和軟銀合資的日本互聯網公司,是日本最受歡迎的門戶網站之一。雅虎日本的互聯網服務在日本市場占主導地位。 下圖從三個維度顯示了雅虎日本的經營規模。第一個是服務數量,雅虎日本提供上百種互聯網服務;第二個是服務器數量,雅虎日本使用超過 150,000 臺服務器(大多爲裸機服務器)全天候支持這上百種互聯網服務的正常運做;第三個是每個月總頁面瀏覽量,2017 年的數據顯示,雅虎日本每個月瀏覽量超過 700 億。因而可知,雅虎日本的服務規模之大。 ![](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195046569-1144299739.png) ## 挑戰 運營規模巨大對雅虎日原本說是個挑戰。高性能和可擴展的服務才能知足海量用戶的需求。同時還須要提供多租戶支持來知足運營衆多服務的需求。有時須要處理敏感消息或關鍵任務,所以持久性也很重要。此外,雅虎擁有衆多的數據中心,對跨地域複製有強烈的需求。在諸多方面,咱們面臨着巨大挑戰,但願找到一個穩定且可擴展的消息平臺,能知足上述需求並大規模地運行服務,同時能確保數據的完整性。 ## 爲何選擇 Apache Pulsar 爲了解決這些挑戰,咱們開始調研各類消息平臺。 ### Apache Pulsar vs Apache Kafka 首先,咱們比較了 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 內置了跨地域複製功能,不須要額外部署跨地域複製組件。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195049022-633309679.png) ### OpenMessaging Benchmark 使用 OpenMessaging Benchmark 能夠很容易比較不一樣消息處理系統。據報道,Apache Pulsar 處理吞吐量和延遲的性能更好。圖中藍線表明 Pulsar,紅線表明 Kafka。左圖顯示吞吐量,上方線條說明吞吐量更高。右圖顯示延遲,下方線條說明延遲更低。 雅虎日本如何用Pulsar構建日均千億的消息平臺? ### 爲何 Apache 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 Pulsar Functions 是輕量級計算框架(如 AWS lambda 或 Google Cloud Functions),不須要外部系統(如 Apache Heron,Apache Storm,Apache Spark 或其餘相似系統)。只需構造邏輯並部署至 Pulsar 集羣。Pulsar Functions 支持 Java、Python 和 Go 語言。 #### Pulsar on Kubernetes Kubernetes 有衆多用戶,雅虎日本也是其中之一。在 Kubernetes 集羣上部署 Pulsar 很容易。下圖展現了 Pulsar 在 Kubernetes 引擎上的使用狀態。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195050588-1949420844.png) 通過詳細調研,咱們發現 Apache Pulsar 不只比 Apache Kafka 的性能更好,還可以知足咱們企業運行的全部需求,在 Kubernetes 上容易部署,因此咱們最終決定採用 Apache Pulsar 做爲內部消息平臺。 ## Apache Pulsar 在雅虎日本的應用 雅虎日本在生產環境中使用 Pulsar 已經好幾年了。我來分享下 Apache Pulsar 在雅虎日本的應用場景。 下圖是雅虎日本的系統構架。咱們有兩個數據中心:一個在東部,一個在西部。每一個數據中心都有 broker、bookie、ZooKeeper 和 WebSocket 代理服務器。咱們使用 Prometheus 收集指標,並經過 Grafana 將其可視化。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195052467-1743849346.png) Prometheus 能夠用來監控 topic、生產者和消費者的數量,以下圖所示。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195054298-1125178821.png) ### 自助服務工具 在雅虎日本,咱們開發了一套工具,用來建立和管理租戶、命名空間和主題。用戶能夠在 UI 界面本身建立租戶和命名空間,並配置設置。目前,這個 UI 僅在雅虎日本內部使用,因此是日語的,沒有開源。使用這個 UI,能夠建立租戶和命名空間,並查看 topic 的統計信息,如吞吐量、平均消息規模等。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195055752-394837458.png) ### 案例 1: 內容更新通知 咱們把 Apache Pulsar 做爲通知服務系統使用。各類內容文件(例如天氣,地圖或新聞數據)從合做夥伴公司推送到雅虎日本。服務須要了解這些更新的內容,因此服務把文件看成 topic。內容更新時會向 topic 發送通知。服務一旦收到通知,就會從文件服務器獲取更新的內容文件。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195057055-1693609413.png) ### 案例 2: 郵件服務中的工做隊列 咱們使用 Apache Pulsar 構建異步工做隊列。郵件索引工做繁重,因此異步執行。首先,Mail BE 服務器中的生產者在 Pulsar 中註冊 job,消費者按照本身的節奏從 Pulsar 獲取 job。若是索引失敗,生產者會從新註冊。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195057986-814901173.png) ### 案例 3: 日誌管道 咱們使用 Apache Pulsar 收集日誌。雅虎日本幾乎全部的服務和應用程序都運行 PaaS 平臺(如 Heron)或 CaaS 平臺(如 Kubernetes),咱們想從中收集日誌。首先,日誌發佈到 Pulsar 後會分紅 topic。根據使用 Pulsar Functions 的最終目的地和服務,日誌最終會發送到其餘數據庫或平臺,例如 HBase、Prometheus 和 Twilio。下圖是雅虎日本的日誌收集架構。 ![雅虎日本如何用Pulsar構建日均千億的消息平臺?](https://img2018.cnblogs.com/blog/377574/201911/377574-20191117195059081-2115255937.png) ## 結論 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/ users@pulsar.apache.org dev@pulsar.apache.org - 在線視頻: 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