SOA架構介紹

按照英文維基百科定義：SOA(Service-Oriented-Architecture)是一種“軟件”和“軟件架構”的設計模式（或者叫設計原則）。它是基於相互獨立的軟件片段要將自身的功能通過“服務”提供給其他應用 面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。

微服務架構介紹

微服務架構（Microservice Architecture）是一種架構概念，旨在通過將功能分解到各個離散的服務中以實現對解決方案的解耦。你可以將其看作是在架構層次而非獲取服務的類上應用很多SOLID原則。微服務架構是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。

概念：把一個大型的單個應用程序和服務拆分為數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。

定義：圍繞業務領域組件來創建應用，這些應用可獨立地進行開發、管理和叠代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題

3.SOA架構特點：

系統集成：站在系統的角度，解決企業系統間的通信問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規範、服務管理規範； 這一步解決的核心問題是【有序】

系統的服務化：站在功能的角度，把業務邏輯抽象成 可復用、可組裝的服務，通過服務的編排實現業務的 快速再生，目的：把原先固有的業務功能轉變為通用 的業務服務，實現業務邏輯的快速復用；這一步解決 的核心問題是【復用】

業務的服務化：站在企業的角度，把企業職能抽象成 可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】
 

微服務架構特點：

1.通過服務實現組件化開發者不再需要協調其它服務部署對本服務的影響。
2.按業務能力來劃分服務和開發團隊開發者可以自由選擇開發技術，提供 API 服務
3.去中心化每個微服務有自己私有的數據庫持久化業務數據
每個微服務只能訪問自己的數據庫，而不能訪問其它服務的數據庫
某些業務場景下，需要在一個事務中更新多個數據庫。這種情況也不能直接訪問其它微服務的數據庫，而是通過對於微服務進行操作。
數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的數據庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。
4.基礎設施自動化（devops、自動化部署）
Java EE部署架構，通過展現層打包WARs，業務層劃分到JARs最後部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何服務器和數據模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯系，經常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理。
 

SOA喜歡重用

SOA的主要目的是為了企業各個系統更加容易地融合在一起。 說到SOA不得不說ESB(EnterpriseService Bus)。 ESB是什麽? 可以把ESB想象成一個連接所有企業級服務的腳手架。

通過service broker，它可以把不同數據格式或模型轉成canonical格式，把XML的輸入轉成CSV傳給legacy服務，把SOAP 1.1服務轉成 SOAP 1.2等等。 它還可以把一個服務

路由到另一個服務上，也可以集中化管理業務邏輯，規則和驗證等等。 它還有一個重要功能是消息隊列和事件驅動的消息傳遞，比如把JMS服務轉化成SOAP協議。 各服務間可能有
復雜的依賴關系。

微服務喜歡重寫

通常由重寫一個模塊開始。要把整個巨石型的應用重寫是有很大的風險的，也不一定必要。我們向微服務遷移的時候通常從耦合度最低的模塊或對擴展性要求最高的模塊開始，
把它們一個一個剝離出來用敏捷地重寫，可以嘗試最新的技術和語言和框架，然 後單獨布署。 它通常不依賴其他服務。微服務中常用的API Gateway的模式主要目的也不是重用代碼，
而是減少客戶端和服務間的往來.

SOA的好處：

1、降低用戶成本，用戶不需要關心各服務之間是什麽語言的、不需要知道如果調用他們，只要通過統一標準找數據總線就可以了。

2、程序之間關系服務簡單

3、識別哪些程序有問題（掛掉）

缺點：提示了系統的復雜程度，性能有相應影響。

復雜度可控，獨立按需擴展，技術選型靈活，容錯，可用性高
①它解決了復雜性的問題。
②這種架構使每個服務都能夠由專註於該服務的團隊獨立開發
③Microservice架構模式使每個微服務都能獨立部署。
④Microservice架構模式使每個服務都可以獨立調整

缺點：多服務運維難度，系統部署依賴，服務間通信成本，數據一致性，系統集成測試，重復工作，性能監控等

結論

我們不能簡單地說一種架構比另一種架構更好。這主要取決於您正在構建的應用程序的目的。自我SOA更適合需要與許多其他應用程序集成的大型復雜企業應用程序環境。這就是說，小型應用程序不適合SOA架構，因為它們不需要消息中間件組件。
而微服務架構，在另一方面，是更適合於較小和良好的分割，基於Web的系統。另外，如果您正在開發移動或Web應用程序，那麽微服務作為開發人員可以為您提供更大的控制權。最後，我們可以得出結論，因為它們服務於不同的目的，微服務和SOA確實是不同類型的體系結構。

SOA架構與微服務的區別異同