開源SaaS解決方案

Part1：IT部署視圖演化及挑戰(zhàn)Part2：動態(tài)基礎(chǔ)設(shè)施Part3：SaaS架構(gòu)關(guān)注技術(shù)Part4：Q&A第一頁，共59頁。IT系統(tǒng)部署視圖演化-1第二頁，共59頁。N輪視圖演化后架構(gòu)第三頁，共59頁。第四頁，共59頁。演化面對的挑戰(zhàn)第五頁，共59頁。Part1：IT部署視圖演化及挑戰(zhàn)Part2：動態(tài)基礎(chǔ)設(shè)施Part3：SaaS架構(gòu)關(guān)注技術(shù)Part4：Q&A第六頁，共59頁。云計算關(guān)鍵特性第七頁，共59頁?；A(chǔ)設(shè)施供應生命周期第八頁，共59頁。資源池動態(tài)伸縮CloudCloudDDDDDDDDD第九頁，共59頁。Part1：IT部署視圖演化及挑戰(zhàn)Part2：動態(tài)基礎(chǔ)設(shè)施Part3：SaaS關(guān)注技術(shù)Part4：Q&A第十頁，共59頁。SaaS關(guān)鍵特性高伸縮：多租戶，功能可配置，流程可配置第十一頁，共59頁。SaaS架構(gòu)關(guān)注內(nèi)容第十二頁，共59頁。數(shù)據(jù)存儲的挑戰(zhàn)第十三頁，共59頁。傳統(tǒng)解決方案VS新興解決方案第十四頁，共59頁。SQL集群技術(shù)-MySQL集群方案有點缺點速度適用場合NDB可用于負載均衡場合；

可用于高可靠性場合；

高伸縮性；

真正的數(shù)據(jù)庫冗余；

容易維護。

隨著數(shù)據(jù)庫的變大，對RAM的需求變得更大，因此成本很高幾乎比典型的單獨服務(wù)器（無千兆以太網(wǎng)，無SCI卡，存儲引擎相關(guān)的限制少）慢10倍。冗余，高可靠性，負載均衡MySQL/GFS-GNBD/HA(Active/Passive)高可靠性

某種程度的冗余

按照高可靠性進行伸縮

沒有負載均衡

沒有保證的冗余

無法對寫操作進行伸縮

對讀操作支持得較好需要高可靠性的、讀操作密集型的應用MySQL/DRBD/HA(Active/Passive)高可靠性；

一定程度的冗余；

以高可靠性名義來看是可伸縮的

沒有負載均衡

沒有保證的冗余

在寫負載方面沒有伸縮性

在讀寫方面相當于單獨服務(wù)器需要高可靠性、讀操作密集型的應用MySQLWriteMaster/MultipleMySQLReadSlaves(Active/Active)讀操作的高可靠性；

讀操作的負載均衡；

在讀操作負載均衡方面是可伸縮的

無寫操作的高可靠性；

無寫操作的負載均衡；

在寫操作方面無伸縮性

同單獨服務(wù)器；在讀操作方面支持得較好讀操作密集型的、需要高可靠性和負載均衡的應用Google

MySQL

MMM技術(shù)第十五頁，共59頁。ShardingvsPartitionShardingPartition存儲依賴可跨越DB可跨越物理機器可跨越表空間,不同的物理屬性不能跨DB存儲存儲方式分布式集中式擴展性ScaleOut(橫向擴展)ScaleUp(升級設(shè)備)可用性無單點，需要處理跨數(shù)據(jù)事務(wù)存在單點(DB數(shù)據(jù)本身)應用場景web2.0多數(shù)傳統(tǒng)應用第十六頁，共59頁。數(shù)據(jù)切分-SQL實現(xiàn)方式優(yōu)點缺點垂直切分實現(xiàn)簡單擴展能力有限

強耦合的應用不容易垂直切分讀寫分離可有效分擔讀的壓力

主要在數(shù)據(jù)庫層擴展，應用修改小對讀寫均衡的應用擴展能有限

依賴于數(shù)據(jù)庫本身的同步能力水平切分SaaS普遍使用

擴展性強實施復雜第十七頁，共59頁。垂直shardinguserphrAppDAL第十八頁，共59頁。水平shardingPhr33%Phr33%AppDALPhr34%第十九頁，共59頁。讀寫分離phrphrAppDAL讀/寫讀第二十頁，共59頁。SQL數(shù)據(jù)訪問區(qū)域(DAL)1.mysqlproxy

實現(xiàn)“讀寫分離（Read/WriteSplitting）”。基本的原理是讓主數(shù)據(jù)庫處理事務(wù)性查詢，而從數(shù)據(jù)庫處理SELECT查詢。數(shù)據(jù)庫復制被用來把事務(wù)性查詢導致的變更同步到集群中的從數(shù)據(jù)庫。2.Amoeba

Amoeba項目是分布式數(shù)據(jù)庫proxy開發(fā)框架。座落與Client、DBServer(s)之間。對客戶

端透明。具有負載均衡、高可用性、sql過濾、讀寫分離、可路由相關(guān)的query到目標數(shù)據(jù)庫、可并發(fā)請

求多臺數(shù)據(jù)庫合并結(jié)果。

主要解決：

*降低數(shù)據(jù)切分帶來的復雜多數(shù)據(jù)庫結(jié)構(gòu)

*提供切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給應用帶來的影響

*降低db與客戶端的連接數(shù)

*讀寫分離3.WebsphereII第二十一頁，共59頁。Case1第二十二頁，共59頁。Case1數(shù)據(jù)生成分布規(guī)則：按照20會員每天采集一次監(jiān)控，每次采集10個指標（都為數(shù)值型）計算，按照20萬會員2010年全年的數(shù)據(jù)量，共計生成7.3億條記錄。分布在4個節(jié)點中，每臺設(shè)備1.825億條。共計50GB。血壓標簽統(tǒng)計地區(qū)執(zhí)行時間120~15090~12080~90test0np_034539ms15732123140882123TransactionNameMinimumAverageMaximumStd.Deviation90Percentquery0.0010.0343.820.1560.04第二十三頁，共59頁。Sql數(shù)據(jù)擴展問題第二十四頁，共59頁。Case2

–hadoopHBase&Hive2003年Google三篇論文:GFS,MapReduce,Bigtable

Hbase是一個分布式開源數(shù)據(jù)庫，基于Hadoop分布式文件系統(tǒng)，模仿并提供了基于Google文件系統(tǒng)的Bigtable數(shù)據(jù)庫的所有功能。其目標是處理非常龐大的表，可以用普通的計算機處理超過10億行數(shù)據(jù)，并且有數(shù)百萬列元素組成的數(shù)據(jù)表。MapReduce是分布式計算軟件構(gòu)架，它可以支持大數(shù)據(jù)量的分布式并行處理。

第二十五頁，共59頁。Hadoop軟件棧第二十六頁，共59頁。Table&ColumnFamily

RowKey

Timestamp

ColumnFamily

血壓（高壓）血壓（低壓）phr_user1t312080t213090t1

phr_user2t514070t414585

RowKey:行鍵，Table的主鍵，Table中的記錄按照RowKey排序Timestamp:時間戳，每次數(shù)據(jù)操作對應的時間戳，可以看作是數(shù)據(jù)的versionnumberColumnFamily：列簇，Table在水平方向有一個或者多個ColumnFamily組成，一個ColumnFamily中可以由任意多個Column組成，即ColumnFamily支持動態(tài)擴展，無需預先定義Column的數(shù)量以及類型，所有Column均以二進制格式存儲，用戶需要自行進行類型轉(zhuǎn)換。第二十七頁，共59頁。Case2

–hadoopHBase&Hive第二十八頁，共59頁。Case2-hadoop&Hive交易名稱交易響應時間（單位：秒）AverageTPSMinimumAverageMaximum90PercentInsert空表0.0010.0121.0760.03595.863Insert（3.06億）0.0010.0120.0590.03995.758交易名稱交易響應時間（單位：秒）AverageTPSMinimumAverageMaximum90PercentQuery0.0140.1454.2380.19627.47交易響應時間（單位：秒）4節(jié)點6節(jié)點8節(jié)點一個月數(shù)據(jù)140.007140.061147.029一年數(shù)據(jù)522.351285.998292.867第二十九頁，共59頁。SQL與NoSQL整合方案-hadoop&HiveDBMS從MySQL讀寫部分數(shù)據(jù)讀NoSQLNoSQL同步1.DBMS保存全部數(shù)據(jù)，主要完成交易類數(shù)據(jù)的讀寫2.通過同步技術(shù)把DBMS的數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫中3.NoSQL負責完成歷史數(shù)據(jù)的查詢統(tǒng)計分析等工作第三十頁，共59頁。NoSQL數(shù)據(jù)庫--MongoDB第三十一頁，共59頁。MongoDB與MySQL混搭采用MySQL與mongoDB混搭的模式，利用NoSQL數(shù)據(jù)的列可以動態(tài)擴展的優(yōu)勢來避免在關(guān)系數(shù)據(jù)庫為了擴展所采用行轉(zhuǎn)列導致的數(shù)據(jù)爆炸性增長的問題1.面向集合的存儲：適合存儲對象及JSON形式的數(shù)據(jù)。2.動態(tài)查詢：Mongo支持豐富的查詢表達式。3.完整的索引支持：包括文檔內(nèi)嵌對象及數(shù)組。Mongo的查詢優(yōu)化器會分析查詢表達式4.復制及自動故障轉(zhuǎn)移。不適用：高度事務(wù)性的系統(tǒng)傳統(tǒng)的商業(yè)智能應用第三十二頁，共59頁。SQL數(shù)據(jù)庫擴展的問題ID

<100ID<200AppDALID<300ID<400第三十三頁，共59頁。NoSQL數(shù)據(jù)庫擴展phrphrAppDALphrphr第三十四頁，共59頁。數(shù)據(jù)緩存工作原理DBMS客戶端App

ServerCacheDBMSCacheCacheCache第一次，從數(shù)據(jù)庫讀取數(shù)據(jù)，并寫入緩存第二次，從緩存讀取數(shù)據(jù)，如果數(shù)據(jù)不存在，那么，在去數(shù)據(jù)庫查詢數(shù)據(jù)目的：避免磁盤IO提高效率，減輕數(shù)據(jù)庫壓力第三十五頁，共59頁。開源緩存對比實現(xiàn)方式優(yōu)點缺點Terracotta采用JVM的heap復制方式不是通過對象序列化的方式傳輸Java實現(xiàn)可以無縫整合到JEE應用本身可以提供集群字節(jié)碼級的監(jiān)控可能會影響效率配置比較復雜memcachedC開發(fā)效率高對CPU資源要求低水平擴展性強非java應用需要通過socket調(diào)用不提供集群技術(shù)，需要自己實現(xiàn)，比較復雜Ehcache/OSCache可以運行在中間價同一個JVM中，執(zhí)行效力高集群需要作緩存同步水平擴展能力有限需要占用JVM的heap第三十六頁，共59頁。云平臺緩存方案客戶端App

ServerMemcacheEHCacheMemcacheMemcacheMemcacheApp

ServerEHCache采用Memcached作為分布式緩存為了保證系統(tǒng)執(zhí)行效率采用ehCache作為二級緩存在ehcache設(shè)置緩存時間，過期后到Memcached組成的緩存池獲得數(shù)據(jù)。該方案也可以采用Terracotta第三十七頁，共59頁。應用服務(wù)服務(wù)區(qū)域業(yè)務(wù)系統(tǒng)的主要業(yè)務(wù)邏輯運行在應用服務(wù)器中，所以，它承擔了更大的壓力，面臨如下挑戰(zhàn)：1.大并發(fā)訪問需要做應用服務(wù)器集群2.系統(tǒng)為了更可用性和友好性支持無縫切換第三十八頁，共59頁。應用服務(wù)器session管理實現(xiàn)方式優(yōu)點缺點典型做法session復制復制負載可以得到極好均衡，也可以保持對fail-over支持sesion復制對網(wǎng)絡(luò)壓力比較大。

需要應用服務(wù)器支持目前流行的中間件產(chǎn)品都支持stickysession實現(xiàn)簡單，在負載均衡層或是proxy層做配置即可

不會因為session同步給網(wǎng)絡(luò)帶來壓力不能實現(xiàn)完全負載均衡、無法實現(xiàn)failoverapache或是其它webserver做propxy基于cache集中式session應用服務(wù)器是無狀態(tài)，可實現(xiàn)完全負載均衡，不會帶來因為session復制帶來的網(wǎng)絡(luò)壓力實施復雜，對于部分功能需要定制開發(fā)使用Terracotta或是memcache等第三十九頁，共59頁。云下有狀態(tài)應用方案-memached-session客戶端App

ServerMemcacheMemcacheMemcacheMemcacheApp

Servermemcached-session-manager具有如下特性：1.支持tomcat6和tomcat72.能夠保持sticky會話和nonesticky會話3.能夠支持tomcat失敗轉(zhuǎn)移4.能夠支持Memcached失敗轉(zhuǎn)移5.實現(xiàn)session序列化6.可以實現(xiàn)session的異步存儲7.Session修改更新Memcached8.JMX管理和監(jiān)控第四十頁，共59頁。云下有狀態(tài)應用方案-Terracotta客戶端App

ServerTerracoattTerracoattTerracoattTerracoattApp

Server1.Terracotta本身支持集群，避免單點故障(雙機或者多機鏡像)2.

Terracotta的基礎(chǔ)是分布式數(shù)據(jù)共享和線程協(xié)同3.不是通過對象序列化的方式傳輸，支持Field級別的變更同步4.不需要修改程序5.支持目前主流的中間價agentagent第四十一頁，共59頁。Webserver區(qū)域ApachevsNginxvslighttpd反向代理等功能1.作為老牌HttpServer，ApacheHttpd在功能表現(xiàn)上令人滿意，配置相對簡單，功能豐富并且穩(wěn)定，可以任意編譯添加所需功能的模塊。2.Nginx作為新興的HttpServer，在性能表現(xiàn)上令人滿意，功能相對豐富，作為功能相對簡單的應用前臺HttpServer是可以推薦的，而且HttpServer可以做到動態(tài)更改配置文件，不需要長時間中斷服務(wù)。3.Lighttpd性能表現(xiàn)很好，但是在功能上有很多不穩(wěn)定之處。第四十二頁，共59頁。Webserver靜態(tài)資源分離靜態(tài)資源（圖片，js腳本，css等）使用單獨的服務(wù)器處理請求瀏覽器靜態(tài)資源靜態(tài)資源動態(tài)請求動態(tài)請求動態(tài)請示動態(tài)請示第四十三頁，共59頁。分布式文件作用

SaaS業(yè)務(wù)系統(tǒng)面臨著海量小圖片數(shù)據(jù)的存儲問題，這些圖片數(shù)據(jù)大小在幾K～幾十K不等但數(shù)目非常龐大，處理這些海量數(shù)據(jù)小文件傳統(tǒng)文件系統(tǒng)已經(jīng)不能滿足要求，系統(tǒng)在scaling的過程中都遇到了這樣的問題：磁盤IO過高；備份困難；單點問題，容量和讀寫無法水平擴展，還存在故障的可能。使用分布式存儲技術(shù)來解決圖片數(shù)據(jù)管理和容量擴展等方面的問題客戶端App

ServerNAS存儲/磁盤陣列App

Server第四十四頁，共59頁。分布式文件系統(tǒng)工作原理存儲節(jié)點，即StorageCluster，完成文件管理的所有功能。包括存儲、同步和提供存取接口；同時通過對metadata的管理實現(xiàn)了IO的并行和高效訪問。具有云存儲虛擬、自治、高效特點的實驗項目，支持多盤組、異構(gòu)整合。Tracker，即跟蹤器主要負責IO調(diào)度，通過負載均衡方式實現(xiàn)可靠、快速的資源存取。

Client可以是以Service的方式對云存儲提供IO服務(wù)。MogileDFS

VS

FastDFS

第四十五頁，共59頁。Case3

GIS系統(tǒng)地圖柵格數(shù)據(jù)測試第四十六頁，共59頁。消息隊列程序解耦消息可靠性到達異步通信提供效率第四十七頁，共59頁。企業(yè)級消息隊列1.消息嚴格的排序；2.支持事務(wù)3.信息通過持久化的方式保證安全可靠代表產(chǎn)品：1.Apache

ActiveMQ2.JbossMQ3.IBM

MQ4.Weblogic

JMS適合場景：企業(yè)級應用中消息可靠傳輸?shù)谒氖隧摚?9頁?；ヂ?lián)網(wǎng)消息隊列1.消息不需要嚴格的排序；2.不支持事務(wù)大多數(shù)情況可接受3.讀寫數(shù)據(jù)非?？?.橫向擴展性好代表產(chǎn)品：Kestrel適合場景：1.互聯(lián)網(wǎng)應用中消息動態(tài)第四十九頁，共59頁。Case4

Kestrel性能表現(xiàn)線程并發(fā)數(shù)存入10000條消息總時間（單位：秒）平均TPS第一次第二次第三次平均13.1446286813.3789056913.2551921773.2595755163067.88102.3287159322.2632132852.2974953192.2964748454354.5502.6794187122.6436958022.5845161462.6358768873793.8第五十頁，共59頁。負載均衡區(qū)域http重定向DNS負載均衡反向代理負載均衡IP負載均衡對應產(chǎn)品包括：nginxapachehttpdLVS(網(wǎng)絡(luò)第四層工作)F5(硬件，四層/