1、系統(tǒng)架構概述,了解什么是架構 了解Alibaba網(wǎng)站架構的歷史 掌握Alibaba網(wǎng)站架構的現(xiàn)狀 掌握網(wǎng)站架構設計的理念,課程目標和內容,架構規(guī)定了軟件的高層劃分及各部分間的交互 架構不是軟件，但架構決策體現(xiàn)于軟件平臺和框架之中 架構的優(yōu)劣決定了業(yè)務應用系統(tǒng)的實施能力和發(fā)展空間 技術搭臺，業(yè)務唱戲 架構搭臺，應用唱戲 架構永遠在隨著業(yè)務的發(fā)展而變遷 擁抱變化！,什么是架構？,B2B架構演化過程,1999 史前,2001 石器時代,2002 中世紀,2005 工業(yè)革命,未來 星際時代？,Perl,WebMacro pojo jdbc,Velocity Ejb,WebX Spring,SOA OP

2、EN API 云計算 ,Perl，CGI Mysql Apache 服務器在美國，56KModem，遠程開發(fā)、測試、部署,1999-史前時代,Java服務器使用線程性能比cgi技術使用進程好 Java相比Perl，可維護性好，開發(fā)效率高 Java開始在國內流行,史前-石器時代原因,開始使用Java 模板技術采用WebMacro 中間層采用Servlet技術，使用POJO封裝業(yè)務邏輯和數(shù)據(jù)訪問 使用BizObj對象封裝基本業(yè)務邏輯和數(shù)據(jù)訪問方法 其它業(yè)務對象繼承BizObj方法，實現(xiàn)自己的業(yè)務邏輯和數(shù)據(jù)訪問方法 使用JDBC訪問數(shù)據(jù)庫 Servlet容器使用resin，Web服務器使用Apach

3、e,2001底-石器時代-www系統(tǒng),2001底-石器時代(續(xù)),基于POJO的biz層,基于WebMacro的模板技術,表現(xiàn)層,業(yè)務層,Oracle數(shù)據(jù)庫,LDAP,數(shù)據(jù)存儲,表現(xiàn)層僅僅使用模板技術，缺乏MVC框架，導致大量的servlet配置 業(yè)務邏輯層和數(shù)據(jù)訪問層耦合，可維護性和可擴展性差 受到EJB風潮的影響,石器時代-中世紀原因,表現(xiàn)層采用WebX 模板技術Velocity 在Turbine基礎上開發(fā)了自己的服務框架和一系列公共服務 通過一個delegate對象訪問業(yè)務邏輯層 業(yè)務邏輯層使用EJB（SLSB，CMP，DAO等） 通過一個faade對象供表現(xiàn)層delegate訪問 Fa

4、ade對象訪問多個SLSB實現(xiàn)的controller對象實現(xiàn)業(yè)務邏輯 使用CMP實現(xiàn)單條記錄的增加和刪除 考慮性能，在CMP之外封裝DAO對象通過JDBC訪問數(shù)據(jù)庫 EJB服務器使用Weblogic Web服務器使用Apache,2002底-中世紀,2002底-中世紀（續(xù)）,搜索引擎,Oracle數(shù)據(jù)庫,LDAP,使用SLSB實現(xiàn)的業(yè)務邏輯對象Controlers,基于Webx以及Service框架的Web層框架,CMP進行單條記錄的增加刪除，DAO對象查找,表現(xiàn)層,商業(yè)邏輯層,數(shù)據(jù)訪問層,數(shù)據(jù)存儲,delegate,Faade,Turbine的發(fā)展緩慢 EJB配置復雜,可維護性差 重量級框架

5、，業(yè)務侵入高 高度容器依賴，可測試性差 CMP性能差，導致DAO和CMP并存,中世紀-工業(yè)革命原因,表現(xiàn)層使用WebX和Service 框架 Velocity模板技術 自有服務框架及多種公共服務：Form Service，Template Service，Mail Service，Rundata Service，Upload Service等 通過command模式和biz層交互 無狀態(tài)Web應用，基于cookie實現(xiàn)session，獲取線性擴展性 業(yè)務邏輯層使用Alibaba Service框架，并且引入spring 框架 Spring容器和Alibaba Service框架無縫集成 AO，

6、BO 使用分布式cache緩存對象 數(shù)據(jù)訪問層 透明的事務處理 引入Hibernate和iBatis，以iBatis為主,2005-工業(yè)革命,2005-工業(yè)革命（續(xù)）,搜索引擎,Oracle數(shù)據(jù)庫,LDAP,基于Spring以及Service框架的biz層框架,基于Webx以及Service框架的Web層框架,分布式 Cache,分布式 Session,基于Spring以及DAO設計模式的數(shù)據(jù)訪問框架,表現(xiàn)層,商業(yè)邏輯層,數(shù)據(jù)訪問層,數(shù)據(jù)存儲,數(shù)據(jù)庫成為瓶頸 - 分布式數(shù)據(jù)庫 應用耦合嚴重 - SOA Pampas平臺,演化還在繼續(xù),中文站會員數(shù)超過2000萬 中文站Offer已經(jīng)超過1.5億

7、 中文站每天的用戶PV已經(jīng)超過1.6億 中文站每天新發(fā)Offer超過100萬 中文站每天重發(fā)Offer超過1500萬 國際站略少，但是增長迅猛,網(wǎng)站的現(xiàn)在,中文站/國際站應用部署圖,網(wǎng)站鏡像部署圖(國際站),中供用戶,網(wǎng)站運營,海外賣家,Load Balance (F5, Alteon),Apache,Jboss,Database,Search Engine,Apache,Jboss,Apache,Jboss,Apache,Static Resource,Cache,Storage,用戶請求處理,流量隨著用戶量而增加 業(yè)務的變更頻繁 用戶行為的收集 產(chǎn)品角色的細分及調整 7 X 24的高可用性

8、,互聯(lián)網(wǎng)的挑戰(zhàn),流量激增,處理用戶請求,應對的挑戰(zhàn),并發(fā)(垂直) 用戶數(shù)量的增加 使用資源的增加 響應(水平) 處理性能的維持,業(yè)務變更,專業(yè)化細分之前,專業(yè)化細分之后,數(shù)據(jù)挖掘,行為數(shù)據(jù)的采集 追蹤埋點 異步收集 采集數(shù)據(jù)的分析 數(shù)據(jù)倉庫 分析引擎 運營團隊決策 風險行為的控制 CTU系統(tǒng) 安全團隊,網(wǎng)站產(chǎn)品的生命周期,團隊再細分,角色專業(yè)化細分,避免宕機 集群化 服務化 備份切換 維護時間有限 新產(chǎn)品發(fā)布 在線發(fā)布 疊加式發(fā)布 用戶透明過渡,高可用性,架構是平衡的藝術 不要把簡單問題復雜化，也不要把復雜問題簡單化 系統(tǒng)架構需要考慮哪些業(yè)務要求和質量指標？ 怎樣取得平衡？ 分解復雜度 自上而

9、下，分離關注點（總體系統(tǒng)局部） 分配復雜度 用合適的技術、合適的組織來解決問題,架構設計理念,架構的考慮要點,架構考慮的方向,總體架構 分解：按不同的業(yè)務領域、用戶群來分解業(yè)務復雜性 分配：將業(yè)務需求分配到各個公司、部門、系統(tǒng)、服務 系統(tǒng)/服務可獨立部署和維護，它們之間多采用分布式交互,業(yè)務劃分(總體架構),業(yè)務劃分(總體架構),系統(tǒng)架構,系統(tǒng)架構 分解：按不同的技術層次來分解技術復雜性 分配：將技術需求分配到各個中間件、容器、框架、工具組件 容器/框架通過特定的技術模式來透明或半透明地解決技術問題,系統(tǒng)細分,應用優(yōu)化,局部調優(yōu)（數(shù)據(jù)存取） 分解：按數(shù)據(jù)的位置、讀寫、計算特性等分解數(shù)據(jù)存取復雜性 分配：將數(shù)據(jù)分配到各個數(shù)據(jù)庫、索引庫、存儲系統(tǒng)、Cache 不同的存儲技術適合于不同