J2EE三層 Web層, 業務邏輯層, 資料存取層。對應職能團隊分為UI互動研發團推，後端服務研發團隊，DBA團隊。
應用伺服器提供物件關係對映服務，資料持久服務，事物服務，安全服務和訊息服務等。


SOA特點：
1. 良好的對外介面，通過網路協議對外提供服務。服務之間鬆耦合。
2. 單個服務發生改變，不影響整個流程。只要介面不變，對外是透明的。
3. 通訊格式XML，後來被JSON取代。
4. 服務的可重用性。
5. SOA可以最大化使用內部和外部的公共服務。


SOA實現方式：Web Service和 ESB。
ESB：
1. 監控和控制服務之間的訊息路由。
2. 控制可插拔的服務化。
3. 解析服務之間通訊的內容和格式。
4. 統一編排資訊處理流程。
5. 冗餘備份。

Web Service的問題
1. 依賴中心化的服務發現機制。
2. SOAP使用XML冗餘大。
3. 服務化管理和治理設施不完善。


微服務，分為多個獨立開發，可配置，可執行可維護的自服務，使用RESTful的API通訊。


微服務真正目的是通過水平擴充套件解決傳統單體應用業務增長遇到的問題，拆分後人員和專案責任單一，低耦合，高內聚。
1. 職責單一的功能放在一個獨立的服務。
2. 每個服務執行在單獨的程序中
3. 每個服務有多個例項執行。執行在容器化的平臺，可以平滑伸縮。
4. 每個服務有自己的資料儲存。獨立的資料，快取，訊息佇列等。
5. 每個服務有獨立的運營平臺。每個服務高度自治，內部變化對外透明。
6. 每個服務可以根據效能獨立地水平伸縮。


單體應用的特點：
1. 所有模組混合執行在同一個JVM程序中。
2. 可以對多個模組的整體水平擴充套件，無法對某個模組水平擴充套件。
3. 某個模組發生變化，所有模組需要編譯打包上線。
4. 模組簡單依賴不清晰，相互耦合。


微服務架構和SOA一脈相承，也略有不同。
1. 目的不同。SOA強調異構服務之間協作和整合。微服務目的是拆分，實現敏捷開發部署。
2. 部署方式不同。拆分成多個小服務，使用敏捷擴容，Docker實現自動化容器管理。SOA服務將多個服務打包在一起，部署在一個伺服器上。
3. 服務粒度不同。微服務拆分粒度更細，職責單一。通過服務組合實現業務流程。SOA對粒度沒有要求，通常是粗粒度的。


微服務核心要點：
1. 職能團隊的劃分
2. 微服務的去中心化治理
3. 微服務的互動模式。讀者容錯模式（介面改變的容錯），消費者驅動契約模式，去資料共享模式（不允許共享資料來整合多個服務）。
4. 微服務的分解和組合模式。拆分達到高內聚低耦合。靈活組裝來滿足各種業務需求。組合方式有：服務代理模式（典型的案例：平滑的系統遷移），服務聚合模式，服務串聯模式，服務分支模式，服務非同步訊息模式，服務共享資料模式（反模式，用於單元化架構和遺留的整體服務）
5. 微服務的容錯模式。 艙壁隔離模式（微服務容器分組和執行緒池隔離），熔斷模式，限流模式（計數器，令牌桶，訊號量），失效轉移模式（快速失敗，切換到備份，重試）
6. 微服務的粒度。微服務初衷職責單一拆到不可再拆。原則是可以合理排版底層的自服務來獲得相應的組合服務，同時考慮團隊人員分配。


共享資料整合的缺點：
1. 服務之間除了介面契約，還有資料儲存契約。
2. 上游資料格式變化，導致下游出問題。
3. 多個服務共享一個資源，資源的運維和職責不清。
4. 多機房部署，考慮到路由，跨機房呼叫，難以實現服務自治。



Spring Cloud Netflix 包括服務發現元件Eureka，容錯性元件Hystrix，智慧路由元件Zuul和客戶端負載均衡元件Ribbon
1. 服務在Eureka例項中註冊，有Spring管理髮現和呼叫
2. 通過配置啟動Eureka伺服器
3. Feign客戶端通過宣告的方式即可匯入服務代理
4. Zuul使用Ribbon服務實現客戶端的負載均衡
5. 通過宣告的方式即可插入Hystrix的客戶端。
6. 通過配置的方式可以啟動Hystrix面板伺服器。
7. Spring下可以直接配置Netflix元件。
8. Zuul可以自動註冊過濾器和路由器，形成一個反響代理伺服器。

9. Hystrix面板可以對服務的狀態監控，並提供容錯機制。