1、1“大型”網站技術架構探討2目錄大型網站架構的目標與挑戰網站架構演變及其技術脈絡架構設計理論與原則討論及總結3大型網站架構的目標與挑戰何謂“大型”網站？網站日均流量IP/PVIP 5,972,587 PV 9,376,IP229,680,000 PV2,955,981,IP25,680,000 PV222,132,IP5,532,000 PV25,723,IP300,000 PV747,000沒有統一的判斷標準，流量大小是一個重要指標日均流量至少IP1,000,000才算大型網站4大型網站架構的目標與挑戰何謂“大型”網站？網站內容是否“動態”才是關鍵5大型網站架構的目標與挑戰 移動APP的幾個

2、重要指標網站內容是否“動態”才是關鍵6大型網站架構的目標與挑戰網站架構目標與挑戰 每個目標背后面臨著技術、設計、維護等諸多方面的挑戰。 而目標本身的期望值也會根據實際情況進行調整，這也意味著網站架構建設是個不斷調整的過程。負載均衡數據備份異地容災。高速緩存并行計算異地鏡像。開發框架多層設計業務分割。7大型網站架構的目標與挑戰網站架構演變及其技術脈絡架構設計理論與原則討論及總結8網站架構演變及其技術脈絡Step1Web動靜態資源分離及其與DB物理分離n優點：“簡單”、安全性提高n缺點：存在單點，談不上高可用性（high availability架構目標）n技術點：應用設計要保證可擴展（frame

3、work很重要Spring/Beetle）、Web Server動/靜態資源分離Web Server（ApacheNginxIISJBoss）、Database Server（MysqlOracleRedis）9Step1技術點Web動靜態資源分離img,doc,js,css等靜態資源使用單獨的Web HTTP Server處理請求動態頁面靜態化處理網站架構演變及其技術脈絡10Step2采取緩存處理n優點：簡單有效、維護方便n缺點：依然存在單點n技術點：客戶端（瀏覽器）緩存、前端頁面緩存、頁面片段緩存、本地數據緩存/數據庫緩存網站架構演變及其技術脈絡減少對網站的訪問減少對Web應用服務器的請求

4、減少對數據庫的查詢減少文件系統I/O操作11Step2技術點客戶端（瀏覽器）緩存技術點說明根據HTTP協議特性，修改Header參數（Cache-Control、Expires、Pragma、Last-Modified、Etag），讓瀏覽器來緩存頁面（一些優秀開發框架會對此做透明的封裝，例如：Beetle）/Protocols/rfc2616/rfc2616-sec14.html使用HTTP1.1協議，由于http pipelining技術特性，能夠使用get請求的決不采取post請求為了節約帶寬，壓縮頁面（Content-Encoding: gzip）；頁面各

5、個元素能“小”即“小”，例如：js包壓縮，js合并，圖片壓縮等會話狀態信息采取Cookie代替傳統使用服務器Sessions對象存儲習慣做法；使用Ajax實現頁面局部刷新如果可能，可采取瀏覽器插件技術突破瀏覽器功能限制，將原本在服務器端運算，盡量遷到瀏覽器端。ActiveX/Applet/Flash/.HTML5 最值得期待，她的出現必定改變整個Web世界能夠讓瀏覽器緩存的數據一定要緩存；瀏覽器能夠處理的運算，決不放在服務器端來處理。網站架構演變及其技術脈絡12Step2技術點前端頁面緩存采用具備緩存功能的http反向代理服務器作前端頁面緩存器，VarnishSquidNcacheAiCach

6、e(商業)【硬件F5】網站架構演變及其技術脈絡13Step2技術點頁面片段緩存ESI(Edge Side Includes)ESI需要服務器端支持，常見apache(mod_esi)、WebLogic、JSP標簽庫(JESI)等。網站架構演變及其技術脈絡14Step2技術點本地數據緩存需要從數據庫系統和Web應用服務器兩個層面考慮緩存優化網站架構演變及其技術脈絡技術點說明關系數據庫系統（如：OracleMySql）Query Cache策略：一般以sql為key來緩存查詢結果，盡量不要拼sql，使用PreparedStatement的“？”模式sql；Query Cache大小要根據數據庫系統

7、具體情況合理設置，過大只會浪費內存，參考值：128M關系數據庫系統Data Buffer策略：就是數據庫數據內存緩存器，其訪問命中率決定數據庫性能，可根據實際物理內存大小適量增大，如：MySql建議buffer值為物理內存60-80%應用服務器Cache包括：對象緩存（例如：對象線程安全，做成單例），更新頻率不大數據考慮緩存（如：基表數據、配置文件信息），考慮使用線程池，對象池，連接池等常見java解決方案：mapOSCacheEHCache等15Step3增加機器做HA、數據庫讀寫分離網站架構演變及其技術脈絡n優點：增加服務器和HA機制，系統性能及可用性得到保證n缺點：讀寫分離，增加程序難度

8、，架構變復雜，維護難度增加n技術點：負載均衡、DAL、數據庫讀寫分離16Step3技術點負載均衡網站架構演變及其技術脈絡類型說明DNS負載均衡實現簡單、有Cache缺乏靈活性，但對分區域（如構建CDN方案）訪問簡單有效反向代理軟件HAProxy、Nginx、Apache、Lighttpd等硬件產品F5、NetScaler等LVS(Linux Virtual Server)/SMART Client自己寫代碼某些情況下簡單有效17Step3技術點數據庫讀寫分離及DAL網站架構演變及其技術脈絡讀寫分離邏輯分批負載均衡失效轉移（fail

9、over）數據庫分區透明支持兩大實現模式：獨立Proxy服務器；單獨API庫文件各個數據庫廠商都有自己復制方案常見通用方案：ETL、GoldenGateTJS18Step4CDN、分布式緩存、分庫網站架構演變及其技術脈絡n優點：異地緩存有效解決不同地方用戶訪問過慢的問題；分庫策略帶來網站性能整體提升n缺點：成本大幅增加，架構進一步復雜化，也維護難度進一步增大，架構開始臃腫了n技術點：CDN、分布式緩存、Shard分庫19Step4技術點CDN網站架構演變及其技術脈絡nCDN(Content Delivery Network)內容分發網絡n將網站的內容分發到最接近用戶的網絡“邊緣”，使用戶可以就

10、近獲取，從而解決互聯網網絡擁擠的狀況，提高用戶訪問的響應速度。n適合靜態內容很多（如：靜態頁面、圖片、視頻等）及頁面內容實時性要求不高的網站，如：新聞類門戶網站nCDN構建可以做的很簡單，也可以很復雜，主要根據自己網站實際情況而定20Step4技術點分布式緩存網站架構演變及其技術脈絡n本地緩存性能優秀，但容量有限，無伸縮性n采用分布式緩存方案突破容量限制，具備良好伸縮性；但分布式涉及遠程網絡通信消耗其性能本地緩存來得優秀，并可涉及節點狀態維護及數據復制問題，其穩定性和可靠性是個挑戰。n目前流行分布式緩存方案：memcached、membase、redis等，基本上當前的NoSQL方案都可以用來

11、做分布式緩存方案21Step4技術點分庫網站架構演變及其技術脈絡n讀寫分離（簡單有效，前面已介紹）n垂直分區良好的松耦合的模塊化設計是垂直分庫的前提22Step4技術點分庫網站架構演變及其技術脈絡n水平分區（Shard）分片Key識別（劃分檢索依據）是關鍵是否還有其它招？用NoSql數據庫部分替換關系數據庫23Step5多個數據中心，向分布式存儲和計算的架構體系邁進網站架構演變及其技術脈絡n優點：多數據中心，帶來更高質量區域服務體驗；分布式存儲及計算架構有效解決pb級數據量存儲、檢索及計算性能問題n缺點：架構復雜、數據同步、一致性及系統維護、技能要求等成本十分高n技術點：分布式文件系統、Map

12、/Reduce、Key-Value存儲24Step5技術點向分布式存儲計算解決方案DFS、Map/Reduce、Key-Value DB網站架構演變及其技術脈絡nDFS分布式文件系統，如：LustreHDFSGFSTFSFreeNas等nMap/Reduce算法（計算框架），基本上現有NoSQL數據庫中都支持此算法。nKey-Value DB，也作為NoSQL解決方案，如：BigTableTairHbase HyperTable等n提供完整解決方案： Google(GFS|Map/Reduce|BigTable) Apache Hadoop(HDFS|Map/Reduce|HBase) 25凡

13、客關鍵系統架構凡客關鍵系統架構26 訂單面臨的矛盾 數據量倍增響應效率還要更高電子商務訂單處理優化分析訂單查詢服務內存硬盤空間索引應用服務器傳統解決方案不能根本上解決問題27熱數據DB(SQL Server，NoSQL)冷數據DB(SQL Server，NoSQL)路由服務6個月以上到終結點的冷數據新增熱數據2013年訂單工作規劃第一個重點項目解決方案：訂單數據冷熱分離查詢訂單入口讀新建修改訂單入口寫Hadoop(Hadoop(提供數據分析用提供數據分析用) )28基于消息隊列的訂單處理機制訂單處理流程的現有機制訂單處理流程的改進方案探討29訂單處理流程的現有機制前臺主庫后臺主庫后臺只讀按頻率

14、讀串行寫讀數據寫數據串行寫按頻率讀大量數據寫入串行寫分發復制創建訂單服務及應用1N訂單同步服務*4訂單支付服務*4訂單取消服務*2訂單轉有效服務*3訂單攔截服務*2下游系統抓取服務按頻率讀現有處理現有處理流程存在流程存在問題問題30訂單處理流程的現有機制WHY？WHAT？WHERE？The Problems流程流程存在存在問題剖析問題剖析HOW can we solve these problems?31基于消息隊列的訂單處理機制訂單處理流程的現有機制訂單處理流程的改進方案探討32訂單處理流程的改進方案使用WCF服務，數據改抓為推；構建基礎模塊，解耦調用方式。保留windows服務，降低查詢頻

15、率，查缺補漏，處理失敗、異常等情況。使用消息隊列，解耦服務依賴，試點驗證，選擇合適的消息隊列。緩存中間數據，減少數據更新，分析業務要求，差別對待一致性。業務業務驅動驅動糾錯糾錯機制機制通信通信機制機制緩存緩存數據數據Required!Better?解決解決方案方案訂單業務的處理是以使用訂單業務的處理是以使用windows服務服務從數據庫從數據庫抓取數據抓取數據的方式的方式驅動驅動根本根本原因原因33訂單處理流程的改進方案1.1 使用WCF服務，數據由抓改推Step Step 1 1業務流的服務接口業務流的服務接口實現實現主要任務主要任務風險風險訂單同步服務訂單轉有效服務訂單攔截服務下游業務方服

16、務訂單新建服務支付同步服務支付請求服務完成原windows服務中業務邏輯的wcf封裝各服務按照業務流程組裝起來服務調用失敗，造成的控制流中斷34訂單處理流程的改進方案基礎模塊基礎模塊解決方案解決方案主要任務主要任務風險風險完成基礎模塊開發，達到解耦服務調用方式的目的異步調用服務異常時，線程資源的緊缺造成消費方服務阻塞大量發生異常時的控制，放棄調用，保證消費方的線程資源；使用消息隊列Factoryvoid Notify(Action del)（統一的事件觸發）（統一的事件觸發） Handler1（如異步（如異步直接調用）直接調用） Handler2（如寫入（如寫入消息隊列）消息隊列）1.2 構建

17、基礎模塊，解耦調用方式Step Step 1 135訂單處理流程的改進方案2 保留windows服務，查缺補漏Step Step 2 2業務流某節點故障？業務流某節點故障？原有原有WindowsWindows服務服務訂單同步服務訂單轉有效服務訂單攔截服務下游業務方服務訂單新建服務支付同步服務支付請求服務保留windows服務，以較低頻率運行，查詢長時間未處理的數據處理完成后，同樣采用調用服務推送的方式，接續處理流程設置閾值，結合VIMOP監控各處理流程節點長時間未處理數據數據庫36訂單處理流程的改進方案3.1 使用使用消息隊列消息隊列，解耦服務依賴，解耦服務依賴Step 3Step 3服務消費

18、方消息隊列服務提供方天生的異步處理機制存儲轉發，消息先寫入本地機器，穩定性高消息寫與消息同步的資源隔離優點 消息一定能通知到一條消息只通知一次低延遲目標目標問題問題 Queue的選擇？MSMQ是否能勝任？消息的丟失，延遲的容忍度？使用開源Queue，可控性更強37訂單處理流程的改進方案3.2 使用使用MSMQ，試點驗證可行性，試點驗證可行性Step 3Step 3幾種幾種Q的處理能力的處理能力使用MSMQ應用于錯誤容忍度相對較高的場景做試點（例如：訂單攔截服務） 驗證MSMQ的處理能力 （weblog的經驗，達到 1000W/天的 消息處理量 ）驗證MSMQ的消息丟失率驗證MSMQ的延遲使用使

19、用MSMQ驗證驗證38消息隊列選擇3.3 MSMQ不可行，嘗試使用不可行，嘗試使用MetaQStep Step 3 3開源開源MetaQ高吞吐量、高可用性、適合大規模分布式系統應用設計初衷：為大規模互聯網應用設計的消息中間件公開的性能測試結果https:/ 緩存緩存中間數據，減少數據庫更新中間數據，減少數據庫更新訂單同步服務訂單攔截服務訂單轉有效服務Memcache服務器后臺主庫技術難點技術難點： 不同業務要求下，數據一致性的控制Step 4Step 440訂單處理流程的改進方案解決方案整體拓撲圖后臺主庫Memcache服務器訂單同步服務消息隊列集群訂單轉有效服務消息隊列集群訂單攔截服務前臺主

20、庫后臺主庫后臺只讀按頻率讀串行寫串行寫按頻率讀大量數據寫入串行寫分發復制創建訂單服務及應用1N訂單同步服務*4訂單支付服務*4訂單取消服務*2訂單轉有效服務*3訂單攔截服務*2下游系統抓取服務按頻率讀改進前改進前改進后改進后現有處理流程現有處理流程New41訂單處理流程的改進方案緩存與數據庫完全一致性轉有效服務攔截服務支付服務取消服務占可定緩存與數據庫最終一致性4.2 分析業務要求，差別對待一致性Step 4Step 4MemcacheSQL ServerService1.Gets(key)2.Update3.Sets(key)MemcacheSQL ServerService11.Gets(

21、key)5.Update2.Sets(key)Service23.Notify6.Sets(key)4.Gets(key)42基于消息隊列的訂單處理機制Hadoop集群架構數據導入方案統計分析方案43Hadoop集群架構NameNode.DataNodeDataNodeDataNodeDataNodeDataNodeDataNodeDataNode總空間：5.51 TB已使用：3.32 TB使用率：60.33%2013-2-1到現在的數據已經導入Hadoop集群44數據導入方案Hadoop集群原始文本存儲服務器SqlServer數據庫Oracle數據庫45數據導入方案具體實施方案Hadoop文

22、件存儲設計Hadoop文件歸檔服務（WCF）原始文本導入Hadoop集群服務46數據導入方案Hadoop文件存儲設計歷史數據當天數據weblog_2013_v4weblog_2013_04_25_v4設計目的：1、數據實時進入Hadoop集群，便于數據及時分析2、消除因為實時導入產生的小文件block碎片3、提高Hadoop分析效率47數據導入方案Hadoop文件歸檔服務（WCF）運用程序運用程序運用程序用途：將Hapoop集群里面的小文件合并成一個大文件Hadoop公用WCF48數據導入方案原始文本導入Hadoop集群服務導入Windows服務主服務輔助服務（監控合并文件）49數據導入方案原

23、始文本導入Hadoop集群服務導入Windows服務讀取文本日志文件數據初步分析加工Hive接口批量導入方法數據進入Hadoop集群主服務50數據導入方案原始文本導入Hadoop集群服務導入Windows服務數據初步分析加工主服務文本文件數據Hadoop數據渠道來源商品購買搜索關鍵字移動設備訪問新注冊用戶51數據導入方案原始文本導入Hadoop集群服務監控前一天文件是否全部入集群Hadoop文件歸檔服務（WCF）前一天文件合并到歷史文件輔助監控服務導入Windows服務全部入集群52數據導入方案數據流文本數據分析加工文件歸檔采集原始文本Hadoop歷史數據Hadoop當天數據53統計分析方案H

24、adoop分析愿景深度挖掘用戶特征習慣，建立用戶模型基于用戶模型，做好市場營銷推廣精準廣告投放預警，廣告價值最大化Hadoop集群54統計分析方案Hadoop分析模型凡客用戶年齡層和購物習慣模型潛在購買用戶模型商品價值效應模型Hadoop集群55統計分析方案1、凡客用戶年齡層和購物習慣模型從產品表獲取商品屬性用戶年齡層商品屬性年齡分類挖掘訪問商品的用戶信息56統計分析方案1、凡客用戶年齡層和購物習慣模型購物習慣沖動型購物理性購物挖掘長期參與各種促銷活動下單用戶挖掘用戶訪問頻率挖掘不定期參與促銷活動極少下單用戶57統計分析方案2、潛在購買用戶模型潛在購買用戶特征加入收藏夾訪問具體單品PV超過設定

25、閥值訪問單品頁時間超過設定閥值加入購物車未下單58統計分析方案3、商品價值效應模型商品價值地域月份性別年齡商品的訪問量商品加入購物車數量商品的收藏次數59統計分析方案統計入口HiveMapReduceHadoop集群95%5%60統計分析方案HiveHadoop集群Web界面Hive Web接口統計服務程序Hive Thrift服務WebLog權限和調用日志wcf服務61統計分析方案存在風險Hadoop集群Job程序無專人管理和優化Hadoop集群服務器硬盤空間需求部門臨時性數據統計需求耗費時間管理風險進度風險移動平臺數據統計分析項目遷移和開發62淘寶系統架構概述淘寶系統架構概述更強，更高，更

26、持久63 架構規定了軟件的高層劃分及各部分間的交互 架構不是軟件，但架構決策體現于軟件平臺和框架之中 架構的優劣決定了業務應用系統的實施能力和發展空間 技術搭臺，業務唱戲 架構搭臺，應用唱戲 架構永遠在隨著業務的發展而變遷 擁抱變化！什么是架構？64B2B架構演化過程1999史前2001石器時代2002中世紀2005工業革命未來星際時代？PerlWebMacropojojdbcVelocityEjbWebXSpringSOAOPEN API云計算 65 Perl，CGI Mysql Apache 服務器在美國，56KModem，遠程開發、測試、部署1999-史前時代66 Java服務器使用線程

27、性能比cgi技術使用進程好 Java相比Perl，可維護性好，開發效率高 Java開始在國內流行史前-石器時代原因67 開始使用Java 模板技術采用WebMacro 中間層采用Servlet技術，使用POJO封裝業務邏輯和數據訪問 使用BizObj對象封裝基本業務邏輯和數據訪問方法 其它業務對象繼承BizObj方法，實現自己的業務邏輯和數據訪問方法 使用JDBC訪問數據庫 Servlet容器使用resin，Web服務器使用Apache2001底-石器時代-www系統682001底-石器時代(續)基于POJO的biz層基于WebMacro的模板技術表現層業務層BizObj業務邏輯方法數據訪問方

28、法OfferObj業務邏輯方法數據訪問方法MemberObj業務邏輯方法數據訪問方法CompanyObj業務邏輯方法數據訪問方法基于pojo的Biz層Oracle數據庫LDAP數據存儲69 表現層僅僅使用模板技術，缺乏MVC框架，導致大量的servlet配置 業務邏輯層和數據訪問層耦合，可維護性和可擴展性差 受到EJB風潮的影響石器時代-中世紀原因70 表現層采用WebX 模板技術Velocity 在Turbine基礎上開發了自己的服務框架和一系列公共服務 通過一個delegate對象訪問業務邏輯層 業務邏輯層使用EJB（SLSB，CMP，DAO等） 通過一個faade對象供表現層delega

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

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

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

32、超過1.6億 中文站每天新發Offer超過100萬 中文站每天重發Offer超過1500萬 國際站略少，但是增長迅猛網站的現在77中文站/國際站應用部署圖78網站鏡像部署圖(國際站)中供用戶網站運營海外賣家79Load Balance(F5, Alteon)ApacheJbossDatabaseSearch EngineApacheJbossApacheJbossApacheStatic ResourceCacheStorage用戶請求處理 80 流量隨著用戶量而增加 業務的變更頻繁 用戶行為的收集 產品角色的細分及調整 7 X 24的高可用性互聯網的挑戰81單擊此處編輯版標題樣式單擊此處編輯

33、版標題樣式流量激增流量激增處理用戶請求RequestProcessResponseRequestProcessResponseRequestProcessResponse應對的挑戰 并發(垂直) 用戶數量的增加 使用資源的增加 響應(水平) 處理性能的維持82單擊此處編輯版標題樣式單擊此處編輯版標題樣式業務變更業務變更專業化細分之前offer list detailmember company personaltransaction no support專業化細分之后offer Clothing Retail Loanmember Trust Pass Special Markettransa

34、ction alipay paypal83數據挖掘offer repostnew offerbid 行為數據的采集追蹤埋點異步收集采集數據的分析數據倉庫分析引擎運營團隊決策風險行為的控制CTU系統安全團隊84單擊此處編輯版標題樣式單擊此處編輯版標題樣式網站產品的生命周期產品需求整理架構團隊設計開發團隊實施質量團隊質檢運營團隊運作用戶需求分析團隊再細分用戶需求分析商業策劃市場策劃 產品需求分析產品設計網站運營架構團隊架構師開發團隊程序員項目經理用戶體驗質量團隊測試流程控制運營團隊產品運營客戶服務角色專業化細分角色專業化細分85業務1業務2業務3避免宕機集群化服務化備份切換維護時間有限新產品發布在

35、線發布疊加式發布用戶透明過渡高可用性86 架構是平衡的藝術 不要把簡單問題復雜化，也不要把復雜問題簡單化 系統架構需要考慮哪些業務要求和質量指標？ 怎樣取得平衡？ 分解復雜度 自上而下，分離關注點（總體系統局部） 分配復雜度 用合適的技術、合適的組織來解決問題架構設計理念更多用戶更多數據更多功能更少硬件更少人力更少故障質量指標質量指標可用性安全性性能穩定性可維護性87分解業務應用數據合并聯動的業務高藕合的數據持續發展插件式擴展能力弱藕合,易于剝離局部可優化調整可測試穩定性高可用性負載均衡線性擴展可被監控架構的考慮要點88業務劃分系統細分應用優化架構考慮的方向89銷售后臺會員管理跟單管理財務管理

36、運營后臺Offer審批會員審批類目運營數據采集分析網站前臺用戶登錄用戶前臺用戶后臺旺鋪、廣告社區、論壇合作部門搜索引擎阿里旺旺支付寶總體架構 分解：按不同的業務領域、用戶群來分解 分配：將業務需求分配到各個 系統/服務可獨立部署和維護，它們之間多采用分布式交互業務劃分(總體架構)90會員體系運營體系業務體系業務劃分(總體架構)91系統架構表現層WebXVelocitySpring MVC業務邏輯層IOC (Spring)SOA (Pampus)EJB數據訪問層iBatisCMPJMS工具安全容錯管理監控日志Build系統架構 分解：按不同的技術層次來分解 分配：將技術需求分配到各個 容器/框架

37、通過特定的技術模式來透明或半透明地解決技術問題92網站應用系統BOPS系統資源系統系統細分93應用優化存儲系統DACSANNAS搜索引擎全文索引目錄索引數據庫索引數據復制水平分割垂直分割Cache內容靜態化數據庫緩存對象緩存客戶端緩存局部調優（數據存取） 分解：按數據的位置、讀寫、計算特性等分解 分配：將數據分配到各個 不同的存儲技術適合于不同的數據存取需求94讀寫應用優化95 總體架構 考慮面向服務體系 系統架構 更加專業化、服務化的信息收集系統 更加全面化、自動化的配置管理 更加有效率的鏡像同步、切換 局部應用優化 分布式文件系統 優化數據同步系統 讀寫分離展望未來96 架構隨著業務發展不

38、斷演進 架構發展要有方向有節奏總結97大型網站架構的目標與挑戰網站架構演變及其技術脈絡架構設計理論與原則討論及總結98架構設計理論與原則網站架構設計的精神食糧99架構設計理論與原則關于數據一致性ACID vs BASE nACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是關系型數據庫的最基本原則，遵循ACID原則強調一致性，對成本要求很高，對性能影響很大。n問題：ACID原則適用于互聯網應用嗎？可用性似乎比一致性重要些nBASE（ Basically Available 、 Soft state 、 Eventually cons

39、istent ）策略BASE策略與ACID不同，其基本思想就是通過犧牲強一致性，以獲得更好的可用性或可靠性基本可用數據能夠保證80%一致性就夠了，剩下20%就不要過于糾結了。可參考八二定律軟狀態在不過分追求數據一致性（強一致性）前提下可考慮軟狀態策略，例如把數據緩存（State）在客戶端一段時間，過后若沒有新請求的話，就清除此緩存（Soft）最終一致性在某一段短時間內允許數據不一致，但經過一段較長時間，等所有節點上數據的拷貝都整合在一起的時候，數據會最終達到完全一致100架構設計理論與原則關于分布式系統CAP理論 一致性分布式系統中，數據一般會存儲在不同節點，一致性就是要保證對數據操作的原子性

40、可用性確保客戶訪問數據時可得到響應。不強調各個節點上數據要保持一致性。分區容忍性數據分區存儲后，即使部分分區組件不可用，其施加的操作也能夠完成CAP理論指出：一個分布式系統不可能同時滿足一致性、可用性和分區容忍性這三項需求，最多只能同時滿足其中兩個。101架構設計理論與原則無共享架構（Share Nothing Architecture） 102架構設計理論與原則ED-SOA架構 nED-SOA，事件驅動，面向服務架構nSOA是系統組件化、模塊化構建性理論；ED是系統組件之間同步通信，采取事件機制異步化，提高響應速度n基于ED-SOA構建松耦合系統可以顯著改善網站可伸縮性架構進化與退化-奧卡姆

41、剃刀原理n進化尋找最適合的；退化簡化不必要的n簡單就好，慎防過渡設計103架構設計理論與原則考量成本，先硬后軟原則 104大型網站架構的目標與挑戰網站架構演變及其技術脈絡架構設計理論與原則討論及總結105討論及總結大型網站架構是怎么樣子的？ 存在萬能的架構嗎？架構本質是什么？ 網站架構如何選型？開發語言重要嗎？ 架構只是浮云？神馬才是重要的？。 106高并發高負載系統架構如何用JavaJava進行高性能網站開發107目錄1.進行高并發和高負載的研究2.高并發和高負載的約束條件3.解決之道硬件篇4.解決之道部署篇5.解決之道環境篇6.解決之道SiteEngine篇7.解決之道測試篇8.結尾108

42、為什么要進行高并發和高負載的研究1. 產品發展的需要2. 公司發展的需要3. 當前形式決定的109高并發和高負載的約束條件1、硬件2、部署3、操作系統4、Web 服務器5、PHP6、MySQL7、測試110解決之道硬件篇處理能力的提升：部署多顆CPU，選擇多核心、具備更高運算頻率、更大高速緩存的CPU；處理能力的提升最直接的反應在于Web請求的處理效率和PHP程序的執行效率。內存帶寬與容量：更大的內存帶寬和容量；內存帶寬與容量的提升最直接的反應在于應對數據庫大量的數據交換。磁盤搜索與I/O能力：選擇更高的轉速、更大的硬盤緩存、組件磁盤陣列（RAID）；磁盤搜索與I/O能力的提升最直接反應在于數

43、據庫大量的查詢和讀寫以及文件的讀寫。網絡帶寬的提升可考慮的因素包括： 更大帶寬、多線路接入、獨享帶寬；服務器在大負載的情況下，對網絡帶寬的占用是十分可觀的。策略：硬件設施是應對大負載的基礎，硬件設施的投入可根據實際壓力和預算量力而行。111解決之道部署篇1、服務器分離2、數據庫集群和庫表散列3、鏡像4、負載均衡分類：1)、DNS輪循2）代理服務器負載均衡 3）地址轉換網關負載均衡 4）NAT負載均衡 5）反向代理負載均衡 6）混合型負載均衡策略：根據硬件投入和業務需求，選擇合理的部署方案。112解決之道部署篇方案一適用范圍：靜態內容為主體的網站和應用系統；對系統安全要求較高的網站和應用系統。M

44、ain Server：主服務器承載程序的主體運行壓力，處理網站或應用系統中的動態請求；將靜態頁面推送至多個發布服務器；將附件文件推送至文件服務器；安全要求較高，以靜態為主的網站，可將服務器置于內網屏蔽外網的訪問。DB Server：數據庫服務器承載數據庫讀寫壓力；只與主服務器進行數據量交換，屏蔽外網訪問。File/Video Server：文件/視頻服務器承載系統中占用系統資源和帶寬資源較大的數據流；作為大附件的存儲和讀寫倉庫；作為視頻服務器將具備視頻自動處理能力。發布服務器組：只負責靜態頁面的發布，承載絕大多數的Web請求；通過Nginx進行負載均衡部署。113解決之道部署篇方案二適用范圍：

45、以動態交互內容為主體的網站或應用系統；負載壓力較大，且預算比較充足的網站或應用系統；Web服務器組：Web服務無主從關系，屬平行冗余設計；通過前端負載均衡設備或Nginx反向代理實現負載均衡；劃分專用文件服務器/視頻服務器有效分離輕/重總線；每臺Web服務器可通過DEC可實現連接所有數據庫，同時劃分主從。數據庫服務器組：相對均衡的承載數據庫讀寫壓力；通過數據庫物理文件的映射實現多數據庫的數據同步。共享磁盤/磁盤陣列將用于數據物理文件的統一讀寫用于大型附件的存儲倉庫通過自身物理磁盤的均衡和冗余，確保整體系統的IO效率和數據安全；方案特性：通過前端負載均衡，合理分配Web壓力；通過文件/視頻服務器

46、與常規Web服務器的分離，合理分配輕重數據流；通過數據庫服務器組，合理分配數據庫IO壓力；每臺Web服務器通常只連接一臺數據庫服務器，通過DEC的心跳檢測，可在極短時間內自動切換至冗余數據庫服務器；磁盤陣列的引入，大幅提升系統IO效率的同時，極大增強了數據安全性。114解決之道環境篇1、操作系統2、Web服務器3、Mysql4、PHP5、代理服務器（緩存服務器）115解決之道環境篇操作系統操作系統的選擇，關注點在于 是否適應于搭建SiteEngine所需要的環境程序？ 系統本身占用的資源比； 系統安全性； 系統是否易于操作？策略：我們選擇FreeBSD，而且是最小化安裝以后的FreeBSD。1

47、16解決之道環境篇Web服務器Web服務器很大一部分資源占用來自于處理Web請求，通常情況下這也就是Apache產生的壓力，Apache是世界使用排名第一的Web服務器軟件。它可以運行在幾乎所有廣泛使用的計算機平臺上。在高并發連接的情況下，Nginx是Apache服務器不錯的替代品。Nginx (“engine x”) 是俄羅斯人編寫的一款高性能的 HTTP 和反向代理服務器。在國內，已經有新浪、搜狐通行證、網易新聞、網易博客、金山逍遙網、金山愛詞霸、校內網、YUPOO相冊、豆瓣、迅雷看看等多家網站、頻道使用 Nginx 服務器。Nginx的優勢：高并發連接：官方測試能夠支撐5萬并發連接，在實

48、際生產環境中跑到23萬并發連接數。 內存消耗少：在3萬并發連接下，開啟的10個Nginx 進程才消耗150M內存（15M*10=150M）。 內置的健康檢查功能：如果 Nginx Proxy 后端的某臺 Web 服務器宕機了，不會影響前端訪問。 策略：相對于老牌的Apache，我們選擇Lighttpd和Nginx這些具有更小的資源占用率和更高的負載能力的web服務器。117解決之道環境篇MysqlMySQL本身具備了很強的負載能力，MySQL優化是一項很復雜的工作，因為這最終需要對系統優化的很好理解。大家都知道數據庫工作就是大量的、短時的查詢和讀寫，除了程序開發時需要注意建立索引、提高查詢效率

49、等軟件開發技巧之外，從硬件設施的角度影響MySQL執行效率最主要來自于磁盤搜索、磁盤IO水平、CPU周期、內存帶寬。根據服務器上的硬件和軟件條件進行MySQl優化。MySQL優化的核心在于系統資源的分配，這不等于無限制的給MySQL分配更多的資源。在MySQL配置文件中我們介紹幾個最值得關注的參數：改變索引緩沖區長度(key_buffer) 改變表長(read_buffer_size) 設定打開表的數目的最大值(table_cache) 對緩長查詢設定一個時間限制(long_query_time) 如果條件允許 ，一般MySQL服務器最好安裝在Linux操作系統中，而不是安裝在FreeBSD中

50、。策略： MySQL優化需要根據業務系統的數據庫讀寫特性和服務器硬件配置，制定不同的優化方案，并且可以根據需要部署MySQL的主從結構。118解決之道環境篇PHP1、加載盡可能少的模塊；2、如果是在windows平臺下，盡可能使用IIS或者Nginx來替代我們平常用的Apache；3、安裝加速器（都是通過緩存php代碼預編譯的結果和數據庫結果來提高php代碼的執行速度） eAcceleratoreAccelerator是一個自由開放源碼php加速器，優化和動態內容緩存，提高了性能php腳本的緩存性能，使得PHP腳本在編譯的狀態下，對服務器的開銷幾乎完全消除。ApcAlternative PHP

51、 Cache（APC）是 PHP 的一個免費公開的優化代碼緩存。它用來提供免費，公開并且強健的架構來緩存和優化 PHP 的中間代碼。memcachememcache是由Danga Interactive開發的，高性能的，分布式的內存對象緩存系統，用于在動態應用中減少數據庫負載，提升訪問速度。主要機制是通過在內存里維護一個統一的巨大的hash表，Memcache能夠用來存儲各種格式的數據，包括圖像、視頻、文件以及數據庫檢索的結果等Xcache國人開發的緩存器，策略： 為PHP安裝加速器。119解決之道環境篇代理服務器Squid Cache（簡稱為Squid）是一個流行的自由軟件（GNU通用公共許

52、可證）的代理服務器和Web緩存服務器。Squid有廣泛的用途，從作為網頁服務器的前置cache服務器緩存相關請求來提高Web服務器的速度，到為一組人共享網絡資源而緩存萬維網，域名系統和其他網絡搜索，到通過過濾流量幫助網絡安全，到局域網通過代理上網。Squid主要設計用于在Unix一類系統運行。策略：安裝Squid 反向代理服務器，能夠大幅度提高服務器效率。120解決之道環境篇總結推薦的服務器環境配置：操作系統：FreeBSD web服務器：Nginx程序語言： PHP+ Zend Optimizer+ eAccelerator數據庫： MySQL 121解決之道SiteEngine篇SiteE

53、ngine 歷史上為了解決高并發高負載做了那些工作：1、靜態化；2、緩存；3、內存表；4、定長表；5、盡可能少用join 還有IN。122解決之道SiteEngine篇SiteEngine在實施高并發高負載中出現的問題：SiteEngine在前期的發展中，一直是面向通用型的中小網站來設計的。從底層上就有不適應高并發高負載的機制存在。具體表現在：1、原有緩存功能，特別是類別的緩存無用武之地；2、無用的sql查詢和sql查詢的效率問題；3、多語言設計導致很多查詢都變得復雜，導致效率低下；4、Mysql中的查詢方法太多；5、前臺的動態交互太少。123解決之道SiteEngine篇為了讓SiteEng

54、ine更好的適應高并發高負載的環境。主要從以下幾個方面進行改進：1、加入Memcache 緩存技術；2、開發一套精簡版高效率的SiteEngine開發框架，專門應對系統開發；3、 MySQL數據庫考慮轉為innodb數據引擎；4、前臺更大量的加入Ajax元素；5、改變類別模式或者改變類別算法，取消類別緩存機制；6、成立專門的研發部門，將項目開發和軟件研發分開；7、加強測試和團隊合作。124解決之道測試篇1、測試方法2、測試用例3、壓力測試壓力測試是一種基本的質量保證行為，它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單：不是在常規條件下運行手動或自動測試，而是在計算機數 量較少或系統

55、資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內部內存、CPU 可用性、磁盤空間和網絡帶寬等。一般用并發來做壓力測試。壓力測試工具：webbench，ApacheBench等3、漏洞測試在我們的系統中漏洞主要包括：sql注入漏洞，xss跨站腳本攻擊等。安全方面還包括系統軟件，如操作系統漏洞，mysql、apache等的漏洞，一般可以通過升級來解決。漏洞測試工具：Acunetix Web Vulnerability Scanner125結尾在系統的開發過程中和項目實施過程中，大家肯定能夠得到很大程度的提升，但是要真正解決高并發和高負載的問題，并不能立竿見影，還需要大家真真正正一點一滴的去

56、了解問題，思考解決方法，不斷嘗試，不斷創新，這個過程是漫長而又艱苦的。還希望我們全體公司成員團結一致、群策群力，為實現我們的目標艱苦奮斗，去開創屬于我們大家更美好的明天。謝謝！126高并發高負載系統架構如何用JavaJava進行高性能網站開發127生成對象時，合理分配空間和大小：Java中的很多類都有它的默認的空間分配大小，對于一些有大小的對象的初始化，應該預計對象的大小，然后使用進行初始化。例如：我們在使用Vector，當聲明Vector vectnew Vector()時，系統調用：public Vector() / 缺省構造函數this(10); / 容量是 10;缺省分配10個對象大小

57、容量。當執行add方法時，可以看到具體實現為：.public synchronized boolean add(Object o) modCount+;ensureCapacityHelper(elementCount+1);elementDataelementCount+ =o;return true;Java程序性能優化程序性能優化技巧技巧128生成對象時，合理分配空間和大小：private void ensureCapacityHelper(int minCapacity) int oldCapacity = elementData.length;if (minCapacity oldC

58、apacity) Object oldData = elementData;int newCapacity = (capacityIncrement 0) ? (oldCapacity + capacityIncrement) :(oldCapacity * 2);if (newCapacity minCapacity) newCapacity = minCapacity;elementData = new ObjectnewCapacity;System.arraycopy(oldData, 0, elementData, 0, elementCount);我們可以看到，當Vector大小超

59、過原來的大小時，一些代碼的目的就是為了做容量的擴充，在預先知道該Vector大小的話，可以指定其大小，避免容量擴充的開銷。 Java程序性能優化程序性能優化技巧技巧129優化循環體：循環是比較重復運行的地方，如果循環次數很大，循環體內不好的代碼對效率的影響就會被放大而變的突出。讓我們看看下面的代碼片：.Vector vect = new Vector(1000);.for( inti=0; ivect.size(); i+).for循環部分改寫成：int size = vect.size();for( int i=0; isize; i+).如果size=1000，就可以減少1000次size

60、()的系統調用開銷，避免了循環體重復調用。Java程序性能優化技巧程序性能優化技巧130優化循環體：再看如下的代碼片：.for (int i = 0;i 100000;i+)if (i%10 = 9) . / 每十次執行一次改寫成也可以提高效率：.for(inti =0,j =10; i100000; i+,j-)if(j = 0). / 每十次執行一次j = 10;所以，當有較大的循環時，應該檢查循環內是否有效率不高的地方，尋找更優的方案加以改進。 Java程序性能優化技巧程序性能優化技巧131少用newnew初始化一個實例：盡量少用new來初始化一個類的實例，當一個對象是用new進行初始化