阿里巴巴微服務架構演進

阿里巴巴服務化架構演進

單一應用架構

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萬人關注的大數據成神之路，肯定真的不來了解一下嗎？

歡迎您關注《大數據成神之路》