Next.js 應(yīng)用除了部署在函數(shù)服務(wù)上還可以選擇運(yùn)行在邊緣節(jié)點(diǎn)。IGA Pages 是火山引擎的產(chǎn)品和阿里云 ESA 屬于相近的邊緣加速類產(chǎn)品它們都把站點(diǎn)加速能力和一部分邊緣運(yùn)行能力結(jié)合起來讓應(yīng)用有機(jī)會(huì)在距離用戶更近的節(jié)點(diǎn)處理請(qǐng)求。但邊緣部署并不是所有 Next.js 應(yīng)用的最佳選擇。真正需要考慮的問題是服務(wù)端到底在做多少計(jì)算、需要訪問多少次數(shù)據(jù)庫以及這些數(shù)據(jù)服務(wù)是否靠近邊緣節(jié)點(diǎn)。一、IGA Pages 和函數(shù)服務(wù)有什么區(qū)別IGA Pages 與阿里云 ESA 可以放在同一類產(chǎn)品中理解但它們不是同一個(gè)產(chǎn)品運(yùn)行時(shí)支持、部署方式和配置限制也不能直接類比實(shí)際使用時(shí)仍然要以各自的官方文檔為準(zhǔn)。函數(shù)服務(wù)通常是在某個(gè)中心區(qū)域運(yùn)行應(yīng)用再通過 DCDN 把用戶請(qǐng)求加速到這個(gè)區(qū)域。它的特點(diǎn)是應(yīng)用代碼和數(shù)據(jù)庫可以放在相近的區(qū)域服務(wù)端訪問數(shù)據(jù)庫的路徑比較短。IGA Pages 更接近邊緣運(yùn)行模式應(yīng)用代碼或服務(wù)端邏輯可以部署到邊緣節(jié)點(diǎn)用戶請(qǐng)求有機(jī)會(huì)在距離自己更近的節(jié)點(diǎn)得到處理。它本身就依托邊緣加速產(chǎn)品提供訪問加速不是一個(gè)需要再額外掛一層 DCDN 的普通源站。兩種方式的核心區(qū)別可以簡(jiǎn)單概括為函數(shù)服務(wù) DCDN應(yīng)用集中運(yùn)行DCDN 負(fù)責(zé)把用戶請(qǐng)求和靜態(tài)資源加速到應(yīng)用所在區(qū)域。IGA Pages應(yīng)用的一部分運(yùn)行能力下沉到邊緣節(jié)點(diǎn)用戶請(qǐng)求可以在更靠近用戶的位置處理。這里的“更靠近用戶”不等于“更靠近數(shù)據(jù)庫”。邊緣節(jié)點(diǎn)帶來的收益最終要和服務(wù)端訪問數(shù)據(jù)的代價(jià)一起評(píng)估。二、先區(qū)分 SSR 和服務(wù)端 API這兩個(gè)詞經(jīng)常一起出現(xiàn)但它們描述的不是同一件事。**SSR服務(wù)端渲染**描述的是頁面生成方式用戶請(qǐng)求頁面時(shí)由服務(wù)端生成 HTML再返回給瀏覽器。SSR 的過程中可以讀取數(shù)據(jù)庫、調(diào)用外部服務(wù)也可以完全不訪問數(shù)據(jù)庫。服務(wù)端 API描述的是接口形態(tài)瀏覽器或其他服務(wù)請(qǐng)求一個(gè)接口服務(wù)端通常返回 JSON 或其他數(shù)據(jù)。Next.js 中常見的實(shí)現(xiàn)是 Route Handler。它主要用于數(shù)據(jù)讀寫、鑒權(quán)、調(diào)用第三方服務(wù)等并不等于頁面渲染。一個(gè) Next.js 應(yīng)用可以同時(shí)擁有 SSR 頁面和服務(wù)端 API但兩者的請(qǐng)求路徑和職責(zé)應(yīng)該分開理解SSR服務(wù)端生成頁面 HTML。服務(wù)端 API服務(wù)端響應(yīng)數(shù)據(jù)或執(zhí)行操作。服務(wù)端組件直接讀取數(shù)據(jù)庫這是服務(wù)端數(shù)據(jù)訪問不自動(dòng)等于一個(gè)對(duì)外 API。因此不能把所有服務(wù)端邏輯都稱為 SSR也不要因?yàn)榇a運(yùn)行在 Next.js 服務(wù)端就把它統(tǒng)稱為 API。三、為什么數(shù)據(jù)庫位置很重要如果頁面是純靜態(tài)的邊緣節(jié)點(diǎn)離用戶越近通常越有優(yōu)勢(shì)。但如果頁面使用 SSR或者服務(wù)端 API 需要訪問數(shù)據(jù)庫情況就復(fù)雜了邊緣節(jié)點(diǎn)處理請(qǐng)求時(shí)仍然要訪問數(shù)據(jù)庫和其他后端服務(wù)。假設(shè)數(shù)據(jù)庫還在大陸而某個(gè)用戶的請(qǐng)求被分配到海外邊緣節(jié)點(diǎn)那么一次 SSR 請(qǐng)求可能經(jīng)過這樣的路徑用戶 → 海外邊緣節(jié)點(diǎn) → 大陸數(shù)據(jù)庫 → 海外邊緣節(jié)點(diǎn) → 用戶這時(shí)代碼雖然離用戶近了但服務(wù)端訪問數(shù)據(jù)庫變遠(yuǎn)了。每次頁面渲染都要跨區(qū)域請(qǐng)求延遲可能抵消邊緣部署帶來的收益數(shù)據(jù)庫連接、網(wǎng)絡(luò)穩(wěn)定性和跨區(qū)域流量成本也需要關(guān)注。不過不能簡(jiǎn)單地認(rèn)為“只要用了數(shù)據(jù)庫就不適合邊緣節(jié)點(diǎn)”。關(guān)鍵要看計(jì)算和數(shù)據(jù)訪問的比例計(jì)算很密集、數(shù)據(jù)庫查詢較少這類服務(wù)端邏輯通常比較適合放到邊緣節(jié)點(diǎn)。請(qǐng)求可以在靠近用戶的地方完成較多計(jì)算只進(jìn)行少量數(shù)據(jù)讀取或校驗(yàn)。數(shù)據(jù)庫查詢非常密集這類邏輯通常不適合直接放到邊緣節(jié)點(diǎn)尤其是查詢之間存在串行依賴、讀寫頻繁或者數(shù)據(jù)庫集中在單一區(qū)域時(shí)。大量邊緣節(jié)點(diǎn)到數(shù)據(jù)庫的往返調(diào)用會(huì)讓網(wǎng)絡(luò)延遲成為主要瓶頸。這里要關(guān)注的不只是“查詢次數(shù)”還包括每次查詢是否必須等待上一次結(jié)果、數(shù)據(jù)量大小、讀寫比例以及數(shù)據(jù)庫是否在邊緣節(jié)點(diǎn)附近。邊緣節(jié)點(diǎn)解決的是用戶到計(jì)算節(jié)點(diǎn)的距離并不能自動(dòng)解決計(jì)算節(jié)點(diǎn)到數(shù)據(jù)庫的距離。也因此給數(shù)據(jù)庫服務(wù)例如 Supabase再套一層加速通常不是優(yōu)先方向。數(shù)據(jù)庫請(qǐng)求包含鑒權(quán)、讀寫、連接和一致性等問題不是把一個(gè)靜態(tài)文件放到 CDN 上那么簡(jiǎn)單。更值得先問的是數(shù)據(jù)庫是不是本來就應(yīng)該部署在海外國(guó)內(nèi)和海外的應(yīng)用、服務(wù)端以及數(shù)據(jù)庫是否應(yīng)該完全拆成兩套如果用戶、計(jì)算和數(shù)據(jù)主要在海外把數(shù)據(jù)庫直接部署在海外通常比讓國(guó)內(nèi)服務(wù)端或邊緣節(jié)點(diǎn)跨區(qū)域訪問數(shù)據(jù)庫更合理。對(duì)于同時(shí)面向國(guó)內(nèi)和海外的應(yīng)用也可以評(píng)估國(guó)內(nèi)、海外分別部署服務(wù)端和數(shù)據(jù)庫讓兩邊的請(qǐng)求盡量在本地閉環(huán)減少跨境調(diào)用和數(shù)據(jù)流動(dòng)。這種按地域拆分的架構(gòu)通常也更容易做數(shù)據(jù)隔離和合規(guī)管理但具體方案仍然需要結(jié)合業(yè)務(wù)類型、數(shù)據(jù)分類和適用法規(guī)單獨(dú)評(píng)估。下面用一個(gè)相對(duì)復(fù)雜的典型場(chǎng)景說明這種數(shù)據(jù)流向。它不是把 Supabase 當(dāng)成普通源站交給 DCDN 加速而是先按用戶地域拆分接入層、Next.js 服務(wù)端和數(shù)據(jù)庫讓 SSR 頁面渲染與服務(wù)端 API 的數(shù)據(jù)請(qǐng)求都盡量在同一區(qū)域完成。四、哪些應(yīng)用適合部署到邊緣節(jié)點(diǎn)純靜態(tài)應(yīng)用這是最適合的場(chǎng)景。頁面構(gòu)建后就能直接分發(fā)不需要在邊緣節(jié)點(diǎn)實(shí)時(shí)訪問數(shù)據(jù)庫用戶可以從附近節(jié)點(diǎn)獲取靜態(tài)文件。計(jì)算密集、數(shù)據(jù)訪問較少的服務(wù)端邏輯如果請(qǐng)求主要是在做計(jì)算而不是反復(fù)查詢數(shù)據(jù)庫例如請(qǐng)求改寫、輕量級(jí)鑒權(quán)、規(guī)則計(jì)算、內(nèi)容處理或數(shù)據(jù)預(yù)處理并且只需要少量數(shù)據(jù)讀取那么把這類邏輯放到邊緣節(jié)點(diǎn)通常比較合適。前后端已經(jīng)分離的應(yīng)用如果前端只是展示頁面服務(wù)端 API 集中部署在靠近數(shù)據(jù)庫的區(qū)域那么可以把前端放到邊緣節(jié)點(diǎn)把數(shù)據(jù)請(qǐng)求交給服務(wù)端 API 處理。這種方式需要單獨(dú)考慮跨域、鑒權(quán)、接口延遲和緩存策略但整體架構(gòu)邊界比較清晰。這里要注意前端部署在邊緣節(jié)點(diǎn)不代表服務(wù)端 API 也必須部署在邊緣節(jié)點(diǎn)。數(shù)據(jù)庫和邊緣運(yùn)行區(qū)域匹配的應(yīng)用如果數(shù)據(jù)庫本身有合適的全球化部署方案或者應(yīng)用的用戶、計(jì)算節(jié)點(diǎn)和數(shù)據(jù)都集中在相近區(qū)域邊緣 SSR 或邊緣服務(wù)端 API 才更有機(jī)會(huì)體現(xiàn)優(yōu)勢(shì)。五、哪些應(yīng)用不適合直接放到邊緣如果應(yīng)用有大量動(dòng)態(tài)頁面SSR 需要頻繁訪問一個(gè)距離邊緣節(jié)點(diǎn)很遠(yuǎn)的數(shù)據(jù)庫或者服務(wù)端 API 的一次請(qǐng)求需要多次串行查詢數(shù)據(jù)庫就不建議為了“全球加速”直接遷移到邊緣節(jié)點(diǎn)。這類應(yīng)用更適合先把服務(wù)端邏輯部署在靠近數(shù)據(jù)庫的函數(shù)服務(wù)中再用 DCDN 加速靜態(tài)資源和用戶訪問。這樣雖然代碼不是全部運(yùn)行在邊緣但數(shù)據(jù)訪問路徑更可控。尤其需要注意下面這種部署方式服務(wù)端部署在海外邊緣節(jié)點(diǎn)數(shù)據(jù)庫部署在大陸每個(gè)請(qǐng)求又需要多次讀寫數(shù)據(jù)庫。這種情況下邊緣節(jié)點(diǎn)離用戶近但離數(shù)據(jù)庫遠(yuǎn)整體響應(yīng)速度可能反而更差。對(duì)于數(shù)據(jù)庫訪問密集的應(yīng)用應(yīng)優(yōu)先保證服務(wù)端和數(shù)據(jù)庫之間的低延遲再考慮把用戶側(cè)的靜態(tài)內(nèi)容和可緩存內(nèi)容交給 DCDN。若業(yè)務(wù)確實(shí)主要在海外還應(yīng)該優(yōu)先評(píng)估把數(shù)據(jù)庫直接部署在海外而不是繼續(xù)嘗試給現(xiàn)有數(shù)據(jù)庫鏈路疊加加速層。六、IGA Pages 不能再在前面疊加一層 DCDN邊緣加速產(chǎn)品本身通常就依托 DCDN 提供全球或區(qū)域加速能力。IGA Pages 已經(jīng)屬于這一類產(chǎn)品因此不應(yīng)該再在它的前面掛另一層 DCDN。如果把一個(gè)邊緣加速產(chǎn)品的域名再配置成另一個(gè) DCDN 的加速對(duì)象或源站兩個(gè)加速層之間可能形成回環(huán)。平臺(tái)會(huì)進(jìn)行回環(huán)檢測(cè)發(fā)現(xiàn)這種配置后通常會(huì)禁止接入或拒絕生效。所以需要先區(qū)分兩種架構(gòu)函數(shù)服務(wù)作為源站 DCDN這是常見的“中心區(qū)域計(jì)算、邊緣加速訪問”架構(gòu)。IGA Pages它本身已經(jīng)包含邊緣加速能力不要再在前面疊加 DCDN。如果需要精細(xì)控制 DCDN 的緩存、路由和傳輸參數(shù)通常應(yīng)該選擇函數(shù)服務(wù)加獨(dú)立 DCDN而不是把 IGA Pages 當(dāng)作普通源站再接入一層 DCDN。七、IGA Pages 的配置限制IGA Pages 的優(yōu)點(diǎn)是把一部分部署和加速能力整合起來但代價(jià)是可調(diào)參數(shù)相對(duì)少。例如HTTP/2、Gzip 等能力不一定能像獨(dú)立配置 DCDN 那樣由用戶自由調(diào)整部分配置可能需要通過工單開通。如果你需要精細(xì)控制緩存、路由和傳輸參數(shù)獨(dú)立使用函數(shù)服務(wù)加 DCDN 會(huì)更靈活。結(jié)論先看計(jì)算和數(shù)據(jù)路徑再看節(jié)點(diǎn)距離IGA Pages 適合純靜態(tài)站點(diǎn)、計(jì)算密集且數(shù)據(jù)庫訪問較少的服務(wù)端邏輯、前后端分離的前端應(yīng)用以及計(jì)算節(jié)點(diǎn)和數(shù)據(jù)服務(wù)能夠就近部署的應(yīng)用。如果你的 Next.js 應(yīng)用使用 SSR或者有服務(wù)端 API并且服務(wù)端要頻繁訪問固定區(qū)域的數(shù)據(jù)庫邊緣節(jié)點(diǎn)未必更快。此時(shí)更應(yīng)該優(yōu)先保證服務(wù)端和數(shù)據(jù)庫之間的低延遲再使用 DCDN 加速用戶訪問。判斷是否使用 IGA Pages可以先問自己四個(gè)問題這是純靜態(tài)內(nèi)容還是需要 SSR 或服務(wù)端 API服務(wù)端邏輯主要是計(jì)算還是主要在查詢數(shù)據(jù)庫數(shù)據(jù)庫是否靠近應(yīng)用將要運(yùn)行的邊緣區(qū)域是否已經(jīng)使用了邊緣加速產(chǎn)品避免再疊加一層 DCDN 形成回環(huán)如果服務(wù)端計(jì)算量較大、數(shù)據(jù)庫訪問較少并且沒有明顯的跨區(qū)域數(shù)據(jù)訪問問題邊緣部署值得優(yōu)先評(píng)估。反過來如果數(shù)據(jù)庫查詢密集、調(diào)用鏈很長(zhǎng)或者數(shù)據(jù)庫距離邊緣節(jié)點(diǎn)很遠(yuǎn)就應(yīng)該謹(jǐn)慎選擇邊緣部署。原文鏈接xiaofeng.dev