为serverless事件而生【.com速译】MicrosoftEventGrid无疑是serverless选项的重要补充，可以提供一套大规模的分布式应用。后台，把管理和安排的工作量控制在最底层。此外，它还为微软的无服务器工具提供了一套事件路由结构，从而简化了其他Azure服务和来自外部源的相关事件订阅机制。Serverless计算作为现代云应用架构的基础，其优势在于摆脱底层基础设施——甚至是网络因素——减轻应用编排工具的管理负担。但是，MicrosoftAuzreFunctions等Serverless模型有其自身的局限性，即需要响应事件而启动。如果没有收到信号，则不会启动。如何使用Azure事件那么我们如何捕获事件呢？传统的事件队列属于分布式架构，但它的问题是往往难以保证事件的正确传递。理想情况下，消息应满足幂等性的要求，即一次且仅进行一次传输以保证传递。但是这在实际场景中是很难实现的，所以我们必须使用相应的系统来完成这个任务。这允许我们使用后端代码来清理日志和存储数据，并使用事件和消息ID来标记重复项。使用事件网格，Microsoft构建了一个发布和订阅系统，并将其与其他Azure服务通知机制集成。事件现在是一流的对象，事件网格配置支持过滤事件并将事件定向到正确的服务。凭借可扩展性，它还可以与包含数千个源的简单架构和复杂环境进行交互。简单来说，Eve??ntGrid是一个工具，负责将Azure中各种来源的事件通知路由到AzureFunctions。它可以将Azure环境转变为一个通知系统，与传统的服务总线不同，事件网格中没有传统的工作流模式：当一个事件发生时，相应的功能就会被启动，相关的应用程序就会被触发。在应用程序中使用事件网格事件网格最初仅支持部分Azure服务，包括来自各种基础结构服务（例如事件中心）和Azure订阅的通知。最有趣的是，您可以将事件网格与AzureFunctions捆绑在一起，以与其他服务协作。例如，Microsoft允许您使用blob存储容器中的事件来触发相应的Azure功能，以便在每次上传图像时运行机器学习驱动的图像识别。通过上面的例子可以看出，它最重要的能力就是把原本松散耦合的操作聚合起来。不需要单体应用，你只需要一个上传服务和一个图像分析功能。此关联由你的Azure存储帐户提供，意味着当图像上传到指定的blob容器时，相关事件将发送到事件网格。之后，事件网格使用筛选机制获取特定消息并将其作为输入传递给函数——即刚刚上传的图像文件的链接。这种能力相信会受到大家的广泛青睐，尤其是对于那些希望将Azure作为构建自己的平台即服务应用程序的工具的用户而言。将事件网格与AzureFunctions结合使用，您不再需要管理大量事件处理程序来支持无服务器代码。相反，每个函数在事件符合条件时自行触发，并在处理完成时被丢弃。此外，现有的Azure服务（如逻辑应用程序）使用大量计算资源进行事件轮询。但是事件网格可以有效的克服这个问题。随着服务迁移到事件网格，相关的执行效率将得到显着提升，从而降低计算需求和应用程序支持成本。将事件网格引入新的无服务器容器化Azure借助LogicApps和Flow，微软的无服务器模型不再局限于Auzre。这意味着您可以使用事件网格触发Flow操作以将源信息从电子商务应用程序转发到Dynamics365，从而根据实时情况更新客户记录或为特定客户快速提供产品报价。此外，您还可以使用AzureIoT平台中的EventHubs来推送IoT设备事件——这不仅可以快速实现数据按需推送，还可以节省传输带宽，避免因IoThub架构复杂而导致的故障。导致成本高。作为微软Serverless模型的核心解决方案，你可以使用AzureFunctions构建一个理想的应用系统——通过EventGrid从Azure服务中获取数据源，触发函数，然后使用AzureContainerInstanceAPI启动负责运行复杂服务的容器。将数据处理与底层事件触发机制相关联。这意味着用户将不再需要Kubernetes实现的容器资源编排机制。使用这种架构，您不再需要构建昂贵的永久性虚拟基础架构，而只需在服务运行时付费。展望未来，或许无基础设施应用将进一步取代Serverless应用，成为此次升级之旅的最终目标。【翻译稿件，合作网站转载请注明原译者和出处.com】
