豌豆莢鄧草原：如何實現實時響應式平臺
編者注：本文為Typesafe采訪豌豆莢平臺架構師鄧草原關于如何使用Akka來實現實時響應式平臺的經驗文章。以下為全文：
今 天刊出的是一篇令我們十分振奮的訪談，訪談對象是豌豆莢平臺架構師鄧草原先生，內容是探討 Akka 在中國移動內容搜索平臺豌豆莢中所擔綱的角色。在我們的采訪中，鄧草原討論了如何使用Akka來實現實時響應式平臺 (Reactive Platform)，表達了他對 Actor 模式的欣賞，并分享了一路走來所遇到過的相關優點和問題。而對于未來的計劃以及期待從 Typesafe 看到的改進，他也給出了自己的反饋意見。
Typesafe：請您首先介紹一下自己吧。
鄧草原：我從事編程有25年了。我是 NetBeans 的 Scala 插件的作者，前些年也寫了一個分布式、并行的實時金融計算和股票交易平臺，這個平臺是基于 Akka 的 Actor 模式寫的，與 Reactive Platform 的理念恰好一致。在用 Scala 和 Akka 編程之前，我也寫過大量的 Erlang 代碼，也為 NetBeans 寫過一個 Erlang 語言的插件（只是這些年沒有時間去更新了）。就在一年前，我加入豌豆莢。
Typesafe：那么接下來請您介紹一下豌豆莢。
鄧草原：豌豆莢 誕生于2009年12月， 是中國領先的移動內容搜索，主要面向移動娛樂內容領域，是中國的移動互聯網行業具有廣泛影響力的創新企業。迄今豌豆莢安裝量超過4.2億次，每天新增安裝 量超過80萬。豌豆莢通過應用內搜索技術，索引了超過1000萬內容，涵蓋應用、游戲、影視劇和綜藝節目、電子書、主題、電影票、問答、旅游等內容類別。
Typesafe：Akka 在豌豆莢扮演了什么角色？
鄧 草原：現在每天會有千萬級數量的移動設備連到我們的系統。我們希望通過實時響應式平臺隨時隨地、以及更好地為這些設備服務。在互聯網時代，網絡正在成為一 個實際上折射了每個人的日常生活的“真實”的虛擬世界，或者說，在網絡時代，網絡將融為每個人的生活本身，而非只是他們生活中的一部分。我相信，從長遠來 看，響應式平臺將導向這樣的一個虛擬世界。
為了實現這種實時性的響應式平臺，我們先要創建了一個持久的連接通道，將每臺設備與我們的后端， 即“系統”(The System) 相連接。“系統”持續不斷地接收來自這些設備的大量事件，并做出即時的響應甚至主動性的“變形”。這正是 Akka 的用武之地。我一直認為 Actor 是最適合并行及增量計算的最小顆粒，想像一下，每個 Actor 對接收到的事件或變化做出相應反應，改變狀態，然后傳遞出新的事件或變化，而并行行為則是大量 Actors 的個體行為的整體表現。如果我們遵循這樣一種 Actor 模式，那么每臺設備都可以映射成一個 Actor，每個用戶也正好是一個 Actor，諸如此類，不一而足，由此組成一個由事件流驅動、并行運行的虛擬世界，它正好是現實世界的映射，像現實世界一樣精彩。Akka為這一構想提供 了解決之道。
Typesafe：您能再介紹一些Akka技術在豌豆莢的用例嗎？
鄧草原：在豌豆莢，作為完整的響應式平臺的第一步，我們先現實一套連接和狀態服務集群（基于我們的開源項目：https://github.com/wandoulabs/spray-socketio）。該集群可概述為：
- 無狀態的連接層
- 有狀態的狀態層
- 用于業務邏輯的事件流接口
上圖是架構。連接層保持著每臺設備的持久連接。每臺設備的狀態由狀態層的 Actor 對應以保持每個連接設備的狀態。Distributed Region 和 Distributed Mediator 則是業務邏輯的接口，其中 Region 根據 ID 來訪問每個狀態 actor，而所有事件和消息則發布到 Mediator 并最終裝換成到 RxScala 的實時事件流，業務層則只需訂閱這一事件流。通過上述架構，不同設備可共享和查詢狀態，雙向推送事件和消息，獲得實時通知，并且實際上實現了所有設備之間 的連接。
Typesafe：到目前為止，您可以看到 Akka 帶來了哪些優勢？
鄧草原：帶來了許多的優勢，下面著重列出其中的一部分：
- 開發效率：在實現 Spray-socketio 之前，我們先完成了Spray-websocket (https://github.com/wandoulabs/spray-websocket), 這是一個基于 Akka 及 Spray 的 WebSocket 協議實現，它通過了所有 Autobahn WebSocket 的測試用例，已經可用于生產環境。基于 Akka 及 Spray 帶來的優勢，我和我的同事陳興潤 (cowboy129@github) 在三個月的時間里就完成了Spray-websocket 和 Spray-socketio 兩個項目的代碼。在這期間，興潤還為 Akka 貢獻了 DistributedPubSubMediator消息模式的代碼。
- 穩定一致的集群：因為 Actor 模式是同時適用于分布式和并行計算的最佳粒度，所以很容易從向單一服務器轉換為向一個集群來部署同樣的功能，Akka 本身也即是一個非常棒的具水平擴展、在線均衡調整和在線升級能力的集群平臺。
- 性 能：對于我們的應用場景來說，迄今為止的性能足夠好了。我們正在運行的集群現在用 4 個節點維持100萬以上的持久連接，每個節點約25萬。集群里另外3個狀態節點則處理每秒5萬次以上的設備心跳，以及另外每秒2萬次的狀態請求。根據我們 所做的性能測試和估算，集群的能力大約為：每個連接節點可輕易處理100萬以上長連接，每個狀態節點則可處理1.5萬次的狀態請求。我們預計，隨著更多節 點逐漸增加到集群中，在不久的將來我們可以達到千萬級甚至數億的長連接，每秒處理的消息數則可達數十萬條。
Typesafe：是否遇到過一些阻礙？
鄧 草原：最主要的阻礙是缺乏 Akka 的最佳實踐指引。我們在3個月里開發了整個系統，但是又花了近 2 個月的時間來調整。在最初的發布階段，我們遇到了節點狀態經常出現 Unreachable 的問題，我和興潤幾乎每天都要收到監控系統的報警和撰寫分析報告。Akka 集群與時間間隔相關的可調參數就有一堆，比如：監控集群節點在線狀態的心跳間隔、監測遠程傳輸端口的心跳間隔、監測 Remote Actor 的心跳間隔以及集群 Gossip 協議的發送間隔等等。由于缺乏前人的使用經驗，我們只好逐個調整、逐個排除以縮小范圍。最后我們發現，問題來自 Remote Actor 的監測。在初期的設計中，狀態節點上的 Actors 會一對一地遠程監測連接節點上的 Actors，從而產生了每秒數百萬的遠程監測心跳，這也太多了，對吧。找到問題后我們用了另一種設計從而去掉了這個遠程監測，現在集群每天都穩定舒暢地 運行，3 個月來再也沒有重啟過。從這里學到的是，對于跨節點的大量的 Actors 的遠程監測 ，一定要慎重；而從更一般的理念來看，一個基于對等關系的非集權“社會”（Akka集群看上去的樣子），如果溝通成本太過高昂，就可能突然陷入混沌無序的 狀態，也即失去了對擾動的彈性。但是，這樣的對等“社會”，一旦調整到位，就會優雅順暢地運轉。
Typesafe：您最想看到 Typesafe 和 Akka 團隊的哪方面的進展？
鄧 草原：最讓我興奮的是可以分片部署帶狀態的 Actors 的 Sharding Cluster 特性。這個特性是 Akka 在今年 3 月份才發布的。它的功能十分強大，可以用在分布式計算的多個領域。例如，在我看來，它可以直接就是一個 Redis 的替代者（每個 key 對應一個 actor）, 也可以是實現一套像 AMQP 這類消息隊列的很好的起點（每個 queue 對應一個 actor ）。從作為 Redis 的替代的角度，我們已經有了一些初步的嘗試，即用分片集群來分布式地存儲基于 AVRO 格式的記錄，數據也是全部保持在內存中。為此，我們還實現了一個類似于 XPath 的表達式，稱為 AvPath ，這一表達式可根據路徑和條件查詢、插入、更新或刪除數據。這些都得益于 Akka 的分片集群特性，因為它本身就支持在線均衡調整和水平擴展。我們會在今年晚些時候將 AvPath 開源。
我們還將跟蹤 Reactive Streams 的進展，并及時把 Spray-websocket 和 Spray-socketio 遷移到 Akka Streams 。
Typesafe：您期待 Typesafe 和 Akka 有哪些改進？
鄧草原：Akka 從分布式計算的學術研究和最佳實踐中汲取并融合進了很多內容，我們非常欣賞 Akka 的進展和理念。對于后續的產品和發布，我們期待：
- 運行時性能改進。運行時的性能顯然還有進一步優化的空間。在計劃發布的 Akka HTTP 模塊中，我們已經看到了parboiled2，它應該會帶來更好的性能。我們希望看到 Akka 社區對性能進行更多的剖析，以了解和解決實際應用中的性能瓶頸。
- 持久化的最佳實踐指引。我們也在嘗試各種持久化技術，包括 HBase 和 Cassandra 等等，想好好了解對于 Journal Store 和 Snapshot Store 的最適用法。我們希望分享和看到社區中有更多更好的實踐案例。
- 部 署和監控工具。我們希望有一個順暢的方式來保證集群部署的一致性，而不需要各初去處理、綁定太多預定義的配置參數。我們不確定是否有比 Zookeeper 等更好的方式。此外，我們希望能更容易地定位集群的瓶頸。我們試了Kamon，但是到現在為止還沒有成功用在 Akka 集群上。