單體架構就是将所有功能都部署在一個web容器中運作的系統就叫做單體架構，一個執行個體中內建了一個系統的所有功能，通過負載均衡軟體/裝置實作多執行個體調用。
單體架構在初創公司、中小型系統、産品試錯等場景下開發的周期快、對開發人員的技能要求低而任然被廣泛地采用。
優點：
1.易于開發 - 目前開發工具和IDE的目标是支援單片應用程式的開發
2.易于部署 - 隻需在适當的運作時上部署WAR檔案（或目錄層次結構）
3.易于擴充 - 可以通過在負載均衡器後面運作應用程式的多個副本來擴充應用程式
缺點：
複雜性高
項目包含的子產品非常多，子產品的邊界模糊，依賴關系不清晰，代碼品質參差不齊，整個項目非常複雜。
部署頻率低
随着代碼的增多，建構和部署的時間也會增加。而在單體應用中，每次功能的變更或缺陷的修複都會導緻我們需要重新部署整個應用。全量部署的方式耗時長、影響的範圍大、風險高，這使得單體應用項目上線部署的頻率較低。而部署頻率低又導緻兩次釋出之間會有大量的功能變更和缺陷修複，出錯機率比較高。
擴充能力受限
單體應用隻能作為一個整體進行擴充，無法結合業務子產品的特點進行伸縮。例如，應用中有的子產品是計算密集型的，它需要強勁的CPU；有的子產品則是IO密集型的，需要更大的記憶體。由于這些子產品部署在一起，我們不得不在硬體的選擇上做出妥協。
開發效率低
每個成員都需要有完整的環境依賴，開發環境的搭建成本高，協同開發時版本沖突頻繁，一個有問題的送出可能會影響其他所有同僚的開發調試。達到一定代碼量後編譯慢啟動慢
技術更新困難
牽一發而動全身，無法子產品化地實作技術架構地更新。在項目生命周期内我們不可能不去更新依賴架構/類庫的版本，更有甚者會重新選擇基礎架構，每一次變更都會傷筋動骨，但我們又不得不做，項目要可持續，溫和的、可循序漸進的技術更新達不到，阻礙技術創新
不利于安全管理
所有開發人員都擁有全量代碼，在安全管控上存在很大風險，尤其是對用大量外包人員或新招大量開發人員的團隊。
SOA
了解到單體架構的這些不足後,自然而然地要做拆分，可以從業務上将不同的子產品拆分到不同的系統中。還可以将同一子產品進一步拆分，可以按技術分層将一個子產品拆分成多個。 而無論怎麼拆分都會面臨一個問題：拆分後的服務怎麼排程？
SOA（Service-Oriented Architecture）是一種分布式服務架構的常見方式：提供一種被各個服務單元/系統彼此認可的協定進行資料通訊，進而實作跨服務單元/系統互動的能力。
SOA在軟體工程及IT行業的發展中有着舉足輕重的地位，在系統标準化、內建化、規模化建設中起到了關鍵作用。它的核心優勢是以相對簡單的方式解決了系統間的服務重用問題。為各個獨立的、松散的系統互通提供了解決方案。
SOA是一種設計方法，其中包含多個服務，服務之間通過互相依賴最終提供一系列的功能。一個服務通常以獨立的形式存在與作業系統程序中。各個服務之間 通過網絡調用。
架構特點：
系統內建：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入一些産品，比如 ESB、以及技術規範、服務管理規範； 這一步解決的核心問題是有序。
系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實作業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實作業務邏輯的快速複用；這一步解決 的核心問題是複用。
業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是高效。
①服務之間通過簡單、精确定義的接口進行通信，不涉及底層程式設計接口和通信模型。
②粗粒度性：粗粒度服務提供一項特定的業務功能，采用粗粒度服務接口的優點在于使用者和服務層之間不必再進行多次的往複，一次往複就足夠了。
③松耦合性：松耦合性要求SOA架構中的不同服務之間應該保持一種松耦合的關系，也就是應該保持一種相對獨立無依賴的關系。這樣的好處有兩點，首先是具有靈活性，其次當組成整個應用程式的服務内部結構和實作逐漸地發生變化時， 系統可以繼續地獨立存在。而緊耦合意味着應用程式的不同元件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時 這種結構就顯得非常脆弱。
④位置透明性：位置透明性要求SOA系統中的所有服務對于其調用者來說都是位置透明的，也就是說，每個服務的調用者隻需要知道想要調用的是哪一個服務，但并不需要知道所調用服務的實體位置在哪。
⑤協定無關性：協定無關性要求每一個服務都可以通過不同的協定來調用。
另外，在許多傳統的IT系統的内在部分采用的是硬連接配接，這種結構很難讓企 業快速響應市場的變化，而SOA能夠重複利用企業現有的資源，可以減輕企業營運成本，提升資源的使用效率，并且減輕企業維護人員的工作量，減少潛在的風險 以及管理費用。
在業務方面和IT方面帶來許多優勢：
①服務給精确的業務流程帶來靈活性；
②使用服務來改善客戶服務，而不必擔心底層複雜的IT基礎架構；
③可以迅速建立新的業務流程和複雜的應用程式，以适應市場變化；
④借助安全、易管理的內建環境，成為響應能力更強的IT組織；
⑤通過使用預裝的、可重複使用的服務構模組化塊，縮短開發和部署周期；
⑥通過使用服務來降低複雜性和維護成本；
⑦是增強而不是替換現有的IT系統。
SOA的目标就是實作靈活可變的IT系統。要達到靈活性，通過三個途徑來解決：标準化封裝、複用、松耦合可編排。
SOA是一個不斷解構的過程，傳統軟體強調系統性，耦合度過高，是以需要松耦合（解耦）；SOA也是一個元件粒度的平衡，內建電路趨勢是內建度越來越高，軟體發展的趨勢是相反的過程；SOA是架構，更是方法，反映了人們對哲學思想的追求的原動力。
SOA的架構(Framework)
SOA的核心主體是服務。所謂“服務（Service）” ，從業務角度而言，服務是一個可重複的經過标準封裝的任務，例如: 檢查帳号餘額;開新帳戶 等等…。SOA的目标是通過服務的流程化來實作業務的靈活性，所謂流程（Process）是由一系列互相關聯的任務所組成，實作一個具體的業務功能。一個流程可以由一系列服務來實作。
服務就像一堆“元器件”，這些元器件通過封裝形成标準服務，他們有相同的接口和語義表達規則。但服務要組裝成一個流程和應用，還需要有效的“管理”，包括如何注冊服務、如何發現服務、如何包裝服務的安全性和可靠性，這些就是SOA治理。SOA治理乃是将SOA這一堆元器件，進行有效組裝，形成一個“産品”的關鍵，否則它永遠是一堆器件，而無法形成一個有機整體。
由IBM提案，國際開放群組(The Open Group)提出了一個SOA架構的參考模型，這個架構架構目前是産業界最權威和嚴謹的SOA架構标準。The Open Group是一個非營利标準化組織，是一個廠商中立和技術中立的機構，緻力于提出各種技術架構和理論結構，緻力于促進全球市場的業務效率。
The Open Group已有超過20年的标準制定與推廣曆史。在1996年，由X/Open與Open Software Foundation合并組成。The Open Group最有名是作為UNIX商标的認證機構。在過去，協會最出名的是其出版的Single UNIX Specification，它擴充了POSIX标準而且是UNIX的官方定義，其成員包括IT使用者、供應商以及政府機構。The Open Group在中國的創始會員為金蝶集團，金蝶集團負責成立了中國分會。TOG在1993年提出的The Open Group Architecture Framework (TOGAF) 架構架構，是一套行之有效的企業架構。曆經15年9個版本發展，支援開放、标準的SOA參考架構，已被80％的福布斯( Forbes)全球排名前50的公司使用。這個SOA參考模型為：
根據這個模型，完整的SOA架構由五大部分組成，分别是：基礎設施服務、企業服務總線、關鍵服務元件、開發工具、管理工具等。
SOA基礎設施是為整個SOA元件和架構提供一個可靠的運作環境，以及服務元件容器，它的核心元件是應用伺服器等基礎軟體支撐設施，提供運作期完整、可靠的軟體支撐。
企業服務總線是指由中間件基礎設施産品技術實作的、通過事件驅動和基于XML消息引擎，為SOA提供的軟體架構的構造物。企業服務總線ESB提供可靠消息傳輸、服務接入、協定轉換、資料格式轉換、基于内容的路由等功能，屏蔽了服務的實體位置，協定和資料格式。在SOA基礎實作的方案上，應用的業務功能能夠被釋出、封裝和提升（Promote）成為業務服務（Business Service）；業務服務的序列可以編排成為BPM的流程，而流程也可以被釋出和提升為複合服務（Composited Service），業務服務還可以被外部的SOA系統再次編排群組合。ESB是實作SOA治理的重要支撐平台，是SOA解決方案的核心，從某種意義上說，如果沒有ESB，就不能算作嚴格意義上的SOA。
關鍵服務實作，是SOA在各種業務服務元件的分類。一般來說，一個企業級的SOA架構通常包括：互動服務、流程服務、資訊服務、夥伴服務、企業應用服務和接入服務。這些服務可能是一些服務元件，也可能是企業應用系統（如ERP）所暴露的服務接口等等。這些服務都可以接入ESB，進行集中統一管理。
開發工具和管理工具：提供完善的、可視化的服務開發和流程編排工具，涵蓋服務的設計、開發、配置、部署、監控、重構等完整的SOA項目開發生命周期。
按照這個模型，許多SOA解決方案是隻提供部分實作。真正按照SOA的思想和模型來建構整個企業的IT架構的案例是非常之少的。許多國外廠商的宣傳案例，基本上是停留在部署應用伺服器，開發了部分WebService元件，可以實作部分資料內建，這個層次而已，而這些WebService是部署在ESB平台之上的，就已經很不錯了。實作了服務流程重組，實作SOA治理的案例就更是很少見到了。
架構方法論
許多企業的IT系統“孤島”現象嚴重，本質上是缺乏足夠有效的整體規劃或者架構規劃造成的。形象地說，建構企業IT大廈如同我們蓋房子是一樣的道理。我們許多企業建設資訊系統時就采用了蓋鄉村民宅的做法。蓋鄉村民宅不需要嚴謹的規劃，也沒有複雜的地下設施建設（如自來水供水、排水、供氣、地下停車場等），也沒有需要建設污水處理、雨水收集等複雜的配套設施。而事實上，企業IT系統建設應該如城市建設，首先需要城市總體規劃，然後根據功能區規劃，設計和建設小區配套設施，“三通一平”實質就是建構建築之間的公共基礎設施，確定每棟建築之間不是“孤島”，然後每棟建築還需詳細的設計和工程施工。如果要消除資訊孤島，實作IT與業務的一緻性，也需要有效的企業架構規劃和設計。
SOA代表着一種面向服務的IT架構風格，SOA的技術本質和出發點，在于IT架構。而IT架構，是組織的企業架構的重要組成部分，它群組織的戰略架構、業務架構一起，形成一個自上而下、緊密聯系、相輔相成的有機整體。SOA代表着一種正在蓬勃興起的革命性IT架構理念，和傳統技術體系差別的關鍵特征之一就在于SOA是戰略導向和業務驅動的。而國際和國内的各方面經驗都告訴我們，對于一個組織而言，捕獲戰略、梳理業務和IT的最有效的措施就是架構。
企業架構(Enterprise Architecture，EA)，是從多個角度對組織的構件層次描述的規劃藍圖，從各個層面反映組織的願景、戰略、業務、服務、人員、技術和産品及其互相之間的關系，輔以其管控和演進的規則。
一個企業架構内容包括業務架構（Business Architecture）、應用架構（Application Architecture）、資訊架構（Information Architecture）、技術架構（Technology Architecture）等。
真正可以落地的SOA建設，必須且隻能從架構出發。沒有架構，"SOA"将變成一盤無法真正解決各種營運問題的技術和産品的大雜燴。優良的架構填補了業務需求與實際資訊系統以及基礎設施設計之間難以逾越的鴻溝。
基于服務的應用系統的本質特征是松耦合，以基本業務功能（服務封裝）為系統的基本實作單元，然後通過服務編排（流程管理）來“組裝”業務應用系統。相對于以往的應用系統，是面向技術元件，由系統程式實作業務流程，在複用、耦合方面都存在靈活性問題。
基于SOA的應用建構過程
服務模組化是第一步，也就是服務識别和顆粒度确定。服務識别是方法論的第一步，服務識别的主要任務，是确定在一定範圍内（通常是企業範圍，或若幹業務場景範圍 内）可能成為服務的候選者清單，并确定服務的顆粒度，以及辨別服務的接口。服務模組化也就确定了應用系統架構的耦合程度。
服務封裝階段的主要任務是對服務進行規範性的描述，其中包括輸入/輸出消息等功能性屬性，以及服務在業務層面的諸多屬性。并決定服務以何種形式向外提供服務。服務可能是新開發的業務功能和業務對象的封裝，也可能是遺留系統的服務封裝，将遺留系統的軟體資産以服務的形式進行封裝，在新的架構上利用已有的資産。
服務治理就是将已經封裝好的服務進行集中統一有效的管理。通過ESB基礎設施，提供服務注冊、存儲、安全控制和版本管理等。服務注冊階段的主要任務是将服務注冊到服務庫。此時需要決定服務的命名、安全、性能、時間特性。
服務編排就是根據業務流程的需求，對服務進行組合群組裝。服務組裝是以實作業務流程為目的，通過對業務服務的組合群組裝，實作更粗粒度的業務服務，實作最終的業務需求。
應用傳遞階段主要任務是完成業務系統服務化組裝和服務部署，實作業務按需傳遞。
基于SOA的應用系統是SOA架構的重要組成部分，也是SOA落地的地基。
SOA架構和微服務架構的差別
SOA和微服務架構一個層面的東西，而ESB和微服務網關是一個層面的東西，一個談到是架構風格和方法，一個談的是實作工具或元件。
1.SOA（Service Oriented Architecture）“面向服務的架構”:他是一種設計方法，其中包含多個服務， 服務之間通過互相依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在與作業系統程序中。各個服務之間 通過網絡調用。
2.微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運作的小應用。這些小應用之間通過服務完成互動和內建。
微服務架構 = 80%的SOA服務架構思想 + 100%的元件化架構思想 + 80%的領域模組化思想
SOA架構特點：
1.系統內建：站在系統的角度，解決企業系統間的通信問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些産品，比如 ESB、以及技術規範、服務管理規範； 這一步解決的核心問題是【有序】
2.系統的服務化：站在功能的角度，把業務邏輯抽象成 可複用、可組裝的服務，通過服務的編排實作業務的 快速再生，目的：把原先固有的業務功能轉變為通用 的業務服務，實作業務邏輯的快速複用；這一步解決 的核心問題是【複用】
3.業務的服務化：站在企業的角度，把企業職能抽象成 可複用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】
4.微服務架構特點：
1.通過服務實作元件化
開發者不再需要協調其它服務部署對本服務的影響。
2.按業務能力來劃分服務和開發團隊
開發者可以自由選擇開發技術，提供 API 服務
3.去中心化
每個微服務有自己私有的資料庫持久化業務資料
每個微服務隻能通路自己的資料庫，而不能通路其它服務的資料庫
某些業務場景下，需要在一個事務中更新多個資料庫。這種情況也不能直接通路其它微服務的資料庫，而是通過對于微服務進行操作。
資料的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的資料庫技術（SQL、NoSQL等）。在複雜的業務場景下，如果包含多個微服務，通常在用戶端或者中間層（網關）處理。
4.基礎設施自動化（devops、自動化部署）的Java EE部署架構，通過展現層打包WARs，業務層劃分到JARs最後部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何伺服器和資料模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運作在自己的程序中，通過輕量的通訊機制聯系，經常是基于HTTP資源API，這些服務基于業務能力建構，能實作集中化管理（因為服務太多啦，不集中管理就無法DevOps啦）。
