JEE架構
JEE將企業級軟件架構分為三個層級：Web層、業務邏輯層、數據存取層，將80%通用的與業務無關的邏輯和流程封裝在應用服務器的模塊化組件中。
遇到的問題：
- 所有模塊化組件混合運行在同一服務中
- 可對多個模塊化組件的整體JVM進程進行水平擴展，無法對某個模塊化組件水平擴展
- 某個模塊化組件上線需要對所有的模塊化組件一起上線
- 模塊依賴不清晰、互相耦合成家常便飯。
服務化架構（SOA，WebService、ESB）
為解決單體架構的瓶頸，SOA出現，，將模塊化組件進一步划分形成獨立的對外服務的網絡化組件，每個網絡化組件通過某種網絡協議對外提供服務：
- 定義良好的接口，通過網絡協議對外提供服務，松耦合，可靈活編排和組裝
- 服務內部實現改變是不影響整個流程對外提供服務
- 定義標准接口讓底層通用服務下沉，供多個上層的使用方同時使用。
- 讓企業最大化的使用內部和外部的公共服務，避免重復造輪子
WebService
使運行在不同的機器及操作系統上的服務互相發現和調用成為可能，並且通過某種協議交換數據
WebService工作原理：
- 服務提供者2和3通過UDDI協議將服務注冊到WebService目錄服務中
- 服務消費者1通過UDDI協議從WebService目錄中查詢服務，獲取服務的WSDL服務描述文件
- 服務消費者1通過WSDL語言遠程調用和消費2和3提供的服務
問題：
- 依賴中心化的服務發現機制
- 通信協議太重
- 服務化管理和治理設施並不完善
ESB
ESB企業服務總線的簡稱，是用於設計和實現網絡化服務交互和通信的軟件模型，用於企業信息化系統集成服務場景中。沒有中心化的服務節點，每個服務提供者都是通過總線的模式插入系統
ESB的核心在於企業服務總線的功能和職責：
- 監控和控制服務之間的消息路由
- 控制可插撥的服務化的功能和版本
- 解析服務之間交互和通信的內容和格式
- 通過組合服務、資源和消息處理器來統一編排業務需要的信息處理流程
- 使用冗余來提供服務備份能力
問題：
- 更多體現了系統集成的便利性，將服務組合在一起，並提供組合的業務流程服務
- 組合在ESB上的服務本身可能是一個過重的整體服務，或者是傳統的JEE服務
- ESB視圖通過總線來隱藏系統內部的復雜性，但是系統內部的復雜性仍然存在
- 對於總線本身的中心化的管理模型，系統變更影響的范圍經常會隨之擴大
微服務
可獨立開發、配置、運行和可維護的自服務，致力於松耦合和高內聚的效果，不再強調服務總線和通信機制多樣性，通過Restful的API和輕量級的消息通信協議來完成。並不是為了拆分而拆分，目的是實現水平擴展解決傳統的單體應用在業務急劇增長時遇到的問題，而且由於拆分的微服務系統中專業的人做專業事，
特點：
- 把每個職責單一的功能放到獨立服務中
- 每個服務單獨一個線程
- 每個服務多實例運行，達到平滑伸縮
- 獨立數據存儲
- 獨立運營平台
- 獨立水平伸縮
與單體架構對比
微服務架構更靈活並且可水平伸縮，讓專業人做專業事
與SOA服務化對比
目的不同
- SOA服務化范圍更廣，強調不同的異構服務間的協作和契約，強調有效集成、業務流程編排
- 微服務在於有效拆解應用，實現敏捷部署和開發，減少跨團隊溝通，讓專業人做專業事，縮小變更和迭代影響的范圍，並達到單一服務更容易水平擴展的目的
部署方式不同
- 微服務將應用拆分成多個細小的服務，部署互相獨立、互不影響
- SOA服務化通常組件化模塊方式打包在一個War包里，然后統一部署在一個應用服務器中
粒度不同
- 微服務倡導拆得更細，甚至小到不能再進行拆分
- SOA對粒度沒有要求，通常粗粒度，強調接口契約的規范化
核心要點和實現原理
- 團隊的划分方法是我們首先要考慮的一個核心要素，服務獨立UI、后台、DBA、運營和運維人員
- 去中心化治理
- 讀者容錯模式：盡最大努力獲取所需的內容
- 消費者驅動契約模式
- 提供者契約：以提供者為中心，消費者無條件遵守提供者的契約使用服務；
- 消費者契約：基於場景需求發現未明確的提供者契約；
- 消費者驅動契約：向所有當前消費者承諾遵守的約束，一旦確定不再打破。
- 去數據共享模式：交互通過定義良好的接口來實現，不允許使用共享數據來實現
- 服務間交互除了接口契約，還存在數據存儲契約
- 上游的數據格式變化時，可能導致下游的處理邏輯出現問題
- 對資源服務的運維難以划清職責和界限
- 跨機房難以服務自治
微服務粒度
拆分到可以讓使用方自由編排底層的子服務來獲取響應的組合服務即可，同時要考慮團隊的建設的數量和分配等
微服務項目層級結構
- 服務導出層
- 服務接口層
- 服務實現層