老舊 Web 上雲端qrtt1
#JCConf�
老舊 Web 上雲端大綱
Cache
CDNActiveCache
針對這次問題所選擇的主要方法
Cache
CDNActiveCache
針對這次問題所選擇的主要方法
實驗性質的主動式快取非常「惡搞」
重新思考快取的對象與策略
老舊 Web 上雲端大綱
Cache
CDNActiveCache
針對這次問題所選擇的主要方法
實驗性質的主動式快取非常「惡搞」
重新思考快取的對象與策略
服務直到世界的盡頭
老舊 Web 上雲端大綱
老舊 Web 上雲端
是一種對於無法維護的 Web 專案的「尊稱」
老舊 Web 上雲端
bad smell 大集合
各式各樣的 duplicated code
各式各樣的 long method, class
各式各樣的 untestable code
老舊 Web 上雲端
由於 legacy code 太可怕了
「上雲端」計劃,有個大前提!!!
不改既有程式
老舊 Web + 老舊機器
IT人蔘的
困境Linux www.iradiopop.com 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
S1
S2
LB
典型的 Web 架構
1 台 Loading Balancer
若干個後端 Server
困境
S1
S2
LB 當使用量滿出來時 ⋯
困境
S1
S2
LB
無法服務、死機、連不上、重開
聰明的 LB
會導向還能動的機器
S1
S2
LB
無法服務、死機、連不上、重開
聰明的 LB
會導向還能動的機器
S1
S2
LB
困境
此乃 Crash 翹翹板
苦逼的 SysAdmin
S1
S2
LB
雲端
當使用量滿出來時 ⋯
S1
S2
LB
雲端
S3
S4
就加更多機器唄(有錢真好)
S1
S2
LB
雲端
寫得再醜的 Web 都有辦法
Scale Out, Scale In
只是極限大輸良好設計的成品sticky session
貴、順、爽
貴、順、爽
LB
可以買很貴的機器
窮
窮
LB
可是瑞凡...
一般的小公司
多半先由便宜的機器開始測試
輕
檢討當預算有限,
買不夠到足夠 Power 的機器時...
原本快的地方變慢了 CPU
慢的地方變快了 I/O
檢討
request
business logic
db query
檢討
request
business logic
cache
db query
檢討
request
business logic
cache
db query
舊機器的 I/O 比雲端還慢,
所以「原本慢的變快了」
檢討
request
business logic
cache
db query
舊機器的 CPU 比雲端還快,
所以「原本快的變慢了」
for(…) { for(…) { for(…) { /* 很暴⼒力地過濾資料 */ } } }
檢討
request
cachedb query
business logic
看起來是個
更值得快取的對象
Active Cache
思路 Active Cache
request cache
heavy business logic
有快取,就是順
思路 Active Cache
request expired cache
heavy business logic
沒快取,就得等
等待
思路 Active Cache
request
heavy business logic
active cache
知道如何更新自己的快取
ActiveCache
不等待
惡搞 Active Cache
Active Cache
資料過期前(時),主動重抓資料
現有的 Library
guava CacheLoader
BUT legacy code 太難改,
決定以不改 code 為目標
惡搞 Active Cache
使用 AOP 插入 Advice
讓 business logic 支援 Active Cache
1. 將 method call 轉成 cache key
2. 註冊 method call 至 cache refresh scheduler
active cache
惡搞 Active Cache
request business logic
KEYCached Refresh Scheduler
business logic
method call to cache key
register key + method call to scheduler
active cache
惡搞 Active Cache
request business logic
Cached Refresh Scheduler
cache storage
auto refresh
business logic
使用者看到的
business logic
真正的
business logic
惡搞 Active Cache
ActiveCache 本來是為了「減少等待時間」設計
放在雲端上,恰巧減少了 Busy Job 搶資源的問題.
經由 cache refresh scheduler 限制 Loading
實作 Active Cache
整體的概念很簡單
使用 AOP Advice 攔截 method call
KEY = method + arguments
實作 Active Cache
methodA(userInfo, str, int, map, otherPojo)
key = signature_ + args[0] + args[1] + args[⋯]
=> methodA_User@a3a4a3a5_str_3_{a:3,b:3}_
=> methodA_user1_str_3_{a:3,b:3}_ 有些物件 toString 後的結果不合用,換成其他特徵代替
實作 Active Cache
有些物件,沒有 getter 能取得特徵!
用 AOP 攔截建構子參數,製作識別資料
methodB(userList, comparator)
=> methodB_user1_user2_⋯_comparator@1a2b
=> methodB_user1_user2_⋯_cmp@SortByDate
實作 Active Cache
Active Cache 如何知道該更新了?
是 User 呼叫的就吐 Cache
是 Scheduler 呼叫的就 Refresh
javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
stacktrace 看到 HttpServlet.service 就當他是 User 唄
遠方進入雲端時代,
Web App 依舊是安裝在 Server 上的
要如何服務離機房較遠的客戶是個問題
遠方客戶最大,但客戶的位置很尷尬!!!
阿拉伯、俄羅斯、印度、埃及、⋯
離 VM 機房很遠,
但離 CDN Edge Location 沒那麼遠。
遠方利用 CDN 傳遞動態資料,適合簡單的 RESTFUL Service
request / response
好遠. 夭壽遠
遠方
好遠. 夭壽遠
filter
CDN
HTTP 304
原來我們這麼近
request / response
服務直到世界的盡頭
利用 CDN 傳遞動態資料,適合簡單的 RESTFUL Service
cached url
遠方服務直到世界的盡頭
如何使 Cache Expire ?
CDN invalidation 很慢,換路徑很快
http://cdn/time-window-token-r/cache-key
http://cdn/time-window-token-g/cache-key
http://cdn/time-window-token-b/cache-key
⼩小⼼心安全問題,不要放敏感資料
Cache
CDNActiveCache
針對這次問題所選擇的主要方法
實驗性質的主動式快取
非常「惡搞」
重新思考快取的對象與策略 服務直到世界的盡頭
Q&A
老舊 Web 上雲端