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

本系列的第 1 部分 介紹了有關架構設計師以及 SOA 架構的知識，分析了 SOA 架構師在設計 SOA 系統架構時有哪些應該特別注意的地方。本文將延續第一部分的內容，向您介紹了 SOA 為企業級架構設計帶來的影響，以及在構建基於 SOA 架構的企業系統時應該怎樣保證所構建的系統架構能夠滿足系統中不同的服務級別需求。

1． SOA 為企業級架構設計帶來的影響

1．1 SOA 的特點及其使用範圍

SOA 既不是一種語言，也不是一種具體的技術，它是一種新的軟體系統架構模型。 SOA 最主要的應用場合在於解決在Internet環境下的不同商業應用之間的業務整合問題。Internet環境區別於Intranet環境的幾個特點主要是：

(a)大量異構系統並存，不同計算機硬體工作方式不同，作業系統不同、程式語言也不同；

(b)大量、頻繁的資料傳輸的速度仍然相對較緩慢並且不穩定；

(c)無法完成服務（service）的版本升級，甚至根本就無法知道網際網路上有哪些機器直接或者間接的使用某個服務。

SOA 架構具有一些典型特性，主要包括鬆耦合性，位置透明性以及協議無關性。鬆耦合性要求 SOA 架構中的不同服務之間應該保持一種鬆耦合的關係，也就是應該保持一種相對獨立無依賴的關係；位置透明性要求 SOA 系統中的所有服務對於他們的呼叫者來說都是位置透明的，也就是說每個服務的呼叫者只需要知道他們呼叫的是哪一個服務，但並不需要知道所呼叫服務的物理位置在哪裡；而協議無關性要求每一個服務都可以通過不同的協議來呼叫。通過這些 SOA 架構所具有的特性我們可以看到，SOA 架構的出現為企業系統架構提供了更加靈活的構建方式，如果企業架構設計師基於 SOA 來構建系統架構，就可以從底層架構的級別來保證整個系統的鬆耦合性以及靈活性，這都為未來企業業務邏輯的擴充套件打好了基礎。

1．2 SOA 架構的分層模型

接下來簡要介紹一下 SOA 系統中的分層模型，整個 SOA 架構的分層模型如圖2所示。

在 SOA 系統中不同的功能模組可以被分為7層：第一層就是系統已經存在的程式資源，例如ERP或者CRM系統等。第2層就是元件層，在這一層中我們用不同的元件把底層系統的功能封裝起來。第3層就是 SOA 系統中最重要的服務層，在這層中我們要用底層功能元件來構建我們所需要的不同功能的服務。總的來說，SOA 中的服務可以被對映成具體系統中的任何功能模組，但是從功能性方面可以大致劃分為以下三種型別：(1)商業服務（business service） 或者是商業過程（business process）。這一類的服務是一個企業可以暴露給外部使用者或者合作伙伴使用的服務。比如說提交貸款申請，使用者信用檢查，貸款信用查詢。(2)商業功能服務（business function service）， 這類服務會完成一些具體的商業操作，也會被更上層的商業服務呼叫，不過大多數情況下這類服務不會暴露給外部使用者直接呼叫，比如說檢索使用者帳戶資訊，儲存使用者資訊等。(3)技術功能服務（technical function service），這類服務主要完成一些底層的技術功能，比如說日誌服務以及安全服務等。在服務層之上的第4層就是商業流程層，在這一層中我們利用已經封裝好的各種服務來構建商業系統中的商業流程。在商業流程層之上的就是第5層表示層了，我們利用表示層來向使用者提供使用者介面服務，這一層可以用基於portal的系統來構建。以上這5層都需要有一個整合的環境來支援它們的執行，第6層中的企業服務匯流排（ESB）提供了這個功能。第7層主要為整個 SOA 系統提供一些輔助的功能，例如服務質量管理，安全管理這一類的輔助功能。． SOA 架構中的非功能性服務級別（service-level）需求

除了系統的業務需求，架構設計師還必須要保證構建出來的系統架構能夠滿足系統中的非功能性服務級別（service-level）需求以及服務質量（QoS）方面的需求。在專案初始及細化階段，架構設計師應該與系統所有涉及方（Stakeholders）一起，為每一個服務級別需求定義其相關的衡量標準。構建出的系統架構必須要能滿足以下幾方面的服務水準要求：效能、可升級性、可靠性、可用性、可擴充套件性、可維護性、易管理性以及安全性。架構設計師在設計架構過程中需要平衡所有的這些服務級別需求。例如，如果服務級別需求中最重要的是系統效能，架構設計師很有可能不得不在一定程度上犧牲系統的可維護性及可擴充套件性，以確保滿足系統效能上的要求。隨著網際網路的發展，新構建的系統對於服務級別需求也變得日益重要，現在基於網際網路的企業系統的使用者已經不僅僅侷限於是本企業的僱員，企業的外部客戶也會成為企業系統的主要使用者。

架構設計師的職責之一就是要儘可能地為提高系統設計人員和系統開發人員的工作效率考慮。在構建整個企業系統架構的過程中，需要充分重視各種服務級別需求，從而避免在系統開發和執行的時候出現重大問題。一個企業級系統中的服務級別需求往往是十分錯綜複雜的， SOA 架構設計師需要憑藉豐富的專業經驗和紮實的理論知識來分離和抽象系統中不同的服務級別需求，圖3展示了這種分析的過程。

圖3

經過 SOA 架構設計師分析和抽象的服務級別需求主要分為以下幾類：

• 效能是指系統提供的服務要滿足一定的效能衡量標準，這些標準可能包括系統反應時間以及處理交易量的能力等；
• 可升級性是指當系統負荷加大時，能夠確保所需的服務質量，而不需要更改整個系統的架構；
• 可靠性是指確保各應用及其相關的所有交易的完整性和一致性的能力；
• 可用性是指一個系統應確保一項服務或者資源永遠都可以被訪問到；
• 可擴充套件性是指在不影響現有系統功能的基礎上，為系統填加新的功能或修改現有功能的能力；
• 可維護性是指在不影響系統其他部分的情況下修正現有功能中問題或缺陷，並對整個系統進行維護的能力；
• 可管理性是指管理系統以確保系統的可升級性、可靠性、可用性、效能和安全性的能力；
• 安全性是指確保系統安全不會被危及的能力。

1) 效能

我們通常可以根據每個使用者訪問的系統響應時間來衡量系統的整體效能；另外，我們也可以通過系統能夠處理的交易量（每秒）來衡量系統的效能。對於架構設計師來說，無論採取哪種衡量系統效能的方法來構建系統架構，這些對於效能的考慮對系統設計開發人員來說都應該是透明的，也就是說對於系統整體架構效能的考慮應該是架構設計師的工作，而不是系統設計開發人員應該關注的事情。在較傳統的基於EJB或者XML-RPC的分散式計算模型中，它們的服務提供都是通過函式呼叫的方式進行的，一個功能的完成往往需要通過客戶端和伺服器來回很多次的遠端函式呼叫才能完成。在Intranet的環境下，這些呼叫給系統的響應速度和穩定性帶來的影響都可以忽略不計，但如果我們在基於 SOA 的架構中使用了很多Web Service來作為服務提供點的話，我們就需要考慮效能的影響，尤其是在Internet環境下，這些往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此在基於 SOA 的系統中，推薦採用大資料量低頻率訪問模式，也就是以大資料量的方式一次性進行資訊交換。這樣做可以在一定程度上提高系統的整體效能。

2) 可升級性

可升級性是指當系統負荷加大時，仍能夠確保所需的服務質量，而不需要更改整個系統的架構。當基於 SOA 的系統中負荷增大時，如果系統的響應時間仍能夠在可接受的限度內，那麼我們就可以認為這個系統是具有可升級性的。要想理解可升級性，我們必須首先了解系統容量或系統的承受能力，也就是一個系統在保證正常執行質量的同時，所能夠處理的最大程式數量或所能支援的最大使用者數量。如果系統運轉時已經不能在可接受時間範圍內反應，那麼這個系統已經到達了它的最大可升級狀態。要想升級已達到最大負載能力的系統，你必須增加新的硬體。新新增的硬體可以以垂直或水平的方式加入。垂直升級包括為現在的機器增加處理器、記憶體或硬碟。水平升級包括在環境中添置新的機器，從而增加系統的整體處理能力。作為一個系統架構設計師所設計出來的架構必須能夠處理對硬體的垂直或者水平升級。基於 SOA 的系統架構可以很好地保證整體系統的可升級性，這主要是因為系統中的功能模組已經被抽象成不同的服務，所有的硬體以及底層平臺的資訊都被遮蔽在服務之下，因此不管是對已有系統的水平升級還是垂直升級，都不會影響到系統整體的架構。

3) 可靠性

可靠性是指確保各應用及其相關的所有交易的完整性和一致性的能力。當系統負荷增加時，你的系統必須能夠持續處理需求訪問，並確保系統能夠象負荷未增加以前一樣正確地處理各個程式。可靠性可能會在一定程度上限制系統的可升級性。如果系統負荷增加時，不能維持它的可靠性，那麼實際上這個系統也並不具備可升級性。因此，一個真正可升級的系統必須是可靠的系統。在基於 SOA 來構建系統架構的時候，可靠性也是必須要著重考慮的問題。要在基於 SOA 架構的系統中保證一定的系統可靠性，就必須要首先保證分佈在系統中的不同服務的可靠性。而不同服務的可靠性一般可以由其部署的應用伺服器或Web伺服器來保證。只有確保每一個 SOA 系統中的服務都具有較高的可靠性，我們才能保證系統整體的可靠效能夠得以保障。

4) 可用性

可用性是指一個系統應確保一項服務或者資源應該總是可被訪問到的。可靠性可以增加系統的整體可用性，但即使系統部件出錯，有時卻並不一定會影響系統的可用性。通過在環境中設定冗餘元件和錯誤恢復機制，雖然一個單獨的元件的錯誤會對系統的可靠性產生不良的影響，但由於系統冗餘的存在，使得整個系統服務仍然可用。在基於 SOA 來構建系統架構的時候，對於關鍵性的服務需要更多地考慮其可用性需求，這可以由兩個層次的技術實現來支援，第一種是利用不同服務的具體內部實現內部所基於的框架的容錯或者冗餘機制來實現對服務可用性的支援；第二種是通過UDDI等動態查詢匹配方式來支援系統整體的高可用性。在 SOA 架構設計師構建企業系統架構的時候，應該綜合考慮這兩個方面的內容，儘量保證所構建的 SOA 系統架構中的關鍵性業務能具有較高的可用性。

5) 可擴充套件性

可擴充套件性是指在不影響現有系統功能的基礎上，為系統新增新的功能或修改現有功能的能力。當系統剛配置好的時候，你很難衡量它的可擴充套件性，直到第一次你必須去擴充套件系統已有功能的時候，你才能真正去衡量和檢測整個系統的可擴充套件性。任何一個架構設計師在構建系統架構時，為了確保架構設計的可擴充套件性，都應該考慮下面幾個要素：低耦合，介面(interfaces)以及封裝。當架構設計師基於 SOA 來構建企業系統架構時，就已經隱含地解決了這幾個可擴充套件性方面的要素。這是因為 SOA 架構中的不同服務之間本身就保持了一種無依賴的低耦合關係；服務本身是通過統一的介面定義（可以是WSDL）語言來描述具體的服務內容，並且很好地封裝了底層的具體實現。在這裡我們也可以從一個方面看到基於 SOA 來構架企業系統能為我們帶來的好處。

6) 可維護性

可維護性是指在不影響系統其他部分的情況下修改現有系統功能中問題或缺陷的能力。同系統的可擴充套件性相同，當系統剛被部署時，你很難判斷一個系統是否已經具備了很好的可維護性。當建立和設計系統架構時，要想提高系統的可維護性，你必須考慮下面幾個要素：低耦合、模組性以及系統文件記錄。在企業系統可擴充套件性中我們已經提到了 SOA 架構能為系統中暴露出來的各個子功能模組也就是服務帶來低耦合性和很好的模組性。關於系統文件紀錄，除了底層子系統的相關文件外，基於 SOA 的系統還會引用到許多系統外部的由第三方提供的服務，因此如果人力資源准許的話，應該增加專職的文件管理員來專門負責有關整個企業系統所涉及的所有外部服務相關文件的收集、歸類和整理，這些相關的文件可能涉及到第三方服務的介面（可以是WSDL）、服務的質量和級別、具體效能測試結果等各種相關文件。基於這些文件，就可以為 SOA 架構設計師構建企業 SOA 架構提供很好的文件參考和支援。

7) 可管理性

可管理性是指管理系統以確保整個系統的可升級性、可靠性、可用性、效能和安全性的能力。具有可管理性的系統，應具備對服務質量需求（QoS）的系統監控能力，通過改變系統的配置從而可以動態地改善服務質量，而不用改變整體系統架構。一個好的系統架構必須能夠監控整個系統的執行情況並具備動態系統配置管理的功能。在對複雜系統進行系統架構建模時， SOA 架構設計師應該儘量考慮利用將系統整體架構構建在已有的成熟的底層系統框架（Framework）上。對於 SOA 架構設計師來說，可以選擇的底層系統框架有很多，可以選用基於MQ, MessageBorker，WebSphere Application Server等產品來構建企業服務匯流排（Enterprise Service Bus）以支援企業的 SOA 系統架構，也可以選用較新的基於WebSphere Application Server 6中內嵌的Sibus來構建企業的ESB以支援 SOA 系統架構。具體選擇哪種底層框架來實施 SOA 系統架構要根據每個系統各自的特點來決定，但這些底層的框架都已經提供了較高的系統可管理性。因此，分析並選擇不同的產品或底層框架來實現企業系統架構也是架構設計師的主要職責之一。有關於如何利用已有底層架構來構建 SOA 系統，中國 SOA 設計中心已經發表了一系列相關的文章，大家可以在DeveloperWorks中的 SOA 專欄看到它們。

8) 安全性

安全性是指確保系統安全不會被危及的能力。目前，安全性應該說是最困難的系統質量控制點。這是因為安全性不僅要求確保系統的保密和完整性，而且還要防止影響可用性的服務拒絕(Denial-of-Service)攻擊。這就要求當 SOA 架構設計師在構建一個架構時，應該把整體系統架構儘可能地分割成各個子功能模組，在將一些子功能模組暴露為外部使用者可見的服務的時候，要圍繞各個子模組構建各自的安全區，這樣更便於保證整體系統架構的安全。如果一個子模組受到了安全攻擊，也可以保證其他模組相對安全。如果企業 SOA 架構中的一些服務是由Web Service實現的，在考慮這些服務安全性的時候也要同時考慮效率的問題，因為WS-Security會為Web Service帶來一定的執行效率損耗。

作者：王強  IBM軟體工程師

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