阿里巴巴服務化架構演進
單一應用架構
All In One
- 整個網站幾個應用
- 前臺 web + 後臺 ops + tasks
- 業務 web + service/dao 各自開發
- 一起集成發佈
技術戰：Webx、Spring Ibatis、Jboss、Oracle
存在的問題：合併時經常代碼衝突、發佈相互制約效率低下、應用代碼龐大臃腫維護困難。
垂直應用架構
按應用拆分
Service / DAO / Impl 都以二方庫 jar 包的形式提供出去
- 代碼拆分，獨立部署，流程隔離，技術棧沒有太大變化
- 應用相互之間直接依賴二方庫
問題：
- 升級困難，要全網推動
- 數據庫連接池壓力大
分佈式服務架構
API 與實現分離
- 使用 RPC 進行通信，服務端升級方便
- 各種服務中心出現，會員中心，商品中心，交易中心等
技術棧：
- Ali-tomcat
- Pandora
- Dubbo
- HSF
存在的問題：
- 依賴衝突
- 中間件升級困難
- 應用配置服務
- 應用開發效率低下
微服務架構
擁抱微服務，提升開發體驗和效率
- 應用更輕量、開發更簡單
- 配置
- 編碼
- 開發
- 調試
- 部署
技術棧：
- Pandora Boot
- Spring Boot
容器隔離Pandora
爲什麼需要隔離？
Pandora的容器架構如下：
Pandora 結構與部署形式：
- 與應用 tgz 包部署在一起
- 應用可單獨升級 pandora.sar
- 應用容器識別 –Dpandora.location，便於本地開發
現有架構的不足：
- pandora 使用方式新人難理解，本地開發麻煩，需要配置 JVM 參數或藉助 IDE
- mvn 依賴與 pandora 實際運行版本不一致導致調試時行號對不上，或源碼找不到
- pandora.sar 全家桶用戶無法按需選擇，應用啓動慢
- 新應用創建時多爲複製老應用，遺留問題始終得不到清理解決，形成惡性循環
- 啓動腳本、自檢、dockerfile 配置、上線流程複雜繁瑣
- 應用狀態不透明，容器及中間件狀態是黑盒
微服務框架 Pandora Boot
微服務運維及診斷
未來發展方向
- Spring Boot 2.0
- JDK9 Jigsaw
- Serverless/RxJava
聲明：本號所有文章除特殊註明，都爲原創，公衆號讀者擁有優先閱讀權，未經作者本人允許不得轉載，否則追究侵權責任。
關注我的公衆號，後臺回覆【JAVAPDF】獲取200頁面試題！
5萬人關注的大數據成神之路，不來了解一下嗎？
5萬人關注的大數據成神之路，真的不來了解一下嗎？
5萬人關注的大數據成神之路，確定真的不來了解一下嗎？
