概述#

Orchestration-Driven Service-Oriented Architecture（編排驅動的服務導向架構）是一個需要在其時代背景下理解的架構風格。外部力量的組合加上邏輯合理但最終災難性的組織哲學，使這個架構走向了不再被採用的命運。然而，它提供了一個極佳的警示案例，說明一個合乎邏輯的組織理念如何能阻礙開發流程中最重要的環節。

歷史與哲學#

這種風格的 SOA 出現於 1990 年代末期，當時企業正在快速合併、成長，需要更精密的 IT 基礎設施來應對：

  • 運算資源稀缺且昂貴：distributed computing（分散式運算）剛剛成為可能且必要
  • 作業系統授權昂貴：開源作業系統尚未被認為足夠可靠
  • 資料庫授權複雜：商業資料庫伺服器帶有拜占庭式的授權方案
  • Reuse（重用）成為主導哲學：架構師被期望盡可能地重用一切

這種架構風格也展示了 technical partitioning（技術分割）的理念被推到極致時會產生什麼後果——動機良好，但結果不佳。

拓撲結構（Topology）#

SOA 的拓撲由以下分層組成：

  • Business Services（業務服務）——位於架構頂層，提供進入點
  • Enterprise Service Bus (ESB)——包含 Orchestration Engine（編排引擎）與 Integration Hub（整合中樞）
  • Enterprise Services（企業服務）——細粒度的共享實作
  • Application Services（應用服務）——一次性的單一實作服務
  • Infrastructure Services（基礎設施服務）——提供運營關注點

所有請求都經過 orchestration engine，它是這個分散式架構中邏輯所在之處。即使是內部呼叫也必須通過 ESB。

Figure 16.1: Topology of orchestration-driven service-oriented architecture

服務分類（Taxonomy）#

架構師的核心哲學圍繞 enterprise-level reuse（企業級重用），每一層的分類都支持這個目標：

Business Services#

  • 位於架構頂層，提供業務入口點
  • 代表粗粒度的業務行為，例如 ExecuteTrade、PlaceOrder
  • 不包含程式碼——只有輸入、輸出和 schema 資訊
  • 通常由業務使用者定義

Enterprise Services#

  • 包含細粒度的共享實作
  • 建構圍繞特定業務領域的原子行為：CreateCustomer、CalculateQuote 等
  • 這些服務是組成粗粒度 business services 的建構區塊
  • 透過 orchestration engine 串聯在一起
  • 目標是逐步建立一組可重用的企業服務資產

Application Services#

  • 一次性、單一實作的服務
  • 不需要與 enterprise services 相同的粒度或重用性
  • 例如某個應用需要地理位置功能，但組織不想花時間做成可重用服務
  • 通常由單一應用團隊擁有

Infrastructure Services#

  • 提供運營關注點：monitoring、logging、authentication、authorization
  • 傾向於具體實作，由共享的基礎設施團隊擁有

Orchestration Engine（編排引擎）#

Orchestration engine 是這個架構的核心，將業務服務的實作縫合在一起：

  • 使用 orchestration 進行事務協調（transactional coordination）和訊息轉換（message transformation）
  • 通常綁定到單一或少數關聯式資料庫
  • 事務行為在 orchestration engine 中以宣告方式處理
  • 同時充當 integration hub，允許整合自訂程式碼與套裝軟體及遺留系統

根據 Conway’s Law，負責 orchestration engine 的整合架構師團隊會成為組織內的政治力量，最終成為官僚瓶頸。

實務上，將事務行為卸載到編排工具聽起來不錯，但找到正確的事務粒度越來越困難。當包裹在分散式事務中的服務越多，架構就變得越來越複雜。

Figure 16.2: Message flow with service-oriented architecture

Reuse 與 Coupling 的矛盾#

SOA 的主要目標是服務層級的重用——逐步建構可增量重用的業務行為。但這產生了嚴重的負面影響：

  • 高度耦合：例如所有保險部門共用一個 Customer 服務，對該服務的變更會波及所有部門
  • 變更困難：需要協調部署、整體測試，拖慢工程效率
  • 不必要的複雜性：共用的 Customer 服務必須包含所有部門的細節（例如汽車保險需要駕照資訊，但殘障保險部門完全不需要）
  • 領域概念被稀釋：像 CatalogCheckout 這樣的領域概念被分散到整個架構中，開發者做一個簡單的功能變更可能需要修改數十個不同層的服務

Figure 16.4: Building canonical representations in service-oriented architecture

架構特性評分#

架構特性評分
Partitioning typeTechnical
Number of quanta1
Deployability1/5
Elasticity3/5
Evolutionary1/5
Fault tolerance3/5
Modularity3/5
Overall cost1/5
Performance2/5
Reliability2/5
Scalability4/5
Simplicity1/5
Testability1/5

關鍵觀察：

  • Deployability 和 testability 極低：現代工程目標（如自動化部署、可測試性）在這個架構流行時並不是優先事項，Agile 軟體運動才剛起步
  • Elasticity 和 scalability 尚可：工具供應商投入大量努力實現這些特性，例如透過 session replication 跨應用伺服器
  • Performance 極差：作為分散式架構，每個業務請求被分散到架構的大量部分中
  • 單一 quantum：儘管是分散式架構，但因為通常使用單一資料庫且 orchestration engine 作為巨大的耦合點，沒有任何部分能擁有獨立的架構特性

Figure 16.5: Ratings for service-oriented architecture

這個架構可能是有史以來最極致的 technically partitioned（技術分割）通用架構。對其缺點的反彈直接催生了 microservices 等更現代的架構風格。

為何這是歷史性/警示性架構#

這個架構是一個重要的里程碑，因為它教會了架構師：

  • 分散式事務在真實世界中有多困難
  • Technical partitioning 的實際限制
  • Reuse 的代價是 coupling——這是軟體架構第一定律（trade-offs）的體現
  • 它同時集合了 monolithic 和 distributed 架構的雙重缺點
Backward Space-Based Architecture Style Microservices Architecture Forward