共用方式為

架構樣式

  • 發行項

架構樣式是共用特定特性的架構系列。 例如， 多層 式是常見的架構樣式。 最近， 微服務架構 已開始獲得青睞。 架構樣式不需要使用特定技術，但某些技術非常適合特定架構。 例如，容器很適合微服務。

我們已識別出一組常見於雲端應用程式中的架構樣式。 每個樣式的文章包括：

  • 樣式的描述和邏輯圖表。
  • 選擇此樣式的時機建議。
  • 優點、挑戰和最佳做法。
  • 使用相關 Azure 服務的建議部署。

快速導覽樣式

本節提供我們識別之架構樣式的快速導覽，以及其使用的一些高階考慮。 請注意，清單並不詳盡。 閱讀連結主題中的更多詳細數據。

多層式

多層式架構樣式的邏輯圖表。

多層式是企業應用程式的傳統架構。 相依性是藉由將應用程式分割成 執行邏輯函式的層 ，例如呈現、商業規則和數據存取。 層次只能呼叫位於其下方的圖層。 不過，這種水準分層可能是責任。 在應用程式的其中一個部分中導入變更可能很難，而不需要觸及應用程式的其餘部分。 這會使頻繁的更新成為挑戰，限制新增新功能的速度。

多層式很適合移轉已使用分層架構的現有應用程式。 因此，多層式最常在基礎結構即服務 （IaaS） 解決方案或使用 IaaS 和受控服務的應用程式中看到。

Web-Queue-Worker

Web-Queue-Worker 架構樣式的邏輯圖表。

針對純粹的 PaaS 解決方案，請考慮使用 Web-Queue-Worker 架構。 在此樣式中，應用程式具有處理 HTTP 要求的 Web 前端，以及執行 CPU 密集工作或長時間執行作業的後端背景工作角色。 前端會透過異步消息佇列與背景工作角色通訊。

Web 佇列背景工作適用於具有一些資源密集型工作的相對簡單網域。 如同多層式，架構很容易理解。 使用受控服務可簡化部署和作業。 但是，使用複雜的網域，很難管理相依性。 前端和背景工作角色可以輕鬆地變成難以維護和更新的大型整合型元件。 如同多層式，這可以減少更新的頻率並限制創新。

微服務

微服務架構樣式的邏輯圖表。

如果您的應用程式具有更複雜的網域，請考慮移至 微服務 架構。 微服務應用程式是由許多小型獨立服務所組成。 每個服務都會實作單一商務功能。 服務會鬆散結合，透過 API 合約進行通訊。

每個服務都可以由一個小型、專注的開發小組來建置。 個別服務可以部署，而不需要小組之間的大量協調，這可鼓勵經常更新。 微服務架構比 N 層或 Web 佇列背景工作角色更複雜， 建置和管理更複雜。 它需要成熟的開發和 DevOps 文化特性。 但正確完成，此樣式可能會導致更高的發行速度、更快速的創新，以及更具彈性的架構。

事件驅動架構

事件驅動架構樣式的圖表。

事件驅動架構 會使用 publish-subscribe （pub-sub） 模型，其中產生者會發佈事件，而取用者會訂閱它們。 生產者與取用者無關，取用者彼此獨立。

針對擷取和處理大量數據且延遲非常低的應用程式，例如IoT解決方案，請考慮事件驅動架構。 當不同的子系統必須在相同的事件數據上執行不同類型的處理時，樣式也很有用。

巨量數據、巨量計算

巨量數據架構樣式的邏輯圖表。

巨量數據和巨量計算是適用於符合特定特定配置檔之工作負載的特製化架構樣式。 巨量數據會將非常大的數據集分割成區塊，在整個集合中執行平行處理，以進行分析和報告。 大型計算也稱為高效能運算（HPC），可在大量核心（千個）之間進行平行計算。 領域包括模擬、模型化和 3D 轉譯。

架構樣式作為條件約束

架構樣式會將條件約束放在設計上，包括一組可以出現的元素，以及這些元素之間的允許關聯性。 條件約束會藉由限制選擇的宇宙來引導架構的「形狀」。 當架構符合特定樣式的條件約束時，會出現某些理想的屬性。

例如，微服務中的條件約束包括：

  • 服務代表單一責任。
  • 每個服務都與其他服務無關。
  • 數據是擁有數據的私用服務。 服務不會共享數據。

藉由遵守這些條件約束，所出現的是一種系統，可以獨立部署服務、隔離錯誤、頻繁更新，而且很容易將新技術引入應用程式。

每個架構樣式都有自己的取捨。 因此，在選擇任何架構樣式之前，請確定您已瞭解該樣式的基本原則和條件約束。 否則，您最終可以得到符合表面層級樣式的設計，但無法達到該樣式的完整潛力。 您需要更注意為何要選擇特定架構樣式，而不是如何實作它。 務實也很重要。 有時最好放寬限制，而不是堅持建築純潔。

在理想情況下，應選擇適當的架構樣式，並達成知情工作負載專案關係人的共識。 工作負載小組應該先找出他們嘗試解決的問題本質。 然後，他們應該識別業務驅動因素和對應的架構特性（也稱為非功能性需求），然後排定優先順序。 例如，如果他們需要較短的上市時間，他們可能會透過快速部署功能來排定可維護性、可測試性和可靠優先順序。 或者，如果工作負載小組有限制的預算，他們可能會排定可行性和簡單性。 選擇和維護架構樣式不是一次性活動，而是持續方法：架構應持續測量、驗證及微調一段時間。 切換架構樣式通常花費大量成本，因此對於長期小組效率與風險降低而言，更能合理地進行前期工作。

下表摘要說明每個樣式如何管理相依性，以及最適合每個類別的網域類型。

架構樣式 相依性管理 網域類型
多層式 水平層除以子網 傳統商務領域。 更新的頻率很低。
Web-queue-worker 前端和後端作業，與異步傳訊分離。 具有一些資源密集工作的相對簡單網域。
微服務 垂直（功能上）分解透過 API 彼此呼叫的服務。 複雜的網域。 經常更新。
事件驅動架構 生產者/取用者。 每個子系統的獨立檢視。 IoT 和實時系統。
巨量數據 將大型數據集分割成小區塊。 本機數據集上的平行處理。 批次和實時數據分析。 使用 ML 進行預測性分析。
大型計算 數據配置給數千個核心。 計算密集的領域，例如模擬。

考慮挑戰和優點

條件約束也會造成挑戰，因此請務必了解採用上述任何樣式時的取捨。 針對這個子域和限定內容，請執行架構樣式的優點超過挑戰。

以下是選取架構樣式時要考慮的一些挑戰類型：

  • 複雜度。 架構的複雜性是否適合您的網域？ 相反地，您的網域樣式太簡單了嗎？ 在此情況下，您可能會冒著「泥漿大球」的風險，因為架構無法協助您完全管理相依性。

  • 異步傳訊和最終一致性。 異步傳訊可用來分離服務，並增加可靠性（因為可以重試訊息）和延展性。 不過，這也會在處理最終一致性以及重複訊息的可能性方面產生挑戰。

  • 服務間通訊。 當您將應用程式分解為個別服務時，服務之間的通訊可能會造成無法接受的延遲或建立網路壅塞（例如，在微服務架構中）。

  • 管理性。 管理應用程式、監視、部署更新等等有多難？