SOA 與微型服務之間有何差異？
服務導向架構 (SOA) 是一種軟體開發方法，使用稱為服務的軟體元件來建立商業應用程式。每個服務都提供商業功能，並且也能跨平台和語言互相通訊。開發人員使用 SOA 在不同系統中重複利用服務，或組合幾個獨立的服務來執行複雜的任務。微型服務架構是由 SOA 架構風格演變而來。雖然每項 SOA 服務都具備完整的商業功能，但每個微型服務則是規模更小的軟體元件，專門只用於處理單一任務。微型服務去除 SOA 的缺點，使軟體與現代化的雲端企業環境更相容。
SOA 架構解決了整合型架構的哪些限制？
在整合型架構中，開發人員會在單一程式碼庫中撰寫所有服務功能的程式碼。藉助服務導向架構 (SOA)，開發人員可以解決整合型架構的挑戰，例如：
- 擴展時需要對整個應用程式進行擴展的挑戰，即使只有特定元件需要額外資源也一樣。
- 由於功能分散在程式碼庫中，因此無法靈活地新增或修改。
- 無法在不同的應用程式中重複使用元件。
- 容錯受限。一個元件發生故障，可能會導致整個系統失效。
- 採用新技術或與使用不同技術的外部系統整合方面的挑戰。
整合型架構也會集中擁有權和負責整個應用程式的開發團隊。由於架構的規模和複雜性，他們面臨持續交付和 DevOps 實務方面的挑戰。
藉助 SOA，開發人員將軟體功能分解為服務供應商層和服務取用者層。這些層透過企業服務匯流排 (ESB) 進行通訊和交換資料。開發人員使用 SOA，將複雜的應用程式簡化為多種可重複使用的服務。
微型服務架構解決了 SOA 架構的哪些限制？
雖然服務導向架構 (SOA) 可能適用於建置大型企業應用程式，但擴展規模較小的特定業務應用程式需要更大的靈活性。以下是 SOA 的一些限制：
- 企業服務匯流排 (ESB) 將多項服務連線在一起，這會成為單一故障點。
- 所有服務共用一個通用的資料儲存器。這使得服務難以個別管理。
- 每項服務都有廣泛的範圍。因此，如果其中一項服務失敗，整個業務工作流程將會受到影響。
因此，開發人員轉向微型服務架構，以獲得更精細的方法來建置應用程式。
微型服務模型將 SOA 服務分割為較小的服務。每項微型服務都在其界定環境中運作，並且獨立於其他服務執行。簡而言之，微型服務架構在個別服務之間具有受限制的相依項或沒有任何相依項，降低了整個系統故障的風險。
架構差異：SOA 與微型服務
服務導向架構 (SOA) 涵蓋更廣泛的企業範圍。不同的業務單元在一個通用的資料共用平台上有效協作。相較之下，微型服務適用於較窄的範圍。
例如，庫存管理將是電子商務系統的 SOA 服務。但是，微型服務方法會將庫存管理分解為較小的服務，例如可用性檢查程式、履行和會計。
實作
SOA 實作涉及將不同類型的服務整合至一個應用程式。它使用企業服務匯流排來連線服務類型，如下所示：
- 支援特定業務營運的功能性服務
- 企業服務將特定業務功能公開給其他服務
- 開發人員用於建置和部署應用程式的應用程式服務
- 用於管理非功能性功能的基礎設施服務，例如驗證和安全
相較之下，微型服務架構是 SOA 更精細且獨立的實作。微型服務不會像 SOA 服務那樣共用資源。每項微型服務會獨立運作，以提供非常特定的功能。
通訊
為了存取遠端服務，SOA 架構使用集中式企業服務匯流排 (ESB)，來連線各種服務與多個訊息協定。其中一些協定包括 SOAP、進階訊息佇列協定 (AMQP) 和 Microsoft 訊息佇列 (MSMQ)。如果 ESB 失敗，所有 SOA 服務都會受到影響。
同時，微型服務架構使用更簡單的訊息傳遞系統，例如 RESTful API，Java 訊息服務 (JMS) 或發布-訂閱 (pub/sub) 事件串流。這些方法不需要微型服務在交換資料時維持作用中連線。
API 是微型服務架構的常用工具。API 允許兩項或多項微型服務直接交換資料，而無需經過集中式通路。但是，它可在開發人員監控和管理的數十種微型服務之間建立複雜的資料路徑。
資料儲存
SOA 環境包含其他連接服務共用的單一資料儲存層。不同的企業應用程式會在 SOA 實作中存取和重複使用相同的資料，這可優化資料儲存器的價值。
相較之下，每項微型服務都有自己的資料儲存。在微型服務架構中，資料獨立性比重用性更為重要。
部署
部署 SOA 服務可能極具挑戰性，因為它們會在一定程度上耦合。例如，如果開發人員修改或新增服務，就必須重建整個應用程式。此外，SOA 應用程式無法充分利用容器化的優勢，這會從作業系統和硬體抽象化應用程式。
同時，微型服務更容易部署，因為它們專為在雲端環境中擴展而設計。每項微型服務都是獨立的應用程式，開發人員可在雲端進行容器化和部署。
主要優勢：微型服務與SOA
服務導向架構 (SOA) 和微型服務都能讓開發團隊針對雲端環境，高效地建置、部署和管理現代應用程式。也就是說，微型服務提供優於 SOA 部署的某些優勢。
重用性
SOA 設計原則之一是將重點放在重用性和元件共用上。在此架構中，多個前端應用程式使用相同的 SOA 服務。例如，開立發票和訂單追蹤儀表板可存取相同的服務，以擷取客戶詳細資訊。
同時，微型服務採取不同的方法。它們套用資料複寫，而不是共用通用資源。這樣一來，以微型服務為基礎的應用程式執行更高效，且不局限於其他服務的資料操作。
速度
SOA 可能會在簡單實作中提供不錯的速度，但隨著開發人員向系統新增更多服務，資料延遲也會增加。所有服務都會爭用相同的通訊資源和資料功能。
相較之下，因為微型服務架構不共用重疊的資源，在系統擴展時，其仍能保持敏捷性和回應能力。如果流量需求增加，開發人員可為特定微型服務指派和增加運算資源。這樣一來，以微型服務為基礎應用程式能夠隨時以可接受的速度執行。
管控靈活性
以 SOA 為基礎的應用程式在不同服務使用的常見儲存庫之間，提供一致的資料管控。
但是，使用微型服務的開發人員可針對獨立的資料儲存單元，決定不同的管控政策。開發團隊可更高效地協作，並且可自由判斷資料管控機制。
何時使用：SOA 與微型服務
服務導向架構 (SOA) 和微型服務為組織提供了不同的方式，以便從整合型架構遷移至雲端環境。視需某些因素，在實際使用案例中某種方式可能比另一個更合適。
SOA
擁有舊式或獨立企業應用程式的組織可受益於 SOA 架構。SOA 將傳統軟體程式簡化為更小的模組化部件。此外，它還彙集了共用資源以簡化業務功能。開發人員可重複使用現有的 SOA 服務來實作更多業務解決方案，而不是建置重疊且冗餘的服務。
微型服務
微型服務架構是支援敏捷開發團隊的更好選擇。開發人員可使用持續整合和持續交付 (CI/CD) 工具，在不影響應用程式穩定性的情況下，進行快速且增量的程式碼變更。開發人員具有以下目標時使用微型服務會更好：
- 使用不同的程式設計語言、程式庫或架構來建置單一應用程式
- 將個別服務與不同的軟體架構結合建置
- 佈建運算資源並即時擴展個別服務
使用微型服務，公司可從現代雲端功能中獲益，並輕鬆部署數百項微型服務。
差異摘要：SOA 與微型服務
| SOA |
微型服務 |
|
| 實作 |
具有共用資源的不同服務。 |
獨立且針對特定用途的小型服務。 |
| 通訊 |
ESB 使用多種訊息傳遞協定，例如 SOAP、AMQP 和 MSMQ。 |
API、Java 訊息服務、發佈/訂閱 |
| 資料儲存體 |
共用的資料儲存體。 |
獨立的資料儲存體。 |
| 部署 |
充滿挑戰。較小的變更需要完全重建。 |
易於部署。每項微型服務都可容器化。 |
| 重複使用性 |
透過共用常用資源讓服務可重複使用。 |
每項服務都有自己獨立的資源。您可以透過其 API 重複使用微型服務。 |
| 速度 |
隨著更多服務的增加而讓速度減慢。 |
隨著流量增長保持速度一致。 |
| 管控靈活性 |
所有服務保持一致的資料管控。 |
每個儲存體具有不同的資料管控政策。 |
AWS 如何協助您滿足微型服務需求？
採取模組化架構模式、無伺服器操作模型，以及敏捷的開發程序，在 Amazon Web Services (AWS) 上建置現代化應用程式。我們提供最完整的平台，可用於建置高度可用的微型服務，以支援任何範圍和規模的現代化應用程式。
以下是在 AWS 上使用微型服務的方式：
- 在受管容器中建置、隔離及執行安全的微型服務，簡化操作，減少管理開銷。在 AWS 的容器部分閱讀詳細內容。
- 使用 AWS Lambda 執行微型服務，無需佈建及管理伺服器。
- 15 個關聯式與非關聯式專用 AWS 雲端資料庫提供選擇，以支援微型服務架構。
- 使用 AWS App Mesh 輕鬆監控和控制 AWS 上執行的微型服務。
- 使用 AWS X-Ray 監控複雜的微型服務互動，並對其進行疑難排解。
AWS 上的微型服務可讓您更快創新、降低風險，加速上市速度，以及減少總體擁有成本。立即建立帳戶，開始使用 AWS 上的微型服務。
