# Autodesk 如何在 Mesos 上實施可擴展事件 > 原文： [http://highscalability.com/blog/2015/8/17/how-autodesk-implemented-scalable-eventing-over-mesos.html](http://highscalability.com/blog/2015/8/17/how-autodesk-implemented-scalable-eventing-over-mesos.html)  *這是 [Autodesk](http://www.autodesk.com/) Cloud 的軟件架構師 [Olivier Paugam](https://www.linkedin.com/pub/olivier-paugam/2/214/475) 的來賓帖子。 我真的很喜歡這篇文章，因為它顯示了如何將基礎架構（Mesos，Kafka，RabbitMQ，Akka，Splunk，Librato，EC2-）組合在一起以解決實際問題。 如今，一個小團隊可以完成多少工作，真是令人驚訝。* 幾個月前，我受命提出一個*中央事件系統*，該系統可以使我們的各種后端相互通信。 我們正在談論活動流后端，渲染，數據轉換，BIM，身份，日志報告，分析等。 而且，我們的工程團隊也可以輕松地進行交互。 當然，系統的每個部分都應能夠*自行擴展。* 我顯然沒有時間寫太多代碼，而是選擇 [Kafka](http://kafka.apache.org/) 作為我們的存儲核心，因為它穩定，廣泛使用并且可以正常工作（請注意，我并不一定要使用它，并且可以切換 到別的東西）。 現在，我當然不能直接公開它，而必須使用一些 API 對其進行前端處理。 不用多考慮，我也拒絕讓后端管理偏移量的想法，因為它對例如處理故障的方式施加了太多約束。 那我最終得到了什么？ 分為兩個單獨的層：**首先是處理傳入流量的 API 層，然后是托管與 Kafka（例如，實現生產者&消費者）交談的長期的有狀態流處理程序**的后端層。 這兩層都可以獨立擴展，只需要在它們之間進行一致的路由即可確保客戶端繼續與同一個后端流處理進行對話。 這些層在 **Scala** 中實現了 100％，并使用[播放！ 框架](https://www.playframework.com/)。 他們也嚴重依賴 **Akka actor 系統**（每個節點通常運行數百個 actor）。 后端層實現了一組自定義的 Kafka 生產者&使用者，并使用一組專用的參與者來管理預讀&寫緩沖區。 一切都實現為嵌套的有限狀態機（我喜歡這個概念）。 分析會轉到 **Splunk** ，而指標會轉到 **Librato** （*收集的*在容器中運行）。 [ ](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01bb08323d7f970d-pi) *發布外觀的藝術渲染。* 那么，如何在兩層之間路由？ 只需使用 [RabbitMQ](https://www.rabbitmq.com/) ，它非常耐用&有彈性，就不好笑了。 AMQP 隊列是實現此簡單“電話切換”模式的好方法。 通過使用將一組固定的后端節點與一個 RabbitMQ 代理相關聯的邏輯分片（例如，對每個事務中存在的某些 Cookie 進行哈希處理或類似操作）來進行擴展也是很簡單的。 為什么我不對 RabbitMQ 經紀人進行集群？ 好吧，主要是因為我很懶，也因為這并不是必須的。 **在我看來，分攤單個經紀人**中的流量實際上同樣有效，而且更易于控制。 與收益相比，要做的額外工作微不足道。 簡而言之，給定一些容器拓撲，我們的請求將遵循特定的路徑，具體取決于哪個后端節點承載了什么流會話。 **擴展整個過程就像給定您需要的**獨立地擴展每個層一樣簡單。 唯一實際的限制將來自您的虛擬網絡適配器以及可以通過多少帶寬。 [ ](http://a6.typepad.com/6a01b7c766c713970b01bb083239de970d-pi) *虛線顯??示了來自給定會話的路徑請求將遵循的路徑。* 現在來了有趣的部分：**我們如何保證可靠的流量并避免拜占庭式故障？** Mucho 說的很簡單，只需采用簡單的兩階段提交式協議，并將客戶端和后端建模為鏡像狀態機（例如，它們始終保持同步）。 這可以通過具有需要顯式確認請求的讀寫操作來實現。 您嘗試閱讀某些內容，如果失敗了，您可以重試，直到您可以放置??確認，然后更改后端（例如，向前移動 Kafka 偏移量或安排要發布的事件塊）為止。 所以我的客戶和后端之間的流量實際上就像是“分配會話”，“讀取”，“ ack”，“讀取”，“ ack” ...“ dispose”。 這種系統的巨大優勢在于，**可以有效地使操作成為冪等，**加上**可以在狀態機**中對所有邏輯進行編碼，而無需任何煩人的聲明性語句（ *對我自己：我應該提供一個純粹的功能實現，以保持冷靜*。 當然，任何網絡故障都將適當地重試。 順便說一下，您還可以獲得自由的控制流和背壓。 因此，整個事情都以 [Apache Thrift](https://thrift.apache.org/) API 的形式公開（目前已通過 HTTPS 進行了壓縮，并且計劃將其遷移到純 TCP）。 我擁有 Python，Scala，.NET 和 Ruby 的客戶端 SDK，以配合我們在 Autodesk 使用的各種令人眼花 variety 亂的技術。 請注意，Kafka 偏移量由客戶端管理（盡管不透明），這使后端更易于控制。 等一下 **如何處理后端節點發生故障的情況？** 多虧了兩階段協議，我們在讀取數據時并沒有真正遇到問題：客戶端反復出現故障，然后使用其當前偏移量重新分配新的流會話。 向 Kafka 寫入數據時會擔心，因為這是異步的，并且可能會受到下游背壓的影響（例如，您的節點發生故障，Kafka 代理也有問題。.urg）。 我為后端節點配備了正常關機功能，它將在等待任何掛起的寫操作通過時快速使任何傳入請求失敗。 最后，我們甚至可以將所有待處理的數據刷新到磁盤（并在以后重新注入）。 再說一遍。 **如果部分基礎架構爆炸了怎么辦？** 。 您與處理您的流會話的實際后端節點之間的任何流量中斷都將使您放慢速度，但當然不會受到任何討厭的影響，這要歸功于兩階段協議。 哦，我忘記添加了**數據，該數據在登陸 Kafka 日志之前會自動加密**（AES 256）。 沒有更多的 la 腳的密鑰共享嘗試使用香草卡夫卡的生產者和消費者進行相同的操作。 在安全性主題上，我可以添加我們的流會話通過 OAUTH2 進行身份驗證，使用按請求的 MD5-HMAC 質詢并通過 TLS 向下訪問后端群集。 那么，您現在要問的是如何部署所有這些時髦的系統？ 好吧，我們在普通的 [Mesos / Marathon](https://github.com/mesosphere/marathon) 集群（目前不是 [DCOS](https://mesosphere.com/) ）上 100％運行它，但我們可以切換到它，并從它們令人敬畏的儀表板中受益。 此時，群集是**托管在 AWS EC2** 上的，我們基本上將整個事物復用到了少數 c3.2xlarge 實例上（對于給定區域的小型部署，10 至 20 個實例就足夠了）。 請注意，我們可以在 [Kubernetes](http://kubernetes.io/) （EC2 或 GCE）上執行完全相同的操作。 [](http://a4.typepad.com/6a01b7c766c713970b01b7c78e36d4970b-pi) *有點提醒我們堆棧的結構。* 一切都使用我們的 [Ochopod](https://github.com/autodesk-cloud/ochopod) 技術（自集群容器）進行了部署，該技術也采用開源的方式。 操作減少到絕對最小值。 例如，例如，對 API 層進行適當的構建推送，只需分配一些新容器，等待它們安頓下來然后逐步淘汰舊容器即可。 所有這些都是通過在集群中運行的專用 Jenkins 從屬服務器（本身也是 Ochopod 容器）完成的！ 我實際上開發了 [Ochothon](https://github.com/autodesk-cloud/ochothon) mini-PaaS，只是為了能夠快速開發/運行所有這些容器。 [](http://cloudengineering.autodesk.com/.a/6a01b7c7651b22970b01b8d117b6df970c-pi) *Ochothon CLI 顯示了我的預生產集群之一。* 為了讓您了解 Ocho- *平臺的全部功能，我只想說**，一個人（我）可以管理 2 個區域（包括所有復制基礎設施**）的 5 個系統部署 ……還有時間寫博客和編寫代碼！ 因此，總體而言，設計和編碼整個過程非常有趣，而且它現在已經在生產中運行，成為我們云基礎架構的關鍵任務部分（這是一個不錯的獎勵）。 讓我們知道，如果您想了解更多有關此異國流媒體系統的信息！ ## 相關文章 * [在 Mesos / Marathon 上部署我們的事件基礎架構& Ochothon！](http://cloudengineering.autodesk.com/blog/2015/05/after-a-long-day-of-devops-to-inaugurate-the-latest-ochothon-release-i-though-id-share-quick-what-it-feels-like-deploying-ou.html) * [Ochopod + Kubernetes = Ochonetes](http://cloudengineering.autodesk.com/blog/2015/05/ochopod_plus_kubernetes.html) * [有限狀態機的返回！](http://cloudengineering.autodesk.com/blog/2015/07/fsm.html) 紙上寫的很好，但他們的服務影響了現實生活。 看一下 123D Catch，大多數時候您無法將任何數據上傳到云中。 我有一個基本問題。 您為什么選擇使用 RabbitMQ 與 2 層進行黑白通信？ 這與使用 Kafka 進行交流有何不同？ 從理論上講，Coz 甚至支持在散列上進行分區，并且也很耐用。 同樣，在使用 kafka 的情況下，更多的是流處理的情況。 請指教..