時(shí)間：2023-07-28 06:30:01 | 來(lái)源：網(wǎng)站運(yùn)營(yíng)
時(shí)間：2023-07-28 06:30:01 來(lái)源：網(wǎng)站運(yùn)營(yíng)
基于Serverless的個(gè)人建站方案的實(shí)現(xiàn)：對(duì)象存儲(chǔ)（Cloud Object Storage，COS）是騰訊云提供的一種存儲(chǔ)海量文件的分布式存儲(chǔ)服務(wù)，用戶可通過(guò)網(wǎng)絡(luò)隨時(shí)存儲(chǔ)和查看數(shù)據(jù)。騰訊云為其提供了多項(xiàng)技術(shù)進(jìn)行輔助，以實(shí)現(xiàn)更好的性能優(yōu)化，例如CDN。所以在本方案中Serverless主要代表了兩個(gè)觀點(diǎn)：前端項(xiàng)目的上線不再?gòu)?qiáng)依賴于服務(wù)器（面向服務(wù)器開(kāi)發(fā)和運(yùn)維），同時(shí)需要的原有后端服務(wù)交給Serverless服務(wù)商。
云存儲(chǔ)是本次研究的核心內(nèi)容之一。云存儲(chǔ)如其字面含義，是基于云服務(wù)的存儲(chǔ)服務(wù)，其功能是常見(jiàn)服務(wù)器的一部分：存儲(chǔ)。通過(guò)云存儲(chǔ)，可以實(shí)現(xiàn)靜態(tài)資源在多個(gè)地域完成部署，配合CDN則可以實(shí)現(xiàn)非常優(yōu)秀的訪問(wèn)體驗(yàn)。
內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）是在現(xiàn)有網(wǎng)絡(luò)中增加的一層新的網(wǎng)絡(luò)架構(gòu)，由遍布全球的高性能加速節(jié)點(diǎn)構(gòu)成。這些高性能的服務(wù)節(jié)點(diǎn)都會(huì)按照一定的緩存策略存儲(chǔ)您的業(yè)務(wù)內(nèi)容，當(dāng)用戶向某一業(yè)務(wù)內(nèi)容發(fā)起請(qǐng)求時(shí)，請(qǐng)求會(huì)被調(diào)度至最接近用戶的服務(wù)節(jié)點(diǎn)，直接由服務(wù)節(jié)點(diǎn)快速響應(yīng)，有效降低用戶訪問(wèn)延遲，提升可用性。
分發(fā)網(wǎng)絡(luò)是本次研究的另外一個(gè)核心內(nèi)容，其技術(shù)也經(jīng)常被使用在性能優(yōu)化層面，而Serverless架構(gòu)則無(wú)疑為CDN提供了更好的服務(wù)基礎(chǔ)。通過(guò)CDN，可以實(shí)現(xiàn)快速的更換分發(fā)地域以及分發(fā)內(nèi)容，始終保持極佳的狀態(tài)以應(yīng)對(duì)用戶的訪問(wèn)。
CDN是一個(gè)非常復(fù)雜的技術(shù)，也有諸多學(xué)術(shù)論文和工程經(jīng)驗(yàn)，在此不再過(guò)多闡述。
Serverless 計(jì)算是一種云計(jì)算執(zhí)行模型，其中云提供商按需分配機(jī)器資源，代表其客戶管理服務(wù)器[1]。嚴(yán)格來(lái)說(shuō)，Serverless并沒(méi)有一個(gè)絕對(duì)清晰的概念或定義，所以Serverless往往被擴(kuò)展為兩個(gè)類(lèi)似但又不盡然的概念：Serverless計(jì)算（服務(wù)）與Serverless 架構(gòu)。
Serverless并不是一個(gè)真實(shí)存在的軟件服務(wù)或者是物理設(shè)備，而是一個(gè)理念和一種思維方式。受限于傳統(tǒng)的B/S模式，的思維定式告訴一個(gè)部署上線的項(xiàng)目一定需要與之配套的服務(wù)器及其服務(wù)。而Serverless則打破了這種思維定式。在服務(wù)上，服務(wù)可以被通用或量化甚至是商業(yè)化，由傳統(tǒng)的定制開(kāi)發(fā)轉(zhuǎn)化為通用開(kāi)發(fā)；在結(jié)構(gòu)上，則徹底“消除”服務(wù)器這一概念，轉(zhuǎn)變?yōu)榈谌椒?wù)商。
值得一提的是，Serverless實(shí)際上也是基于B/S模式的，其概念也并不是語(yǔ)義上的“無(wú)服務(wù)器”，而是指的是由其他的服務(wù)替代傳統(tǒng)的服務(wù)器，從而減輕技術(shù)團(tuán)隊(duì)的后端開(kāi)發(fā)壓力，甚至是不再開(kāi)發(fā)后端功能。
傳統(tǒng)方式一般會(huì)將資源保存在本地服務(wù)器上，通過(guò)相對(duì)路徑的方式進(jìn)行訪問(wèn)?；蛘撸瑫?huì)使用云服務(wù)來(lái)減緩服務(wù)器壓力。
示例項(xiàng)目則不同，在Serverless的基礎(chǔ)上，瀏覽器會(huì)通過(guò)一個(gè)entry.json文件訪問(wèn)云服務(wù)服務(wù)器。總結(jié)一下，
首先，示例項(xiàng)目是部署在云端的，這就意味著當(dāng)想要對(duì)其進(jìn)行修改或重新部署會(huì)有一定的不便，必須通過(guò)第三方服務(wù)平臺(tái)進(jìn)行相關(guān)操作。通常來(lái)說(shuō)，這都意味著對(duì)一個(gè)項(xiàng)目進(jìn)行重新打包，又或者是由平臺(tái)的重新部署。這樣做的隱患，則是當(dāng)意識(shí)到項(xiàng)目出現(xiàn)bug或遇到錯(cuò)誤時(shí)，無(wú)法像擁有后端服務(wù)器的項(xiàng)目一樣直接修改相關(guān)內(nèi)容，這可能會(huì)導(dǎo)致非常大的損失或安全問(wèn)題。
為了規(guī)避這個(gè)隱患，示例項(xiàng)目將數(shù)據(jù)與視圖再一次的分離，只不過(guò)這一次的分離是物理意義上的。當(dāng)用戶訪問(wèn)示例項(xiàng)目時(shí)，瀏覽器通過(guò)解析代碼會(huì)向基礎(chǔ)COS服務(wù)發(fā)送一個(gè)get請(qǐng)求，以獲取到最新的entry.json文件。通過(guò)解析entry.json文件，瀏覽器會(huì)獲得其他entry.json文件的地址，從而獲得示例項(xiàng)目所需的所有靜態(tài)資源的地址以及其他屬性，至此框架即可按照其需求針對(duì)不同的組件獲取不同的靜態(tài)資源。對(duì)于訪問(wèn)CDN也是類(lèi)似的方式，CDN與COS之間還有一套自有的回源方案，從而確保訪問(wèn)到正確的靜態(tài)資源。
重要的是，在上文舉出的例子中，開(kāi)發(fā)者現(xiàn)在可以完全自由地修改任意一部分內(nèi)容，因?yàn)檫@個(gè)方案在不經(jīng)意間實(shí)現(xiàn)了完全解耦。當(dāng)開(kāi)發(fā)者想要修改頁(yè)面樣式和邏輯時(shí)，僅需要對(duì)代碼倉(cāng)庫(kù)進(jìn)行對(duì)應(yīng)操作，而不需要處理靜態(tài)資源；當(dāng)開(kāi)發(fā)者想要修改靜態(tài)資源時(shí)，例如為示例項(xiàng)目的首頁(yè)功能加入一個(gè)新的插圖，又或者是在回答和文章中加入新的內(nèi)容，開(kāi)發(fā)者僅需要修改對(duì)應(yīng)的entry.json，并維護(hù)COS和CDN即可，而不需要關(guān)心頁(yè)面樣式和邏輯。
至此，示例項(xiàng)目地靜態(tài)資源已經(jīng)可以基于COS和CDN成功托管，并通過(guò)entry.json實(shí)現(xiàn)解耦狀態(tài)下的運(yùn)維。對(duì)于用戶來(lái)說(shuō)，什么都沒(méi)有改變；而對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，一切都在云端。
因?yàn)閑ntry.json是面向JavaScript的，所以將所有的數(shù)據(jù)存儲(chǔ)為對(duì)象或樹(shù)會(huì)更為實(shí)用。
Vercel是一個(gè)面向前端開(kāi)發(fā)者的部署和協(xié)作平臺(tái)。?Vercel將前端開(kāi)發(fā)者放在首位，為他們提供了構(gòu)建高性能網(wǎng)站和應(yīng)用程序的綜合工具。[2]。如果你沒(méi)怎么使用過(guò)Vercel并且也沒(méi)看懂我說(shuō)了什么，暫且認(rèn)為Vercel非常強(qiáng)就可以了。
本研究的研究方向在Vercel中得到了完美的體現(xiàn)，而Vercel的業(yè)務(wù)也是向用戶提供Serverless服務(wù)。其核心功能依然是類(lèi)似GitHub Pages的靜態(tài)資源部署功能，但實(shí)際上其拓展已經(jīng)遠(yuǎn)遠(yuǎn)超越了GitHub Pages，例如其原生支持云函數(shù)、云數(shù)據(jù)庫(kù)等公有云服務(wù)，同時(shí)支持商業(yè)服務(wù)。
Vercel的靜態(tài)資源部署功能也與其他平臺(tái)不同。對(duì)于GitHub等平臺(tái)來(lái)說(shuō)，部署的靜態(tài)資源本質(zhì)上是一個(gè)傳統(tǒng)的基于HTML和CSS以及JS的簡(jiǎn)單站點(diǎn)。為了實(shí)現(xiàn)這一點(diǎn)，就需要開(kāi)發(fā)者手動(dòng)對(duì)其開(kāi)發(fā)的項(xiàng)目進(jìn)行打包，并再次進(jìn)行托管后部署。
這種方式聽(tīng)起來(lái)并沒(méi)有什么問(wèn)題，因?yàn)閭鹘y(tǒng)的B/S模式中，在服務(wù)器上都是如此操作的（暫不討論服務(wù)器渲染（SSR））。而這種部署方式的優(yōu)點(diǎn)是可以保持源代碼的穩(wěn)定，防止在服務(wù)器端遭到攻擊或篡改，源碼將會(huì)被很好的隱藏。但對(duì)于本研究的Serverless方向，這種方式顯得有些許捉襟見(jiàn)肘。例如，因?yàn)楸狙芯康牟渴鸱绞讲⒉粫?huì)有服務(wù)器操作，那么就會(huì)需要對(duì)項(xiàng)目源代碼和項(xiàng)目打包文件開(kāi)辟兩個(gè)代碼倉(cāng)庫(kù)進(jìn)行托管，甚至是需要在騰訊云等平臺(tái)的靜態(tài)資源部署中維護(hù)一個(gè)額外的部署服務(wù)。此時(shí)，源代碼依舊是在云端的，且當(dāng)想要更新代碼時(shí)，就需要重新操作部署服務(wù)。這種方式對(duì)于個(gè)人開(kāi)發(fā)者來(lái)說(shuō)顯得過(guò)于沉重，甚至是在使用靜態(tài)資源部署服務(wù)，這種已經(jīng)使用了部分Serverless思想的部署方式時(shí)依然會(huì)帶來(lái)不便。
Vercel解決了這個(gè)問(wèn)題。Vercel除了支持部署這種經(jīng)打包處理的代碼以外，還支持直接對(duì)源代碼進(jìn)行部署。當(dāng)通過(guò)GitHub授權(quán)后，Vercel會(huì)自動(dòng)從GitHub拉取倉(cāng)庫(kù)代碼，并在服務(wù)器端進(jìn)行打包操作，并將打包后的代碼部署到Vercel的服務(wù)器上，以供用戶訪問(wèn)；當(dāng)在GitHub端更新代碼或合并分支后，Vercel也會(huì)對(duì)GitHub倉(cāng)庫(kù)進(jìn)行監(jiān)聽(tīng)和檢測(cè)并執(zhí)行上述操作，從而實(shí)現(xiàn)完全自動(dòng)化的部署方式。
Vercel的功能是強(qiáng)大的，但是其業(yè)務(wù)更傾向于部署，而不是完整的公有云服務(wù)。Vercel也有一定的缺陷，其目前執(zhí)行的是偏向于免費(fèi)的開(kāi)源策略，這導(dǎo)致其服務(wù)的具體范圍受限，對(duì)于商業(yè)需求來(lái)說(shuō)可能不是非常友好。Vercel也包含商業(yè)服務(wù)，因?yàn)槠渑c本研究研究方向不符，故不在部署方式中進(jìn)行研究。
GitHub Pages
GitHub Pages的設(shè)置相對(duì)來(lái)說(shuō)較為簡(jiǎn)單。當(dāng)用戶在代碼倉(cāng)庫(kù)托管了一個(gè)站點(diǎn)代碼后（需要index.html文件作為入口），即可成功開(kāi)啟GitHub Pages功能。GitHub會(huì)在用戶指定的代碼分支中尋找index.html，并將該文件作為整個(gè)站點(diǎn)的入口，繼而用戶可以即可通過(guò)GitHub分配的域名訪問(wèn)。除了GitHub默認(rèn)分配的域名，用戶也可以根據(jù)自己的實(shí)際情況自定義域名，并在DNS中進(jìn)行對(duì)應(yīng)配置即可使域名生效。GitHub Pages是近些年興起的一個(gè)全新產(chǎn)品，它為全球數(shù)以千萬(wàn)計(jì)的開(kāi)發(fā)者提供了一個(gè)更為便捷的站點(diǎn)部署方式，適用于幾乎所有的個(gè)人博客和開(kāi)源項(xiàng)目主頁(yè)，又或者是API文檔等。GitHub Pages還可以和Hexo或VuePress等靜態(tài)文檔框架相結(jié)合，將枯燥的Markdown或其他類(lèi)型的文檔生成為生動(dòng)形象的靜態(tài)頁(yè)面，并一鍵式的部署上線，廣受好評(píng)。GitHub Pages自身也支持Jekyll主題。
GitHub Pages似乎非常符合本研究的目標(biāo)，但遺憾的是，GitHub Pages因?yàn)槠浞?wù)器問(wèn)題，導(dǎo)致中國(guó)大陸訪問(wèn)十分不穩(wěn)定。但即使如此，絕大多數(shù)開(kāi)源項(xiàng)目和個(gè)人博客均采用了這種方式。
騰訊云（靜態(tài)頁(yè)面）
以騰訊云為代表的諸多公有云服務(wù)上幾乎都提供了自家的靜態(tài)頁(yè)面部署服務(wù)，其核心內(nèi)容與GitHub Pages類(lèi)似，但使用起來(lái)略有不同。騰訊云沒(méi)有打造自己的代碼倉(cāng)庫(kù)，而是將靜態(tài)頁(yè)面服務(wù)部署到了自家的COS服務(wù)以及Serverless服務(wù)。在COS中，用戶可以將站點(diǎn)部署，并開(kāi)啟靜態(tài)頁(yè)面功能，即可使用騰訊云分配的域名進(jìn)行訪問(wèn)。
相對(duì)于GitHub Pages來(lái)說(shuō)，公有云服務(wù)商提供的相關(guān)服務(wù)要遠(yuǎn)遠(yuǎn)強(qiáng)大得多。例如，雖然騰訊云也支持對(duì)域名進(jìn)行自定義配置，但是騰訊云還可加入重定向規(guī)則和錯(cuò)誤文檔，而配合其他云服務(wù)使用還可以實(shí)現(xiàn)ECDN（全站加速服務(wù)，將整個(gè)站點(diǎn)分發(fā)給CDN而不是某個(gè)靜態(tài)文件）。
騰訊云的靜態(tài)頁(yè)面服務(wù)并不是完全免費(fèi)的。雖然騰訊云的功能更為強(qiáng)大，但是如果將一個(gè)開(kāi)源項(xiàng)目的靜態(tài)站點(diǎn)部署在騰訊云，則意味著必須有人承擔(dān)對(duì)應(yīng)的流量和存儲(chǔ)費(fèi)用。在2.4節(jié)中已經(jīng)提到，本研究不會(huì)將具體的價(jià)格作為對(duì)比的因素之一，但是對(duì)于一項(xiàng)服務(wù)是否能夠長(zhǎng)時(shí)間免費(fèi)提供，依然值得被開(kāi)發(fā)者納入討論范圍內(nèi)。
GitHub + 騰訊云（COS與CDN）
將項(xiàng)目中的靜態(tài)資源部署到騰訊云的COS服務(wù)中，并使用CDN以達(dá)到更好的性能，這也是目前一種常見(jiàn)的方式。絕大多數(shù)開(kāi)源項(xiàng)目會(huì)使用額外的CDN服務(wù)以滿足其他區(qū)域的訪問(wèn)問(wèn)題，CDN服務(wù)可能來(lái)自于不同的服務(wù)商。
總體來(lái)說(shuō)實(shí)際的部署與設(shè)計(jì)不會(huì)有非常大的差異，但非常重要的一點(diǎn)是開(kāi)發(fā)者需要根據(jù)實(shí)際的業(yè)務(wù)選擇是否要進(jìn)行額外的Serverless分發(fā)方式。對(duì)于部分內(nèi)容，例如由框架編譯出的.js文件，幾乎無(wú)法被存儲(chǔ)與COS或CDN，這可能會(huì)對(duì)站點(diǎn)帶來(lái)非常大的不確定性，而如果此時(shí)已經(jīng)引發(fā)了性能問(wèn)題，則原因極有可能出現(xiàn)在如GitHub Pages等服務(wù)商上。
這種部署方式非常適合一些用作展示的項(xiàng)目，例如一個(gè)在線的電子相冊(cè)或是作品集。COS與CDN更適合去存儲(chǔ)和分發(fā)一些高頻使用，但又不會(huì)經(jīng)常修改的中大型文件，最為常見(jiàn)的就是多媒體內(nèi)容。如果瀏覽器因?yàn)樵S多個(gè)小文件而不斷向遠(yuǎn)端發(fā)送請(qǐng)求，這本身也會(huì)導(dǎo)致用戶客戶端的性能問(wèn)題。
混合使用的方式會(huì)帶來(lái)較大的便利，現(xiàn)在開(kāi)發(fā)者可以專(zhuān)心于開(kāi)發(fā)新功能或更新新的靜態(tài)資源，而不是同時(shí)去做兩件事。
騰訊云（靜態(tài)頁(yè)面） + 騰訊云（COS與CDN）
因?yàn)镃OS特性，開(kāi)發(fā)者其實(shí)可以將靜態(tài)資源和站點(diǎn)部署在同一個(gè)存儲(chǔ)桶內(nèi)。
如果將代碼托管（本節(jié)為部署）和Serverless服務(wù)選擇為相同的運(yùn)營(yíng)商，則可能會(huì)帶來(lái)如此的便利。騰訊云可以非常容易地對(duì)站點(diǎn)進(jìn)行分發(fā)，又或者是對(duì)一些資源進(jìn)行分發(fā)，并在加以其他的云服務(wù)或是Serverless服務(wù)，即可實(shí)現(xiàn)一個(gè)較好的展示方式。
當(dāng)靜態(tài)資源被部署在相同的桶內(nèi)時(shí)，對(duì)于用戶來(lái)說(shuō)訪問(wèn)的過(guò)程依然是通過(guò)遠(yuǎn)端獲取數(shù)據(jù)，這可能會(huì)導(dǎo)致網(wǎng)絡(luò)不暢的用戶遭遇到中國(guó)大陸用戶使用GitHub Pages遇到的問(wèn)題，這兩個(gè)問(wèn)題的本質(zhì)是相同的，用戶的網(wǎng)絡(luò)性能受限于服務(wù)器與用戶之間的物理距離。在使用額外的COS與CDN服務(wù)時(shí)，即可以針對(duì)不同的用戶進(jìn)行優(yōu)化。但遺憾的是，如果CDN服務(wù)較為單一，用戶則可能會(huì)面臨著繞遠(yuǎn)或難以命中的狀態(tài)。對(duì)于這種隱患，則需要開(kāi)發(fā)者繼續(xù)優(yōu)化網(wǎng)絡(luò)服務(wù)，選擇擴(kuò)大CDN服務(wù)的范圍，或者是修改前端項(xiàng)目的業(yè)務(wù)邏輯，根據(jù)用戶所處地域而強(qiáng)制分配訪問(wèn)的具體服務(wù)器。
GitHub + Vercel + 騰訊云（COS與CDN）
本節(jié)的內(nèi)容，與其他小節(jié)的差異是巨大的。
GitHub，騰訊云，或者其他第三方服務(wù)商提供的靜態(tài)頁(yè)面部署服務(wù)的前提是，開(kāi)發(fā)者必須將已經(jīng)打包好的靜態(tài)頁(yè)面部署在服務(wù)商中.
而Vercel則與他們相反。Vercel的原理是，開(kāi)發(fā)者將前端項(xiàng)目的源碼進(jìn)行部署，而由Vercel對(duì)源碼進(jìn)行打包和部署，實(shí)現(xiàn)了一種偽SSR（服務(wù)端渲染）的工作方式。部署方式如圖11所示。
Vercel相對(duì)來(lái)說(shuō)是一個(gè)對(duì)開(kāi)發(fā)者十分友好地第三方服務(wù)平臺(tái)，他完成了代碼的自動(dòng)部署和打包工作，讓開(kāi)發(fā)者可以更加專(zhuān)注于業(yè)務(wù)。開(kāi)發(fā)者只需要完成第一次部署，就不再需要關(guān)心站點(diǎn)的部署問(wèn)題。其實(shí)如果在現(xiàn)在重新思考這一節(jié)，Vercel就是一個(gè)針對(duì)個(gè)人開(kāi)發(fā)者和小團(tuán)隊(duì)的自動(dòng)化部署系統(tǒng)，甚至做大一點(diǎn)能接入GitHub能實(shí)現(xiàn)自動(dòng)Merge……
開(kāi)發(fā)者通過(guò)將源代碼托管在GitHub，并根據(jù)開(kāi)發(fā)情況對(duì)核心分支（也就是Vercel選擇部署的分支）進(jìn)行適時(shí)更新，Vercel就會(huì)察覺(jué)到這些變化并將最新的代碼打包為新的站點(diǎn)，并部署在Vercel的服務(wù)器上。
Vercel的主要生態(tài)依然是GitHub。當(dāng)Vercel用戶將賬戶與GitHub賬戶綁定后，即可自動(dòng)獲取到該賬戶的倉(cāng)庫(kù)。同時(shí)，Vercel也支持針對(duì)一個(gè)第三方倉(cāng)庫(kù)進(jìn)行部署。Vercel會(huì)在控制臺(tái)中向開(kāi)發(fā)者展示部署時(shí)服務(wù)器的實(shí)時(shí)狀態(tài)。
Vercel也支持自定義域名的功能，其實(shí)現(xiàn)方式相對(duì)于GitHub和騰訊云更為自由和快速，不需要等待DNS響應(yīng)生效。Vercel本身也提供了一定的Serverless服務(wù)，包括云函數(shù)等。
相對(duì)于GitHub，Vercel可以提供更好的網(wǎng)絡(luò)性能，同時(shí)也可以極大程度的簡(jiǎn)化開(kāi)發(fā)和部署流程。
本節(jié)將會(huì)通過(guò)對(duì)示例項(xiàng)目的不同部署方式進(jìn)行性能測(cè)試。測(cè)試方法為由固定IP向目標(biāo)站點(diǎn)發(fā)送訪問(wèn)請(qǐng)求，并通過(guò)工具記錄相關(guān)加載時(shí)間。
通過(guò)測(cè)試數(shù)據(jù)的平均值判斷不同部署方式之間的用戶相對(duì)訪問(wèn)速度，通過(guò)測(cè)試數(shù)據(jù)的方差判斷不同部署方式之間的用戶相對(duì)訪問(wèn)穩(wěn)定性。
由于訪問(wèn)速度直接受限于IP地址與服務(wù)器之間的物理距離，故不再針對(duì)不同區(qū)域的不同IP進(jìn)行測(cè)試。
在測(cè)試結(jié)果中，訪問(wèn)速度和訪問(wèn)穩(wěn)定性會(huì)是相對(duì)的結(jié)果。
在測(cè)試過(guò)程中，將會(huì)分別測(cè)試首頁(yè)加載測(cè)試與靜態(tài)資源加載測(cè)試。首頁(yè)加載測(cè)試為直接訪問(wèn)首頁(yè)進(jìn)行測(cè)試，以模擬用戶體驗(yàn)；靜態(tài)資源加載測(cè)試為測(cè)試靜態(tài)資源加載速度及在大負(fù)載的情況下部署方式的穩(wěn)定性。
對(duì)于功能回答與文章，其設(shè)計(jì)目的為測(cè)試示例項(xiàng)目的架構(gòu)穩(wěn)定性，并已通過(guò)測(cè)試。由于其內(nèi)容基于云端，無(wú)法做到本地化參與測(cè)試，故在本節(jié)將不會(huì)測(cè)試相關(guān)內(nèi)容。
為了獲取更為全面和真實(shí)的數(shù)據(jù)，本研究將使用Microsoft Edge瀏覽器的開(kāi)發(fā)工具進(jìn)行站點(diǎn)加載性能測(cè)試。測(cè)試過(guò)程中，將會(huì)使用固定IP地址向目標(biāo)地址發(fā)送請(qǐng)求。每一個(gè)部署方式都將重復(fù)測(cè)試五次，并在每次請(qǐng)求后完全清除緩存與Cookie。
每一次請(qǐng)求統(tǒng)計(jì)將包括如下數(shù)據(jù)：
(1) 完成時(shí)間（毫秒）；
(2) DOM加載時(shí)間（毫秒）；
(3) 完全加載時(shí)間（毫秒）。
其中，完成時(shí)間是頁(yè)面最后一個(gè)請(qǐng)求截止時(shí)間 ；DOM加載時(shí)間是DOM內(nèi)容進(jìn)行加載并解析完成的時(shí)間，即頁(yè)面白屏?xí)r間；完全加載時(shí)間是頁(yè)面所有的資源加載完成的時(shí)間[3]。
由于開(kāi)發(fā)工具會(huì)對(duì)實(shí)際訪問(wèn)時(shí)間進(jìn)行優(yōu)化顯示，導(dǎo)致無(wú)法在所有情況下讀取到完整的數(shù)據(jù)。但考慮到當(dāng)值被優(yōu)化時(shí)其值已經(jīng)足夠大，測(cè)試中將忽略這一部分的精度差異。對(duì)于得到的值，將舍棄小數(shù)部分。
關(guān)鍵詞：方案,實(shí)現(xiàn)
客戶&案例
營(yíng)銷(xiāo)資訊
關(guān)于我們
客戶&案例
營(yíng)銷(xiāo)資訊
關(guān)于我們
微信公眾號(hào)
版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。
在線咨詢