微软Event Grid无疑是对无服务器选项的一大重要补充，可提供一套可构建大规模分布式应用程序的后台，且将管理与编排工作量控制在最低水平。另外，也为微软的无服务器工具提供了一套事件路由结构，从而简化其它Azure服务以及外部来源的相关事件订阅机制。
无服务器计算作为现代云应用架构的基础，具有摆脱底层基础设施——甚至是网络因素——以减少应用编排工具管理负担等优势。但微软Auzre Functions这类无服务器模式本身就存在局限性，即要求以响应事件的方式启动。如果未收到信号，则不会启动。
Azure事件使用方法
那么我们该如何捕捉事件?传统事件队列隶属于分布式体系架构，但其问题在于往往难以确保事件的正确传送。在理想情况下，信息应符合幂等要求，即进行且仅进行一次传送以保证交付。但这在实际场景中难以实现，因此大家必须采用相应的系统来完成这项任务。如此一来，我们即可利用后端代码清理日志并存储数据，并利用事件与消息ID来标记重复内容。
利用Event Grid，微软方面建立起一套发布与订阅系统，并与其它Azure服务通知机制集成起来。现在各事件成为一级对象，而Event Grid配置可实现事件过滤并将其定向至正确的服务。凭借着可扩展性，也能够对接简单架构以及包含数千个来源的复杂环境。
简单来讲，Event Grid是一款负责将Azure内各来源的事件通知路由至Azure Functions的工具。其能够将Azure环境转化为通知体系，而且与传统服务总线不同，Event Grid中不存在传统工作流模式：当某一事件发生时，会启动对应的函数，并触发与之相关的应用。
在应用程序中使用Event Grid
Event Grid最初只支持部分Azure服务，包括来自各基础设施服务(例如Event Hubs)以及Azure订阅的通知。而最为有趣的是，大家可以将Event Grid与Azure Functions捆绑起来以共同配合其它服务。例如，微软允许大家在blob存储容器当中使用事件以触发对应Azure函数，用以在每一次图片上传时运行机器学习支持型图像识别。
通过上述实例，可以看到其最重要的能力是将原本松散耦合的各项操作聚合在一起。无需整体应用，您只需要上传服务以及图像分析功能即可。这种关联由您的Azure存储帐户提供，意味着当图像被上传至指定的blob容器时，相关事件会被传送至Event Grid。此后，Event Grid利用过滤机制获取特定消息，并将其作为输入内容传递给某一函数——即刚刚上传完成的图片文件的链接。
这种能力相信能够得到大家的广泛青睐，特别是对于希望将Azure作为自主平台即服务应用构建工具的用户。利用Event Grid配合Azure Functions，您不再需要管理大量事件处理程序以支持无服务器代码。相反，各函数会在事件符合条件时自行触发，并在处理完成后被丢弃。
另外，现有Azure服务(例如Logic Apps)使用大量计算资源进行事件轮询。但Event Grid能够有效克服这一问题。随着服务被迁移至Event Grid当中，相关执行效率将得到显著提升，进而降低计算需求以及应用支持成本。
将Event Grid纳入新的无服务器容器化Azure
凭借着Logic Apps与Flow，微软的无服务器模式不再局限于Auzre之内。这意味着大家可以利用Event Grid触发Flow操作，将来自电子商务应用的馈送信息转发至Dynamics 365，从而根据实时情况更新客户记录或快速为特定客户提供产品报价。另外，大家也可以在Azure的物联网平台内使用Event Hubs以实现物联网设备事件推送——这不仅能够快速根据需求实现数据推送，同时也可节约传输带宽并避免因物联网中枢架构过于复杂而导致的高成本问题。
作为微软无服务器模式的核心方案，大家可以利用Azure Functions构建起理想的应用体系——通过Event Grid从Azure服务处获取数据源，触发函数而后利用Azure容器实例API启动负责运行复杂服务的容器，从而将数据处理与底层事件触发机制关联起来。这意味着用户将不再需要由Kubernets实现的容器资源编排机制。利用这类架构，您不再需要建立昂贵的永久性虚拟基础设施，而仅在服务运行时支付开销。
而着眼于未来，也许无基础设施应用将进一步取代无服务器应用，成为这场升级之旅的最终目标。
本文作者：核子可乐译
来源：51CTO
