AI技術(shù)現(xiàn)在很火，各大公司都開始朝著這個領(lǐng)域發(fā)力。他們不僅創(chuàng)建出很多出色成果，還通過一系列技術(shù)、工具和服務(wù)，幫助普通開發(fā)者也能輕而易舉地開發(fā)出新穎的AI應(yīng)用。

本文將告訴大家如何在Akamai云計算平臺上優(yōu)化一個基于Qwik和OpenAI服務(wù)的Web項目。具體來說，我們將通過本文詳細剖析項目的整體架構(gòu)和優(yōu)化方式，從而為廣大開發(fā)者帶來啟發(fā)。

基本架構(gòu)

假設(shè)有這樣的一個Web應(yīng)用：

在兩個文本框中輸入兩個“對手”，隨后由AI來決定在戰(zhàn)斗中誰會獲勝。該應(yīng)用還提供了一些解釋決策原因以及創(chuàng)建圖像的選項。該應(yīng)用相當基礎(chǔ)，用戶提交兩個對手，然后應(yīng)用程序即時返回一個由AI生成的響應(yīng)，從中得知哪個對手會在戰(zhàn)斗中獲勝。

架構(gòu)也很簡單：

客戶端向服務(wù)器發(fā)送請求。

服務(wù)器構(gòu)造提示并將提示轉(zhuǎn)發(fā)給OpenAI。

OpenAI向服務(wù)器返回一個流式響應(yīng)。

服務(wù)器對流式響應(yīng)進行任何必要的調(diào)整，并將其轉(zhuǎn)發(fā)給客戶端。

該應(yīng)用搭建在Akamai的云計算服務(wù)（以前的Linode）上，不過下文將要介紹的內(nèi)容對任何云平臺應(yīng)該都適用。

看起來像是高級餐廳里的服務(wù)員， ? ?則是“一只眼睛”，或者說是AI

從技術(shù)上講，這是完全可行的，但存在一些問題，特別是當用戶提交重復請求時。將響應(yīng)存儲在我們自己的服務(wù)器上，并且只針對唯一請求訪問OpenAI，可能會讓整個過程更快速，更具成本效益。

這就需要假設(shè)我們不需要每個請求都是非確定性的（即相同的輸入產(chǎn)生不同的輸出）。我們可以假設(shè)相同的輸入產(chǎn)生相同的輸出是可接受的。畢竟，誰會贏得一場戰(zhàn)斗的預測結(jié)果可能并不會改變。

添加數(shù)據(jù)庫架構(gòu)

如果我們想要存儲來自O(shè)penAI的響應(yīng)，一種實際的放置地點是某種類型的數(shù)據(jù)庫，這種數(shù)據(jù)庫應(yīng)該能讓我們圍繞兩個對手進行快速、簡單的查找。這樣，在收到請求時，就可以首先檢查數(shù)據(jù)庫：

客戶端向服務(wù)器發(fā)送請求。

服務(wù)器檢查數(shù)據(jù)庫中是否存在與用戶輸入相匹配的條目。

如果存在匹配的記錄，服務(wù)器使用該數(shù)據(jù)回復并完成請求。跳過后續(xù)步驟。

如果不存在匹配的記錄，則服務(wù)器繼續(xù)執(zhí)行上一小節(jié)中流程的第三步（聯(lián)系OpenAI）。

在關(guān)閉響應(yīng)前，服務(wù)器將OpenAI的結(jié)果存儲在數(shù)據(jù)庫中。

虛線代表可選請求，而 看起來像是一個硬盤

有了這樣的設(shè)置，任何重復的請求都將由數(shù)據(jù)庫直接處理。通過將一些OpenAI請求設(shè)置為可選，我們還有可能降低用戶體驗的延遲，同時通過減少API請求的數(shù)量來節(jié)省費用。

這是一個很好的開始，特別是如果服務(wù)器和數(shù)據(jù)庫位于同一個地區(qū)。這將比訪問OpenAI的服務(wù)器快得多。

然而，隨著應(yīng)用程序變得更加受歡迎，我們可能會開始吸引來自世界各地的用戶。數(shù)據(jù)庫查詢的速度自然是越快越好，但往返傳輸數(shù)據(jù)造成的延遲又該如何消除？

我們可以通過將應(yīng)用移動到距離用戶更近的地方來解決這個問題。

引入邊緣計算

邊緣（Edge）指一種讓內(nèi)容盡可能接近用戶的方式。對一些應(yīng)用場景來說，邊緣可能意味著物聯(lián)網(wǎng)設(shè)備或手機基站，但在Web應(yīng)用之類的場景中，最典型的邊緣往往是內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）。

CDN是一種全球分布的計算機網(wǎng)絡(luò)，可以從網(wǎng)絡(luò)中最近的節(jié)點響應(yīng)用戶請求。傳統(tǒng)的CDN是為靜態(tài)資產(chǎn)設(shè)計的，但近年來，CDN開始支持邊緣計算。

有了邊緣計算，我們可以將很多后端邏輯移動到距離用戶非常近的地方，而且不僅限于計算！大多數(shù)邊緣計算提供商還在同一邊緣節(jié)點上提供某種最終一致的鍵值存儲服務(wù)。

這會對我們的應(yīng)用程序產(chǎn)生什么影響？

客戶端向我們的后端發(fā)送請求。

邊緣計算網(wǎng)絡(luò)將請求路由到最近的邊緣節(jié)點。

邊緣節(jié)點檢查與用戶輸入匹配的鍵值存儲中是否存在現(xiàn)有記錄。

如果存在匹配的記錄，邊緣節(jié)點將使用該數(shù)據(jù)回復，完成請求。跳過后續(xù)步驟。

如果不存在匹配的記錄，則邊緣節(jié)點將請求轉(zhuǎn)發(fā)到源服務(wù)器，源服務(wù)器再將其傳遞給OpenAI……

在關(guān)閉響應(yīng)前，服務(wù)器將OpenAI的結(jié)果存儲在邊緣鍵值存儲中。

邊緣節(jié)點是藍色方框，用 表示；EdgeWorker是Akamai的邊緣計算產(chǎn)品，用 表示；EdgeKV是Akamai的鍵值存儲服務(wù)，用 表示。從物理距離來說，邊緣節(jié)點比云中的源服務(wù)器更接近客戶端

源服務(wù)器在這里可能并非絕對必要，但我們認為它的存在有一定必要性。基于數(shù)據(jù)、計算和邏輯流程考慮，這與先前的架構(gòu)基本相同。主要區(qū)別在于先前存儲的結(jié)果現(xiàn)在更接近用戶，幾乎可以立即返回。

注意：盡管數(shù)據(jù)被緩存在邊緣，但響應(yīng)仍然是動態(tài)構(gòu)建的。如果不需要動態(tài)響應(yīng)，將CDN放置在源服務(wù)器前并設(shè)置正確的HTTP頭來緩存響應(yīng)，可能是一種更簡單的做法。

這樣就完成了！任何重復請求幾乎會立即得到響應(yīng)，同時也節(jié)省了不必要的API請求。文本響應(yīng)的架構(gòu)問題順利解決，但是別忘了，還有AI圖像生成功能呢。

緩存圖片

處理圖片時，我們需要考慮內(nèi)容的交付和存儲。相信OpenAI有自己的解決方案，但一些企業(yè)出于安全、合規(guī)性或可靠性等原因的考慮，可能希望與圖片交付和存儲有關(guān)的整個基礎(chǔ)設(shè)施都完全由自己掌控。一些情況下，企業(yè)甚至可能寧愿運行自己的圖像生成服務(wù)，而不是使用OpenAI。

在當前的工作流程中，用戶發(fā)出請求，最終請求傳遞到OpenAI。OpenAI生成圖像，但不返回圖像，而是返回一個JSON響應(yīng)，其中包含圖像的URL，該URL托管在OpenAI的基礎(chǔ)設(shè)施上。使用此響應(yīng)時，可以用URL將<img>標簽添加到頁面，從而啟動另一個請求來獲取對應(yīng)的圖像。

如果要將圖像托管在自己的基礎(chǔ)設(shè)施上，需要一個存儲圖像的地方。我們可以將圖像寫入源服務(wù)器的磁盤，但這可能會快速使用大量磁盤空間，并且必須升級服務(wù)器，這可能會很昂貴。對象存儲是一種更便宜的解決方案，我們可以將圖像上傳到自己的對象存儲實例，并使用該實例對應(yīng)的URL。

這解決了存儲問題，但對象存儲桶通常都部署在單個區(qū)域，這與我們在數(shù)據(jù)庫中存儲文本時遇到的問題類似。單個區(qū)域可能距離用戶很遠，這可能會導致很高的延遲。

又到了邊緣的用武之地了。為純靜態(tài)資產(chǎn)添加CDN功能其實非常簡單。一旦配置完成，CDN將在初始請求時從對象存儲中拉取圖像，并將其緩存以供來自同一區(qū)域的后續(xù)訪問者直接交付。

我們的圖片處理流程如下：

客戶端發(fā)送請求，根據(jù)對手生成圖像。

邊緣計算檢查該請求的圖像數(shù)據(jù)是否已存在。如果存在，則直接返回URL。

圖像與URL一起添加到頁面，并由瀏覽器請求圖像。

如果圖像已經(jīng)緩存在CDN中，則瀏覽器幾乎能立即加載。流程結(jié)束。

如果圖像尚未被緩存，CDN將從對象存儲位置拉取圖像，緩存一份副本供未來的請求使用，并將圖像返回給客戶端。這是流程的另一個結(jié)尾。

如果圖像數(shù)據(jù)不在邊緣鍵值存儲中，生成圖像的請求將發(fā)送到服務(wù)器，然后傳遞到OpenAI，后者生成圖像并返回URL信息。服務(wù)器啟動任務(wù)將圖像保存在對象存儲桶中，將圖像數(shù)據(jù)存儲在邊緣鍵值存儲中，并將圖像數(shù)據(jù)返回給邊緣計算節(jié)點。

使用新的圖像數(shù)據(jù)，客戶端創(chuàng)建圖像，生成新請求，并從步驟五繼續(xù)。

內(nèi)容交付網(wǎng)絡(luò)以交付卡車（）和網(wǎng)絡(luò)信號（）表示，對象存儲以盒子里的襪子（）或存儲中的對象表示

誠然，最后這種架構(gòu)稍微復雜了一些，但如果應(yīng)用程序要處理大量流量，這種架構(gòu)也是很有必要的。

大功告成

通過所有這些改變，我們已經(jīng)為唯一請求創(chuàng)建了AI生成的文本和圖像，并為重復請求提供了來自邊緣的緩存內(nèi)容。結(jié)果是更快的響應(yīng)時間和更好的用戶體驗（當然，API調(diào)用也更少）。

上述內(nèi)容完全以Akamai云計算平臺為例，但其實所涉及的各種數(shù)據(jù)庫、邊緣計算、對象存儲和CDN也適用于其他平臺。這是一個有著廣泛適用性的思路。只不過通過與Akamai的云計算和邊緣計算服務(wù)整合不僅僅能改善性能，還可以獲得很多非常酷的安全功能。

例如，在Akamai的網(wǎng)絡(luò)上，我們可以使用諸如Web應(yīng)用程序防火墻（WAF）、分布式拒絕服務(wù)（DDoS）防護、智能爬蟲檢測等功能，從而更好地保障應(yīng)用程序、數(shù)據(jù)、客戶信息的安全性。