發行項
03/25/2015

本文章是由機器翻譯。

Microsoft Azure

事件資料流導向系統的興起

它是所有關于資料這幾天。資料可以説明我們做出明智的決定。大資料説明我們作出知情和有見地的決定。大的資料流程的説明我們做出知情的、有見地的和及時的決策。這些不斷流動的資料流程通常被稱為事件流。它是越來越多地共同打造軟體系統，其主要目的是處理事件流。

甚至可以跨越不同的行業和領域，那裡是可識別的常見建築模式，圍繞這些事件面向流的系統。這種模式為現代事件面向流的系統起著經典的 n 層體系結構為傳統的對處所企業系統舉行的相同的基本作用。我會開始探索這一新興模式的縮略圖。

模式識別

首先，我應該澄清術語事件什麼意思。在這裡，這意味著只是有點事情發生在一個系統中的資料。事件往往較小的大小以位元組或千位元組範圍。你還會聽到像消息、遙測或甚至只是資料替代事件的條款。

接下來，有事件生產者。這些生產者可以是幾乎任何東西 — — 連接汽車、智慧溫控器、遊戲機、個人健身設備或甚至軟體系統生成自我-診斷事件。它是重要的是認識到，雖然，在大部分的這些系統，你在跟許多事件生產者。

許多系統預期事件生產者在數萬人，進千家萬戶的數以百萬計或多個不等的數目。這意味著這些系統往往具有高容量和高速度。高容量意味著還有大量的全面和高速度意味著頻繁地生成資料的資料。

另外還有事件消費者。消費者是這些類型的系統的真正核心。他們是負責分析、解釋和對事件的回應。在一個典型的系統中的消費者的數量可能範圍從幾個到一對夫婦打。事件不被路由到特定的消費者。每個消費者在看同一組事件。在微軟 Azure 中，消費者是最有可能的雲服務。

考慮一下這個例子。還有代表金融交易事件流。在這個場景中的事件生產者是零售商店的銷售點系統。一個消費者擁有責任分析欺詐活動的流，併發出警報。另一位消費者分析相同的流，以使得時間只是供應鏈的優化。最後，第三的消費者負責事件轉化為長期的冷庫，為以後分析。

當結合現實的高容量與高-速度事件生產者和消費者的這種模式將介紹幾個有趣的問題：

你如何防止事件生產潮從絕大多數消費者？那就是，該系統時如何回應事件產率開始超過消耗率？
因為事件速度很高，你如何可以擴展單個事件消費者？

解決問題的關鍵是使用事件代理（請參閱圖 1)。這是精確地由最近發佈 Azure 事件樞紐的作用。

圖 1 天青事件集線器架構

那麼如何，確切地說，不使用代理（例如事件集線器解決我到目前為止已經概述的問題？

瞭解事件集線器

事件集線器提供吸收和保留事件，直到下游消費者能趕上所需的彈性。事件集線器可以有效地調配出變異事件中流率因此消費者不必擔心這件事。無此流平性、接收的消費者可能會變得不堪重負，開始失敗。

使用代理隔離事件生產者和事件消費者從彼此。這種隔離是特別重要的體系結構模式的更成熟的版本附加的仲介人有必要的生產者和消費者之間。事件集線器是組成、煤層或體系結構中的邊界點。通過事件集線器進行交互的所有元件不需要彼此的特定知識。

在這一點上，它可能容易混淆事件集線器與傳統消息提供隔離的相同類型的服務的國際企業。然而，事件集線器是不同的幾個關鍵的方式，使這種建築模式的理想選擇。

獨立的消費者

事件中心使用的是發佈 / 訂閱的模式；然而，每個消費者都有相同的事件流的獨立見解。在一些傳統的消息傳遞系統與多個消費者，郵件被覆制為每個感興趣的消費者。這可能是低效的速度及空間，但好處是每個消費者都有它自己的"收件匣"。作為一個消費者處理消息，它會從其收件匣中移除它們。還有其他消費者沒有影響，因為他們在他們自己的收件匣中有它們自己的副本。

與事件集線器，還有一套不可改變的事件，以及因為他們是不可變的只需要有一份副本的每個事件。同樣，消費者永遠不會從系統中刪除事件。所有的消費者正在尋找相同的事件集。正因為如此，消費者自己跟蹤的責任他們所在的地方在事件流中。他們這樣做是通過跟蹤他們在事件流中的偏移量。還有實際上為此 SDK 中內置的 API。

基於時間的保留

在傳統的消息傳遞系統中，消費者是負責告知系統，它完成的消息時。然後，該系統可以擺脫消息。因為事件集線器消費者負責跟蹤自己事件流內的位置，如何不事件集線器知道當消費者做的事件？總之，它不會。與事件集線器，您將配置的保留期和事件存儲的大量時間。這意味著事件屆滿對他們自己的獨立于任何消費者行動。

基於時間的含義是保留的消費者的需求，檢查並處理過期之前的事件。與基於時間的保留，每個消費者都有壓力，保持。幸運的是，事件中心的基礎設計允許個體消費者作為必要的規模。

支援這項活動樞紐由物理分區的事件流。資源調配事件集線器時設置分區的數。請參閱官方文檔 bit.ly/11QAxOY 更多詳細資訊。

當事件發佈到事件的中心，它們被放在分區中。某一特定的事件駐留在只有一個分區。事件是均勻分佈在預設情況下中的輪循機制方式的分區。有提供分區關聯的機制。最常見的允許您設置分區鍵屬性的事件，並具有相同鍵的所有事件將都送交同一分區。

如何分區的事件流，説明消費者與基於時間的保留？在事件集線器中，正確的說法是實際上的消費群體。稱這一組的原因是每個消費者確實含有多個實例。每個組有一個實例，每個分區。從這一點上，消費群是指作為一個整體消費者和消費者實例是指一個特定分區中感興趣的組的成員。

這意味著一個消費者團體可以處理並行流事件。組中的每個消費者實例可以處理一個分區獨立于其他實例。這些消費者實例均可以駐留在一台機器，從另一個運行在隔離每個消費者實例。可以跨多台電腦，甚至到了每個消費者實例運行在一個專用的盒子上分發。這種方式，事件集線器繞過一些與競爭消費者的傳統模式相關的典型問題。

隔離是一個關鍵的概念。第一，你孤立事件生產者和事件消費者從彼此，從而使靈活的體系結構組成以及負荷量。第二，消費群體是彼此，隔離整個消費群體減少連鎖故障的機會。第三，消費者在一個給定的消費群體中的實例是，使水準方向上縮放為個人消費群體而彼此隔離。

使用事件集線器

有幾個好的教程，入門事件集線器。查閱正式檔在 bit.ly/11QAxOY 和教程使用您所選擇的平臺。

您需要提供一個事件中心第一次。這個過程非常簡單。你很容易可以把它嘗試與審判的 Azure 帳戶。在 Azure 監管中心中，導航到服務匯流排節。你將需要創建一個服務匯流排命名空間，如果你不已經有一個。在那之後，你會看到稱為已說明，用於創建一個事件中心的事件集線器的一個選項卡（見圖 2)。

圖 2 創建一個事件樞紐

您還需要為事件樞紐設置一個共用的訪問策略之前就可以開始。這些政策管理安全事件樞紐。在門戶中，導航到您剛才創建的事件集線器並選擇配置選項卡。

選擇管理的許可權，並為策略指定一個名稱，如"超級"或"做-不-使用-中-生產"。在那之後，切換到儀表板選項卡，按一下底部的連接資訊按鈕。你會想要注意到的連接字串，以及你給你事件中心的名稱。

建置事件

我會在這裡顯示的代碼使用.NET SDK，但您可以使用任何支援 HTTP 或 AMQP 的平臺。您將需要參考微軟 Azure 服務匯流排 NuGet 套裝程式。你需要的類是 Microsoft.ServiceBus.Messaging 命名空間中。你需要做的就是創建一個用戶端，創建一個事件併發送：

var client = EventHubClient.CreateFromConnectionString (
  connectionString,
  eventHubName);
var body = Encoding.UTF8.GetBytes("My first event");
var eventData = new EventData (body);
await client.SendAsync (eventData);

雖然簡單，但有幾個有趣的專案，指出。該事件的身體是只是一個位元組陣列。處理此事件的任何消費群體將需要知道如何解釋這些位元組為單位）。它是提示的可能的消費群體將需要某種形式，用來確定如何反序列化的身體。該事件被發送之前，可以附加中繼資料：

eventData.Properties.Add ("event-type", "utf8string");

這意味著使用鍵和值都是眾所周知的生產者和消費者團體。如果你想要確保一組事件發送到同一分區，您可以設置分區鍵：

eventData.PartitionKey = "something-meaningful-to-your-domain";

如果事件不具有親和力與分區，你會得到更好的性能。在某些情況下，雖然，你就會想一套相關的事件路由到一個單一消費者實例進行處理。要在他們收到的訂單，保證具有給定分區中的事件。同樣地，沒有簡單的方法，以保證事件的順序在不同的分區，在事件的中心。這通常是永生永世事件動機要關聯到一個特定的分區。

例如，如果您要啟用智慧汽車，你想為給定的車能在同一分區中的所有事件。您可能會選擇分區鍵的車輛識別號碼（VIN）。或您的系統可能會集中在智慧樓宇、與數以百計的生產事件的每一幢樓房中的設備。在這種情況下，您可能使用建築本身的身份為該分區鍵等所有事件從相同的建設用地在同一個分區中的所有設備。

總體來看，分區的親和力是危險的做法，只應謹慎使用。分區鍵一個糟糕的選擇可能導致一個不均勻的事件分配跨分區。這可能最終意味著消費群體會有麻煩的縮放比例。好消息是，很多時候，您可以更改系統的設計，以避免需要分區的親和力。

使用事件

你可能會擔心你會怎麼這一切。你的顧客群體需要來跟蹤其偏移量在事件流中。每個組需要有一個為每個分區的實例。幸運的是，還有的 API。

引用 NuGet 套裝程式微軟 Azure 服務匯流排集線器事件ProcessorHost。你需要的類是 Microsoft.ServiceBus.Messaging 命名空間中。入門很簡單，只執行一個單一的介面：IEventProcessor。

一旦你實現了你的事件處理器，您將創建 EventProcessorHost 註冊您的事件處理器的一個實例。主機將處理你所有的繁重工作。當它啟動時，它將檢查您的事件中心去看看它有多少個分區。然後，它將創建您為每個可用的分區的事件處理器的一個實例。

有三種方法，您需要實現。前兩個是 OpenAsync 和 CloseAsync。宿主調用 OpenAsync 時事件處理器實例是第一批出分區。這意味著事件處理器實例具有獨佔存取權限到分區問題的消費群。同樣，主機會丟失其租約時，或當它關閉時調用 CloseAsync。雖然你現在開始，您可以使用一個非常簡單的實現：

public Task OpenAsync(PartitionContext context)
{
  return Task.FromResult(true);
}
public Task CloseAsync(PartitionContext context, CloseReason reason)
{
  return Task.FromResult(true);
}

這兩種方法接收一個 PartitionCoNtext 參數。剩餘的方法以及接收。如果您想要查看有關特定的分區空間租給了事件處理器的詳細資訊，您可以檢查此參數。最後一個方法是，在哪裡你實際收到的事件（見圖 3)。

圖 3 提供了事件的最終方法

public async Task ProcessEventsAsync (PartitionContext context, 
  IEnumerable<EventData> messages)
{
  foreach (var message in messages)
  {
    var eventType = message.Properties["event-type"];
    var bytes = message.GetBytes();
    if (eventType.ToString() == "utf8string") {
      var body = System.Text.Encoding.UTF8.GetString (bytes);
      // Do something interesting with the body
    } else {
      // Record that you don't know what to do with this event
    }
  }
  await context.CheckpointAsync();
  // This is not production-ready code
}

正如你所看到的這很簡單。您會收到的事件你可以遍歷或做任何工作需要的可枚舉集合。您還可以調用的上下文。CheckpointAsync 方法的末尾。這就告訴主人你成功處理了這一組事件，您想要記錄一個檢查點。檢查點是在批次處理中的最後一個事件的偏移量。

這就是如何你消費群可以跟蹤的每個分區已處理的事件。主機啟動後，它嘗試獲取任何可用的分區的租約。當它開始處理為一個分區時，它將檢查該分區的檢查點資訊。僅去年執行檢查點操作的偏移量比更近的事件被發送到他們各自的處理器。

主機還提供自動負載調配跨機器。例如，假設您有事件樞紐，16 分區。這意味著將有 16 個實例的事件處理器 — — 一個用於每個分區。如果您在一台機器上運行主機，它在同一機器上創建所有 16 個實例。如果你在相同的消費群二機及其部分上啟動另一台主機，兩台主機將開始跨兩個機級分佈的事件處理器實例。最終將每台機器的八個事件處理器實例。同樣地，如果你取下第二台機器，然後第一個主機接管回來的孤立的分區。

假設您的 IEventProcessor 的實現是 MyEventProcessor。然後具現化該主機可以是這麼簡單：

var host = new EventProcessorHost(
  hostName,
  eventHubName,
  consumerGroupName,
  eventHubConnectionString,
  checkpointConnectionString);
await host.RegisterEventProcessorAsync<MyEventProcessor>();

EventHubConnectionString 和 eventHubName 是在前面的示例發送事件時使用相同的值。它是最好用到所需要的只是限制使用的共用的訪問策略的連接字串。

主機名稱標識 EventProcessorHost 的實例。在執行階段主機群集（意為多台電腦），建議您提供的名稱能夠反映正在其運行的機器的身份。

ConsumerGroupName 參數標識此主機表示邏輯的消費群。還有一個預設消費者群體你可以引用使用常量 EventHubConsumerGroup.DefaultGroupName。你需要進行第一項規定消費群任何其他名稱。執行此操作所創建的 Microsoft.ServiceBus.NamespaceManager 的實例，並使用方法，如 CreateConsumerGroupAsync。

最後，您需要提供連接到使用 checkpointConnectionString Azure 存儲帳戶連接字串。此存儲帳戶是主機跟蹤有關分區的所有狀態事件偏移量。這種狀態存儲在 blob 以純文字格式，您可以隨時檢查。

有其他事件樞紐--預置與集成在一起的 Azure 服務。Azure 流分析 (目前在預覽）提供轉換和分析事件流起源于事件中心的聲明式類似于 SQL 的語法。同樣，事件集線器提供一個壺嘴很受歡迎的 Apache 風暴，現在可在通過 HDInsight Azure 上預覽。

總結

這裡列出的建築模式是僅僅是個開始。當執行真實世界的系統，有許多其他問題，您需要考慮的因素。這些問題涉及高級的安全、資源調配和管理事件生產者、協定轉換、出站通信。不過，你現在需要構建一個使用事件代理（例如事件樞紐系統的基本概念與裝備。

Christopher Bennage是微軟模式的成員 &實踐團隊。他喜歡用電腦製作東西。

感謝以下的微軟技術專家對本文的審閱：穆斯塔法 Elhemali 和DanRosanova

共用方式為