突破網(wǎng)絡(luò)應(yīng)用和數(shù)據(jù)庫加速及擴(kuò)展的兩個瓶頸
在web2.0時代,大部分網(wǎng)站都將遇到高速增長的日訪問量,為了保持網(wǎng)站的競爭力及用戶體驗、只有不斷革新產(chǎn)品及增強與用戶的交互性。此時的網(wǎng)站陷入了再熟悉不過的艱難境地,大量的動態(tài)內(nèi)容導(dǎo)致網(wǎng)站的訪問速度大大減慢,如果此時選擇增加額外的服務(wù)器及帶寬,來縮短網(wǎng)站的響應(yīng)時間,增加的運營成本不可估量。且一般網(wǎng)站開發(fā)資源是十分有限的,即使code base能被顯著改善,網(wǎng)站重構(gòu)的能力依然受到限制。
對于上面這些問題,ungeo動態(tài)云可以簡單高效的解決網(wǎng)站因開發(fā)資源有限、日益增長的訪問量造成用戶體驗變差等問題。ungeo動態(tài)云通過在全國各地自建的服務(wù)器群(節(jié)點),以IaaS和SaaS的方式為各類網(wǎng)站、政府機構(gòu)和大中型企業(yè)提供高效、穩(wěn)定、安全的動態(tài)內(nèi)容及SSL內(nèi)容分發(fā)服務(wù),數(shù)據(jù)庫拆分服務(wù)以及存儲服務(wù)。
UNGEO動態(tài)云緩存(UnGeo Dynamic Cloud Cache)
Ungeo動態(tài)云緩存是國內(nèi)首推基于動態(tài)緩存技術(shù)的動態(tài)內(nèi)容和SSL內(nèi)容分發(fā)網(wǎng)絡(luò),解決了動態(tài)內(nèi)容、SSL內(nèi)容、登錄頁面等分發(fā)難題和緩存實時更新的難題。它不同于傳統(tǒng)CDN的鏈路優(yōu)化方法,它是在最近的節(jié)點處理用戶對動態(tài)內(nèi)容和SSL內(nèi)容的請求,在提高訪問速度的同時極大地減少回源帶寬需求和源站服務(wù)器的負(fù)荷。
高性能:
每秒處理26萬個HTTP請求/單節(jié)點
https:每秒可處理15000個RSA-1024鑰匙簽署,25000個鑰匙驗證,在DES或AES-256加密模式下,每秒傳輸1.5G個字節(jié)。
管理海量并發(fā):每個IP端口6萬個
部分功能:
模式化、智能化的動態(tài)微緩存和共享網(wǎng)絡(luò)內(nèi)容,包括GET和POST請求。
允許cookie穿透緩存響應(yīng):通過在緩存響應(yīng)簽名中填加cookie值、添加用戶代理標(biāo)頭、添加重寫/減少的用戶代理請求標(biāo)頭 、添加“接受語言”請求標(biāo)頭等,更好地控制緩存響應(yīng)。
會話驅(qū)動內(nèi)容的緩存(Session-driven content caching):適用于除首頁外需登錄才能訪問的網(wǎng)站。
客戶端個性化處理的緩存,如個性化頁面的緩存。
對POST請求的響應(yīng)緩存
對同一個URL的壓縮和非壓縮響應(yīng),aiCache都進(jìn)行緩存。這兩個版本的緩存響應(yīng)是一個 URL, 且TTL相同(但因為緩存發(fā)生的時間不同,所以更新的時間點不同)。另外, HTTP/1.1和HTTP/1.0也是兩個緩存版本。
cookie驅(qū)動緩存控制:解決網(wǎng)頁的內(nèi)容會根據(jù)請求中有無cookie而變化這種情況的緩存
緩存清除控制:通過軟清除和硬清除兩種方式來清除aiCache內(nèi)存中的緩存內(nèi)容,以提高內(nèi)存利用率。另可設(shè)置對TTL有效期內(nèi)的緩存內(nèi)容不清除。
緩存路徑管理:有時,相同的網(wǎng)頁因請求的URL不同而緩存多份。如在請求的URL中添加參數(shù)以識別并統(tǒng)計請求來源,或?qū)Φ卿浻脩舻恼埱筇砑与S機字符串。為避免緩存多份相同的網(wǎng)頁,aiCache通過查詢忽略功能來實現(xiàn)對不同的URL請求只緩存一份響應(yīng)。
查詢參數(shù)破壞:查詢參數(shù)破壞指aiCache緩存或提供響應(yīng)時忽略URL中的部分參數(shù)。象上述情況,也可通過查詢參數(shù)破壞來應(yīng)對。
Ungeo云分發(fā)的動態(tài)緩存加速適用于手機網(wǎng)站,使手機格式從100多種減少到十幾種,從而大大降低了手機網(wǎng)站的建設(shè)成本和維 護(hù)成本。
強大、靈活的日志工具:輕松管理日志,而且可以收集更多的運行數(shù)據(jù)。日志工具和CLI一起使用,讓您實時知道黑匣子里到底發(fā)生了什么,讓您實時發(fā)現(xiàn)“蟻穴”,以免“千里長堤,潰于蟻穴”。
Fallback功能:當(dāng)原始服務(wù)器癱瘓時,安久動態(tài)云會使用緩存內(nèi)容處理請求和響應(yīng),使網(wǎng)站仍然在線。
四層安全防護(hù)抵御DOS和DDOS攻擊:1)識別并處理惡意請求、2)智能IP封鎖、3)智能請求截流:如配置每個IP每20秒只能有10個請求、4)RTATC反向圖靈訪問令牌控制(驗證碼/智能問答) :每個IP的初次請求通過RTATC令牌驗證后才能正常訪問。
自動刷新網(wǎng)絡(luò)監(jiān)測器:獲取實時的網(wǎng)站運行全面統(tǒng)計數(shù)據(jù)。
UNGEO動態(tài)云拆分(UnGeo Dynamic Cloud Sharding)
安久動態(tài)云拆分是dbShards部署在安久動態(tài)云的基礎(chǔ)設(shè)施和平臺管理上的一個SaaS(軟件即服務(wù))。dbShards云計算版通過安久的平臺環(huán)境為客戶提供了dbShards所有在可靠性和擴(kuò)展性上的性能提升。云計算允許用戶在擴(kuò)展高負(fù)荷網(wǎng)絡(luò)應(yīng)用時,任意添加額外的應(yīng)用服務(wù)器,從而提供無與倫比的靈活性。安久動態(tài)云拆分解決了以下云計算模式下的數(shù)據(jù)庫拆分問題:
解決了云計算中數(shù)據(jù)庫加速的瓶頸。如果一個應(yīng)用被設(shè)計成使用單個MySQL服務(wù)器,尤其是單個云計算服務(wù)器可使用的CPU和內(nèi)存都有限時,這就會成為限制云計算效率的一個瓶頸。dbShards云計算版解決了這一瓶頸問題。
解決了云計算中數(shù)據(jù)庫加速的復(fù)制難題。盡管可靠的復(fù)制和故障恢復(fù)往往伴隨著較慢的恢復(fù)時間,但對于云計算來說,這一點至關(guān)重要。標(biāo)準(zhǔn)的MySQL復(fù)制是不可靠的——因為事務(wù)是異步復(fù)制的,所以當(dāng)主數(shù)據(jù)庫故障時,丟失事務(wù)的可能性會非常大。DbShards即將獲得專利的可靠復(fù)制技術(shù)沒有犧牲任何性能就解決了這些問題。
解決了橫向擴(kuò)展的難題,極大地降低了擴(kuò)展成本。拆分一個數(shù)據(jù)庫為多個子庫,每一個子庫部署在單獨的安久動態(tài)云服務(wù)器上,允許象擴(kuò)展應(yīng)用程序一樣方便的擴(kuò)展數(shù)據(jù)庫,dbShards云計算版使得這一方案成為可能。安久動態(tài)云拆分作為一種云計算服務(wù),按照小時計數(shù)收費,為客戶降低運維成本。
解決了執(zhí)行性能和擴(kuò)展能力的難題。dbShards并沒有在讀操作方面增加任何額外開銷,但dbShards和所有其他提供可靠復(fù)制的產(chǎn)品一樣,在寫操作方面增加了一些開銷,因為寫操作事務(wù)必須通知到第二個或者說是“從”數(shù)據(jù)庫服務(wù)器?;谥虚g層的可靠復(fù)制產(chǎn)品都增加了許多額外開銷,使得寫操作被局限于每秒數(shù)十或數(shù)百次,甚至在超級服務(wù)器上也是如此。dbShards使用即將獲得專利的技術(shù),在保持高性能的同時提供可靠性。下面的圖表表明,當(dāng)使用配置4個子庫的大型EC2服務(wù)器時,dbShards可以執(zhí)行高達(dá)每秒10,000次寫操作(insert語句),并隨著子庫數(shù)的增加進(jìn)行線性擴(kuò)展。
下圖中的測試數(shù)據(jù)是基于使用dbShards隨產(chǎn)品發(fā)布的一個簡單的書店應(yīng)用程序產(chǎn)生的。這個應(yīng)用程序建立了一個仿真的商業(yè)模型,包含大量對建立了外鍵和索引的關(guān)聯(lián)表的插入操作。