SOA(服務導向架構)

menu icon

SOA(服務導向架構)

探索 SOA(服務導向架構)這個應用程式開發與整合發展的重要階段。

何謂 SOA(服務導向架構)?

SOA(服務導向架構)定義一種透過服務介面讓軟體元件可重複使用的方式。 這些介面利用共同的通訊標準,讓它們能夠快速併入新應用程式,無需每次執行深度整合。

SOA 中的每一項服務都包含執行完整的個別商業功能(例如,檢查客戶的信用、計算每月的貸款支付,或處理抵押貸款申請)所需的程式碼和資料整合。 服務介面提供鬆散連結,這表示可以在不清楚或完全不知道如何在底層實作整合的情況下呼叫服務介面。 服務會使用標準網路通訊協定(例如 SOAP(簡式物件存取通訊協定)/HTTP 或 JSON/HTTP)來公開,以傳送要求來讀取或變更資料。 這些服務的發佈方式可讓開發人員快速找到它們,並重複使用它們來組合新的應用程式。

這些服務可以從頭開始建置,但通常是透過將舊版記錄系統中的功能公開為服務介面來建立。

因此,SOA 代表過去幾十年來應用程式開發和整合發展的一個重要階段。 在 SOA 於 1990 年代後期出現之前,若要將應用程式連接到另一個系統所含的資料或功能,需要進行複雜的點對點整合,即開發人員必須針對每項新開發專案進行部分或全面的重建整合。 透過 SOA 將這些功能公開,可以消除每次重建深度整合的需求。

請注意,雖然 SOA 與較新的微服務架構有許多共同之處,但兩者並非緊密關聯,且實際運作範圍不同;下文將有相關討論。

何謂 ESB?

ESB(企業服務匯流排)是一種模式,集中式元件會執行與後端系統的整合,然後將這些整合作業提供為服務介面。 它可執行資料模型轉換、深度連線功能、遞送,以及可能的多個要求組合,並將這些提供為單一服務介面,以供新的應用程式重複使用。 ESB 模式通常使用特別設計的整合執行時期和工具來實作,這些整合執行時期和工具非常適合上述功能,其可確保生產力發揮最佳潛能。

理論上,您可以在沒有 ESB 的情況下實作 SOA,但每位應用程式擁有者都必須找到自己獨特的服務介面公開方式,這是一項繁重的工作(即使介面最終可重複使用也一樣),也會為未來的維護作業帶來重大挑戰。 事實上,ESB 最終會被視為任何 SOA 實作的實質元素,有時這兩個術語還被當成同義詞使用,進而造成混淆。

請參見「ESB(企業服務匯流排)簡介」以進一步瞭解 ESB。

SOA 的優勢

與之前的架構相比,SOA 可為企業帶來重大優勢:

  • 提高企業敏捷性;上市速度更快:從可重複使用的服務介面組裝應用程式(而不是採用每個新開發專案進行重寫及重新整合)能帶來高效率,讓開發人員能夠更快地建置應用程式以回應新商機。
  • 能夠在新市場中善用傳統功能:精心設計的 SOA 可讓開發人員輕易將功能「鎖定」在一個運算平台或環境中,並將其擴展到新的環境和市場中。 例如,許多公司已經使用 SOA 來將大型主機規模的財務系統功能公開到 Web,讓客戶能自行存取之前只有透過與公司員工或事業夥伴直接互動才能存取的流程和資訊。
  • 改善業務與 IT 之間的協作:在 SOA 中,可以使用「產生保險報價」或「計算資本設備投資報酬率」等商業術語來定義服務。 這麼做可讓業務分析師與開發人員展開更有效的合作,以獲取有助於改善成果的重要洞察見解,例如:由服務定義的業務流程範圍,或變更流程對於業務的影響。

SOA 範例

到了 2010 年,幾乎所有產業的領先企業都在全力實作 SOA。 例如:

  • Delaware Electric 採用 SOA 來整合以前互不相通的系統,藉此提升開發效率,並在為期五年的州政府強制凍漲電價期間維持償債能力。
  • Cisco 採用 SOA 以確保其所有產品和通路的產品訂購體驗保持一致;他們的作法是將訂購程序公開為服務,讓 Cisco 的組織部門、收購對象和事業夥伴可以將其整合到各自的網站中。
  • 費城的 Independence Blue Cross (IBC) 實作 SOA,以確保 IBC 客服人員、醫師辦公室和 IBC 網站使用者等處理患者資料的相關人士都使用相同資料來源,即「單一事實版本」。

SOA 與微服務比較

專家們已撰寫數千頁的書面和數位文章來比較 SOA 與微服務之間的差異,並定義兩者關係的細微處。 就本文目的來看,兩者的主要差異在於元件聯結與使用範圍:

  • SOA 是企業層面概念。 它可讓現有應用程式透過各自對應一個商業功能的鬆散聯結介面來公開,使部分延伸企業的應用程式可以重複使用其他應用程式的功能。
  • 微服務架構是應用程式範圍的概念。 它可讓單一應用程式的內部細分成一些可獨立變更、擴充及管理的小組件。 它不會定義應用程式如何彼此相互溝通;因此,我們回到 SOA 所提供的企業服務介面範圍。

隨著虛擬化雲端運算、敏捷開發實踐作法及 DevOps 的崛起,微服務架構應運而生並蓬勃發展。 在這些情境中,微服務的大部分優勢來自元件之間完全解除聯結,因此可簡化並改善:

  • 開發人員的敏捷性和生產力:微服務可讓開發人員在應用程式的某部分納入新技術,而應用程式的其他部分無需達到同樣水準。 任何元件都可以獨立進行修改、測試及部署,以加快疊代週期。
  • 可調整性:微服務可以充分利用雲端的可調整性 — 任何元件都可以獨立進行擴充,以儘快回應工作負載需求,並以最有效率的方式利用運算資源。
  • 備援力:同樣地,由於解除聯結,某項微服務失效並不會影響其他的微服務。 此外,每項微服務可以各自符合本身的可用性要求,不用注資其他元件或整個應用程式以達到最高的整體可用性要求。

如需深入瞭解 SOA 與微服務之間的差異,請參閱「SOA 與微服務比較:有什麼不同?

如同微服務架構有可能改善應用程式設計的敏捷性、可調整性及復原力,這些技術也可以應用於整合作業。 這一點很重要,因為久而久之,高度集中的 ESB 模式及其關聯的集中式整合專家團隊可能會成為瓶頸。 若套用微服務原則,我們有可能將 ESB 細分為更精細的分散式整合。 這是實現敏捷整合的一項核心前提。

SOA 與 IBM Cloud

隨著您公司將 IT 基礎架構轉向混合雲方法,您很有可能會將各種工作負載(包括基於 SOA 的工作負載)轉換為更輕量且更具彈性的雲端部署模型。 IBM 是 SOA 的先驅之一,而 IBM Cloud 供應項目及服務可善用您的現有 SOA 投資並將其擴充到雲端。

進行下一步:

無論核心應用程式或資料庫位於何處,SOA 都能透過不同管道提供服務,這有助您的組織在雲端旅程進行應用程式現代化時充分利用投資。

立即開始使用 IBM Cloud 帳戶。