戰(zhàn)：CDN與WAF一體化防護(hù)與性能優(yōu)化)
1. 為什么我會(huì)盯上阿里云邊緣安全加速先說(shuō)背景。我自己手上有幾個(gè)網(wǎng)站和API服務(wù)有內(nèi)容類的、也有幾個(gè)給小程序提供數(shù)據(jù)的接口。前幾年一直用的是普通CDN圖個(gè)便宜省事把靜態(tài)資源一緩存帶寬成本確實(shí)壓下來(lái)了。但真正讓我覺(jué)得日子不好過(guò)的是這兩年網(wǎng)站流量慢慢上來(lái)之后各種掃描、撞庫(kù)、CC攻擊的請(qǐng)求也跟著漲幾臺(tái)源站服務(wù)器經(jīng)常莫名其妙被打到CPU報(bào)警。傳統(tǒng)CDN就管加速安全這塊基本是裸奔最多給個(gè)半死不活的IP黑白名單遇到真正像樣點(diǎn)的攻擊根本扛不住源站IP一暴露分分鐘被打穿。后來(lái)我仔細(xì)看了下阿里云的邊緣安全加速ESAEdge Security Acceleration簡(jiǎn)單說(shuō)就是把CDN加速和WAF、DDoS防護(hù)、訪問(wèn)控制這些安全能力統(tǒng)一放到了邊緣節(jié)點(diǎn)上。也就是說(shuō)用戶請(qǐng)求還沒(méi)到你的源站在離他最近的邊緣節(jié)點(diǎn)就已經(jīng)做完了安全檢測(cè)和流量清洗同時(shí)再把靜態(tài)內(nèi)容、動(dòng)態(tài)請(qǐng)求用最優(yōu)路徑回源。這種“安全加速一體”的思路比單獨(dú)買一臺(tái)高防服務(wù)器、或者CDN和WAF分開(kāi)配兩套方案省心不少也更省錢。當(dāng)然光看產(chǎn)品介紹誰(shuí)都會(huì)吹我自己也踩過(guò)不少“宣傳很豐滿落地很骨感”的坑。所以這篇文章主要是把近幾個(gè)月實(shí)打?qū)嵉氖褂皿w驗(yàn)做一個(gè)記錄從開(kāi)通配置、安全防護(hù)、性能表現(xiàn)、成本控制到各種奇奇怪怪的問(wèn)題都盡量寫(xiě)詳細(xì)。如果你也有類似的網(wǎng)站或接口在考慮要不要上邊緣安全加速這篇應(yīng)該能幫你省不少時(shí)間。2. 基礎(chǔ)配置階段最容易被忽略的幾個(gè)細(xì)節(jié)2.1 接入域名前先想清楚業(yè)務(wù)該走“加速”還是“安全”我第一次用ESA的時(shí)候腦子里想的就是“直接把域名CNAME解析過(guò)去就行”。但實(shí)際上阿里云邊緣安全加速的控制臺(tái)要比普通CDN復(fù)雜一些一上來(lái)就會(huì)遇到站點(diǎn)接入模式的選擇常見(jiàn)的有“CNAME接入”和“NS接入”兩種。CNAME接入比較簡(jiǎn)單就是把你需要的子域名單獨(dú)指到ESA分配的CNAME地址不影響其他域名的DNS解析。NS接入則是把整個(gè)域名的DNS服務(wù)器都托管給阿里云這樣所有子域名默認(rèn)都走ESA配置更省事控制力也更強(qiáng)但代價(jià)是整個(gè)域名的解析權(quán)都交出去了對(duì)于那些還有其他業(yè)務(wù)域名在跑的團(tuán)隊(duì)影響面比較大。我最后選的是CNAME接入因?yàn)槭稚嫌蛎嘤械挠肅loudflare的DNS管著有的是阿里云自家的混在一起如果用NS接入很容易誤傷其他業(yè)務(wù)。這里有個(gè)很關(guān)鍵的經(jīng)驗(yàn)接入之前一定要把業(yè)務(wù)分類。純靜態(tài)資源圖片、JS、CSS直接走默認(rèn)的加速配置就行安全策略不用開(kāi)太狠但如果你的接口API是給App或小程序用的就必須單獨(dú)建一個(gè)站點(diǎn)或域名分組把WAF規(guī)則、限流策略、Bot管理單獨(dú)調(diào)不然默認(rèn)規(guī)則很容易誤傷正常請(qǐng)求。我自己一開(kāi)始圖省事全部放到一個(gè)站點(diǎn)下結(jié)果某個(gè)API接口的請(qǐng)求被CC防護(hù)誤判攔了一部分排查了半天才發(fā)現(xiàn)是規(guī)則范圍太寬了。2.2 HTTPS證書(shū)配置解決“頁(yè)面不存在”這類怪問(wèn)題阿里云目前對(duì)ESA提供免費(fèi)證書(shū)的申請(qǐng)和自動(dòng)續(xù)期這個(gè)確實(shí)省心。但我還是要提醒一句如果你在邊緣安全加速上配了HTTPS源站那邊最好也把HTTPS配好并且證書(shū)要有效否則會(huì)碰到一個(gè)容易讓人抓狂的現(xiàn)象——瀏覽器訪問(wèn)頁(yè)面提示“抱歉您所指定的頁(yè)面不存在”。這個(gè)問(wèn)題的根源通常不是真的頁(yè)面不存在而是ESA邊緣節(jié)點(diǎn)回源的時(shí)候如果源站返回了418、302跳轉(zhuǎn)、或者SSL握手失敗ESA會(huì)把錯(cuò)誤信息緩存下來(lái)直接展示一個(gè)默認(rèn)錯(cuò)誤頁(yè)。尤其當(dāng)你之前用了別的CDN或者源站Nginx配了強(qiáng)制HTTPS跳轉(zhuǎn)邊緣節(jié)點(diǎn)回源時(shí)和源站之間協(xié)商協(xié)議不一致就會(huì)產(chǎn)生這種奇怪現(xiàn)象。我后來(lái)是把源站的強(qiáng)制跳轉(zhuǎn)關(guān)掉在ESA邊緣配置里統(tǒng)一做HTTP到HTTPS的跳轉(zhuǎn)同時(shí)把回源協(xié)議設(shè)為“HTTPS源站也走443”問(wèn)題就沒(méi)再出現(xiàn)過(guò)。還有一個(gè)細(xì)節(jié)證書(shū)續(xù)期之后如果ESA控制臺(tái)里的證書(shū)狀態(tài)沒(méi)有自動(dòng)更新你需要手動(dòng)點(diǎn)擊一下“更新證書(shū)”或重新部署。我遇到過(guò)幾次免費(fèi)證書(shū)自動(dòng)續(xù)期后控制臺(tái)顯示已生效但邊緣節(jié)點(diǎn)實(shí)際還是舊證書(shū)導(dǎo)致部分移動(dòng)端App請(qǐng)求失敗。排查方法很簡(jiǎn)單用OpenSSL命令看看實(shí)際證書(shū)的生效時(shí)間如果和控制臺(tái)不一致就手動(dòng)觸發(fā)一次證書(shū)重新下發(fā)。openssl s_client -connect 你的域名:443 -servername 你的域名 2/dev/null | openssl x509 -noout -dates2.3 回源配置的坑別讓源頭成為瓶頸很多人以為邊緣安全加速只要配好域名就萬(wàn)事大吉其實(shí)回源配置才是決定穩(wěn)定性的大頭。ESA支持“域名回源”和“IP回源”。如果你源站是阿里云ECS我建議直接用內(nèi)網(wǎng)IP回源走阿里云內(nèi)部網(wǎng)絡(luò)不占用公網(wǎng)帶寬延遲和穩(wěn)定性都要好很多。如果源站在其他云廠商或者自建機(jī)房那就只能用公網(wǎng)IP回源這時(shí)候一定要在源站的防火墻或安全組里只放行ESA的回源IP段。這里我必須強(qiáng)調(diào)千萬(wàn)要把回源IP段配到源站白名單里。我的源站之前被掃描器直接掃到IP然后瘋狂打源站就是因?yàn)榛卦碔P白名單沒(méi)配好。后來(lái)我在Nginx層加了一層allow/deny只允許ESA的回源IP訪問(wèn)源站的80和443端口攻擊流量即使繞過(guò)ESA直連IP也進(jìn)不來(lái)。# 僅放行指定回源IP段其他IP一律拒絕 allow 你的阿里云邊緣節(jié)點(diǎn)IP段1; allow 你的阿里云邊緣節(jié)點(diǎn)IP段2; deny all;如果你用的是阿里云ECS的Linux系統(tǒng)配置完記得安全組也要同步加一下規(guī)則ECS安全組和Nginx兩層都要放行ESA回源IP。這個(gè)弄完之后源站的壓力瞬間小了很多。3. 安全防護(hù)能力實(shí)測(cè)WAF和CC防護(hù)到底靈不靈3.1 WAF核心規(guī)則默認(rèn)規(guī)則夠用但別裸奔阿里云ESA內(nèi)置了一套WAF托管規(guī)則可以在控制臺(tái)一鍵開(kāi)啟。默認(rèn)規(guī)則覆蓋了常見(jiàn)的SQL注入、XSS攻擊、命令注入、惡意爬蟲(chóng)識(shí)別等。我開(kāi)啟之后讓同事配合做了一輪“安全測(cè)試”就是模擬一些常見(jiàn)的攻擊Payload比如在URL參數(shù)里傳 or 11 --這種結(jié)果還是相當(dāng)靠譜基本都能攔截下來(lái)并返回405或460狀態(tài)碼。但有一個(gè)容易被忽略的點(diǎn)WAF托管規(guī)則默認(rèn)會(huì)對(duì)所有請(qǐng)求做檢測(cè)這會(huì)導(dǎo)致一些正常情況下看起來(lái)“不太正?！钡暮戏ㄕ?qǐng)求被誤判。比如我有個(gè)接口參數(shù)里本身允許用戶傳一段帶有特殊字符的文本像英文單引號(hào)、尖括號(hào)、SQL關(guān)鍵字之類結(jié)果被WAF當(dāng)成注入攻擊給攔了。解決方案有兩條一是把對(duì)應(yīng)的接口加入WAF白名單另一個(gè)更推薦的做法是在ESA控制臺(tái)里給該站點(diǎn)單獨(dú)配置更精細(xì)的規(guī)則把包含這些參數(shù)的URI排除在檢測(cè)范圍之外。千萬(wàn)別圖省事直接把整個(gè)站點(diǎn)的WAF關(guān)掉。還有一點(diǎn)WAF的攔截模式默認(rèn)是“觀察”還是“攔截”這個(gè)是可以在控制臺(tái)調(diào)的。我第一次開(kāi)啟時(shí)默認(rèn)是攔截模式結(jié)果某天晚上網(wǎng)站訪問(wèn)量突然掉了一半一看日志才發(fā)現(xiàn)某個(gè)老接口的POST請(qǐng)求一直被攔截。后來(lái)我先把WAF切到“觀察”模式跑了一個(gè)禮拜每天看誤判日志把正常業(yè)務(wù)請(qǐng)求加到白名單之后才重新切回“攔截”模式。所以凡是涉及到規(guī)則變更建議都先觀察后攔截不要一上來(lái)就開(kāi)大招。3.2 CC防護(hù)與限流別把正常用戶也攔在外面CC攻擊Challenge Collapsar簡(jiǎn)單說(shuō)就是模擬正常用戶的高頻請(qǐng)求把源站和邊緣節(jié)點(diǎn)的資源耗光。ESA的CC防護(hù)和頻控規(guī)則我實(shí)際體驗(yàn)下來(lái)對(duì)單一IP的突發(fā)高頻請(qǐng)求識(shí)別還是比較準(zhǔn)的。尤其是針對(duì)登錄接口、短信發(fā)送接口這類容易被“羊毛黨”盯上的路徑可以配置“單IP每秒鐘允許請(qǐng)求數(shù)”和“單IP每分鐘允許請(qǐng)求數(shù)”兩個(gè)維度。這里有一個(gè)很實(shí)際的調(diào)優(yōu)經(jīng)驗(yàn)。我最初把某個(gè)API的單IP閾值設(shè)成了“每秒10次”想著正常用戶不太可能一秒請(qǐng)求10次結(jié)果活動(dòng)期間用戶集中搶券一個(gè)辦公室出口IP下可能有幾十個(gè)人共用瞬間就被限流攔掉了。后來(lái)我把閾值調(diào)成“每秒20次”同時(shí)加上“每個(gè)會(huì)話Cookie每秒鐘最多5次”的二級(jí)限制才兼顧了正常用戶和防刷需求。CC防護(hù)的攔截閾值沒(méi)有絕對(duì)標(biāo)準(zhǔn)得看你的業(yè)務(wù)形態(tài)。如果是面向C端的高并發(fā)API單IP閾值適當(dāng)放寬如果是后臺(tái)管理系統(tǒng)或者管理接口閾值就要收得很緊甚至可以配置只允許指定IP段訪問(wèn)。有條件的話把辦公網(wǎng)的出口IP加進(jìn)白名單避免自己人把賬號(hào)鎖了。3.3 自定義規(guī)則和Bot管理的實(shí)戰(zhàn)經(jīng)驗(yàn)ESA的自定義攔截規(guī)則部分我后來(lái)花的精力最多。除了默認(rèn)的WAF規(guī)則它還支持按Header、Cookie、URI、參數(shù)等多個(gè)維度組合條件做攔截或放行。比如有段時(shí)間有個(gè)爬蟲(chóng)一直用同一類User-Agent瘋狂抓數(shù)據(jù)我在控制臺(tái)配置了一條規(guī)則User-Agent包含特定關(guān)鍵字比如某些Python庫(kù)、爬蟲(chóng)框架且URI匹配到數(shù)據(jù)接口路徑直接攔截。配置生效后這類請(qǐng)求的日志立馬安靜了效果立竿見(jiàn)影。Bot管理這個(gè)是針對(duì)更高級(jí)的爬蟲(chóng)的能識(shí)別無(wú)頭瀏覽器、模擬瀏覽器行為的請(qǐng)求。我體驗(yàn)下來(lái)確實(shí)有一定效果但對(duì)性能有一定損耗請(qǐng)求耗時(shí)會(huì)有微小的增加。如果你的網(wǎng)站是靜態(tài)頁(yè)為主CDN緩存命中率高其實(shí)不太需要開(kāi)Bot管理但如果你的核心資產(chǎn)是API數(shù)據(jù)接口開(kāi)了Bot管理之后精準(zhǔn)度提升明顯。這個(gè)可以根據(jù)業(yè)務(wù)接口的重要程度按域名開(kāi)啟不用全局都開(kāi)。還有一點(diǎn)提醒大家ESA的安全日志和攔截日志都是可以在控制臺(tái)實(shí)時(shí)查看的一定要養(yǎng)成定期翻日志的習(xí)慣。我至少每周看一次攔截報(bào)表關(guān)注哪些路徑被攻擊得多、哪些規(guī)則在誤殺及時(shí)做調(diào)整。4. 加速性能實(shí)測(cè)不只是靜態(tài)緩存那么簡(jiǎn)單4.1 動(dòng)靜態(tài)混合加速對(duì)比傳統(tǒng)CDN的優(yōu)勢(shì)傳統(tǒng)CDN對(duì)靜態(tài)資源加速效果很好但是遇到帶參數(shù)的動(dòng)態(tài)請(qǐng)求、API接口、登錄請(qǐng)求往往是直接回源速度提升不明顯。ESA在這方面做了一些優(yōu)化把自己的動(dòng)態(tài)加速DCDN能力也整合進(jìn)來(lái)了通過(guò)智能路由、TCP優(yōu)化等手段讓動(dòng)態(tài)請(qǐng)求也能選擇最優(yōu)鏈路回源減少公網(wǎng)鏈路抖動(dòng)帶來(lái)的延遲。我實(shí)際做了對(duì)比測(cè)試。同樣一個(gè)API接口直接請(qǐng)求源站IP的延遲在80~120毫秒左右經(jīng)過(guò)普通CDN回源之后延遲反而可能會(huì)比直連源站還高一點(diǎn)但經(jīng)過(guò)ESA的動(dòng)態(tài)加速之后從廣州、北京、上海三個(gè)地點(diǎn)測(cè)試平均延遲能降到40~70毫秒。對(duì)于需要多次請(qǐng)求才能完成一個(gè)業(yè)務(wù)動(dòng)作的App來(lái)說(shuō)這個(gè)延遲差距體感非常明顯。這里也補(bǔ)充一下ESA的動(dòng)態(tài)加速能力很多是在邊緣節(jié)點(diǎn)上通過(guò)應(yīng)用層協(xié)議優(yōu)化實(shí)現(xiàn)的比如HTTP/2、HTTP/3QUIC的加速。我開(kāi)啟HTTP/3之后弱網(wǎng)環(huán)境下比如地鐵、電梯里的加載速度提升比較明顯。不過(guò)要注意的是如果你的網(wǎng)站不支持HTTPS那HTTP/3根本用不上所以基礎(chǔ)HTTPS配置一定要先做好。4.2 緩存命中率優(yōu)化讓邊緣節(jié)點(diǎn)真正“扛活”邊緣安全加速不只是安全產(chǎn)品它的本質(zhì)還是個(gè)CDN所以緩存命中率直接影響回源壓力和用戶體驗(yàn)。我剛開(kāi)始接入的時(shí)候緩存命中率只有50%左右源站壓力還是很大。后來(lái)我發(fā)現(xiàn)問(wèn)題出在緩存策略上默認(rèn)配置對(duì)帶參數(shù)的URL基本不緩存每次請(qǐng)求都回源。于是我專門花了半天時(shí)間梳理了網(wǎng)站的請(qǐng)求類型圖片、CSS、JS、字體這些靜態(tài)資源沒(méi)有Cookie的、URL不帶參數(shù)的全部設(shè)置成“忽略查詢字符串”的緩存模式緩存時(shí)間設(shè)為1天到7天不等HTML頁(yè)面設(shè)置成緩存10分鐘配合源站每次發(fā)布后主動(dòng)刷新緩存API接口則按業(yè)務(wù)容忍度設(shè)置緩存30秒到5分鐘數(shù)據(jù)要求實(shí)時(shí)性高的不緩存。這么調(diào)完以后緩存命中率從50%提升到了90%以上源站后端服務(wù)器的CPU使用率直接降了大約40%。這里想提醒大家緩存配置的核心思路是“能緩存的一定要緩存不能緩存的一分鐘都別亂存”尤其對(duì)于電商類網(wǎng)站如果把購(gòu)物車接口緩存了會(huì)出現(xiàn)加購(gòu)后看不到商品這種嚴(yán)重事故。寧可犧牲一點(diǎn)速度也不能犧牲數(shù)據(jù)一致性。4.3 實(shí)時(shí)日志和監(jiān)控告警別等用戶投訴才發(fā)現(xiàn)問(wèn)題最后想聊一下監(jiān)控這塊。ESA控制臺(tái)提供了詳細(xì)的訪問(wèn)日志、回源日志、攔截日志和實(shí)時(shí)監(jiān)控面板。我強(qiáng)烈建議你開(kāi)通日志服務(wù)或至少訂閱實(shí)時(shí)日志把ESA日志投遞到自己的日志平臺(tái)比如阿里云SLS或自建ELK這樣出問(wèn)題的時(shí)候可以快速定位而不是登錄控制臺(tái)一頁(yè)一頁(yè)翻。我自己就吃過(guò)虧。有段時(shí)間邊緣節(jié)點(diǎn)命中率很低但是控制臺(tái)總覽頁(yè)看著延遲還行直到有用戶反饋App打開(kāi)圖片很慢我才去翻日志發(fā)現(xiàn)大部分請(qǐng)求都回源了源站在高峰期被拖垮導(dǎo)致整體變慢。后來(lái)配置了“回源帶寬”“回源請(qǐng)求數(shù)”“5xx錯(cuò)誤率”這幾個(gè)監(jiān)控項(xiàng)的告警閾值一超過(guò)就會(huì)收到短信和郵件通知。這個(gè)告警一定要配而且要配在回源側(cè)因?yàn)檫吘壒?jié)點(diǎn)的帶寬有緩存扛著看起來(lái)再平穩(wěn)回源側(cè)可能已經(jīng)冒煙了。5. 賬算明白邊緣安全加速到底花多少錢5.1 計(jì)費(fèi)項(xiàng)拆解別被“按量付費(fèi)”嚇到很多人在意ESA的價(jià)格說(shuō)實(shí)話我第一次看計(jì)費(fèi)文檔也頭大因?yàn)橛屑铀倭髁抠M(fèi)、安全防護(hù)費(fèi)WAF規(guī)則數(shù)、Bot管理、動(dòng)態(tài)請(qǐng)求數(shù)費(fèi)用、邊緣函數(shù)調(diào)用次數(shù)費(fèi)等多個(gè)維度。不過(guò)實(shí)際用下來(lái)大部分中小網(wǎng)站的賬單大頭還是“流量費(fèi)”和“請(qǐng)求數(shù)”。我自己的網(wǎng)站是內(nèi)容站API服務(wù)日均請(qǐng)求量大概40萬(wàn)次其中靜態(tài)資源請(qǐng)求占70%API請(qǐng)求占30%。啟用ESA之后靜態(tài)請(qǐng)求基本被緩存節(jié)點(diǎn)直接扛掉真正回源的請(qǐng)求量很少所以加速流量費(fèi)并沒(méi)有想象中那么高。而安全防護(hù)這塊基礎(chǔ)WAF托管規(guī)則是包含在套餐里的只要不額外買高級(jí)版的自定義規(guī)則數(shù)和Bot管理費(fèi)用還是比較可控的。對(duì)比之前我用的“普通CDN另一家云WAF”的組合ESA的費(fèi)用大概便宜了20%~30%而且運(yùn)維成本低了不止一星半點(diǎn)。以前兩個(gè)控制臺(tái)來(lái)回切換出了問(wèn)題還要猜是CDN的問(wèn)題還是WAF的問(wèn)題現(xiàn)在一個(gè)產(chǎn)品全解決出問(wèn)題看ESA的日志基本就夠定位了。5.2 成本優(yōu)化的幾個(gè)實(shí)操方向如果你發(fā)現(xiàn)月底賬單超出預(yù)期不用急著換產(chǎn)品先做這幾件事第一梳理緩存策略。緩存命中率每提升10%回源流量就少一大截費(fèi)用自然降下來(lái)。把圖片這類大頭靜態(tài)資源緩存時(shí)間盡量拉長(zhǎng)版本更新時(shí)用文件名加版本號(hào)的方式來(lái)刷新而不是頻繁地手動(dòng)緩存刷新。第二確認(rèn)有沒(méi)有不必要的“動(dòng)態(tài)請(qǐng)求加速”。ESA對(duì)動(dòng)態(tài)請(qǐng)求有單獨(dú)的計(jì)費(fèi)如果你的接口本身離源站很近比如源站和用戶都在同一城市那動(dòng)態(tài)加速帶來(lái)的收益有限可以只對(duì)需要跨地域訪問(wèn)的API開(kāi)啟動(dòng)態(tài)加速把省下來(lái)的錢花在其他地方。第三安全規(guī)則不是越多越好。ESA的WAF自定義規(guī)則如果超過(guò)免費(fèi)額度會(huì)按條數(shù)計(jì)費(fèi)。我見(jiàn)過(guò)有人為了圖心理安慰一口氣配了上百條規(guī)則最后發(fā)現(xiàn)有一半以上的規(guī)則命中率為0。定期檢查規(guī)則命中率把完全沒(méi)用的規(guī)則刪掉能省一部分費(fèi)用。第四如果你只是個(gè)人博客或輕量站點(diǎn)可以先從按量付費(fèi)跑起來(lái)觀察一個(gè)月的賬單規(guī)模再?zèng)Q定要不要買資源包。資源包適合流量比較穩(wěn)定的業(yè)務(wù)價(jià)格能便宜不少如果流量波動(dòng)大按量付費(fèi)反而更靈活不會(huì)因?yàn)橘I了包用不完造成浪費(fèi)。5.3 從“救火”到“日常運(yùn)營(yíng)”的心態(tài)轉(zhuǎn)變最后說(shuō)一個(gè)花了不少錢才想明白的道理邊緣安全加速不是裝上就一勞永逸的。它是一個(gè)需要持續(xù)運(yùn)維的東西。安全規(guī)則要定期調(diào)緩存策略要跟著業(yè)務(wù)版本走監(jiān)控告警要有專人盯。我之前一直以為它是“裸奔”網(wǎng)站的救命稻草用了之后才悟了真正讓網(wǎng)站穩(wěn)的是你有沒(méi)有一套持續(xù)的運(yùn)營(yíng)流程。我現(xiàn)在的做法是每周固定花一小時(shí)看ESA的攔截報(bào)表和監(jiān)控?cái)?shù)據(jù)每次發(fā)版前先檢查一下緩存策略是否需要調(diào)整特別是有沒(méi)有新增的API路徑不小心被緩存了每季度做一次規(guī)則梳理把長(zhǎng)期零命中的規(guī)則清理掉。這套流程執(zhí)行下來(lái)網(wǎng)站的穩(wěn)定性、用戶口碑都有了實(shí)打?qū)嵉奶嵘?. 那些年我踩過(guò)的坑給你提個(gè)醒最后再分享幾個(gè)具體問(wèn)題都是我實(shí)際遇到過(guò)、并且在文檔里不容易直接找到答案的。第一個(gè)是“群里問(wèn)了幾百遍沒(méi)人理”的證書(shū)續(xù)期后顯示不生效問(wèn)題。如果你用了阿里云免費(fèi)證書(shū)到期后證書(shū)會(huì)自動(dòng)續(xù)期但ESA控制臺(tái)里的“證書(shū)狀態(tài)”不一定馬上同步。遇到這種情況直接把證書(shū)重新部署一遍不用重新申請(qǐng)通常幾秒鐘就生效了。部署完記得用第一節(jié)里的OpenSSL命令驗(yàn)證一下實(shí)際證書(shū)時(shí)間不要只看控制臺(tái)。第二個(gè)是“換SSL證書(shū)后網(wǎng)站報(bào)錯(cuò)”的問(wèn)題。有些同學(xué)在群暉NAS或者其他服務(wù)器上換了新證書(shū)但瀏覽器訪問(wèn)還是報(bào)錯(cuò)甚至提示頁(yè)面不存在或證書(shū)無(wú)效。這種現(xiàn)象多半是因?yàn)檫吘壒?jié)點(diǎn)緩存了舊證書(shū)狀態(tài)或者瀏覽器緩存里的HSTS記錄還指向舊證書(shū)。清一下瀏覽器緩存再用無(wú)痕模式訪問(wèn)試試如果還不行就在ESA控制臺(tái)重新下發(fā)一次證書(shū)。第三個(gè)是“邊緣函數(shù)配置出錯(cuò)導(dǎo)致整個(gè)站點(diǎn)500”。邊緣函數(shù)確實(shí)很強(qiáng)大可以在邊緣直接改寫(xiě)請(qǐng)求、做鑒權(quán)、做響應(yīng)頭注入。但它一旦崩了影響的是整個(gè)域名。我在邊緣函數(shù)測(cè)試階段就踩過(guò)一次坑函數(shù)代碼里有個(gè)明顯的語(yǔ)法錯(cuò)誤保存后直接導(dǎo)致站點(diǎn)全部500。后來(lái)我學(xué)會(huì)了先在一個(gè)測(cè)試子域名上驗(yàn)證邊緣函數(shù)確認(rèn)穩(wěn)定后再把正式域名切過(guò)來(lái)。這個(gè)習(xí)慣救了我好多次。第四個(gè)小坑是“HTTPS回源端口別配錯(cuò)”。默認(rèn)回源端口是443還是80要看你源站實(shí)際監(jiān)聽(tīng)的端口。如果你的源站Nginx只監(jiān)聽(tīng)了80而你把ESA回源協(xié)議配成HTTPS回源握手就會(huì)失敗站點(diǎn)表現(xiàn)為間歇性打不開(kāi)。檢查源站端口和ESA回源配置是否一致是排查這類問(wèn)題的第一步。最后一點(diǎn)是別迷信“默認(rèn)配置”。ESA的默認(rèn)配置非常適合“快速上手”但離“好用”還有距離。你要花時(shí)間把緩存規(guī)則、WAF規(guī)則、監(jiān)控告警都按自己的業(yè)務(wù)重新調(diào)一遍才能發(fā)揮產(chǎn)品的真正價(jià)值。7. 一些真實(shí)感受和后續(xù)打算坦率說(shuō)用了這段時(shí)間的阿里云邊緣安全加速整體體驗(yàn)是超出預(yù)期的。它的價(jià)值不光是“網(wǎng)站變快了”“攻擊變少了”這種單點(diǎn)指標(biāo)而是把加速和安全這兩件以前需要分開(kāi)操心的事情收斂到了一個(gè)入口、一個(gè)控制臺(tái)、一套日志里。對(duì)我這種一個(gè)人要管好幾個(gè)網(wǎng)站和接口的開(kāi)發(fā)者來(lái)說(shuō)這種“少折騰”本身就是最大的價(jià)值。如果你問(wèn)我適合什么人用我大概會(huì)這么建議個(gè)人博客或純靜態(tài)站用普通CDN或?qū)ο蟠鎯?chǔ)靜態(tài)托管就夠了不太需要上ESA但如果你有動(dòng)態(tài)API、有小程序后端、有電商或內(nèi)容交易類業(yè)務(wù)同時(shí)又被掃描和攻擊搞得頭疼ESA可以認(rèn)真考慮。尤其是你已經(jīng)用了阿里云ECS、RDS、OSS這一整套生態(tài)的邊緣安全加速和這些產(chǎn)品之間天然打通配置鏈路和賬號(hào)體系都順滑很多。后面我準(zhǔn)備把ESA的邊緣函數(shù)好好再研究一下目前只是做了一些簡(jiǎn)單的請(qǐng)求改寫(xiě)和緩存控制據(jù)說(shuō)還可以做邊緣渲染和輕量業(yè)務(wù)邏輯如果能把我?guī)讉€(gè)小接口的邏輯直接下沉到邊緣節(jié)點(diǎn)源站說(shuō)不定能再省幾臺(tái)低配ECS。真跑通了我再來(lái)更新一篇實(shí)戰(zhàn)記錄。 阿里云邊緣安全加速ESA實(shí)戰(zhàn)：CDN與WAF一體化防護(hù)與性能優(yōu)化
1. 為什么我會(huì)盯上阿里云邊緣安全加速先說(shuō)背景。我自己手上有幾個(gè)網(wǎng)站和API服務(wù)有內(nèi)容類的、也有幾個(gè)給小程序提供數(shù)據(jù)的接口。前幾年一直用的是普通CDN圖個(gè)便宜省事把靜態(tài)資源一緩存帶寬成本確實(shí)壓下來(lái)了。但真正讓我覺(jué)得日子不好過(guò)的是這兩年網(wǎng)站流量慢慢上來(lái)之后各種掃描、撞庫(kù)、CC攻擊的請(qǐng)求也跟著漲幾臺(tái)源站服務(wù)器經(jīng)常莫名其妙被打到CPU報(bào)警。傳統(tǒng)CDN就管加速安全這塊基本是裸奔最多給個(gè)半死不活的IP黑白名單遇到真正像樣點(diǎn)的攻擊根本扛不住源站IP一暴露分分鐘被打穿。后來(lái)我仔細(xì)看了下阿里云的邊緣安全加速ESAEdge Security Acceleration簡(jiǎn)單說(shuō)就是把CDN加速和WAF、DDoS防護(hù)、訪問(wèn)控制這些安全能力統(tǒng)一放到了邊緣節(jié)點(diǎn)上。也就是說(shuō)用戶請(qǐng)求還沒(méi)到你的源站在離他最近的邊緣節(jié)點(diǎn)就已經(jīng)做完了安全檢測(cè)和流量清洗同時(shí)再把靜態(tài)內(nèi)容、動(dòng)態(tài)請(qǐng)求用最優(yōu)路徑回源。這種“安全加速一體”的思路比單獨(dú)買一臺(tái)高防服務(wù)器、或者CDN和WAF分開(kāi)配兩套方案省心不少也更省錢。當(dāng)然光看產(chǎn)品介紹誰(shuí)都會(huì)吹我自己也踩過(guò)不少“宣傳很豐滿落地很骨感”的坑。所以這篇文章主要是把近幾個(gè)月實(shí)打?qū)嵉氖褂皿w驗(yàn)做一個(gè)記錄從開(kāi)通配置、安全防護(hù)、性能表現(xiàn)、成本控制到各種奇奇怪怪的問(wèn)題都盡量寫(xiě)詳細(xì)。如果你也有類似的網(wǎng)站或接口在考慮要不要上邊緣安全加速這篇應(yīng)該能幫你省不少時(shí)間。2. 基礎(chǔ)配置階段最容易被忽略的幾個(gè)細(xì)節(jié)2.1 接入域名前先想清楚業(yè)務(wù)該走“加速”還是“安全”我第一次用ESA的時(shí)候腦子里想的就是“直接把域名CNAME解析過(guò)去就行”。但實(shí)際上阿里云邊緣安全加速的控制臺(tái)要比普通CDN復(fù)雜一些一上來(lái)就會(huì)遇到站點(diǎn)接入模式的選擇常見(jiàn)的有“CNAME接入”和“NS接入”兩種。CNAME接入比較簡(jiǎn)單就是把你需要的子域名單獨(dú)指到ESA分配的CNAME地址不影響其他域名的DNS解析。NS接入則是把整個(gè)域名的DNS服務(wù)器都托管給阿里云這樣所有子域名默認(rèn)都走ESA配置更省事控制力也更強(qiáng)但代價(jià)是整個(gè)域名的解析權(quán)都交出去了對(duì)于那些還有其他業(yè)務(wù)域名在跑的團(tuán)隊(duì)影響面比較大。我最后選的是CNAME接入因?yàn)槭稚嫌蛎嘤械挠肅loudflare的DNS管著有的是阿里云自家的混在一起如果用NS接入很容易誤傷其他業(yè)務(wù)。這里有個(gè)很關(guān)鍵的經(jīng)驗(yàn)接入之前一定要把業(yè)務(wù)分類。純靜態(tài)資源圖片、JS、CSS直接走默認(rèn)的加速配置就行安全策略不用開(kāi)太狠但如果你的接口API是給App或小程序用的就必須單獨(dú)建一個(gè)站點(diǎn)或域名分組把WAF規(guī)則、限流策略、Bot管理單獨(dú)調(diào)不然默認(rèn)規(guī)則很容易誤傷正常請(qǐng)求。我自己一開(kāi)始圖省事全部放到一個(gè)站點(diǎn)下結(jié)果某個(gè)API接口的請(qǐng)求被CC防護(hù)誤判攔了一部分排查了半天才發(fā)現(xiàn)是規(guī)則范圍太寬了。2.2 HTTPS證書(shū)配置解決“頁(yè)面不存在”這類怪問(wèn)題阿里云目前對(duì)ESA提供免費(fèi)證書(shū)的申請(qǐng)和自動(dòng)續(xù)期這個(gè)確實(shí)省心。但我還是要提醒一句如果你在邊緣安全加速上配了HTTPS源站那邊最好也把HTTPS配好并且證書(shū)要有效否則會(huì)碰到一個(gè)容易讓人抓狂的現(xiàn)象——瀏覽器訪問(wèn)頁(yè)面提示“抱歉您所指定的頁(yè)面不存在”。這個(gè)問(wèn)題的根源通常不是真的頁(yè)面不存在而是ESA邊緣節(jié)點(diǎn)回源的時(shí)候如果源站返回了418、302跳轉(zhuǎn)、或者SSL握手失敗ESA會(huì)把錯(cuò)誤信息緩存下來(lái)直接展示一個(gè)默認(rèn)錯(cuò)誤頁(yè)。尤其當(dāng)你之前用了別的CDN或者源站Nginx配了強(qiáng)制HTTPS跳轉(zhuǎn)邊緣節(jié)點(diǎn)回源時(shí)和源站之間協(xié)商協(xié)議不一致就會(huì)產(chǎn)生這種奇怪現(xiàn)象。我后來(lái)是把源站的強(qiáng)制跳轉(zhuǎn)關(guān)掉在ESA邊緣配置里統(tǒng)一做HTTP到HTTPS的跳轉(zhuǎn)同時(shí)把回源協(xié)議設(shè)為“HTTPS源站也走443”問(wèn)題就沒(méi)再出現(xiàn)過(guò)。還有一個(gè)細(xì)節(jié)證書(shū)續(xù)期之后如果ESA控制臺(tái)里的證書(shū)狀態(tài)沒(méi)有自動(dòng)更新你需要手動(dòng)點(diǎn)擊一下“更新證書(shū)”或重新部署。我遇到過(guò)幾次免費(fèi)證書(shū)自動(dòng)續(xù)期后控制臺(tái)顯示已生效但邊緣節(jié)點(diǎn)實(shí)際還是舊證書(shū)導(dǎo)致部分移動(dòng)端App請(qǐng)求失敗。排查方法很簡(jiǎn)單用OpenSSL命令看看實(shí)際證書(shū)的生效時(shí)間如果和控制臺(tái)不一致就手動(dòng)觸發(fā)一次證書(shū)重新下發(fā)。openssl s_client -connect 你的域名:443 -servername 你的域名 2/dev/null | openssl x509 -noout -dates2.3 回源配置的坑別讓源頭成為瓶頸很多人以為邊緣安全加速只要配好域名就萬(wàn)事大吉其實(shí)回源配置才是決定穩(wěn)定性的大頭。ESA支持“域名回源”和“IP回源”。如果你源站是阿里云ECS我建議直接用內(nèi)網(wǎng)IP回源走阿里云內(nèi)部網(wǎng)絡(luò)不占用公網(wǎng)帶寬延遲和穩(wěn)定性都要好很多。如果源站在其他云廠商或者自建機(jī)房那就只能用公網(wǎng)IP回源這時(shí)候一定要在源站的防火墻或安全組里只放行ESA的回源IP段。這里我必須強(qiáng)調(diào)千萬(wàn)要把回源IP段配到源站白名單里。我的源站之前被掃描器直接掃到IP然后瘋狂打源站就是因?yàn)榛卦碔P白名單沒(méi)配好。后來(lái)我在Nginx層加了一層allow/deny只允許ESA的回源IP訪問(wèn)源站的80和443端口攻擊流量即使繞過(guò)ESA直連IP也進(jìn)不來(lái)。# 僅放行指定回源IP段其他IP一律拒絕 allow 你的阿里云邊緣節(jié)點(diǎn)IP段1; allow 你的阿里云邊緣節(jié)點(diǎn)IP段2; deny all;如果你用的是阿里云ECS的Linux系統(tǒng)配置完記得安全組也要同步加一下規(guī)則ECS安全組和Nginx兩層都要放行ESA回源IP。這個(gè)弄完之后源站的壓力瞬間小了很多。3. 安全防護(hù)能力實(shí)測(cè)WAF和CC防護(hù)到底靈不靈3.1 WAF核心規(guī)則默認(rèn)規(guī)則夠用但別裸奔阿里云ESA內(nèi)置了一套WAF托管規(guī)則可以在控制臺(tái)一鍵開(kāi)啟。默認(rèn)規(guī)則覆蓋了常見(jiàn)的SQL注入、XSS攻擊、命令注入、惡意爬蟲(chóng)識(shí)別等。我開(kāi)啟之后讓同事配合做了一輪“安全測(cè)試”就是模擬一些常見(jiàn)的攻擊Payload比如在URL參數(shù)里傳 or 11 --這種結(jié)果還是相當(dāng)靠譜基本都能攔截下來(lái)并返回405或460狀態(tài)碼。但有一個(gè)容易被忽略的點(diǎn)WAF托管規(guī)則默認(rèn)會(huì)對(duì)所有請(qǐng)求做檢測(cè)這會(huì)導(dǎo)致一些正常情況下看起來(lái)“不太正?！钡暮戏ㄕ?qǐng)求被誤判。比如我有個(gè)接口參數(shù)里本身允許用戶傳一段帶有特殊字符的文本像英文單引號(hào)、尖括號(hào)、SQL關(guān)鍵字之類結(jié)果被WAF當(dāng)成注入攻擊給攔了。解決方案有兩條一是把對(duì)應(yīng)的接口加入WAF白名單另一個(gè)更推薦的做法是在ESA控制臺(tái)里給該站點(diǎn)單獨(dú)配置更精細(xì)的規(guī)則把包含這些參數(shù)的URI排除在檢測(cè)范圍之外。千萬(wàn)別圖省事直接把整個(gè)站點(diǎn)的WAF關(guān)掉。還有一點(diǎn)WAF的攔截模式默認(rèn)是“觀察”還是“攔截”這個(gè)是可以在控制臺(tái)調(diào)的。我第一次開(kāi)啟時(shí)默認(rèn)是攔截模式結(jié)果某天晚上網(wǎng)站訪問(wèn)量突然掉了一半一看日志才發(fā)現(xiàn)某個(gè)老接口的POST請(qǐng)求一直被攔截。后來(lái)我先把WAF切到“觀察”模式跑了一個(gè)禮拜每天看誤判日志把正常業(yè)務(wù)請(qǐng)求加到白名單之后才重新切回“攔截”模式。所以凡是涉及到規(guī)則變更建議都先觀察后攔截不要一上來(lái)就開(kāi)大招。3.2 CC防護(hù)與限流別把正常用戶也攔在外面CC攻擊Challenge Collapsar簡(jiǎn)單說(shuō)就是模擬正常用戶的高頻請(qǐng)求把源站和邊緣節(jié)點(diǎn)的資源耗光。ESA的CC防護(hù)和頻控規(guī)則我實(shí)際體驗(yàn)下來(lái)對(duì)單一IP的突發(fā)高頻請(qǐng)求識(shí)別還是比較準(zhǔn)的。尤其是針對(duì)登錄接口、短信發(fā)送接口這類容易被“羊毛黨”盯上的路徑可以配置“單IP每秒鐘允許請(qǐng)求數(shù)”和“單IP每分鐘允許請(qǐng)求數(shù)”兩個(gè)維度。這里有一個(gè)很實(shí)際的調(diào)優(yōu)經(jīng)驗(yàn)。我最初把某個(gè)API的單IP閾值設(shè)成了“每秒10次”想著正常用戶不太可能一秒請(qǐng)求10次結(jié)果活動(dòng)期間用戶集中搶券一個(gè)辦公室出口IP下可能有幾十個(gè)人共用瞬間就被限流攔掉了。后來(lái)我把閾值調(diào)成“每秒20次”同時(shí)加上“每個(gè)會(huì)話Cookie每秒鐘最多5次”的二級(jí)限制才兼顧了正常用戶和防刷需求。CC防護(hù)的攔截閾值沒(méi)有絕對(duì)標(biāo)準(zhǔn)得看你的業(yè)務(wù)形態(tài)。如果是面向C端的高并發(fā)API單IP閾值適當(dāng)放寬如果是后臺(tái)管理系統(tǒng)或者管理接口閾值就要收得很緊甚至可以配置只允許指定IP段訪問(wèn)。有條件的話把辦公網(wǎng)的出口IP加進(jìn)白名單避免自己人把賬號(hào)鎖了。3.3 自定義規(guī)則和Bot管理的實(shí)戰(zhàn)經(jīng)驗(yàn)ESA的自定義攔截規(guī)則部分我后來(lái)花的精力最多。除了默認(rèn)的WAF規(guī)則它還支持按Header、Cookie、URI、參數(shù)等多個(gè)維度組合條件做攔截或放行。比如有段時(shí)間有個(gè)爬蟲(chóng)一直用同一類User-Agent瘋狂抓數(shù)據(jù)我在控制臺(tái)配置了一條規(guī)則User-Agent包含特定關(guān)鍵字比如某些Python庫(kù)、爬蟲(chóng)框架且URI匹配到數(shù)據(jù)接口路徑直接攔截。配置生效后這類請(qǐng)求的日志立馬安靜了效果立竿見(jiàn)影。Bot管理這個(gè)是針對(duì)更高級(jí)的爬蟲(chóng)的能識(shí)別無(wú)頭瀏覽器、模擬瀏覽器行為的請(qǐng)求。我體驗(yàn)下來(lái)確實(shí)有一定效果但對(duì)性能有一定損耗請(qǐng)求耗時(shí)會(huì)有微小的增加。如果你的網(wǎng)站是靜態(tài)頁(yè)為主CDN緩存命中率高其實(shí)不太需要開(kāi)Bot管理但如果你的核心資產(chǎn)是API數(shù)據(jù)接口開(kāi)了Bot管理之后精準(zhǔn)度提升明顯。這個(gè)可以根據(jù)業(yè)務(wù)接口的重要程度按域名開(kāi)啟不用全局都開(kāi)。還有一點(diǎn)提醒大家ESA的安全日志和攔截日志都是可以在控制臺(tái)實(shí)時(shí)查看的一定要養(yǎng)成定期翻日志的習(xí)慣。我至少每周看一次攔截報(bào)表關(guān)注哪些路徑被攻擊得多、哪些規(guī)則在誤殺及時(shí)做調(diào)整。4. 加速性能實(shí)測(cè)不只是靜態(tài)緩存那么簡(jiǎn)單4.1 動(dòng)靜態(tài)混合加速對(duì)比傳統(tǒng)CDN的優(yōu)勢(shì)傳統(tǒng)CDN對(duì)靜態(tài)資源加速效果很好但是遇到帶參數(shù)的動(dòng)態(tài)請(qǐng)求、API接口、登錄請(qǐng)求往往是直接回源速度提升不明顯。ESA在這方面做了一些優(yōu)化把自己的動(dòng)態(tài)加速DCDN能力也整合進(jìn)來(lái)了通過(guò)智能路由、TCP優(yōu)化等手段讓動(dòng)態(tài)請(qǐng)求也能選擇最優(yōu)鏈路回源減少公網(wǎng)鏈路抖動(dòng)帶來(lái)的延遲。我實(shí)際做了對(duì)比測(cè)試。同樣一個(gè)API接口直接請(qǐng)求源站IP的延遲在80~120毫秒左右經(jīng)過(guò)普通CDN回源之后延遲反而可能會(huì)比直連源站還高一點(diǎn)但經(jīng)過(guò)ESA的動(dòng)態(tài)加速之后從廣州、北京、上海三個(gè)地點(diǎn)測(cè)試平均延遲能降到40~70毫秒。對(duì)于需要多次請(qǐng)求才能完成一個(gè)業(yè)務(wù)動(dòng)作的App來(lái)說(shuō)這個(gè)延遲差距體感非常明顯。這里也補(bǔ)充一下ESA的動(dòng)態(tài)加速能力很多是在邊緣節(jié)點(diǎn)上通過(guò)應(yīng)用層協(xié)議優(yōu)化實(shí)現(xiàn)的比如HTTP/2、HTTP/3QUIC的加速。我開(kāi)啟HTTP/3之后弱網(wǎng)環(huán)境下比如地鐵、電梯里的加載速度提升比較明顯。不過(guò)要注意的是如果你的網(wǎng)站不支持HTTPS那HTTP/3根本用不上所以基礎(chǔ)HTTPS配置一定要先做好。4.2 緩存命中率優(yōu)化讓邊緣節(jié)點(diǎn)真正“扛活”邊緣安全加速不只是安全產(chǎn)品它的本質(zhì)還是個(gè)CDN所以緩存命中率直接影響回源壓力和用戶體驗(yàn)。我剛開(kāi)始接入的時(shí)候緩存命中率只有50%左右源站壓力還是很大。后來(lái)我發(fā)現(xiàn)問(wèn)題出在緩存策略上默認(rèn)配置對(duì)帶參數(shù)的URL基本不緩存每次請(qǐng)求都回源。于是我專門花了半天時(shí)間梳理了網(wǎng)站的請(qǐng)求類型圖片、CSS、JS、字體這些靜態(tài)資源沒(méi)有Cookie的、URL不帶參數(shù)的全部設(shè)置成“忽略查詢字符串”的緩存模式緩存時(shí)間設(shè)為1天到7天不等HTML頁(yè)面設(shè)置成緩存10分鐘配合源站每次發(fā)布后主動(dòng)刷新緩存API接口則按業(yè)務(wù)容忍度設(shè)置緩存30秒到5分鐘數(shù)據(jù)要求實(shí)時(shí)性高的不緩存。這么調(diào)完以后緩存命中率從50%提升到了90%以上源站后端服務(wù)器的CPU使用率直接降了大約40%。這里想提醒大家緩存配置的核心思路是“能緩存的一定要緩存不能緩存的一分鐘都別亂存”尤其對(duì)于電商類網(wǎng)站如果把購(gòu)物車接口緩存了會(huì)出現(xiàn)加購(gòu)后看不到商品這種嚴(yán)重事故。寧可犧牲一點(diǎn)速度也不能犧牲數(shù)據(jù)一致性。4.3 實(shí)時(shí)日志和監(jiān)控告警別等用戶投訴才發(fā)現(xiàn)問(wèn)題最后想聊一下監(jiān)控這塊。ESA控制臺(tái)提供了詳細(xì)的訪問(wèn)日志、回源日志、攔截日志和實(shí)時(shí)監(jiān)控面板。我強(qiáng)烈建議你開(kāi)通日志服務(wù)或至少訂閱實(shí)時(shí)日志把ESA日志投遞到自己的日志平臺(tái)比如阿里云SLS或自建ELK這樣出問(wèn)題的時(shí)候可以快速定位而不是登錄控制臺(tái)一頁(yè)一頁(yè)翻。我自己就吃過(guò)虧。有段時(shí)間邊緣節(jié)點(diǎn)命中率很低但是控制臺(tái)總覽頁(yè)看著延遲還行直到有用戶反饋App打開(kāi)圖片很慢我才去翻日志發(fā)現(xiàn)大部分請(qǐng)求都回源了源站在高峰期被拖垮導(dǎo)致整體變慢。后來(lái)配置了“回源帶寬”“回源請(qǐng)求數(shù)”“5xx錯(cuò)誤率”這幾個(gè)監(jiān)控項(xiàng)的告警閾值一超過(guò)就會(huì)收到短信和郵件通知。這個(gè)告警一定要配而且要配在回源側(cè)因?yàn)檫吘壒?jié)點(diǎn)的帶寬有緩存扛著看起來(lái)再平穩(wěn)回源側(cè)可能已經(jīng)冒煙了。5. 賬算明白邊緣安全加速到底花多少錢5.1 計(jì)費(fèi)項(xiàng)拆解別被“按量付費(fèi)”嚇到很多人在意ESA的價(jià)格說(shuō)實(shí)話我第一次看計(jì)費(fèi)文檔也頭大因?yàn)橛屑铀倭髁抠M(fèi)、安全防護(hù)費(fèi)WAF規(guī)則數(shù)、Bot管理、動(dòng)態(tài)請(qǐng)求數(shù)費(fèi)用、邊緣函數(shù)調(diào)用次數(shù)費(fèi)等多個(gè)維度。不過(guò)實(shí)際用下來(lái)大部分中小網(wǎng)站的賬單大頭還是“流量費(fèi)”和“請(qǐng)求數(shù)”。我自己的網(wǎng)站是內(nèi)容站API服務(wù)日均請(qǐng)求量大概40萬(wàn)次其中靜態(tài)資源請(qǐng)求占70%API請(qǐng)求占30%。啟用ESA之后靜態(tài)請(qǐng)求基本被緩存節(jié)點(diǎn)直接扛掉真正回源的請(qǐng)求量很少所以加速流量費(fèi)并沒(méi)有想象中那么高。而安全防護(hù)這塊基礎(chǔ)WAF托管規(guī)則是包含在套餐里的只要不額外買高級(jí)版的自定義規(guī)則數(shù)和Bot管理費(fèi)用還是比較可控的。對(duì)比之前我用的“普通CDN另一家云WAF”的組合ESA的費(fèi)用大概便宜了20%~30%而且運(yùn)維成本低了不止一星半點(diǎn)。以前兩個(gè)控制臺(tái)來(lái)回切換出了問(wèn)題還要猜是CDN的問(wèn)題還是WAF的問(wèn)題現(xiàn)在一個(gè)產(chǎn)品全解決出問(wèn)題看ESA的日志基本就夠定位了。5.2 成本優(yōu)化的幾個(gè)實(shí)操方向如果你發(fā)現(xiàn)月底賬單超出預(yù)期不用急著換產(chǎn)品先做這幾件事第一梳理緩存策略。緩存命中率每提升10%回源流量就少一大截費(fèi)用自然降下來(lái)。把圖片這類大頭靜態(tài)資源緩存時(shí)間盡量拉長(zhǎng)版本更新時(shí)用文件名加版本號(hào)的方式來(lái)刷新而不是頻繁地手動(dòng)緩存刷新。第二確認(rèn)有沒(méi)有不必要的“動(dòng)態(tài)請(qǐng)求加速”。ESA對(duì)動(dòng)態(tài)請(qǐng)求有單獨(dú)的計(jì)費(fèi)如果你的接口本身離源站很近比如源站和用戶都在同一城市那動(dòng)態(tài)加速帶來(lái)的收益有限可以只對(duì)需要跨地域訪問(wèn)的API開(kāi)啟動(dòng)態(tài)加速把省下來(lái)的錢花在其他地方。第三安全規(guī)則不是越多越好。ESA的WAF自定義規(guī)則如果超過(guò)免費(fèi)額度會(huì)按條數(shù)計(jì)費(fèi)。我見(jiàn)過(guò)有人為了圖心理安慰一口氣配了上百條規(guī)則最后發(fā)現(xiàn)有一半以上的規(guī)則命中率為0。定期檢查規(guī)則命中率把完全沒(méi)用的規(guī)則刪掉能省一部分費(fèi)用。第四如果你只是個(gè)人博客或輕量站點(diǎn)可以先從按量付費(fèi)跑起來(lái)觀察一個(gè)月的賬單規(guī)模再?zèng)Q定要不要買資源包。資源包適合流量比較穩(wěn)定的業(yè)務(wù)價(jià)格能便宜不少如果流量波動(dòng)大按量付費(fèi)反而更靈活不會(huì)因?yàn)橘I了包用不完造成浪費(fèi)。5.3 從“救火”到“日常運(yùn)營(yíng)”的心態(tài)轉(zhuǎn)變最后說(shuō)一個(gè)花了不少錢才想明白的道理邊緣安全加速不是裝上就一勞永逸的。它是一個(gè)需要持續(xù)運(yùn)維的東西。安全規(guī)則要定期調(diào)緩存策略要跟著業(yè)務(wù)版本走監(jiān)控告警要有專人盯。我之前一直以為它是“裸奔”網(wǎng)站的救命稻草用了之后才悟了真正讓網(wǎng)站穩(wěn)的是你有沒(méi)有一套持續(xù)的運(yùn)營(yíng)流程。我現(xiàn)在的做法是每周固定花一小時(shí)看ESA的攔截報(bào)表和監(jiān)控?cái)?shù)據(jù)每次發(fā)版前先檢查一下緩存策略是否需要調(diào)整特別是有沒(méi)有新增的API路徑不小心被緩存了每季度做一次規(guī)則梳理把長(zhǎng)期零命中的規(guī)則清理掉。這套流程執(zhí)行下來(lái)網(wǎng)站的穩(wěn)定性、用戶口碑都有了實(shí)打?qū)嵉奶嵘?. 那些年我踩過(guò)的坑給你提個(gè)醒最后再分享幾個(gè)具體問(wèn)題都是我實(shí)際遇到過(guò)、并且在文檔里不容易直接找到答案的。第一個(gè)是“群里問(wèn)了幾百遍沒(méi)人理”的證書(shū)續(xù)期后顯示不生效問(wèn)題。如果你用了阿里云免費(fèi)證書(shū)到期后證書(shū)會(huì)自動(dòng)續(xù)期但ESA控制臺(tái)里的“證書(shū)狀態(tài)”不一定馬上同步。遇到這種情況直接把證書(shū)重新部署一遍不用重新申請(qǐng)通常幾秒鐘就生效了。部署完記得用第一節(jié)里的OpenSSL命令驗(yàn)證一下實(shí)際證書(shū)時(shí)間不要只看控制臺(tái)。第二個(gè)是“換SSL證書(shū)后網(wǎng)站報(bào)錯(cuò)”的問(wèn)題。有些同學(xué)在群暉NAS或者其他服務(wù)器上換了新證書(shū)但瀏覽器訪問(wèn)還是報(bào)錯(cuò)甚至提示頁(yè)面不存在或證書(shū)無(wú)效。這種現(xiàn)象多半是因?yàn)檫吘壒?jié)點(diǎn)緩存了舊證書(shū)狀態(tài)或者瀏覽器緩存里的HSTS記錄還指向舊證書(shū)。清一下瀏覽器緩存再用無(wú)痕模式訪問(wèn)試試如果還不行就在ESA控制臺(tái)重新下發(fā)一次證書(shū)。第三個(gè)是“邊緣函數(shù)配置出錯(cuò)導(dǎo)致整個(gè)站點(diǎn)500”。邊緣函數(shù)確實(shí)很強(qiáng)大可以在邊緣直接改寫(xiě)請(qǐng)求、做鑒權(quán)、做響應(yīng)頭注入。但它一旦崩了影響的是整個(gè)域名。我在邊緣函數(shù)測(cè)試階段就踩過(guò)一次坑函數(shù)代碼里有個(gè)明顯的語(yǔ)法錯(cuò)誤保存后直接導(dǎo)致站點(diǎn)全部500。后來(lái)我學(xué)會(huì)了先在一個(gè)測(cè)試子域名上驗(yàn)證邊緣函數(shù)確認(rèn)穩(wěn)定后再把正式域名切過(guò)來(lái)。這個(gè)習(xí)慣救了我好多次。第四個(gè)小坑是“HTTPS回源端口別配錯(cuò)”。默認(rèn)回源端口是443還是80要看你源站實(shí)際監(jiān)聽(tīng)的端口。如果你的源站Nginx只監(jiān)聽(tīng)了80而你把ESA回源協(xié)議配成HTTPS回源握手就會(huì)失敗站點(diǎn)表現(xiàn)為間歇性打不開(kāi)。檢查源站端口和ESA回源配置是否一致是排查這類問(wèn)題的第一步。最后一點(diǎn)是別迷信“默認(rèn)配置”。ESA的默認(rèn)配置非常適合“快速上手”但離“好用”還有距離。你要花時(shí)間把緩存規(guī)則、WAF規(guī)則、監(jiān)控告警都按自己的業(yè)務(wù)重新調(diào)一遍才能發(fā)揮產(chǎn)品的真正價(jià)值。7. 一些真實(shí)感受和后續(xù)打算坦率說(shuō)用了這段時(shí)間的阿里云邊緣安全加速整體體驗(yàn)是超出預(yù)期的。它的價(jià)值不光是“網(wǎng)站變快了”“攻擊變少了”這種單點(diǎn)指標(biāo)而是把加速和安全這兩件以前需要分開(kāi)操心的事情收斂到了一個(gè)入口、一個(gè)控制臺(tái)、一套日志里。對(duì)我這種一個(gè)人要管好幾個(gè)網(wǎng)站和接口的開(kāi)發(fā)者來(lái)說(shuō)這種“少折騰”本身就是最大的價(jià)值。如果你問(wèn)我適合什么人用我大概會(huì)這么建議個(gè)人博客或純靜態(tài)站用普通CDN或?qū)ο蟠鎯?chǔ)靜態(tài)托管就夠了不太需要上ESA但如果你有動(dòng)態(tài)API、有小程序后端、有電商或內(nèi)容交易類業(yè)務(wù)同時(shí)又被掃描和攻擊搞得頭疼ESA可以認(rèn)真考慮。尤其是你已經(jīng)用了阿里云ECS、RDS、OSS這一整套生態(tài)的邊緣安全加速和這些產(chǎn)品之間天然打通配置鏈路和賬號(hào)體系都順滑很多。后面我準(zhǔn)備把ESA的邊緣函數(shù)好好再研究一下目前只是做了一些簡(jiǎn)單的請(qǐng)求改寫(xiě)和緩存控制據(jù)說(shuō)還可以做邊緣渲染和輕量業(yè)務(wù)邏輯如果能把我?guī)讉€(gè)小接口的邏輯直接下沉到邊緣節(jié)點(diǎn)源站說(shuō)不定能再省幾臺(tái)低配ECS。真跑通了我再來(lái)更新一篇實(shí)戰(zhàn)記錄。