azure虚拟机发邮件_Microsoft Azure平台中的邮件选项

azure虚拟机发邮件

Author Credit: Steef-Jan Wiggers, Microsoft Azure MVP

作者信用：Steef-Jan Wiggers，Microsoft Azure MVP

Microsoft Azure offers various services for messaging and events. Today, there are four options for messaging and events in Azure: Service Bus, Storage Queues, Event Hubs, and Event Grid. Two deal specifically with events — Event Hubs and Event Grid, and two for Azure messaging — Service Bus and Storage queues. Before we discuss these Azure Services — let’s describe first what are events and messages.

Microsoft Azure提供了各种用于消息传递和事件的服务。 如今，Azure中有四个用于消息传递和事件的选项：服务总线，存储队列，事件中心和事件网格。 其中两个专门处理事件-事件中心和事件网格，另外两个用于Azure消息传递-服务总线和存储队列。 在讨论这些Azure服务之前，让我们首先描述什么是事件和消息。

消息传递与事件 (Messaging versus Eventing)

Messages and events are not the same. Messages have a clear intent — they are sent for a specific action or response. When a message is sent to a warehouse system requesting an item to pick — this message has intent or a command that requires an action — the client or system sending the message is expecting a response in this case. An event, on the other hand, reflects a fact — an occurrence in the past. Let’s say the requested item leaves the warehouse and the system sent out a notification message there could be many systems or devices interested in it. This notification, i.e., event, however, doesn’t define intent as the publisher is not aware of these systems and devices nor doesn’t have to be.

消息和事件不一样。 消息具有明确的意图-发送消息是为了进行特定的操作或响应。 在将消息发送到仓库系统以请求物品拣选时-该消息具有意图或需要采取措施的命令-在这种情况下，发送该消息的客户端或系统期望得到响应。 另一方面，事件反映了事实-过去发生的事情。 假设所请求的物品离开仓库，系统发出了一条通知消息，可能有许多系统或设备对此感兴趣。 但是，此通知(即事件)并没有定义意图，因为发布者不知道这些系统和设备，也不是必须的。

Now that difference is apparent between events and messages we will discuss the Azure Services associated with them.

现在事件和消息之间的区别已经很明显，我们将讨论与它们关联的Azure服务。

Azure服务总线 (Azure Service Bus)

The Service Bus is one of the oldest services of the Azure platform — it is a highly reliable, brokered cloud messaging system. This service is aimed at enterprise messaging scenarios and offers middleware technologies like message queueing and publish/subscribe messaging. Furthermore, the service bus provides decoupling between services and applications. The critical capabilities of the service bus are

服务总线是Azure平台上最古老的服务之一-它是高度可靠的代理云消息传递系统。 该服务针对企业消息传递方案，并提供中间件技术，例如消息队列和发布/订阅消息传递。 此外，服务总线提供服务与应用程序之间的解耦。 服务总线的关键功能是

• Queues are offering an asynchronous messaging capability with first-in-first-out (FIFO) message delivery. Only one consumer receives each message. Messages are persisted in the queue, and the consumer does not have to pick up the message straight away, i.e., the message publisher and consumer do not have to be connected to queue at the same time. Hence, queues are suitable for store-and-forward messages in a particular scenario.
  队列通过先进先出(FIFO)消息传递提供了异步消息传递功能。 每条消息只有一个消费者。 消息将保留在队列中，并且使用者不必立即拾取消息，即消息发布者和使用者不必同时连接到队列。 因此，队列适合于特定情况下的存储和转发消息。
• Topics and subscriptions offer a similar capability as queues. However, there can be more consumers for messages that are sent to a topic. A topic has one or more subscriptions. Furthermore, subscriptions can have filters, and thus various messages to a topic can end up in different subscriptions belonging to the topic.
  主题和订阅提供与队列类似的功能。 但是，发送给主题的消息可能会有更多的使用者。 一个主题有一个或多个订阅。 此外，订阅可以具有过滤器，因此指向该主题的各种消息可以最终属于该主题的不同订阅。

• Relay provides a gateway to connect on-premise services to Azure, without having to open a firewall connection to the network. The Relay has two features — Hybrid Connections and WCF-Relays. Both enable a secure connection to on-premise services. The difference is that the hybrid connection uses the open standard web socket, while WCF-Relay uses the legacy Windows Communication Foundation (WCF) to enable remote procedure calls.

  中继提供了将本地服务连接到Azure的网关，而无需打开与网络的防火墙连接。 中继具有两个功能 -混合连接和WCF中继。 两者都可确保与本地服务的安全连接。 不同之处在于，混合连接使用开放的标准Web套接字，而WCF-Relay使用传统的Windows Communication Foundation(WCF)来启用远程过程调用。

Azure Service Bus is available in three tiers:

Azure服务总线分为三层：

• Basic — queues and scheduled messages, and message size up to 256 KB.
  基本-队列和计划的消息，消息大小最大为256 KB。
• Standard — on top of basic with Topics and subscriptions, transactions, sessions, and de-duplication.
  标准-基本的主题和订阅，事务，会话和重复数据删除。
• Premium — on top of the standard, and message size up to 1 MB.
  高级—在标准之上，消息大小最大为1 MB。

Azure事件网格 (Azure Event Grid)

Event Grid is one of the latest services added to the Azure Platform. This service enables event-driven, reactive programming through a publish-subscribe model — in the Building reactive solution with Azure Event Grid, you can read more about it.

事件网格是添加到Azure平台的最新服务之一。 此服务通过发布-订阅模型启用事件驱动的响应式编程—在“ 使用Azure Event Grid构建响应式解决方案”中 ，您可以阅读有关它的更多信息。

With Event Grid, there is a concept of publishers of events, which do not expect how the events are handled, and subscribers who decide how to handle the events. Publishers emit events to Event Grid — centrally manages events by routing them to subscribers of them. Furthermore, the routing can be done on the event type, or by a pre- and or postfix.

使用事件网格，有一个事件发布者的概念，它们不期望事件的处理方式，而订阅者则决定如何处理事件。 发布者将事件发送到事件网格-通过将事件路由到事件的订阅者来集中管理事件。 此外，可以根据事件类型或通过前缀和/或后缀来完成路由。

Event Grid has the following characteristics

事件网格具有以下特征

• dynamically scalable
  动态可扩展
• low cost
  低成本
• serverless
  无服务器

Both Azure Service Bus with Topics and Subscriptions and Event Grid offers a pub-sub model. However, they are different in behavior as shown in the picture below.

具有主题和订阅的Azure服务总线以及事件网格都提供了发布-订阅模型。 但是，它们的行为不同，如下图所示。

Azure事件中心 (Azure Event Hubs)

You can view Azure Event Hubs as a significant data pipeline. This service is designed to ingest large data streams generated by devices and services. Moreover, Event Hubs facilitates the capture, retention, and replay of telemetry. In case your solution requires a high throughput of data ingestion then Event Hubs is the right service.

您可以将Azure事件中心视为重要的数据管道。 该服务旨在吸收设备和服务生成的大型数据流。 此外，事件中心可促进遥测的捕获，保留和重放。 如果您的解决方案需要高数据吞吐量，则事件中心是正确的服务。

With Event Hubs, you can define so-called ‘consumer groups’, which allows you to read the stream of events. In case you have one receiver read the stream of events, then you can use the default consumer group. However, when you have multiple receivers for the stream concurrently, and each wants to read the stream at its rate — then you will need to set up numerous consumer groups. Furthermore, each receiver will manage an index (or offset) — a pointer to where in the stream of events it will start reading. The receiver can begin at the beginning of the stream and read to the end and subsequently wait for new events — or it can start reading partway through the stream.

使用事件中心，您可以定义所谓的“消费者组”，从而可以读取事件流。 如果您有一个接收者读取事件流，则可以使用默认的使用者组。 但是，当您同时有多个流接收器，并且每个接收器都想以其速率读取流时-那么您将需要设置多个使用者组。 此外，每个接收器都将管理索引(或偏移量)，即指向事件流中它将开始读取的位置的指针。 接收器可以从流的开头开始，读到末尾，然后等待新事件-或者可以开始在流的中途开始读取。

Event Hubs support the following protocols: HTTPS, AMQP, and AMQP over WebSockets. Furthermore, it supports Shared Access Policies for Security, and .NET/C for language support for building solutions. It is available in three tiers:

事件中心支持以下协议：通过WebSocket的HTTPS，AMQP和AMQP。 此外，它支持安全性共享访问策略，并为构建解决方案的语言支持提供.NET / C支持。 它分为三层：

• Basic — offers a maximum of 20 throughput units with 1 MB/s ingress and 2MB/s egress per unit. The message size is up to 256 KB, and retention of 1 day, one consumer group, and 100 brokered connections.
  基本-提供最多20个吞吐量单位，每个单位1 MB / s的入口和2MB / s的出口。 邮件大小最大为256 KB，保留1天，一个使用方组和100个代理连接。
• Standard — on top of basic it offers, lower costs for throughput units and messages. Furthermore, you get 20 consumer groups and 1000 brokered connections.
  标准-除了基本功能外，它还降低了吞吐量单位和消息的成本。 此外，您将获得20个消费者组和1000个代理连接。
• Dedicated — offers a dedicated environment with a maximum message size of 1 MB, 50 throughput units, a retention period of seven days, and 25000 brokered connections.
  专用-提供一个专用环境，最大消息大小为1 MB，50个吞吐量单位，保留期为7天，以及25000个代理连接。

储存s列 (Storage Queues)

Like Service Bus Queues, Azure Storage queue offers asynchronous messaging, and the publisher and consumer do not have to be connected at the same time. The message can be stored and picked up later by the consumer. A storage queue is suitable as a task queue, and messages can remain in the queue for a maximum of seven days.

与服务总线队列一样， Azure存储队列也提供异步消息传递，并且发布者和使用者不必同时连接。 该消息可以被存储并在以后由消费者提取。 存储队列适合作为任务队列，消息可以在队列中最多保留7天。

Azure Storage Queues differ from Service Bus Queues — each serves a different purpose (see picture below).

Azure存储队列与服务总线队列不同-每个服务都有不同的用途(请参见下图)。

See also Storage queues and Service Bus queues — compared and contrasted document on Microsoft docs for comparison of these cloud queue technologies.

另请参阅存储队列和服务总线队列 -Microsoft文档上的比较文档和对比文档，以比较这些云队列技术。

什么时候选择什么？ (When to choose what?)

In the previous sections, we discussed the four Azure messaging services that are available. Now we will talk about when to choose which Azure messaging service by using sample reference cases. Note that each of these Azure messaging services can be part of your solution depending on your requirements. Note that these services are not competing with each other!

在前面的部分中，我们讨论了可用的四种Azure消息传递服务。 现在，我们将讨论通过使用示例参考案例来选择哪种Azure消息传递服务的时间。 请注意，根据您的要求，这些Azure消息服务中的每一个都可以成为解决方案的一部分。 请注意，这些服务不会互相竞争！

将数据流式传输到Azure (Stream data into Azure)

When devices and services generate large volumes of telemetry data then Event Hubs is a candidate service for you when you want to ingest that data. Subsequently, multiple applications can be based on a publish-subscribe mechanism that consumes that data.

当设备和服务生成大量遥测数据时，当您要提取数据时，事件中心将为您提供候选服务。 随后，多个应用程序可以基于使用该数据的发布-订阅机制。

Telemetry data can be for instance log data (website visitors, click behavior) from your website. Furthermore, you want to process the data in real-time with Stream Analytics and push specific page click behavior to Data Lake — and store visitor data in a Cosmos DB collection. To support this scenario, you create two consumer groups, one for a function that will store visitor events (for instance log in) to the Cosmos DB collection (user logins) and one for a Stream Analytics job — the results of individual queries are stored in Data Lake.

遥测数据可以是您网站上的日志数据(网站访问者，点击行为)。 此外，您想使用Stream Analytics实时处理数据并将特定的页面单击行为推送到Data Lake —并将访问者数据存储在Cosmos DB集合中。 为了支持这种情况，您将创建两个使用者组，一个用于将将访客事件(例如，登录)存储到Cosmos DB集合(用户登录)的功能，另一个用于Stream Analytics作业—存储各个查询的结果在Data Lake中。

For pricing details of Event Hubs see the pricing page.

有关Event Hub的定价详细信息，请参见定价页面 。

使用事件网格处理事件 (Handle events with Event Grid)

The Event Grid service on the Azure Platform is suitable to route events coming from Azure resources like Event Hub, Azure Storage, and third party (custom) to any given event handler or WebHook. You can, for instance, create an Event Grid Topic, and send your application events to Event Grid to leverage its reliable delivery, advanced routing, and direct integration with Azure. Furthermore, you can make use of Event Grid and Logic Apps to process data without writing code.

Azure平台上的事件网格服务适合将来自事件资源，事件存储，Azure存储和第三方(自定义)等Azure资源的事件路由到任何给定的事件处理程序或WebHook。 例如，您可以创建事件网格主题，然后将应用程序事件发送到事件网格以利用其可靠的传递，高级路由以及与Azure的直接集成。 此外，您可以使用事件网格和逻辑应用程序来处理数据，而无需编写代码。

Let’s assume you ingest public data, i.e. weather data using a Logic App with a schedule trigger mechanism. The Logic App processes an array of data and stores every part of the array as an individual JSON file in blob storage. The blob storage is configured with Event Grid, and one or more Logic Apps handles each blob created event.

假设您使用带有计划触发机制的Logic App来摄取公共数据，即天气数据。 Logic App处理数据数组，并将数组的每个部分作为单独的JSON文件存储在Blob存储中。 Blob存储配置有事件网格，并且一个或多个Logic Apps处理每个Blob创建的事件。

For pricing details of Event Grid see pricing page.

有关Event Grid的定价详细信息，请参见定价页面 。

Azure中的企业消息传递 (Enterprise Messaging in Azure)

With the Azure messaging in Service Bus, there are several scenarios you can think of where this service brings value. Service Bus offers, topics and subscriptions (pub-sub), and message queues. When you require a message broker in Azure, then Service Bus is fit for your solution.

通过Service Bus中的Azure消息传递，您可以想到几种方案，该服务将在何处带来价值。 Service Bus提供，主题和订阅(发布-订阅)以及消息队列。 当您在Azure中需要消息代理时，则Service Bus适合您的解决方案。

Assume you want to process flat-file batch files (1,2) in Azure through multiple micro-services — each service has one responsibility. The microservices (3) shown in the diagram below are activated by a message in a service bus queue. The queue is an intermediary between services and decouples them from each other. The microservices are packaged into a container and are hosted in a managed Azure Kubernetes Cluster (AKS). The microservices can scale, and this also accounts for the queues, i.e. they can handle the massive throughput of messages that can activate the microservices to process the EDI files (parse, translate, store) (4).

假设您要通过多个微服务在Azure中处理平面文件批处理文件(1,2)-每个服务都有一个责任。 下图所示的微服务(3)由服务总线队列中的消息激活。 队列是服务之间的中介，使它们彼此分离。 微服务打包到一个容器中，并托管在托管的Azure Kubernetes群集(AKS)中。 微服务可以扩展，这也可以解决队列问题，即它们可以处理大量消息，这些消息可以激活微服务来处理EDI文件(解析，翻译，存储)(4)。

There are some samples available for the Azure Service Bus through the following link. For pricing details of the Azure Service Bus see pricing page.

通过以下链接有一些适用于Azure Service Bus的示例。 有关Azure Service Bus的定价详细信息，请参见定价页面 。

任务队列 (Task Queue)

Storage Queues are a part of the Azure Storage Account service. Furthermore, they feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services. You can consider storage queues:

存储队列是Azure存储帐户服务的一部分。 此外，它们还具有基于REST的简单GET / PUT / PEEK接口，可在服务内部和服务之间提供可靠，持久的消息传递。 您可以考虑存储队列：

• when you must store a significant amount of message, i.e. over 80 GB,
  当您必须存储大量消息(即超过80 GB)时，
• time-to-live for your messages is less than seven days,
  您的消息的生存时间少于7天，
• your application needs to track progress for processing a message inside of the queue,
  您的应用程序需要跟踪处理队列内消息的进度，
• or require server-side logs of all of the transactions executed against your queues.
  或要求针对您的队列执行的所有事务的服务器端日志。

When for instance, you want to process a workload asynchronous or pass messages from one web role to a worker role or function, you can use a simple queue like Storage Queue. Similar to the sample in the Enterprise Messaging scenario you can use a Storage queue, however, if it needs to be in an ordered manner, then Service Bus queues are a better fit because of the strict ordering (First-in-first-out).

例如，当您要异步处理工作负载或将消息从一个Web角色传递到辅助角色或功能时，可以使用诸如存储队列之类的简单队列。 与企业消息传递场景中的示例类似，您可以使用存储队列，但是，如果需要以有序方式进行存储，则由于严格的顺序(先进先出)，服务总线队列更适合。

Assume you need to upload a large number of high-resolution images and each need to be resized and analyzed asynchronously — then images are stored first, and then task messages are sent to storage queues, i.e., task messages for resizing on one storage queue, and task messages for analysis on another.

假设您需要上传大量高分辨率图像，并且每个图像都需要重新调整大小并进行异步分析-然后先存储图像，然后将任务消息发送到存储队列，即用于在一个存储队列上调整大小的任务消息，和任务消息以供另一个分析。

The diagram above shows how you could use simple queues for a particular scenario. For pricing details of Storage Queues see the pricing page.

上图显示了如何针对特定场景使用简单队列。 有关Storage Queues的定价详细信息，请参见定价页面 。

摘要 (Summary)

Four Azure messaging services each serving a purpose and have a fit in your architecture or solution. Below you will find a summary of these services, how they fit in a segment, characteristics, and what type of concept (Serverless, Big Data, Enterprise).

四个Azure消息传递服务各自服务于一个目的，并且适合您的体系结构或解决方案。 您将在下面找到这些服务的摘要，它们如何适合细分市场，特征以及什么样的概念类型(无服务器，大数据，企业)。

结语 (Wrap up)

In this blog, we described Azure messaging and event services. Each has its characteristics and can be the right service to adhere to your requirements. These services do not compete with each other and are in some use cases complementary to each other. Hopefully, this blog post has given you some insights into these Azure Messaging services and provide guidance when to choose what.

在此博客中，我们描述了Azure消息传递和事件服务。 每个都有其特点，并且可以作为满足您要求的正确服务。 这些服务不会互相竞争，并且在某些用例中会相互补充。 希望该博客文章为您提供了有关这些Azure消息服务的一些见解，并提供了选择内容的指导。

Originally published at www.serverless360.com on July 16, 2018.

最初于 2018年7月16日 发布在 www.serverless360.com 上。

翻译自: https://medium.com/@madhavan.anandharaju/messaging-options-in-the-microsoft-azure-platform-8fa8e5ee6753

azure虚拟机发邮件