架構設計師與SOA， 第 1 部分

SOA(Service-Oriented Architecture)，即面向服務的架構，這是最近一兩年出現在各種技術期刊上最多的詞彙了。現在有很多架構設計師和設計開發人員簡單的把SOA和Web Services技術等同起來，認為SOA就是Web Service的一種實現。本質上來說，SOA體現的是一種新的系統架構，SOA的出現，將為整個企業級軟體架構設計帶來巨大的影響。本系列兩部分文章將根據作者自己的理解來幫助大家分析和了解什麼是SOA架構，SOA將怎樣對企業系統架構設計帶來積極的影響，什麼是SOA架構設計師的角色，以及SOA架構師在設計SOA系統架構時有哪些應該特別注意的地方。

1. 什麼是架構？什麼是基於SOA的架構？

1．1 什麼是架構

從架構設計師的角度來看，架構就是一套構建系統的準則。通過這套準則，我們可以把一個複雜的系統劃分為一套更簡單的子系統的集合，這些子系統之間應該保持相互獨立，並與整個系統保持一致。而且每一個子系統還可以繼續細分下去，從而構成一個複雜的企業級架構。

當一名架構設計師在構建某個企業級的軟體系統時，除了要考慮這個系統的架構以及其應具有的功能行為以外，還要關注整個架構的可用性，效能問題，容錯能力，可重用性，安全性，擴充套件性，可管理維護性，可靠性等各個相關方面。有的時候一名好的架構設計師甚至還需要考慮所構建的系統架構是否合乎美學要求。由此我們可以看到，我們衡量一個好的架構設計並不能只從功能角度出發，還要考慮很多其他的因素，對任何一個方面的欠缺考慮都有可能為整個系統的構建埋下隱患。

1．2 什麼是基於SOA的架構

SOA本身就是一種面向企業級服務的系統架構，簡單來說，SOA就是一種進行系統開發的新的體系架構，在基於SOA架構的系統中，具體應用程式的功能是由一些鬆耦合並且具有統一介面定義方式的元件（也就是service）組合構建起來的。因此，基於SOA的架構也一定是從企業的具體需求開始構建的。但是，SOA和其它企業架構的不同之處就在於SOA提供的業務靈活性。業務靈活性是指企業能對業務變更快速和有效地進行響應、並且利用業務變更來得到競爭優勢的能力。對企業級架構設計師來說，建立一個業務靈活的架構意味著建立一個可以滿足當前還未知的業務需求的IT架構。

利用基於SOA的系統構建方法，如圖1中所示的一樣，一個基於SOA架構的系統中的所有的程式功能都被封裝在一些功能模組中，我們就是利用這些已經封裝好的功能模組組裝構建我們所需要的程式或者系統，而這些功能模組就是SOA架構中的不同的服務（services）。

圖1

因此，SOA架構本質上來說體現了一種複合的概念：它不僅為一個企業中商業流程的組織和實現提供了一種指導模式，同時也為具體的底層service開發提供了指導。

2. SOA架構設計師的角色

2．1 SOA架構設計師應該具備什麼？

談到SOA架構設計師的角色，我們首先要了解架構設計師應具有的能力。總體上來說，一個好的架構設計師不僅應該是一個成熟的，具有實際經驗的並具有快速學習能力的人，而且他還應該具有良好的管理能力和溝通能力。只有具備了必需的能力，架構設計師才能在關鍵的時刻作出困難的決定，這就是一名架構設計師應該承擔的責任。從角色上來看，SOA 架構師不僅會負責端到端的服務請求者和提供者的設計，並且會負責對系統中非功能服務請求的調研和表述。

對於任何一名經驗豐富的架構設計師來說，不論他是採用基於傳統的架構設計方法（基於J2EE架構或者.NET架構）還是採用基於SOA的架構設計方法來構建一個企業級的系統架構，具有相關商業領域的知識對於架構設計師來說都是必不可少的，架構設計師往往可以通過實際的工作經驗積累以及接受相關的專項培訓來獲得這些商業領域的知識。除了具有相關商業領域的知識以外，一名合格的架構設計師必須具有較廣泛的技術背景，這可能包括軟硬體，通訊，安全等各個方面的知識。但這並不是意味著要成為一名架構設計師就必須熟悉每一門具體技術的細節，架構設計師必須至少能對各種技術有一個整體上的瞭解，能夠熟知每種技術的特點以及優缺點，只有這樣架構設計師才能在特定的應用場景下正確地選擇各種技術來設計企業整體架構。

2．2 什麼是SOA架構設計師的職責？

那什麼是企業級SOA架構設計師的具體角色呢？什麼是SOA架構設計師與設計和開發人員之間的差別呢？相信這些都是使大家最容易產生迷惑的問題。舉個實際的例子來說，當構建一個基於SOA架構的系統的時候，針對一個具體的 service，系統設計人員主要應該關注的是這個service能夠為外部使用者提供什麼樣的服務，也就是說系統設計人員關注的是這個service所提供的功能。而對於SOA架構設計師來說，他們更關心的可能是當有一千個使用者同時呼叫這個 service的時候，什麼會發生？也就是說架構設計師關注的應該是一些商業需求和服務級別（service-level）需求。所有的架構設計師的角色都包含了在構建一個系統的一開始就應該儘量減少可能存在的技術風險。而技術風險一般指的是一切未知的、未經證明的或未經測試所帶來的風險。這些風險通常與服務級別（service-level）需求相關，偶爾也會與企業具體的業務需求相關。無論是哪種型別的風險，在專案初期設計整體系統架構的過程中更易於發掘這些風險，如果等到架構實施時再發覺這些風險，那麼很可能會致使大量的開發人員等在那裡，直到這些風險被妥善解決。如果進一步的細化，我們可以看到SOA架構設計師的主要任務包括對整個系統解決方案輪廓的構建，需求分析，對體系結構的整體決策，相關元件建模，相關操作建模，系統元件的邏輯和物理佈局設計。

作為SOA架構設計師必須要能夠領導整個開發團隊，這樣才能保證設計和開發人員是按照構建好的系統架構來開發整個系統的，這一點十分的重要。這就要求一名架構設計師不僅要有很好的技術洞察力，同時還要具有一定的專案管理和專案實施的能力。在系統開發的過程中，架構設計師必須要有良好的溝通和表達能力，這就體現在由架構設計師構建的系統模型是否具有很好的可讀性和易理解性。如果由架構設計師構造出的系統模型不是很清晰的話，就可能會影響設計和開發人員對於整個系統架構的理解。為了避免這種情況的出現，定期由架構設計師主持的開發團隊內部討論是十分重要的。

3. 構建SOA架構時應該注意的問題

3．1 原有系統架構中的整合需求

當架構師基於SOA來構建一個企業級的系統架構的時候，一定要注意對原有系統架構中的整合需求進行細緻的分析和整理。我們都知道，面向服務的體系結構是當前及未來應用程式系統開發的重點，面向服務的體系結構本質上來說是一種具有特殊性質的體系結構，它由具有互操作性和位置透明的元件整合構建並互連而成。基於SOA的企業系統架構通常都是在現有系統架構投資的基礎上發展起來的，我們並不需要徹底重新開發全部的子系統；SOA可以通過利用當前系統已有的資源（開發人員、軟體語言、硬體平臺、資料庫和應用程式）來重複利用系統中現有的系統和資源。SOA是一種可適應的、靈活的體系結構型別，基於SOA構建的系統架構可以在系統的開發和維護中縮短產品上市時間，因而可以降低企業系統開發的成本和風險。因此，當SOA架構師遇到一個十分複雜的企業系統時，首先考慮的應該是如何重用已有的投資而不是替換遺留系統，因為如果考慮到有限的預算，整體系統替換的成本是十分高昂的。

當SOA架構師分析原有系統中的整合需求的時候，不應該只限定為基於元件構建的已有應用程式的整合，真正的整合比這要寬泛得多。在分析和評估一個已有系統體系結構的整合需求時，我們必須考慮一些更加具體的整合的型別，這主要包括以下幾個方面：應用程式整合的需求，終端使用者介面整合的需求，流程整合的需求以及已有系統資訊整合的需求。當SOA架構師分析和評估現有系統中所有可能的整合需求的時候，我們可以發現實際上所有整合方式在任何種類的企業中都有一定程度的體現。針對不同的企業型別，這些整合方式可能是簡化的，或者沒有明確地進行定義的。因而，SOA架構師在著手設計新的體系結構框架時，必須要全面的考慮所有可能的整合需求。例如，在一些型別的企業系統環境中可能只有很少的資料來源型別，因此，系統中對訊息整合的需求就可能會很簡單，但在一些特定的系統中，例如航運系統中的EDI（Electronic Data Interchange 電子資料交換）系統，會有大量的電子資料交換處理的需求，因此也就會存在很多不同的資料來源型別，在這種情況下整個系統對於訊息資料的整合需求就會比較複雜。因此，如果SOA架構師希望所構建的系統架構能夠隨著企業的成長和變化成功地繼續得以保持，則整個系統構架中的整合功能就應該由服務提供，而不是由特定的應用程式來完成。

3．2 服務粒度的控制以及無狀態服務的設計

當SOA架構師構建一個企業級的SOA系統架構的時候，關於系統中最重要的元素，也就是SOA系統中的服務的構建有兩點需要特別注意的地方：首先是對於服務粒度的控制，另外就是對於無狀態服務的設計。

服務粒度的控制

SOA系統中的服務粒度的控制是一項十分重要的設計任務。通常來說，對於將暴露在整個系統外部的服務推薦使用粗粒度的介面，而相對較細粒度的服務介面通常用於企業系統架構的內部。從技術上講，粗粒度的服務介面可能是一個特定服務的完整執行，而細粒度的服務介面可能是實現這個粗粒度服務介面的具體的內部操作。 舉個例子來說，對於一個基於SOA架構的網上商店來說，粗粒度的服務可能就是暴露給外部使用者使用的提交購買表單的操作，而系統內部的細粒度的服務可能就是實現這個提交購買表單服務的一系列的內部服務，比如說建立購買記錄，設定客戶地址，更新資料庫等一系列的操作。雖然細粒度的介面能為服務請求者提供了更加細化和更多的靈活性，但同時也意味著引入較難控制的互動模式易變性,也就是說服務的互動模式可能隨著不同的服務請求者而不同。如果我們暴露這些易於變化的服務介面給系統的外部使用者，就可能造成外部服務請求者難於支援不斷變化的服務提供者所暴露的細粒度服務介面。而粗粒度服務介面保證了服務請求者將以一致的方式使用系統中所暴露出的服務。雖然面向服務的體系結構（SOA）並不強制要求一定要使用粗粒度的服務介面，但是建議使用它們作為外部整合的介面。通常架構設計師可以使用BPEL來建立由細粒度操作組成的業務流程的粗粒度的服務介面。

無狀態服務的設計

SOA系統架構中的具體服務應該都是獨立的、自包含的請求，在實現這些服務的時候不需要前一個請求的狀態，也就是說服務不應該依賴於其他服務的上下文和狀態，即SOA架構中的服務應該是無狀態的服務。當某一個服務需要依賴時，我們最好把它定義成具體的業務流程（BPEL）。在服務的具體實現機制上，我們可以通過使用 EJB 元件來實現粗粒度的服務。我們通常會利用無狀態的Session Bean來實現具體的服務，如果基於Web Service技術，我們就可以將無狀態的Session Bean暴露為外部使用者可以呼叫的到的Web服務，也就是把傳統的Session Facade模型轉化為了 EJB 的Web服務端點，這樣，我們就可以向 Web 服務客戶提供粗粒度的服務。

如果我們要在 J2EE的環境下（基於WebSphere）構建Web服務，Web 服務客戶可以通過兩種方式訪問 J2EE 應用程式。客戶可以訪問用 JAX-RPC API 建立的 Web 服務（使用 Servlet 來實現）；Web 服務客戶也可以通過 EJB的服務端點介面訪問無狀態的Session Bean，但Web 服務客戶不能訪問其他型別的企業Bean，如有狀態的Session Bean，實體Bean和訊息驅動Bean。後一種選擇（公開無狀態 EJB 元件作為 Web 服務）有很多優勢，基於已有的EJB元件，我們可以利用現有的業務邏輯和流程。在許多企業中，現有的業務邏輯可能已經使用 EJB 元件編寫，通過 Web 服務公開它可能是實現從外界訪問這些服務的最佳選擇。EJB 端點是一種很好的選擇，因為它使業務邏輯和端點位於同一層上。另外EJB容器會自動提供對併發的支援，作為無狀態Session Bean實現的 EJB 服務端點不必擔心多執行緒訪問，因為 EJB 容器必須序列化對無狀態會話 bean 任何特定例項的請求。 由於EJB容器都會提供對於Security和Transaction的支援，因此Bean的開發人員可以不需要編寫安全程式碼以及事務處理程式碼。 效能問題對於Web服務來說一直都是一個問題，由於幾乎所有 EJB 容器都提供了對無狀態會話 Bean 群集的支援以及對無狀態Session Bean 池與資源管理的支援，因此當負載增加時，可以向群集中增加機器，Web 服務請求可以定向到這些不同的伺服器，同時由於無狀態Session Bean 池改進了資源利用和記憶體管理，使 Web 服務能夠有效地響應多個客戶請求。由此我們可以看到，通過把 Web 服務模型化為 EJB 端點，可以使服務具有更強的可伸縮性，並增強了系統整體的可靠性。

4. 結束語

本文簡要介紹了有關架構設計師以及SOA架構的知識，分析了SOA架構師在設計SOA系統架構時有哪些應該特別注意的地方。

本文的第二部分將向您介紹在構建基於SOA架構的企業系統時應該怎樣保證所構建的系統架構能夠滿足系統中不同的服務級別需求。從架構設計師的角度，SOA是一種新的設計模式，方法學。因此，SOA本身涵蓋了很多的內容，也觸及到了系統整體架構設計、實現、維護等各個方面。本文的內容只是涉及到了有關於架構方面的一部分內容，希望能對廣大的SOA系統開發設計人員起到一定的幫助作用。

作者：王 強 (wangq@cn.ibm.com), 高階軟體工程師, IBM 中國軟體開發實驗室

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-600853/，如需轉載，請註明出處，否則將追究法律責任。