架構樣式Architecture styles

架構樣式是一系列共用特定特性的架構。An architecture style is a family of architectures that share certain characteristics. 例如,多層式架構 (N-tier) 是一般架構樣式。For example, N-tier is a common architecture style. 最近,微服務架構已開始受到青睞。More recently, microservice architectures have started to gain favor. 架構樣式不需要使用特定技術,但是有些技術非常適合特定架構。Architecture styles don't require the use of particular technologies, but some technologies are well-suited for certain architectures. 例如,容器的本質很適合微服務。For example, containers are a natural fit for microservices.

我們已找出一組可經常在雲端應用程式中發現的架構樣式。We have identified a set of architecture styles that are commonly found in cloud applications. 每個樣式的文章包括:The article for each style includes:

  • 樣式的描述和邏輯圖表。A description and logical diagram of the style.
  • 選擇此樣式的時機建議。Recommendations for when to choose this style.
  • 優點、挑戰和最佳作法。Benefits, challenges, and best practices.
  • 使用相關 Azure 服務的建議部署。A recommended deployment using relevant Azure services.

樣式快速導覽A quick tour of the styles

本節會針對我們已識別的架構樣式提供快速導覽,以及一些使用方式上的高層級考量。This section gives a quick tour of the architecture styles that we've identified, along with some high-level considerations for their use. 在連結的主題中閱讀更多詳細資料。Read more details in the linked topics.

多層式架構 (N-tier)N-tier

多層式架構 (N-Tier) 是企業應用程式的傳統架構。N-tier is a traditional architecture for enterprise applications. 相依性是透過將應用程式分「層」來進行管理,這些層會執行展示、商務邏輯和資料存取等邏輯函式。 Dependencies are managed by dividing the application into layers that perform logical functions, such as presentation, business logic, and data access. 一個層只能呼叫位於該層下方的層。A layer can only call into layers that sit below it. 不過,此水平分層可能是負擔。However, this horizontal layering can be a liability. 您可能很難在沒有碰觸到應用程式其餘部分的情況下,將變更引入應用程式的一個部分。It can be hard to introduce changes in one part of the application without touching the rest of the application. 這讓經常性更新變成一個挑戰,進而對新增功能的速度造成限制。That makes frequent updates a challenge, limiting how quickly new features can be added.

多層式架構 (N-Tier) 相當適合用來移轉已使用分層架構的現有應用程式。N-tier is a natural fit for migrating existing applications that already use a layered architecture. 因此,多層式架構 (N-Tier) 最常出現在在基礎結構即服務 (IaaS) 方案,或混合使用 IaaS 和受控服務的應用程式中。For that reason, N-tier is most often seen in infrastructure as a service (IaaS) solutions, or application that use a mix of IaaS and managed services.

Web 佇列背景工作角色 (Web-Queue-Worker)Web-Queue-Worker

如需單純的 PaaS 解決方案,請考慮使用 Web 佇列背景工作角色 架構。For a purely PaaS solution, consider a Web-Queue-Worker architecture. 在此樣式中,應用程式會有 Web 前端來處理 HTTP 要求,以及有後端背景工作角色來執行耗用大量 CPU 的工作或長時間執行作業。In this style, the application has a web front end that handles HTTP requests and a back-end worker that performs CPU-intensive tasks or long-running operations. 前端會透過非同步的訊息佇列與背景工作角色通訊。The front end communicates to the worker through an asynchronous message queue.

Web 佇列背景工作角色適用於具有一些耗用大量資源的工作,但相對簡單的網域。Web-queue-worker is suitable for relatively simple domains with some resource-intensive tasks. 如同多層式架構 (N-tier),該架構相當容易理解。Like N-tier, the architecture is easy to understand. 使用受控服務可簡化部署和作業。The use of managed services simplifies deployment and operations. 但搭配複雜的網域,就很難管理相依性。But with complex domains, it can be hard to manage dependencies. 前端與背景工作角色很容易就會成為難以維護及更新的大型整合元件。The front end and the worker can easily become large, monolithic components that are hard to maintain and update. 如同多層式架構 (N-tier),這會減少更新頻率並限制創新。As with N-tier, this can reduce the frequency of updates and limit innovation.


如果您的應用程式有較複雜的網域,請考慮移至 微服務 架構。If your application has a more complex domain, consider moving to a Microservices architecture. 微服務應用程式是由許多小型且獨立的服務所組成。A microservices application is composed of many small, independent services. 每個服務會實作單一商務功能。Each service implements a single business capability. 服務相依性低,透過 API 合約進行通訊。Services are loosely coupled, communicating through API contracts.

每個服務都可由小型的重點開發團隊來建置。Each service can be built by a small, focused development team. 無須小組間的大量協調就可以部署個別服務,並且可頻繁地進行更新。Individual services can be deployed without a lot of coordination between teams, which encourages frequent updates. 比起多層式架構 (N-tier) 或 Web 佇列背景工作角色架構,微服務架構的建立和管理是較為複雜的。A microservice architecture is more complex to build and manage than either N-tier or web-queue-worker. 它需要成熟的開發和 DevOps 文化特性。It requires a mature development and DevOps culture. 但是,此樣式可帶來更快的發行速度、更迅速的創新和更容易復原的架構。But done right, this style can lead to higher release velocity, faster innovation, and a more resilient architecture.

事件驅動架構Event-driven architecture

事件驅動的架構 會使用發行-訂閱 (pub sub) 模型,其中產生者發行事件,而取用者訂閱這些事件。Event-Driven Architectures use a publish-subscribe (pub-sub) model, where producers publish events, and consumers subscribe to them. 產生者與取用者彼此獨立,且取用者間也彼此獨立。The producers are independent from the consumers, and consumers are independent from each other.

對於擷取和處理大量資料,且延遲非常低的應用程式 (如 IoT 解決方案),請考慮使用事件驅動架構。Consider an event-driven architecture for applications that ingest and process a large volume of data with very low latency, such as IoT solutions. 當不同子系統必須在相同事件資料上執行不同類型的處理程序時,此樣式也十分適用。The style is also useful when different subsystems must perform different types of processing on the same event data.

巨量資料與大量計算Big Data, Big Compute

對符合某些特定設定檔的工作負載而言, 巨量資料大量計算 是其專屬架構樣式。Big Data and Big Compute are specialized architecture styles for workloads that fit certain specific profiles. 巨量資料會將非常大的資料集分割成區塊,並在整個集合上執行平行處理,以便進行分析和報告。Big data divides a very large dataset into chunks, performing parallel processing across the entire set, for analysis and reporting. 大量計算 (也稱為高效能運算 (HPC)) 會在大量核心 (數千個) 間執行平行計算。Big compute, also called high-performance computing (HPC), makes parallel computations across a large number (thousands) of cores. 網域包含模擬、模型和 3-D 轉譯。Domains include simulations, modeling, and 3-D rendering.

作為限制的架構樣式Architecture styles as constraints

架構樣式會在設計置入限制,包括一組可以顯示的元素和這些元素間的允許關聯性。An architecture style places constraints on the design, including the set of elements that can appear and the allowed relationships between those elements. 透過在廣泛的選擇中加上限制,這些限制可引導架構的「形狀」。Constraints guide the "shape" of an architecture by restricting the universe of choices. 當架構符合特定樣式的限制時,某些理想的屬性就會出現。When an architecture conforms to the constraints of a particular style, certain desirable properties emerge.

例如,微服務中的限制包括:For example, the constraints in microservices include:

  • 服務代表單一責任。A service represents a single responsibility.
  • 每個服務彼此獨立。Every service is independent of the others.
  • 服務所擁有的資料只專屬於該服務。Data is private to the service that owns it. 服務不會共用資料。Services do not share data.

藉由遵循這些限制,會出現的是系統中的服務可以各自獨立部署、錯務可被隔離、允許頻繁更新,以及可輕鬆將新技術引入應用程式。By adhering to these constraints, what emerges is a system where services can be deployed independently, faults are isolated, frequent updates are possible, and it's easy to introduce new technologies into the application.

選擇架構樣式之前,請確定您了解該樣式的基礎原則和限制。Before choosing an architecture style, make sure that you understand the underlying principles and constraints of that style. 否則,您可能表面上會得到符合樣式的設計,但並沒有充分運用該樣式。Otherwise, you can end up with a design that conforms to the style at a superficial level, but does not achieve the full potential of that style. 實用也是很重要的。It's also important to be pragmatic. 有時候比起堅持架構單純性,放鬆限制會比較好。Sometimes it's better to relax a constraint, rather than insist on architectural purity.

下表摘要說明每種樣式管理相依性的方式,以及每種樣式適用的最佳網域類型。The following table summarizes how each style manages dependencies, and the types of domain that are best suited for each.

架構樣式Architecture style 相依性管理Dependency management 網域類型Domain type
多層式架構 (N-tier)N-tier 依據子網路分割的水平分層Horizontal tiers divided by subnet 傳統企業網域。Traditional business domain. 更新的頻率低。Frequency of updates is low.
Web 佇列背景工作Web-Queue-Worker 前端和後端作業,透過非同步傳訊區分。Front and backend jobs, decoupled by async messaging. 具有一些資源密集工作且相對簡單的網域。Relatively simple domain with some resource intensive tasks.
微服務Microservices 以垂直方式 (功能性) 區分服務,服務彼此透過 API 呼叫。Vertically (functionally) decomposed services that call each other through APIs. 複雜的網域。Complicated domain. 頻繁更新。Frequent updates.
事件驅動架構。Event-driven architecture. 生產者/取用者。Producer/consumer. 每個子系統的獨立檢視。Independent view per sub-system. IoT 和即時系統IoT and real-time systems
巨量資料Big data 將大型資料集分割成小區塊。Divide a huge dataset into small chunks. 在本機資料集上平行處理。Parallel processing on local datasets. 批次和即時資料分析。Batch and real-time data analysis. 使用 ML 的預測分析。Predictive analysis using ML.
大量計算Big compute 資料會配置到數千個核心。Data allocation to thousands of cores. 計算密集型網域 (例如模擬)。Compute intensive domains such as simulation.

挑戰和優點考量Consider challenges and benefits

限制也會產生挑戰,因此採用這些樣式時,請務必了解利弊得失。Constraints also create challenges, so it's important to understand the trade-offs when adopting any of these styles. 針對此子網域和繫結的內容,請考慮優點多於挑戰的架構樣式。Do the benefits of the architecture style outweigh the challenges, for this subdomain and bounded context.

以下是一些選取架構樣式時要考量的挑戰類型:Here are some of the types of challenges to consider when selecting an architecture style:

  • 複雜度Complexity. 架構樣式的複雜度適合您的網域嗎?Is the complexity of the architecture justified for your domain? 或是反過來,該樣式對您的網域而言太簡化了嗎?Conversely, is the style too simplistic for your domain? 在此情況下,您最後可能會得到「大泥球 (big ball of mud)」,因為架構不會協助您清楚地管理相依性。In that case, you risk ending up with a "big ball of mud", because the architecture does not help you to manage dependencies cleanly.

  • 非同步傳訊和最終一致性Asynchronous messaging and eventual consistency. 非同步傳訊可以用來分離服務,並增加可靠性 (因為可重試訊息) 和延展性。Asynchronous messaging can be used to decouple services, and increase reliability (because messages can be retried) and scalability. 不過,這也會為處理最終一致性帶來挑戰,且可能會造成重複訊息。However, this also creates challenges in handling eventual consistency, as well as the possibility of duplicate messages.

  • 服務間通訊Inter-service communication. 當您將應用程式分解成個別服務時,會發生的風險是,服務間的通訊會造成無法接受的延遲或產生網路壅塞 (例如使用微服務架構時)。As you decompose an application into separate services, there is a risk that communication between services will cause unacceptable latency or create network congestion (for example, in a microservices architecture).

  • 可管理性Manageability. 要管理應用程式、監視器或部署更新等作業會有多困難呢?How hard is it to manage the application, monitor, deploy updates, and so on?