微軟Event Grid無疑是對無服務器選項的一大重要補充，可提供一套可構建大規模分布式應用程序的后臺，且將管理與編排工作量控制在最低水平。另外，也為微軟的無服務器工具提供了一套事件路由結構，從而簡化其它Azure服務以及外部來源的相關事件訂閱機制。

無服務器計算作為現代云應用架構的基礎，具有擺脫底層基礎設施——甚至是網絡因素——以減少應用編排工具管理負擔等優勢。但微軟Auzre Functions這類無服務器模式本身就存在局限性，即要求以響應事件的方式啟動。如果未收到信號，則不會啟動。

Azure事件使用方法

那么我們該如何捕捉事件?傳統事件隊列隸屬于分布式體系架構，但其問題在于往往難以確保事件的正確傳送。在理想情況下，信息應符合冪等要求，即進行且僅進行一次傳送以保證交付。但這在實際場景中難以實現，因此大家必須采用相應的系統來完成這項任務。如此一來，我們即可利用后端代碼清理日志并存儲數據，并利用事件與消息ID來標記重復內容。

利用Event Grid，微軟方面建立起一套發布與訂閱系統，并與其它Azure服務通知機制集成起來?，F在各事件成為一級對象，而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實現的容器資源編排機制。利用這類架構，您不再需要建立昂貴的永久性虛擬基礎設施，而僅在服務運行時支付開銷。

而著眼于未來，也許無基礎設施應用將進一步取代無服務器應用，成為這場升級之旅的最終目標。