Article
03/03/2015

Cet article a fait l'objet d'une traduction automatique.

Microsoft Azure

L'avènement des systèmes d'événement orientés flux

C'est tout au sujet de données ces jours-ci. Données nous aident à prendre des décisions éclairées. Données volumineuses nous aide à prendre des décisions éclairées et perspicaces. Gros flux de données nous aident à prendre des décisions éclairées, perspicaces et en temps opportun. Coulant en permanence les flux de données appelle souvent flux d'événements. Il est de plus en plus commun pour construire des systèmes de logiciel dont le but principal est de traiter les flux d'événements.

Même à travers de différents secteurs et domaines, il y a un modèle architectural commun perceptible autour de ces systèmes à événements discrets orienté flux. Ce modèle pour les systèmes à événements discrets moderne orienté flux joue le même rôle fondamental que l'architecture n-tiers classique depuis les systèmes d'entreprise traditionnel local. Je vais commencer en explorant un croquis miniature de ce modèle naissant.

Identifier le modèle

Tout d'abord, je dois préciser ce que l'on entend par l'événement de terme. Ici, cela signifie simplement un peu de données, ce qui signifie que quelque chose s'est passé dans un système. Événements tendent à être de petite taille, dans la gamme octet ou kilo-octets. Vous entendrez aussi des termes comme message, télémétrie ou même juste des données au lieu de l'événement.

Ensuite, il y a des producteurs de l'événement. Ces producteurs pourraient être presque n'importe quoi — connecté voitures, thermostats intelligents, consoles de jeux vidéo, appareils de conditionnement physique ou encore un système logiciel générant auto -des événements de diagnostic. Il est important de reconnaître, cependant, que dans la plupart de ces systèmes, vous faites affaire avec nombreux producteurs de l'événement.

De nombreux systèmes anticipent le nombre de producteurs d'événements dans les dizaines de milliers et allant en dizaines de millions ou plus. Autrement dit, que ces systèmes ont tendent à haut volume et haute vélocité. Volume élevé signifie il y a beaucoup de données globale et haute vélocité signifie que les données sont fréquemment générées.

Il y a aussi des consommateurs d'événements. Les consommateurs sont le cœur véritable de ces types de systèmes. Ils sont responsables de l'analyser, interpréter et répondre aux événements. Le nombre de consommateurs dans un système typique peut aller d'un couple à quelques dizaines. Événements ne sont pas routés vers des consommateurs spécifiques. Chaque consommateur est en regardant le même ensemble d'événements. Dans le cadre de Microsoft Azure, les consommateurs sont très probables services cloud.

Considérez cet exemple. Il y a un flux d'événement qui représentent les opérations financières. Les producteurs de l'événement dans ce scénario sont des systèmes de point de vente dans les magasins de détail. Un consommateur détient la responsabilité d'analyser le flux d'activité frauduleuse et déclencher des alertes. Un autre consommateur analyse le même flux de données pour faire des optimisations de chaîne d'approvisionnement en juste-à-temps. Enfin, un troisième consommateur est chargé de traduire les événements en entreposage frigorifique à long terme analytique plus tard.

Lorsqu'il est combiné avec la réalité de grand volume et haute -vitesse events, ce modèle des producteurs et des consommateurs présente quelques-uns intéressant des problèmes :

Comment empêchez-vous les ondes de la production événement auprès des consommateurs écrasante ? Autrement dit, comment le système réagisse lorsque le taux de production de l'événement commence à dépasser le taux de consommation ?
Parce que la vitesse de l'événement est élevée, comment s'adapte un consommateur d'événements individuels ?

La clé du problème est d'utiliser un courtier de l'événement (voir Figure 1). C'est précisément le rôle joué par les moyeux d'événement Azure publié récemment.

Figure 1 l'événement Azur Hub Architecture

Alors comment, exactement, à l'aide d'un courtier comme événement moyeux résout les problèmes, que j'ai indiqué jusqu'à présent ?

Comprendre l'événement Hubs

Événement moyeux assure l'élasticité nécessaire pour absorber et persistant les événements jusqu'à ce que les consommateurs en aval peuvent rattraper. Événement moyeux peut efficacement aplanies variabilité en cas taux de flux donc consommateurs ne doivent pas s'en inquiéter. Sans cette mise à niveau, un consommateur récepteur pourrait devenir dépassé et commencent à échouer.

À l'aide d'un courtier isole l'événement producteurs et les consommateurs d'événements les uns des autres. Cet isolement est particulièrement important dans des versions plus sophistiquées du modèle architectural où les intermédiaires supplémentaires sont nécessaires entre les producteurs et les consommateurs. Moyeux d'événement est un point de composition, une couture ou limite dans l'architecture. Tous les composants qui interagissent via un Hub d'événement ne nécessitent pas une connaissance précise des uns des autres.

À ce stade, il pourrait être facile de confondre les événements moyeux avec traditional enterprise messaging services qu'offrent le même type d'isolement. Toutefois, l'événement moyeux est différent sur plusieurs points clés qui le rendent idéal pour ce modèle architectural.

Consommateurs indépendants

Événement moyeux utilise une publication et abonnement modèle ; Toutefois, chaque consommateur dispose d'un avis indépendant du même flux d'événement. Dans certains systèmes de messagerie traditionnelles avec plusieurs consommateurs, les messages sont copiés pour chaque consommateur intéressé. Cela peut s'avérer insuffisante en termes de vitesse et de l'espace, mais l'avantage est que chaque consommateur a son propre "inbox". Comme un consommateur traite les messages, il retire de sa boîte de réception. Il n'y a aucun effet sur les autres consommateurs parce qu'ils ont leurs propres copies dans leur propre boîte de réception.

Avec moyeux de l'événement, il y a un ensemble d'événements immuables et, parce qu'ils sont immuables, il ne doit être une copie de chaque événement. De même, consommateurs jamais supprimer les événements du système. Tous les consommateurs regardent de la même série d'événements. Pour cette raison, les consommateurs chez la responsabilité de garder une trace de là où ils sont dans le cas où stream. Ils le font par leur offset dans le flux d'événements de suivi. Il n'y a effectivement une API pour cela intégrée dans le SDK.

Basé sur le temps rétention

Dans les systèmes de messagerie traditionnels, le client est responsable pour raconter le système lorsqu'il est effectué avec le message. Le système peut alors se débarrasser du message. Parce qu'un consommateur d'événements moyeux est responsable du suivi de sa propre position dans le flux d'événement, comment un événement Hub sait-il quand le consommateur se fait avec les événements ? En bref, ce n'est pas. Avec moyeux de l'événement, vous configurez une période de rétention et les événements sont stockés pendant ce laps de temps. Cela signifie événements expireront sur leur propres, indépendamment de toute action de consommateurs.

L'implication de rétention basés sur le temps, c'est que le consommateur doit examiner et traiter les événements avant qu'ils n'expirent. Avec rétention basés sur le temps, chaque consommateur a pression pour se tenir. Heureusement, la conception sous-jacente de moyeux de l'événement permet d'échelle des consommateurs individuels si nécessaire.

Moyeux événement prend en charge cette par est physiquement partitionnement le flux d'événements. Vous définissez le nombre de partitions lors de la configuration d'un Hub de l'événement. Voir la documentation officielle à bit.ly/11QAxOY pour plus de détails.

Comme les événements sont publiés sur un Hub Event, ils sont placés dans des partitions. Un événement donné réside dans une seule partition. Événements sont répartis par défaut dans les partitions de manière alternée. Il y a des mécanismes permettant d'affinité de la partition. Le plus commun vous permet de définir une propriété de clé de partition sur un événement, et tous les événements avec la même clé seront livrés à la même partition.

Comment un flux de données partitionnées événement aide consommateurs avec rétention basés sur le temps ? Dans le cadre des pôles de l'événement, le terme correct est en fait le groupe des consommateurs. La raison pour l'appeler un groupe est que chaque consommateur consiste vraiment à plusieurs instances. Chaque groupe a une instance par partition. De ce point, groupe de consommateurs se réfère à la consommation dans son ensemble et consommateur instance fait référence au membre du groupe intéressé par une partition particulière.

Autrement dit, qu'un groupe de consommateurs peut traiter des événements de flux de données en parallèle. Chaque instance de consommateurs au sein du groupe peut traiter une partition indépendante d'autres instances. Ces instances de consommateurs peuvent tous résider dans une seule machine, chaque instance de consommateurs en cours d'exécution dans l'isolement de l'un de l'autre. Ils pourraient tous être réparties sur plusieurs machines, même au point de chaque instance de consommateurs en cours d'exécution sur une zone dédiée. De cette façon, événement moyeux contourne certains problèmes typiques associés au modèle classique des consommateurs concurrentes.

L'isolement est un concept clé ici. Tout d'abord, vous êtes isoler événement producteurs et les consommateurs d'événements entre eux, permettant ainsi la composition de l'architecture flexible, ainsi que chargez la mise à niveau. Deuxièmement, les groupes de consommateurs sont isolées de l'autre, réduisant la possibilité pour les échecs en cascade à travers les groupes de consommateurs. Troisièmement, les instances de consommateurs dans un groupe donné de consommateurs sont isolés entre eux pour permettre la mise à l'échelle horizontale pour les groupes de consommateurs individuels.

Utilisez l'événement Hubs

Il y a plusieurs bons tutoriels pour débuter avec moyeux de l'événement. Consultez la documentation officielle à bit.ly/11QAxOY et suivre le tutoriel qui utilise la plateforme de votre choix.

Vous devrez fournir un Hub d'événement tout d'abord. Le processus est assez simple. Vous pouvez facilement l'essayer avec un compte d'essai Azure. Dans le portail de gestion Azure, accédez à la section Service Bus. Vous aurez besoin créer un espace de noms Service Bus si vous n'avez pas déjà un. Après cela, vous verrez un onglet nommé Hubs d'événement qui a reçu des instructions pour la création d'un pôle de l'événement (voir Figure 2).

Figure 2 créer un Hub d'événement

Vous devrez également mettre en place une politique d'accès partagé pour le moyeu de l'événement avant de commencer. Ces politiques de gestion de la sécurité pour un concentrateur de l'événement. Dans le portail, naviguez vers le Hub Event, vous venez de créer et sélectionnez l'onglet configurer.

Choisissez Manage pour les autorisations et donner à la politique un nom tel que "super" ou "-non-utilisation-en production." Après cela, revenez à l'onglet Tableau de bord et cliquez sur le bouton informations de connexion à la base. Vous aurez envie de prendre note de la chaîne de connexion là, ainsi que le nom que vous avez donné votre concentrateur d'événements.

Produire des événements

Le code que je vais montrer ici utilise le SDK de .NET, mais vous pouvez utiliser n'importe quelle plate-forme qui prend en charge HTTP ou AMQP. Vous devrez référencer le package Microsoft Azure Service Bus NuGet. Les classes dont vous avez besoin sont dans l'espace de noms Microsoft.ServiceBus.Messaging. Tout ce que vous devez faire est de créer un client, créer un événement et envoyer :

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

Malgré la simplicité, il y a quelques intéressants éléments à souligner. Le corps de l'événement est simplement un tableau d'octets. Les groupes de consommateurs traiter cet événement devra savoir comment interpréter ces octets. Il est probable que les groupes de consommateurs aura besoin d'une sorte d'indication pour déterminer comment désérialiser le corps. Avant que l'événement est envoyé, les métadonnées peuvent être fixées :

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

Autrement dit, à l'aide de clés et les valeurs qui sont bien connus par les producteurs et les groupes de consommateurs. Si vous voulez vous assurer qu'un ensemble d'événements est livré à la même partition, vous pouvez définir une clé de partition :

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

Vous obtiendrez de meilleures performances si les événements n'ont d'affinité avec les partitions. Dans certains cas, cependant, vous aurez envie d'un ensemble d'événements connexes, acheminés vers une instance de chaque consommateur pour traitement. Événements à une partition donnée sont certaines d'être dans l'ordre qu'ils ont été reçus. De même, il n'y a pas de moyen facile pour garantir l'ordre des événements sur des partitions différentes dans un Hub de l'événement. C'est souvent la motivation de vouloir les événements pour avoir une affinité à une partition particulière.

Par exemple, si vous activez voitures intelligentes, vous voulez tous les événements pour une voiture donnée pour être dans la même partition. Vous pouvez choisir le numéro d'Identification de véhicule (NIV) pour la clé de partition. Ou votre système pourrait se concentrer sur les bâtiments intelligents, avec des centaines de dispositifs dans chaque bâtiment, production d'événements. Dans ce cas, vous pouvez utiliser l'identité du bâtiment lui-même tel la partition touche donc tous les événements de tous les appareils dans le même terrain à bâtir dans la même partition.

Dans l'ensemble, affinité de partition est une pratique dangereuse et vous devez l'utiliser seulement avec précaution. Un mauvais choix de la clé de partition peut entraîner une répartition inégale événement dans partitions. En fin de compte, cela pourrait signifier des groupes de consommateurs aurait mal mise à l'échelle. La bonne nouvelle est que plusieurs fois, vous pouvez modifier la conception du système afin d'éviter la nécessité d'une affinité de la partition.

Consommer des événements

Vous pouvez être préoccupé de comment vous allez gérer tout cela. Dans le cas où votre consommation groupes doivent garder une trace de leur décalage stream. Chaque groupe doit avoir une instance pour chaque partition. Heureusement, il existe une API pour ça.

Le package NuGet Microsoft Azure Service Bus Hub-événement de référenceProcessorHost. Les classes dont vous avez besoin sont dans l'espace de noms Microsoft.ServiceBus.Messaging. Mise en route est aussi simple que la mise en œuvre d'une seule interface : IEventProcessor.

Une fois que vous avez implémenté le processeur de votre événement, vous allez créer une instance de EventProcessorHost pour enregistrer votre traitement de l'événement. L'hôte se chargera de toutes les tâches rébarbatives pour vous. Lorsqu'il démarre, il examinera votre Hub Event pour voir combien il a des partitions. Il créera ensuite une instance de votre traitement de l'événement pour chaque partition disponible.

Il y a trois méthodes, que vous devez implémenter. Les deux premiers sont OpenAsync et CloseAsync. L'hôte appelle OpenAsync lorsque l'instance de processeur d'événement est d'abord accordé un bail de partition. Cela signifie que l'instance d'événement processeur a un accès exclusif à la partition pour le groupe de consommateurs en question. De même, l'hôte appelle CloseAsync quand son bail est perdu ou quand il s'arrête. Alors que vous êtes mise en route, vous pouvez utiliser une implémentation très simple :

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

Ces deux méthodes reçoivent un argument de PartitionContext. La méthode reste le reçoit, aussi bien. Vous pouvez examiner cet argument si vous souhaitez afficher des détails sur la partition spécifique loué pour le processeur de l'événement. La dernière méthode est où vous recevez les événements (voir Figure 3).

Figure 3 la dernière méthode qui fournit les événements

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
}

Comme vous pouvez le voir, c'est simple. Vous recevez un ensemble dénombrable d'événements vous pouvez parcourir et faire quelque travaux sont nécessaires. Vous avez également cette invocation du contexte.CheckpointAsync à la fin de la méthode. Cela indique l'hôte vous avez traitées avec succès de cette série d'événements et vous souhaitez enregistrer un point de contrôle. Le point de contrôle correspond à l'offset du dernier événement dans le lot.

Voilà comment votre groupe de consommateurs peut garder une trace de quels événements ont été traitées pour chaque partition. Après qu'un hôte est démarré, il tente d'acquérir un bail pour n'importe quelle partition disponible. Lorsqu'il démarre le traitement d'une partition, il examinera les informations de point de contrôle pour cette partition. Seuls les événements plus récents que le dernier décalage contrôlée sont envoyés à leurs processeurs respectifs.

L'hôte fournit aussi nivellement de charge automatique sur plusieurs ordinateurs. Par exemple, supposons que vous avez un Hub d'événement avec 16 partitions. Autrement dit, il y aura 16 instances du processeur de votre événement, un pour chaque partition. Si vous utilisez l'hôte sur une seule machine, il crée toutes les 16 instances sur le même ordinateur. Si vous commencez un autre hôte sur une seconde machine et c' est partie du même groupe de consommateurs, les deux hôtes commencera à la distribution des instances de processeur d'événements de niveau entre les deux machines. En fin de compte, il y aura huit instances de processeur d'événements par ordinateur. De même, si vous prenez la deuxième machine, puis le premier hôte ramène sur les partitions orphelines.

Supposons que votre implémentation de IEventProcessor est MyEventProcessor. Instanciation de l'hôte peut être aussi simple que cela :

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

Les eventHubConnectionString et les eventHubName sont les mêmes valeurs utilisées lors de l'envoi des événements dans l'exemple précédent. Il est préférable d'utiliser des chaînes de connexion avec les stratégies d'accès partagé à juste ce qu'il faut restreignent l'utilisation.

Le nom d'hôte identifie l'instance de l'EventProcessorHost. Lorsque vous exécutez l'hôte d'un cluster (ce qui signifie que plusieurs machines), il est recommandé de que vous fournissez un nom qui reflète l'identité de la machine sur lequel il s'exécute.

L'argument consumerGroupName identifie le groupe de consommateurs logique représente cet hôte. Il y a un groupe de consommateurs par défaut vous pouvez référencer à l'aide de la constante EventHubConsumerGroup.DefaultGroupName. Tout autre nom vous exige la première disposition du groupe de consommateurs. Le faire en créant une instance de Microsoft.ServiceBus.NamespaceManager et à l'aide de méthodes telles que CreateConsumerGroupAsync.

Enfin, vous devez fournir une chaîne de connexion à un compte de stockage Azure à l'aide de checkpointConnectionString. Ce compte de stockage est où l'hôte suit l'état tout ce qui concerne les partitions et événement compense. Cet État est stocké dans les blobs en texte brut, que vous pouvez facilement examiner.

Il y a des autres services Azure intégrés aux moyeux événement out-of-the-box. Azure Stream Analytique (en avant-première) fournit une syntaxe de type SQL déclarative pour transformer et l'analyse des flux d'événements originaires de moyeux de l'événement. De même, événement moyeux offre un bec pour la tempête très populaire de Apache, maintenant disponible en avant-première sur Azure via HDInsight.

Jaquette en haut

Le modèle architectural décrit ici est que le début. Lorsque vous implémentez un système réel, il y a nombreux d'autres préoccupations que vous devrez prendre en considération. Ces préoccupations concernent la sécurité avancée, le dimensionnement et la gestion des producteurs de l'événement, traduction de protocole, les communications sortantes et plus. Néanmoins, vous êtes maintenant équipé avec les nécessaire de construire un système à l'aide d'un courtier d'événement tels qu'événement Hubs les concepts fondamentaux.

Christopher Bennage est un membre des modèles Microsoft &pratiques équipe. Il aime faire des choses avec les ordinateurs.

Remercie les experts techniques Microsoft suivants pour avoir relu cet article : Mostafa Elhemali et Dan Rosanova

Partager via