賴斯：歡迎來到我們關於架構的專題小組，你們一直想知道軌道。該專題小組稱爲事件驅動的大規模架構。當您思考事件驅動架構時，您會想到什麼？這是規模、性能和靈活性的好處嗎？也許你想到了一個你可能經歷過的特殊問題。也許你從技術的角度來考慮，比如說無服務器，或者流處理，比如 Kafka？不管您如何看待事件驅動的架構，您可能有一些問題。我們將深入探討事件驅動系統的主題，我們將與一個專家小組進行討論，他們一直在大規模地操作這些系統，並且擁有豐富的經驗。

我和三位軟件領域的傑出領導者一起工作。他們來自操作當今軟件中一些最大和最知名系統的地方。

背景

我叫韋斯 · 賴斯。我是 VMware 的平臺架構師，在 Tanzu 上工作。我主持 QCON 舊金山軟件會議。我很幸運能成爲 InfoQ 播客的共同主持人之一。

格溫，我想讓你做的是自我介紹，也許可以談談你建立的系統。那麼，您是如何在事件驅動上着陸的？什麼風把你吹來了？

沙皮拉：基本上，我是一名軟件工程師，是 Confluent 的首席工程師。我領導雲端本地 Kafka 團隊。我們將 Kafka 作爲一項面向客戶的大規模服務。在那之前，我是一名工程師，是阿帕奇 ·Kafka 的提交人。

Confluent 是如何在事件驅動架構上實現的

基本上，在我們嘗試了所有其他方法之後，我們以事件驅動的方式着陸。不是那樣的。我花了很多時間與已經在使用 Kafka 進行事件驅動的客戶在一起。我必須與我的客戶一起學習模式，以及他們如何解決問題。它解決了什麼問題。它創造了什麼。然後當我開始管理雲中的 Kafka 時，我們發現自己有一塊巨石 (monolith)，我們知道我們必須解決它。你總是從一塊巨石開始。他們寫得很快。我們知道我們想要更好的東西，我們有很多不同的選擇。真正讓我們成爲事件驅動型的是，它讓我們避免了團隊之間的指責，因爲一切都是通過事件進行的。它永遠被記錄下來。如果需要，您可以在登臺環境中查看發送了哪些消息，並重構系統的整個邏輯流。如果您在生產中看到了一些東西，而不是您所期望的，那麼您實際上可以瞭解整個事件主題，並瞭解在另一個系統中發生了什麼。對我們來說，這是巨大的。這不是我的責任，你的責任。我們必須非常明確，這是你擁有的。這些是你對事件的反應，我們可以從中吸取教訓。

賴斯：不過，這也帶來了很多其他問題，比如事情對所有這些事件的實際反應以及它們是如何編排的。伊恩，你呢？

背景，以及 PokerStars sports 是如何在事件驅動架構上實現的

托馬斯：我是一名高級首席工程師，在弗利特 (Flutter) 國際公司工作，這是我七年前開始的一份工作的化身，在天空投注公司工作。我從事博彩業。這些年來，我一直致力於天空投注，投注，現在橫向撲克明星體育。從事件驅動的角度來看，我有幾個不同的角度。我很有興趣瞭解更多關於我自己的一個方面是 PokerStars 多年來的發展，因爲這是最大的實時事件驅動系統之一，我認爲可能存在於這個地方。

我在 2014 年加入了天空賭局 (Sky Bet back)。當時我們採用的主要方式是從一個單片系統（一個龐大的 Informix 數據庫）中提取數據，並將其分發給組織內的工程團隊，以允許他們控制數據，然後他們可以構建可擴展的前端。從那以後，我一直致力於各種其他系統的化身，包括一些由 Kafka 支持的系統，這些系統非常成功。看看我們如何實際使用它來管理自己的狀態，這是一個非常有趣的旅程。有很多不同的角度。我最近一直在做的一件事是研究我們如何在前端使用實時事件，並將撲克傳統應用到體育博彩和遊戲中。

背景，以及 BBC 是如何在事件驅動架構上着陸的

克拉克：我是馬修。我是英國廣播公司的架構主管。我相信大家都知道 BBC。我們有幾十個網站和應用程序，有了這些，我們就有了數百項服務。這是一個相當廣泛的事情。保持領先是很有趣的，但是有很多微服務思維和基於雲的思維，所以基於事件的架構必須屬於這一類。這不是教條式的事情。並不是說我們在任何地方都使用它。基於大量時間請求的系統是更好的解決方案。一直以來都有這些優點和缺點。基於事件的方法必須在它有很多優勢的地方發揮作用。從根本上說，如果你有一個搜索引擎或推薦引擎之類的東西，它不會自己填滿。您需要這些事件進入並填充它，因此它成爲一個好的服務。

使用事件驅動系統時瞭解域模型的重要性

Reisz：我首先想問的問題之一，可能只是一些你進入事件驅動系統時沒有想到的事情，一些讓你大喫一驚的事情。這是你旅程的早期。我將從我自己的角度給你舉一個例子。我發現當我使用事件驅動系統時，它有點難。在我參與之前，我必須非常瞭解這個領域，才能真正理解正在發生的舞蹈編排。格溫，你談了一些舞蹈和編曲。例如，當您使用事件驅動系統時，真正瞭解域模型的重要性是什麼？

夏皮拉：尤其是作爲一個試圖爲其他團隊提供建議的架構師，你還必須知道你不知道的東西。你的很多工作就是劃清這件事的界限，然後說，這是你所擁有的，不要走出去。如果你想在你發送的信息之外做點什麼，別人會擁有它。相信他們做正確的事情，他們擁有自己的領域。文化和架構是如何協同工作的，這很有趣，因爲如果你試圖編寫一個協調的系統而不是編舞，你實際上必須瞭解每個人的邏輯。你就是那個，我會打電話給你，這會發生的。然後我們再叫另一件事。如果這失敗了，我就不得不稱之爲另一件事。我覺得，在很多方面，舞蹈文化意味着你是你領域的專家，你定義了界限。那麼你就不必擔心其他領域了。還有其他專家，你可以相信他們。我認爲這是一種良好的公司文化。

事件驅動系統帶來的驚喜

Reisz:Ian，當你從一個更經典的單片系統開始使用事件驅動系統時，有哪些事情讓你感到驚訝？

托馬斯：我認爲大的一次似乎一次又一次地出現，從這個同步的東西到有時間軸的東西也要考慮。特別是當您有可能不同的數據源，或不同的數據生產者，並且思考，這是否真的發生在這之前？我該怎麼處理？然後，從這一點開始思考，如果我看到這個事件兩次會發生什麼？如果我從未見過它會發生什麼？我如何協調時間過後的一致性？如果你僅僅從人們從同步編程模型到異步編程模型的角度來看待它，你可以看到到處都是這種情況，就在一個整體中。你也有類似的情況。當這些數據也分佈在不同的系統中時，您需要了解，我如何去檢查這些數據，或者如何在另一個系統中看到這些數據，或者如何回放日誌？這很有挑戰性。我會說是的，可能是時間因素。

瑞茲：馬修，有什麼想法嗎？

克拉克：是的，我同意你所說的。是的，瞭解事物的狀態，你是否失去了什麼，你是否有比賽條件，這些事情變得非常困難，非常堅毅，絕對。我們談論無狀態是一個多麼美妙的範例。您可以通過無服務器功能實現這一點。你需要關心，你只需要擔心當下的時刻。然而在一個事件驅動的世界裏，你有你的微服務，它有很多狀態。它收到了很多活動。如果你失去了一些，你就有麻煩了。它可能不得不把它傳給其他東西。如果失敗了，或者需要重新部署或其他什麼，會發生什麼？突然間，你看了看，這不是一個小問題。這不是夢想。當我從我非常滿意的經典 restapi 轉移過來時，它非常簡單，突然間這不是靈丹妙藥，是嗎？它有各種各樣的挑戰。

如何處理無序事件

Reisz：人們想學習的一個問題是如何處理那些無序事件。伊恩，你說了一點關於必須處理不同時間發生的不同事件。您如何處理這樣一種想法，即該事件可能不一定以這種同步事件順序出現？你怎麼處理這樣的事情？

托馬斯：對我們來說，當我們看到這一點時，最重要的地方是下注的位置，也就是說，有人真的在你身上花了一些錢。被拋來拋去的關鍵詞是冪等性，確保你的事件可以在沒有嚴重後果的情況下重演，特別是財務方面。這是一個真正的教育案例，所以要理解這是一種可能性，並在設計系統時牢記這一點，就像大多數事情一樣。我們有很多事情需要考慮，如果我們多次遇到這個事件，我們如何丟棄這些東西？如果我們沒有看到它，我們如何回放或將新事件推送到系統中，以嘗試獲得正確的一致性？然後，我們的一些運營人員對我們最大的一個阻礙是，在生產中這樣做是對還是錯，或者你做了什麼。你自己決定吧。如果您有一個數據庫，並且您的數據不一致，那麼您至少有能力進入並調整它。您可以運行一些 SQL 命令。“我可以解決這個問題。” 當你依靠回放的事件日誌時，你必須考慮控制平面是什麼樣的？我用什麼方法使自己恢復良好狀態？

回到一個好的，已知的狀態

瑞茲：格溫，你有什麼建議讓人們考慮讓自己回到一個衆所周知的狀態？

沙皮拉：我非常相信確保一切都是冪等的。你再往回走一點，相信如果你重播，它不會讓你陷入更糟糕的狀態。在我看來，真正做異步事件的最大障礙，並不是異步事件真的那麼難，而是人們在內心深處沒有接受這是唯一的方法。做一些同步的事情，做一些可擴展的事情，做一些性能好的事情，基本上你不會得到這三個。它可以是同步的、高性能的，但不能擴展。您可以同步並嘗試擴展，但您將擁有非常大的隊列。它不會有太多的表現。如果您想要性能和可擴展的東西，您必須是異步的。一旦你開始走，我就得走了。那麼，真的，有一個冪等事件有那麼難嗎？通常沒那麼難。只是你必須，我在一個新的世界裏，我不想用新的工具創造我的舊世界。事實上，我現在身處一個新世界。

編舞與精心編曲（Choreography vs well-defined orchestration）

Reisz:Nandip 問了一個關於定義良好的業務流程的問題。當我看到這篇文章時，我讀到的是編舞與配器，回到我們之前討論的內容。是否總是有這樣一種情況，即一切都應該是編舞，或者是否有這樣一種情況，即我們需要有單獨步驟的定義良好的編排？馬太福音？

克拉克：從來沒有一個正確的答案。我們有兩種方法。有時您可以使用編排設置來操作它，有時則不能。我們之前說過的是，假設您在某個時候會被重放，無論您使用什麼，您都會在事件驅動的消息中發現 bug，例如，您需要重放內容的地方。即使您的技術非常擅長在正確的位置發佈正確的內容，並保證至少一次一致性，您也必須在某個時候處理內容的重複，因爲這只是您工作的一部分。

瑞茲：伊恩，格溫，有什麼想法嗎？

托馬斯：我真的很喜歡燕翠，他在這一點上做出了妥協，這是在一個有界的背景下，編曲可能是正確的選擇。當你觀察不同環境之間的交流時，事件驅動的編舞才真正開始發揮作用，而且它很強大。當然，這還不是一個完全的扣籃。我認爲這可能是一個很好的定義起點。

賴斯：那是個好主意。燕翠，這也正是我的想法。他有一篇很好的博文，如果你想更多地瞭解這兩者之間的區別的話，可以深入探討這一點。

在 Kafka 架構上分離事件和創建主題

格溫，這裏有一個問題是關於分離事件，以及你如何真正開始思考你的話題。當有人走到你面前，問你關於分離事件和創建 Kafka 架構主題的問題時，你如何與他們談論這一點？你讓他們想些什麼？你告訴他們要考慮什麼？

夏皮拉：這很有趣，因爲我過去常常回答數據庫的問題，這個積分應該是什麼，什麼應該是分離維度。感覺就像是同樣的事情不斷重演。首先，就像得到一本關於數據建模的好的、非常古老的書一樣，基本上不會有什麼傷害，就像建模就是建模一樣。你有一本領域驅動的設計書。另一方面，您有一個老式的數據倉庫建模或數據建模系統。在 Kafka 中，您需要考慮的是一些規模要求。這就是它所做的稍微不同的事情。如果某個事件非常常見，那麼您可能希望將主要度量和度量主題與稍微不常見的內容分開。因爲它們可能會被單獨處理，你會希望在不同的時間內對它們做出反應。另一件重要的事情是排序保證，這在數據庫中是不會發生的。如果內容在不同的主題中，那麼您將無法控制它們的順序。它們可以按任何順序處理，你需要對此表示同意。如果你想讓事情有一個順序，你把它們放在同一個分區的同一個主題上，你就有了這個完整的順序，它就在那裏。那麼很多隻是業務邏輯。我看到一個關於一個事件應該有多大的問題經過。這就像一個函數應該有多大。如果它變得過大，可能是一種氣味。一天結束時，你的模型有好的邊界嗎？在您的企業中，事件是真實世界的事件嗎？它是否與正在進行的某項業務保持一致？這是主要考慮因素。你不想用不同的方式人爲地把東西切碎嗎？

托馬斯：我們曾經與工程師們進行過很多對話，他們專門關注 Kafka 和 Kafka 流，瞭解主題設計如何影響他們的流，因爲有很多長期影響。特別是，如果您使用它來存儲狀態和壓縮主題。人們從一開始就設置了錯誤數量的分區。

Shapira：有一件事我要提醒周圍的人，也要提醒內部和我的雲管理者，你們不想把暫時的限制變成一種宗教。如果你認爲某件事是正確的商業行爲，但你必須做出妥協，因爲技術迫使妥協，你想非常清楚地記錄我們想要做 X，但實際上這是不可能的。因爲那時你不知道，也許一年後 X 將成爲可能，你可以回到它。例如，Kafka 過去的分區數量是有限的。它早就消失了，而且正在變得更加消失。人們圍繞它設計了整個世界的意識形態，很難說，你這樣做是因爲它是正確的，還是因爲你相信事實上已經不存在的侷限性。

賴斯：伊恩，我想讓你雙擊一下。你說你的主題設計的長期影響，比如什麼？再多描述一下？

Thomas：有時候，考慮到根據事實改變事情是多麼容易，並考慮到您可能需要的吞吐量，這有點幼稚。對於 Gwen 在那裏提到的事件大小，如果您的事件太大，那麼您想要的複製模型以及在代理之間要發送的通信量就會出現問題。對我們來說，最主要的是，如果我們把狀態保存在一個壓縮的主題中，然後你突然意識到，等等，我們沒有足夠的分區來支持我們現在所擁有的吞吐量，因爲這已經增加了。如果您嘗試擴展，則所有這些以前的事件都將位於錯誤的分區上。你必須和這樣的人一起玩，如果你將來需要的話，你打算如何擴大規模？您知道您現在選擇的約束條件是什麼嗎？

我們傾向於嘗試在 Amazon 1 型和 2 型框架中建模。比如，這是你現在就可以做而不用擔心的事情嗎？它在未來很容易改變嗎？我認爲，如果你不一定對系統的工作原理或者你正在使用的實際技術有足夠的瞭解，你就不可能在沒有真正意義的情況下很容易地把一個 2 型的東西變成一個 1 型的東西。它可以確保人們意識到這是一個限制，在設計系統以及如何通過這項技術放置數據時，請記住這一點。

克拉克：事實上，我發現即使是偉大的 1 型，2 型，這個想法，這是一個可逆的決定嗎？這是我在事件驅動架構中遇到的挑戰之一。它會把你鎖在以後很難改變的事情裏。一旦有多個客戶機正在接受您的事件，更改事件格式就變得非常棘手了。您希望可以在客戶不關心的情況下向 JSON 或其他任何內容添加新字段，但這樣做總是讓人感到非常緊張。我想我們還沒弄清楚你是怎麼處理的。

夏皮拉：這方面有一整本書。格雷格 · 楊的書。

瑞茲：讓我們談談這個，格溫，因爲有一些問題出現了。你如何解決這樣的問題？

格溫，你說的是一本書？

夏皮拉：是的。這是格雷格 · 楊的作品。他寫了一整本關於事件版本控制的書，這表明這不是一個容易的問題，我現在不打算在五分鐘內爲你們解決它。Kafka 以其對穩定的狂熱而聞名於世。你可以像一個 0.8 的經紀人、一個 3.0 的製作人和一個 1.0 的消費者那樣，讓一切都運轉起來。它的代價是你進化的速度極其緩慢。如果每個客戶端和每個應用程序都有一個大的，如果你得到版本 1 的事件，如果你得到版本 2 的事件，這是非常不神奇的。

第 2 天，與事件驅動系統相關的問題

Reisz：今天早上，Katharina Probst 在她的主旨演講中提到了一系列針對微服務的第二天操作。她列舉了一些事情，比如負載測試、混沌工程、AIOps 監控。當我們談論事件驅動系統時，您需要考慮哪些第二天的問題？例如，您談到了版本控制。什麼是你需要思考的事情，也許你真的沒有考慮過？

克拉克：我想到的是一對夫婦，斯凱爾絕對是其中之一。如果大量事件已重新發布，會發生什麼情況？通常，你會發現，如果你是一個微服務所有者，你可能會發現你的一個攻擊性玩家突然出於任何原因選擇發佈東西。也許他們有個臭蟲什麼的。你需要有能力處理這件事。或者，至少，您前面可能有一個隊列，您可以從中處理積壓工作。您不希望積壓工作持續很長時間。你有一個有趣的規模挑戰，從任何地方，所有的交通可以來自所有這些事件。事實上，你正在存儲狀態，你是如何存儲狀態的？如果你重新部署自己會怎麼樣？你確定在這些時刻你沒有掉東西嗎？

賴斯：伊恩，你的想法是什麼？

托馬斯：我完全同意這兩個觀點。也許隨着時間的推移，我注意到的其中一個問題是第二天過去了，但更像是第 600 天，當構建系統的人繼續前進時，人們害怕新的人進來，試圖弄清楚這件事是如何運作的，無法改變事情，並且感到擔憂。很多都像你在開始時提到的，領域，以及它是如何記錄的？人們是如何改變事情的？實際上，冷淡地嘗試採用這個系統，並使其適應公司當前的需求是什麼樣的？

瑞茲：格溫，你有什麼想法嗎？

夏皮拉：是的，我覺得我的第二天活動，我們應該在第 0 天完成，諸如此類的事情。測試框架，您擁有所有這些微服務，您將獨立升級它們。人們都在談論建立信心，所以你真的要做一個改變，你想有一個測試框架，運行時間不會太長，也許一兩個小時，但不會太長。B、 大多數情況下都會通過。它每天應該很少有綠色建築。第三，相當容易使用、發展和診斷。我在第二天發現，實際上升級和發佈都很困難，因爲我們沒有一個很好的測試框架，現在我們必須基本上停止一系列生產項目，重新開始。我們有 50，60 個服務，我們甚至沒有那麼大，我們如何實際測試不斷髮展的場景，所有這些場景，以確信我們沒有破壞其他任何東西？

事件驅動系統的監測和可觀測性

賴斯：這裏有一大堆關於可觀察性、監控和諸如此類的問題。我想換個話題，給你們每個人一個機會談談可觀察性、監控事件驅動系統和任何工具的重要性。我想，伊恩，當我們交換一些電子郵件時，你談到了第二天的想法，實際上是在你正在使用的東西中加入一些監控類型的工具。我很想知道，你們每個人關於監控事件驅動系統的一些提示、技巧和想法。

托馬斯：其中一些給我們帶來最大價值的東西是添加跟蹤，以便在消息和記錄通過系統的各個部分時能夠看到它們的生命週期。再加上 Kibana 這樣的工具，可以非常強大地準確地理解事物是如何在 X 應用程序上移動的。我們經常被問到的一個問題是，我們看到了嗎？有一件事你並不總是有奢侈的是，你是製片人，這是事件的來源。對於我們來說，我們從第三方供應商那裏獲取了大量數據，這些供應商在足球比賽中有球探併發布更新，我們只是不太知道，這種情況發生了嗎？我們應該看到這場足球賽的比分達到了 3-0，或者別的什麼，但是我們沒有那種狀態，所以我們看到了什麼比賽，什麼順序？我們構建了一些工具，使我們能夠真正快速地進入生產箱並回放一些事件。

在我們花時間圍繞這一點構建內部工具之前，總是讓我們絆倒的事情是，我們希望在代理和客戶之間建立 TLS。這是 Kafka 特有的。這強制了我們的 ACL，所以您可能沒有查看特定主題的權限，您必須考慮一下，您在那裏做什麼。如果您確實有一些調試工具，請確保您不會干擾實際的生產客戶，這樣他們就不會到處亂打，並且確保您正在考慮它實際上會如何影響工作系統。然後，如果我們需要提取數據，通常情況下，我不知道每個人的系統是否都不同，因此我們有多個級別的跳轉帖子來聯繫實際的 Kafka 經紀人。然後你會想，我如何從中提取有用的信息，然後把它拿走，在 PIR 中分類，或者類似的東西？歸根結底是這樣的，直到你需要它們，你才真正發現你的需求，這就是確保你已經把時間放在一邊，把精力放在構建你需要的東西上。

賴斯：你的里程數可能會有所不同。絕對地 Matthew，你們在可觀察性方面學到的任何東西都可能是對其他人的好建議。

克拉克：正如伊恩所說，追蹤真的很好，不是嗎？我們在 Amazon X-Ray 上做了很多工作，效果非常好。然後，在每一個微服務級別上，您都能正確地記錄日誌，以便能夠診斷哪裏存在問題。只要你在每一個微服務之間都有一些經紀人，不管是 Kafka，還是動情，或者其他什麼，那麼你就有希望發現並分離出讓你失望的微服務，並儘快解決它。

瑞茲：格溫，你有什麼消息嗎？

沙皮拉：我要補充的唯一一件事可能是採樣的想法，你可以有一個外部系統來對一些事件進行採樣，特別是如果正在進行的一切都是非常大規模的。然後，在後臺仔細檢查是否存在異常值，並確保沒有任何意外情況，比如事物不會過大。伊恩剛剛對它說，你知道你的數據的形狀應該是什麼樣的。這就是你如何檢測我們是否應該看到它，而它不在這裏，諸如此類的事情。我們也知道，我們不應該期望一秒鐘內有許多授權嘗試。如果我們明白了，可能是出了嚴重的問題。我們已經建立了這個系統，它在後臺運行，並對樣本的一些規則進行了雙重檢查。我認爲這對我們很有幫助。

從戰爭故事中吸取的教訓

瑞茲：格溫，我要從你開始談這件事，因爲我想你已經提到了一件。對於不同的戰爭故事有很多要求，這讓你學到了一些不同的課程。你從一些戰爭故事中學到了什麼教訓？告訴我們關於戰爭的故事，也許還有教訓？

Shapira：我認爲這與前面的版本控制討論有關。我們基本上想升級很多東西。我們有大約 1000 個單一服務類型的實例，我們只想升級它們。這是一個無狀態的服務，這使它變得簡單。我們剛剛通過我們的管道推送了大約 1000 個升級事件，希望所有事件都能得到處理，其中 997 個能夠隨着時間的推移自行升級，而 3 個不會。我們甚至不知道爲什麼。活動即將開始，一切看起來都很好。我們有痕跡。我們到處都有原木。最終，我們發現這是我們最古老的三項服務，基本上就像我們擁有的前三個客戶一樣，可以追溯到 2017 年。他們有一些不同的授權密鑰，阻止他們下載這些他們需要下載的東西來升級自己。甚至沒有人確切記得鑰匙是怎麼到那裏的。顯然，這是一個不同類型的事件。才三點。我們最終野蠻地強迫他們。這類事情，即使你對進化非常小心，比如一步一步地進化成一個系統，它將與 2017 年發生的任何事情完全不兼容，甚至沒有人記得。我認爲這裏的主要教訓就是不要有任何懸而未決的東西。每三個月、六個月都要升級一次，如果你在做什麼項目時沒有太多的變動，那麼可能還要再升級一點。

瑞茲：伊恩，你呢，告訴我們一些戰爭故事？

托馬斯：當你問這個問題時，我突然想到了一對夫婦。他們都是幾年前的人，所以我不認爲我說這些話傷害了任何人的感情。其中一個是關於事件的大小，或者更確切地說是與事件相關的事物的大小。在 Sky Bet 上，構建頁面的方法之一是，從 Informix 流出的信息流經過各種 rabbitmq，然後由節點處理，最終存儲在 Mongo 文檔中。由於更新發生的方式，我們傾向於從 Mongo 讀取文檔，找出這對文檔意味着什麼，然後將其寫回。這種邏輯中存在一個缺陷，這意味着我們從未真正從 Mongo 文檔中刪除過內容。因爲它是一個主頁，我想它是網站上的賽馬主頁，它只是逐漸變大了。雖然這並不明顯，但不幸的是，當該網站在節禮日（在英國，這是一個體育博彩的大日子）宕機時，所有這些事情都出了問題。我們不知道爲什麼。這基本上是因爲我們頻繁地從 Mongo 中提取文檔，從而使我們的網絡飽和，以至於我們無法再實際處理它。那是非常有趣的一天。

我能想到的另一個問題是，很難解決，可能涉及到與 Kafka 合作的最佳實踐，那就是我們有兩個製作人的情況非常奇怪，所以這很簡單。我們有兩個製作人編寫一個主題，但具有相同密鑰的記錄最終出現在不同的分區上。其中一個基本上是一個節點應用程序，另一個是用 Kotlin 編寫的。密鑰的使用方式和用於生成實際分區散列的數據類型意味着整數在 Kotlin 中使用，因此溢出。它實際上是在生成與 Node.js 不同的散列。那是一個相當不錯的一天，尋找它。

夏皮拉：你是怎麼發現的？

托馬斯：我不記得了。那是幾年前的事了。我們只是在這些節目中逐行播放，有什麼不同？我們最後得出的唯一結論是這一個是節點，而那一個基本上就是 JVM。實現中可能有什麼不同？這只是一個數字。

我能想到的另一個問題是，很難解決，可能涉及到與 Kafka 合作的最佳實踐，那就是我們有兩個製作人的情況非常奇怪，所以這很簡單。我們有兩個製作人編寫一個主題，但具有相同密鑰的記錄最終出現在不同的分區上。其中一個基本上是一個節點應用程序，另一個是用 Kotlin 編寫的。密鑰的使用方式和用於生成實際分區散列的數據類型意味着整數在 Kotlin 中使用，因此溢出。它實際上是在生成與 Node.js 不同的散列。那是一個相當不錯的一天，尋找它。

夏皮拉：你是怎麼發現的？

托馬斯：我不記得了。那是幾年前的事了。我們只是在這些節目中逐行播放，有什麼不同？我們最後得出的唯一結論是這一個是節點，而那一個基本上就是 JVM。實現中可能有什麼不同？這只是一個數字。

第二天，關於操作事件驅動系統的建議

Reisz：我想把重點放在第二天，如果你能和某人坐下來，就第二天或事件驅動系統的長期運行給他們一點建議。我們一直在談論 Kafka。你有什麼建議？不一定非要和 Kafka 在一起？你有什麼建議嗎？

克拉克：盡你最大的努力讓事情儘可能簡單，因爲這些事情變得如此複雜真是不可思議。如果我們有時間的話，我會說的故事是，我們如何有一個時刻，所有這些不同的系統在做所有這些不同的事件，如果我們將這些事件標準化，並將它們放在一起，並將所有事件作爲一個超級主題，這不是很好嗎？當然，那是個糟糕的主意。因爲它們都有不同的屬性，以不同的方式擴展，以不同的方式需要。就像微服務的概念一樣，讓事情分開，讓事情簡單。不要以爲事件驅動就是答案，因爲它是一個很好的解決方案，但並不總是正確的解決方案。請注意，它可能不像最初看起來那麼簡單。

不是事件驅動系統的最佳系統

Reisz：對於事件驅動系統，哪些系統可能不是最好的？你有什麼想法嗎，馬修？

克拉克：從根本上說，如果你是一個面向用戶的東西，它會以一個請求結束，不是嗎？一個用戶出現了，給我一個東西。在某個時刻，您的事件必須轉變爲請求。這一切都是爲了找出它在哪裏。在英國廣播公司，我們更喜歡有它，所以實際上我們會根據用戶的到來做很多請求，這樣我們就可以迴應他們是誰。我們希望在這方面充滿活力。這是一個例子。你不能現實地提前準備，因爲你想對當下做出反應。

對於事件驅動系統和第二天推薦來說，不太好的事情

賴斯：伊恩，哪些東西不是偉大的事件驅動系統？那麼，第二天你對某人的建議是什麼？

托馬斯：不好的事情？我認爲考慮它的一個好方法是，如果我有一個工作流，你希望能夠識別該工作流中的所有步驟，並將其作爲一個深思熟慮的實體加以關注。這是一種很好的編排方式，而不是事件驅動。我的建議與此類似，不要強制在不需要的地方安裝它，但在設計數據時也要非常慎重，以允許其不斷髮展。請記住，您選擇的實現方式。你需要 SNS、SQS 還是運動？考慮一下您正在使用和設計的實際代理和系統的約束，而不是針對它們。

什麼時候不使用事件驅動？我幾乎可以這樣說，從節點開始，尋找需要這種可靠性水平或重放能力的地方，以及真正強大的大規模解耦。基本上，請注意什麼時候需要事件驅動而不是啓動程序，因爲我確實覺得它增加了一層複雜性，可能你永遠都無法實現，誰知道呢？也許你的創業不會那麼成功。

就第二天而言，我會稍微爲自己着想，並說你確實可以選擇不以自己的身份排名。它只是消除了一系列的痛苦，然後把它交給一個實際上相當興奮和樂意照顧它的人。我認爲這在總體上是正確的，就像我們不做自己的監控一樣。我們有一羣第三方提供商爲我們進行監控。我們不經營我們自己的 Kubernetes，我們用 AKS，EKS，GKE 來做這些。是的，基本上，偶爾有一些你不必擔心的事情是很好的。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4fAjZKBo8ps--9xGQnHsdQ