Azure Application架構設計

雲端正在改變Application的設計和保護方式。Applications被劃分為更小的、更分散的服務，而不是單體式(monoliths) Application。

這些服務通過 API 或使用非同步messaging 或events來通訊。Service根據需要添加new instance來做水平擴展。

這些設計變化帶來了新的挑戰。Applications狀態是分佈式的，運作是"平行和非同步"來完成的。Application必須：

• 有效地相互溝通。
• 能夠快速部署。
• 發生故障時保持韌性。
• 能夠與其他系統無縫整合。

Azure 允許我們建立由各種組件組成的Application：

• Website front ends
• Back-end services
• Triggered functions

Azure 包含各種通訊方式，讓這些不同的組件相互傳遞資料。

本文中，我們將能夠評估和設計有效的Application架構。這個架構提供了用於交換訊息的最佳 Azure 解決方案。它還有助於為我們的Application自動部署解決方案並管理配置。 Azure 還支援與 API 的整合並提供適當的快取。

我們的學習目標為：

• 描述訊息與 事件的場景.
• 設計一個 訊息傳遞解決方案.
• 設計一個 event hub messaging 解決方案.
• 設計一個 event-driven 解決方案.
• 設計一個 快取解決方案
• 設計一個API 整合解決方案.
• 設計一個 自動化app 部署解決方案.
• 設計一個 application 配置管理解決方案.

描述 訊息 與 事件的場景

假設我們正在為分佈式音樂共享應用程式設計架構。 我們希望確保Applications盡可能是可靠和可擴展。 我們要使用 Azure 技術來建立強大的communication infrastructure。

但在使用 Azure 技術之前，我們必須了解每個單獨的組件如何與Application的其他組件進行通訊。 對於每次通訊，我們可以選擇不同的 Azure 技術。

用訊息或事件在我們的Application上

我們必須了解的第一件事是Application是否發送訊息(message)或事件(Events)。 了解其差異有助於我們選擇合適的 Azure 服務。

什麼是訊息?

訊息具有以下特徵。

• 包含由一個組件產生的原始資料，將由另一個組件使用。
• 包含資料本身，而不僅僅是對該資料的引用。

發送的組件預期目的地組件以某種方式處理訊息內容。 整個系統的完整性可能取決於發送者和接收者執行特定工作。

訊息範例

假設使用者使用我們的行動app上傳了一首新歌曲。 Application必須將該歌曲發送到在 Azure 中運行的 Web API。 必需發送歌曲檔案，而不僅僅發出訊息說已添加新歌曲。 app預期 Web API 將新歌曲存儲在DB中，並可供其他使用者使用。

什麼是事件?

事件比訊息更輕量，最常用於廣播通訊。事件涉及兩個組件：

• Publishers，發送事件。
• 接收事件的subscribers。

對於事件，接收的組件通常會決定它們對哪些通訊需要並訂閱這些事件。subscription由Azure Event Grid或 Azure Event Hubs管理。當Publishers發送事件時，Azure Event Grid或 Azure Event Hubs將該事件路由到需要的subscribers。這種模式被稱為publish-subscribe architecture，並且是最常用的。

具有以下特徵：

• 是否是指示發生了某事的一個通知(資訊量比訊息少)？
• 可以發送給多個接收者，也可以不發送。
• 通常主要在“fan out”，許多subscribers。
• Publisher對接收的組件不會有任何預期會採取的動作。
• 是一個離散單位(discrete unit)，但事件可能是相關且有序系列的一部分

何時該使用訊息或事件?

一個Application可能將事件用於某些目的，而將訊息用於其他目的。 下表描述了何時該使用哪一個:

對於每次通訊，需要考慮以下問題：發送端的組件是否預期目的地的組件以特定方式處理通訊？

• 如果是，請選擇使用訊息。
• 如果不是，也許可以使用事件，因為事件就是一個通知。
• 傳遞的保證。 如果要建置分散式應用程式，而且想要保證會處理所有溝通，請考慮使用訊息。 在訊息溝通中，預期訊息傳送者和接收者都已完成其工作。如果不是，請用事件。因為可能應用程式不需要訂閱者或來自任何接收者的動作。

設計一個 訊息傳遞 解決方案

假設我們正在計劃音樂共享應用程式。 我們需要：

• 確保音樂檔案從app可靠地上傳到 Web API。
• 將有關新歌曲的詳細資訊直接發送到應用程式。 例如，當上傳者將新音樂加到他們的收藏中時。

這個場景是基於訊息系統的使用。 Azure 提供了兩種基於訊息的解決方案 — Queue Storage 與Azure Service Bus (queues and topics)。

Azure Queue Storage

Azure Queue storage 是一種使用 Azure storage來存儲大量訊息的服務。 可以使用基於 REST 的介面從世界任何地方安全地存取這些訊息。 Queues storage可以包儲存數百萬條訊息。 Azure queue storage會受它上層storage account的容量限制。 Queue通常提供更高的可靠性、訊息的傳遞是被保證的並且有transactional support。

Azure Service Bus

Azure Service Bus是一個完全託管的message broker，具有message queues和publish-subscribe topics。 Service Bus用於將應用程式和服務彼此分離，提供以下效益：

• 橫跨computing workers的負載平衡工作。
• 橫跨service和application邊界能安全的路由和傳輸資料和控制。
• 協調需要高度可靠性的transactional work。

Azure Service Bus Queue

Azure Service Bus queues 是一個建立在專用的messaging infrastructure之上的message broker system。 Service Bus會保留messages，直到目標準備好接收它們。

Azure Service Bus適用於企業等級的應用程式。 例如，使用communication protocols 和不同data contracts的應用程式。

Azure Service Bus publish-subscribe topic

Azure Service Bus topics 就像queue，但可以有多個subscribers。 當一條message被發送到一個topic時，可以觸發多個組件來執行一個task。

例如，假設使用者正在使用音樂共享應用程式收聽歌曲。app可能會向 Listened topic發送message。 該topic可能有一個 UpdateUserListenHistory 的subscription，以及一個不同的 UpdateArtistsFanList 的subscription。 每個subscription都會收到自己的訊息副本。

該用哪一種訊息服務呢?

每個messaging service的功能集都略有不同。 這意味我們您可以選擇其中一個或同時使用兩者。 這取決於要解決的問題。

Azure Queue storage：

• 一個simple queue來組織訊息。
• 通過queue的所有訊息進行稽核。
• Queue大小超過 80 GB。
• 追踪Queue內的訊息的處理進度。

Azure Service Bus (message queues)：

• 最多一次傳送保證。
• FIFO(first-in-first-out)的保證。
• 將訊息分組到transactions中。
• 在不輪詢queue的情況下接收訊息。
• 為queue提供role-based access model。
• 處理大於 64 KB 但小於 256 KB 的message。
• Queue大小不會超過 80 GB。
• 能批次推送/處理訊息。

Azure Service Bus (publish-subscribe topics)：

• 多個接收者來處理每條訊息。
• 單一訊息有多個目的地，但需要類似queue的行為。

設計一個 Event Hub Messaging 解決方案

有些應用程式會從幾乎同樣多的來源產生大量事件。 我們通常將其稱為大數據。 大數據可能需要廣泛的基礎設施。

假設我們的公司製造的引擎中有數百個感測器。 在一架飛機可以飛行之前，它的引擎連接到一個測試裝置。 此外，當飛機連接到地面設備時，暫存的飛行資料會串流式的傳輸。

在這種情況下，我們可能會選擇event hubs-based messaging 方案。 Event hubs每秒可以接收和處理數百萬個訊息。 發送到Event hubs的資料可以即時轉換並存儲以供日後分析。

Azure Event Hub的作業方式

Azure Event Hubs 是一種全託管的real time data ingestion。 Event hubs支援同一stream上的Real time data ingestion和微服務批次處理。可以使用許多不同的語言來傳送和接收事件。 也可以使用 Apache Storm 從 Azure event hub接收訊息。 以下是Event Hub的一些使用場景。

• 異常偵測（欺詐/異常值）和即時的儀表板
• Analytics pipelines，例如clickstreams和歸檔資料
• real-time analysis的交易處理

其他的特性則有:

Azure Event Hub收到的事件會新增至其data stream尾端。

• data stream會根據收到事件的時間進行排序。
• Consumer可以使用時間位移(time offsets)沿著資料流搜尋。

Event Hub使用「Pull」model，將其與其他訊息服務 (例如 Azure Service Bus queues) 區別開來。

• Event Hub會在其快取中保存每個訊息，並允許讀取。
• 訊息從Event Hub讀取後，不會刪除。 訊息會留給其他Consumer。

Event Hub沒有內建機制可處理未如預期般處理的訊息。

Azure Event Hub會根據 purchased throughput (processing) units數量來調整 (處理)。 效能功能會因每個pricing tier而有所不同，例如基本、標準或進階。

下圖顯示如何在飛機引擎應用程式中使用event hubs。

• event hubs從測試設備擷取streaming data。
• 資料存儲在 Azure Blob storage。
• Azure Stream Analytics查找感測器資料中的模式。
• Power BI 用於對製造改進做出決策。

Event Hub的一些考量

使用Event Hub時，請考慮以下事項：

• 開發語言和框架整合。我們可以發送和接收多種不同開發語言的事件。也可以使用 Apache Storm 從Event hub接收事件。
• 選擇tier 與throughput。Event hub的縮放由我們購買的throughput units或processing units的數量控制。其他效能方面取決於選擇的pricing tier，有basic, standard, premium, 與dedicated pricing tiers可用。single throughput unit等於：

Ingress：每秒最多 1 MB 或每秒 1000 個event（以先到者為準）。

Egress：高達每秒 2 MB 或每秒 4096 個event。

• Event Hub使用pull model。 Event Hub使用的pull model將本身與其他一些messaging services（例如 Azure Service Bus Queues）區分開來。pull model意味著Event Hub只是將message保存在其cache中並允許讀取它。當從Event hub讀取message時，它不會被刪除，但會根據需要由更多使用者讀取。
• 考慮data failure。沒有內建機制來處理未按預期處理的訊息。例如，假設我們的客戶因資料格式而出現問題。一旦訊息的TTL(time-to-live)到期，Event Hub還是會將資料格式有問題的訊息刪除。
• 處理data stream。 Event Hub接收到的事件被添加到其data stream的末端。這個stream按接收到的時間對事件進行排序，客戶可以使用時間位移沿這個stream進行尋找。

設計一個事件導向(event-driven) 解決方案

事件導向(Event driven)架構使我們無需修改現有的code即可連接到核心應用程式。 當事件發生時，我們可以使用自己的代碼對這些事件做出回應。 事件導向的應用程式使用send and forget原則。 事件被發送到下一個系統，它可以是另一個service, 一個event hub, 一個stream, 或一個message broker。

讓我們再次回顧這個音樂共享應用程式，這次使用的是在 Azure 中運作的 Web API。 當使用者上傳一首新歌曲時，我們必須通知有安裝我們行動app的設備並且對該類型音樂感興趣的所有人。 在這個要求中。 Azure Event Grid是滿足此類要求的解決方案。

• 聲音檔案的publisher不需要知道任何對共享音樂感興趣的subscribers。
• 我們希望有一個一對多的關係，我們可以有多個subscribers。 可以選擇決定是否對這首新歌感興趣的subscribers。

Azure Event Grid

Azure Event Grid 是在 Azure Service Fabric 之上運行的全託管的event routing service。Event Grid從 Azure blob storage account和 Azure media service等來源傳送事件。這些事件被分發到 Azure Functions 和 Webhook 等處理程序。Event Grid的存在是為了更容易地在 Azure 上構建基於事件的serverless app。

• Aggregate所有事件並提供從任何來源到任何目的地的路由。
• 是一種管理來自多個來源和subsecibers的事件路由和傳遞的服務。此過程消除了polling的需求，並最大限度地降低了成本和網路延遲。

下圖顯示了位於多個事件來源和多個事件處理程序之間的 Azure Event Grid。事件來源將事件發送到event grid，event grid將相關事件轉發給subscribers。事件使用topic來決定將哪些事件發送到哪些處理程序。事件來源用一個或多個topic標記每個事件，事件處理程序訂閱他們感興趣的topic。

Event Grid發送一個event以指示某些事情已經發生或改變。 但是，實際變動的object不是event data的一部分。 相反，通常會傳遞 URL 或identifier來參考變動物件。

Event Grid/ Event Hubs / Service Bus的比較

將這些服務整合在一起

在某些情況下，我們可以整合這些服務來履行不同的角色。 例如，電商網站可以使用Service Bus來處理訂單，使用Event Hub來擷取網站的監控資料，並使用Event Grid來回應事件，例如貨品已出貨。 在其他情況下，我們將它們鏈接在一起以形成事件和data pipeline。 我們使用Event Grid來回應其他服務中的事件。 下圖顯示了streaming data的工作流程。

設計一個快取解決方案

快取(Caching)是一種常用技術，主要在提高系統的效能和可擴展性。 它通過將頻繁存取的資料臨時複製到靠近應用程式的快速存儲來實現這一點。 如果這種快速資料存儲的位置比原始資料來源更靠近應用程式，那麼快取可以通過更快地提供資料來顯著提高client application的回應時間。

當client重複讀取相同的資料時，快取是最有效，特別是如果以下所有條件都適用於原始資料存儲：

• 它不常變動。
• 與快取的速度相比，它很慢。
• 它受到high level of contention。
• 當網路延遲會導致存取速度變慢時。

在這裡，我們將學會如何使用 Azure Cache for Redis 來管理快取需求。

為Application建議快取解決方案

假設我們是一家遊戲公司，公司推出了一款新遊戲，該遊戲將有即時排行榜供遊戲玩家查閱他們的分數。 排行榜將即時顯示用戶在遊戲中的排名，並在遊戲中的events發生變化時立即更新。 這需要在memory中的快速讀寫，我們被要求為其設計快取解決方案。

Azure Cache for Redis

Azure Cache for Redis 提供基於 Redis 軟體的in-memory data store。 Redis 提高了大量使用後端資料存儲的應用程式的效能和可擴展性。 它能夠通過將頻繁access的資料保存在server的memory中來處理大量應用程式的request，這些資料可以快速寫入和讀取。 Redis 為現代應用程式帶來了關鍵的low-latency 與 high-throughput data storage solution。

Azure Redis Cache同時提供：

• Redis 開源（OSS Redis）
• Redis Labs (Redis Enterprise) 作為託管服務的商用產品。

Azure Redis Cache提供安全的專用 Redis server instance和完整的 Redis API 相容性。 該服務由 Microsoft 營運，託管在 Azure 上，可供 Azure 內外的任何應用程式使用。

可以將 Azure Cache for Redis 用於多種場景，包括：

• Distributed data or content cache
• A session store
• A message broker

小提示：可以將 Azure Cache for Redis 部署為standalone。 或者，我們可以將Azure Cache for Redis與其他 Azure DB服務一起部署，例如 Azure SQL 或 Cosmos DB

下圖為cahce的作業流程

何時使用Azure Cache for Redis

Azure Cache for Redis 通過支援常見的應用程序架構模式來提高應用程序效能。 一些最常見的包括以下模式。

設計一個API 整合解決方案

假設我們公司是吳柏毅或富胖達外送平台。 客戶使用app瀏覽或網站多家餐廳的菜單。 然後客戶下訂單購買他們想要的食物。 公司平台的骨幹是大量 API。 我們推送以下一些 API給以下使用 ：

• 我們的手機app
• 我們的web app
• 合作餐廳
• 送貨車輛上的IoT設備
• 內部開發團隊
• 公司員工，例如業務分析師

每個已發布的 應用程序都在不同的server上，有自己的業務流程，並有自己的security, revisions, analytics等policies。 我們的任務是找到一種降低這種複雜性的方法。

讓我們了解 Azure API management如何在整個 API lifecycle內標準化、集中化和幫助保護 API 發布和維護的所有面向。

Azure APIM

Azure API Management是一個雲端服務平台，可讓我們安全的推送， 維護與 分析公司內的所有 API。 下圖顯示了 Azure API management，它充當組織所有 API 的“front door”，然後將其路由到部署 API 的server。

Azure API management充當 API gateway。 通過這種方式， Azure API management可以decouple我們的應用程式。 這使我們可以在 Azure 中設置 API 政策和其他管理選項，同時保持已部署的backend Application不變。

何時該使用Azure API Management

以下是用來幫助我們確定 Azure API Management是否適合管理和發布組織的 API 清單的標準。

• API 數量
• API 變動率
• API 管理作業的繁重度

當我們有大量部署的 API 時，我們可能會經常修改這些 API，並且需要大量的管理量能。 Azure API management可以幫助我們管理和發布它們。 對於通常涉及小型、靜態或簡單 API 部署的使用場景，Azure API management可能不是好的選擇。 讓我們更詳細地回顧一下決策標準。

Azure API Management的一些考量

要使用Azure API Management的原因有很多。 以上面的送餐場景為例，讓我們從 API 標準化、API 管理集中化和 增強API 安全性等方面來研究 API 生命週期管理。 下表描述了這些功能。

設計一個 自動化app 部署解決方案

隨著遷移到雲端，許多團隊都採用了敏捷開發方法。 這些團隊必須快速迭代並反復將他們的解決方案部署到雲端中。 必須確保團隊的基礎設施處於可靠狀態。 Application code必須通過統一的流程進行管理。

為了應對這些挑戰，我們可以自動化部署並使用infrastructure as code的實踐。 在這一節，我們將學習如何評估不同的 Azure 解決方案，以便為我們的應用程式部署和自動化。 這些解決方案包括 Azure Resource Manager templates與Azure Automation。

Azure Resource Manager templates

Azure Resource Manager templates 是為我們的部署定義基礎架構和配置的檔案。 編寫template時，我們採用宣告式方法來配置資源。 這些template描述了部署中的每個資源，但沒有描述如何部署這些資源。

使用template進行資源配置有很多效益。 下表描述了這些效益：

目前有兩種類型的模板可供使用：JSON template 和Bicep templates。 JavaScript Object Notation (JSON) 是一種開放標準的文件格式，可供多種開發語言使用。 Bicep 是一種新的domain-specific language，最近開發用於通過使用更簡單的語法來建立template。 我們可以為template和資源部署使用任一template格式。我們可以使用 Bicep CLI，將任何 JSON 範本反向組譯成 Bicep 範本。

Bicep template

Bicep 它是一種 Azure Resource Manager template語言，用於以declaratively方式部署 Azure resource。 它是為特定場景而設計的。 Bicep用於建立Azure Resource Manager templates。

選擇 Bicep 作為infrastructure as code 佈署的主要工具集的原因有很多。 下表列出了這些效益。

Azurer Automation

Azure Automation 提供基於雲端的自動化與配置服務，支援跨 Azure 和不是 Azure 環境的一致化管理。 自動化使我們可以完全控制流程自動化，配置管理 與更新管理。

設計一個 application 配置管理解決方案

傳統上，交付新的應用程式需要完全重新部署應用程式本身。 功能的測試或部署通常需要應用程式的多個版本。 每個部署可能需要不同的配置、憑證、更改配置或測試參數。

配置管理是一種現代軟體開發實踐，它將配置與代碼佈署分離，並能夠根據需求快速更改功能可用性。 Decoupling configuration as a service使系統能夠動態管理部署生命週期。

我們將了解可幫助我們解決部署問題的 Azure Configuration Management solutions。

Azure App Configuration

Azure App Configuration 提供了一項服務來集中管理application settings 與feature flags。 使用App Configuration來存儲我們的應用程式的所有配置，並在一個地方保護它們的存取。

以下兩個圖表顯示了 Azure App Configuration在開發和生產環境中的作業方式：

開發環境

生產環境

App Configuration的效益

App Configuration提供以下效益：

• A fully managed service that can be set up in minutes.
• Flexible key representations and mappings.
• Tagging with labels.
• Point-in-time replay of settings.
• Dedicated UI for feature flag management.
• Comparison of two sets of configurations on custom-defined dimensions.
• Enhanced security through Azure-managed identities.
• Encryption of sensitive information at rest and in transit.
• Native integration with popular frameworks.