老舊web上雲端

老舊 Web 上雲端qrtt1

#JCConf�

老舊 Web 上雲端大綱

Cache

CDNActiveCache

針對這次問題所選擇的主要方法

Cache

CDNActiveCache


實驗性質的主動式快取非常「惡搞」

重新思考快取的對象與策略


Cache

CDNActiveCache


實驗性質的主動式快取非常「惡搞」

重新思考快取的對象與策略

服務直到世界的盡頭


老舊 Web 上雲端

是一種對於無法維護的 Web 專案的「尊稱」


bad smell 大集合

各式各樣的 duplicated code

各式各樣的 long method, class

各式各樣的 untestable code


由於 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

困境

此乃 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


沒快取，就得等

等待

思路 Active Cache

request


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上雲端

Engineering