什麼是服務導向架構？
服務導向架構 (SOA) 是一種軟體開發方法，它使用稱為服務的軟體元件來建立業務應用程式。每個服務都提供一種業務功能，服務之間還可以跨平台、跨語言進行通訊。開發人員使用 SOA 在不同系統中重複利用服務，或組合幾個獨立的服務來執行複雜的任務。
例如，某個組織的多個業務流程需要使用者身分驗證功能。該組織無需為所有業務流程重寫身分驗證程式碼，而只需建立一個身分驗證服務，再將該服務用於所有應用程式。同樣的，醫療機構中的幾乎所有系統 (例如患者管理系統和電子健康記錄 (EHR) 系統) 都需要對患者進行登記。這些系統可以呼叫單個通用服務來執行患者登記任務。
服務導向架構有哪些優點？
與所有程序作為一個單元執行的傳統巨型架構相較，服務導向架構 (SOA) 有數項勝出的優點。以下是 SOA 的幾個主要優點：
更快上市
開發人員可跨越不同的業務流程重複使用服務，節省時間與成本。以 SOA 組合應用程式，比從頭編寫程式碼、再執行整合快速許多。
有效維護
比起巨型應用程式中的大型程式碼區塊，為小型服務進行建立、更新和偵錯要輕鬆許多。在 SOA 中修改任何服務，業務流程的整體功能不受影響。
適應性更強
SOA 更能適應技術的演進。您可高效又經濟地將應用程式現代化。例如，醫療機構可在較新的雲端應用程式中使用舊型電子健康記錄系統的功能。
服務導向架構的基本原則有哪些？
有關實作服務導向架構 (SOA)，並無定義完善的標準指導方針。然而，所有 SOA 實作之間有一些共通的基本原則。
相互操作性
SOA 中的每項服務都有描述文件，指明服務的功能和相關條款與條件。任何用戶端系統不分底層的平台或程式設計語言，都能執行服務。例如，業務流程能使用以 C# 與 Python 兩者編寫的服務。因為沒有直接互動，一項服務中發生變更，不會影響使用服務的其他元件。
鬆耦合
SOA 中的服務應為鬆耦合，對於外部資源 (例如資料模型或資訊系統) 的相依性盡可能低。同時也應該無狀態，不保留過往工作階段或交易的任何資訊。如此一來，如您修改一項服務，不會明顯影響用戶端應用程式和使用服務的其他服務。
抽象化
SOA 中的用戶端或服務使用者不需知道服務的程式碼邏輯或實作詳情。對他們而言，服務應該看似黑盒子。用戶端可透過服務合約和其他服務描述文件，取得服務功能以及使用方式等所需資訊。
資料粒度
SOA 中的服務應為適當大小與範圍，以每項服務封裝一項離散
業務功能為理想。開發人員就能為了執行複雜的操作，使用多項服務建立一項複合服務。
服務導向架構有哪些元件？
服務導向架構 (SOA) 主要有四個元件。
服務
服務是 SOA 的建置區塊。可以是私有性，僅限組織的內部使用者可用，亦可為公有性，經由網際網路供所有人使用。個別而言，每項服務有三大功能。
服務實作
服務實作是為執行特定服務功能而建置邏輯的程式碼，例如使用者驗證或帳單計算。
服務供應商
服務供應商會建立、維護及提供一或多項服務，供他人使用。組織可自行建立服務，亦可向第三方服務廠商購買。
服務使用者
由服務使用者請求服務供應商執行特定服務。可以是整個系統、應用程式，或其他服務。以服務合約指定服務供應商與使用者彼此互動時必須遵守的規定。服務供應商與使用者可隸屬不同部門、組織，甚至行業。
服務登錄
服務登錄或稱服務儲存庫，是可由網路存取的可用服務目錄。其中儲存著服務供應商提供的服務描述文件。服務描述文件含有關於服務、以及如何與該服務通訊的資訊。服務使用者利用服務登錄可輕鬆查找所需的服務。
服務導向架構如何運作？
服務導向架構 (SOA) 中，服務獨立運作，為使用者提供功能或資料交換。由使用者請求資訊，和傳送輸入資料到服務。服務處理資料、執行任務，並傳回回應。例如，假設應用程式使用驗證服務，向服務提供使用者名稱和密碼。服務則驗證使用者名稱和密碼，傳回適當回應。
通訊協定
服務通訊時會使用既定規則，這些規則訂定經由網路進行資料傳輸的事項。這些規則稱為通訊協定。實作 SOA 的部分標準協定包括下列：
• 簡單物件存取協定 (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Java 訊息服務 (JMS)
甚至可在 SOA 實作中使用不只一種協定。
什麼是服務導向架構中的 ESB？
企業服務匯流排 (ESB) 是您在與有多種服務的系統通訊時可以使用的軟體。此軟體可不分技術，在服務與服務使用者之間建立通訊。
ESB 的優點
ESB 能透過可重複使用的服務介面，提供通訊和轉換功能。可將 ESB 視為一項集中服務，將服務請求送到適當服務。並可將請求轉換成服務底層的平台和程式設計語言能接受的格式。
實作服務導向架構時有哪些限制？
可擴展性有限
服務共用許多資源，需要協調以執行功能時，系統的可擴展性會大受影響。
提高相依性
服務導向架構 (SOA) 的系統可日漸複雜，於服務之間形成許多相依性。如果數項服務循環地相互呼叫，恐怕難以修改或偵錯。共用資源，例如集中資料庫，也能拖慢系統速度。
單一故障點
對於含有 ESB 的 SOA 實作，ESB 會製造單一故障點。這是一項集中服務，與 SOA 倡導的去中心化概念不同。如果 ESB 關閉，用戶端和服務完全無法相互通訊。
什麼是微型服務？
微型服務架構是以極小且完全獨立的軟體元件所組成，這些元件稱為微型服務，專門處理並且專注在一項任務。微型服務透過 API 通訊，API 是開發人員為了讓其他軟體系統與其微型服務通訊而建立的規則。
微型服務的架構風格最適合現代化的雲端運算環境。這種微型服務經常是在容器內操作，容器是將程式碼與所有相依項封裝在一起的的獨立軟體單元。
微型服務的優點
微型服務是獨立的可擴展、快速、可攜、適用於各種平台，也正是雲端的原生特性。此外也已解耦，換言之對其他微型服務的相依性有限，甚至全無。為此目的，微型服務能本機存取所需全部資料，不必遠端存取其他系統也存取及使用的集中資料。因此，微型服務為顧及效能和敏捷性，會建立重複資料。
SOA 與微型服務相較
微型服務架構是由 SOA 架構風格演變而來。微型服務去除 SOA 的缺點，使軟體與現代化的雲端企業環境更相容。經過微調，並且比起資料共享，較偏好採複製資料的方式。於是能以透過輕量 API 所顯示，其本身的通訊協定完全獨立。基本上是由使用者透過其 API 使用微型服務，以此免除集中 ESB 的需要。
AWS 如何協助您實作微型服務？
利用 AWS，很適合採取模組化架構模式、無伺服器操作模型，以及敏捷的開發人員程序，以建置現代化應用程式。具備建置高度可用微型服務的最為完整平台，技術支援任何範圍和規模的現代化應用程式。例如，您可以執行以下操作：
• 在受管容器中建置、隔離及執行安全的微型服務，簡化操作，減少管理開銷。
• 使用 AWS Lambda 執行微型服務，不必佈建及管理伺服器。
• 15 個關聯式與非關聯式專用 AWS 資料庫提供選擇，以支援微型服務架構。
• 使用 AWS App Mesh 輕鬆監控和控制 AWS 上執行的微型服務。
• 以 AWS X-Ray 監控與排解複雜的微型服務互動。
AWS 上的微型服務可讓您更快創新、降低風險，加速上市速度，以及減少總體擁有成本。立即建立 AWS 帳戶，開始使用 AWS 上的 SOA 與微型服務。
