如何做一個隨時可變的網(wǎng)頁？

時間：2023-07-04 01:24:02 | 來源：網(wǎng)站運營

時間：2023-07-04 01:24:02 來源：網(wǎng)站運營

如何做一個隨時可變的網(wǎng)頁？：我們在日常運營中會經(jīng)常碰到突發(fā)情況，需要快速修改一段文字或者調(diào)整下網(wǎng)頁的顏色，比如這次我們?yōu)榱司拺言诳箵粢咔橹袪奚挠⑿酆褪湃サ耐?，我們需要將官網(wǎng)調(diào)整成灰色，這個操作對待技術(shù)人員來說，不算什么技術(shù)性工作，但是如果市場人員臨時接到這樣的修改需求，臨時聯(lián)系技術(shù)時，可能會沒那么快速的相應(yīng)。

所以今天我們聊一聊如何把網(wǎng)頁做成可以隨時響應(yīng)這種突發(fā)需求呢？

我們從以下幾個點來闡述：

1、灰度發(fā)布，快速修改，客戶無感知

2、GTM（tagmanager）無技術(shù)參與，快速修改

3、前端化工程，不停服務(wù)發(fā)布版本




一、灰度發(fā)布

灰度發(fā)布（又叫金絲雀發(fā)布或者藍綠發(fā)布），指的就是在黑與白之間，能夠平滑過渡的一種發(fā)布方式。字面上理解也比較清晰，黑切換到白時自然是灰色，所以灰度發(fā)布主要體現(xiàn)的就是舊版切換到新版時的這個過程。

這個主要針對的是前后端混合開發(fā)的項目，比如后端服務(wù)為Java這種重型架構(gòu)，采用的是MVC形式，前端頁面沒有獨立于后端服務(wù)，每次修改之后需要后端服務(wù)重新打包發(fā)布才可以生效。

這種架構(gòu)相對來說靈活性會降低很多，因為每次發(fā)布會有10-20秒的服務(wù)宕機時間。如果服務(wù)多的話可能會持續(xù)2分鐘都有。

大家肯定都不希望看到自己的服務(wù)會產(chǎn)生宕機情況，所以每次發(fā)版一般都安排在晚上20點以后，這個時間段使用人較少，影響也小。有的會安排在凌晨，大家玩游戲的時候經(jīng)常會接到這樣的通知，凌晨2點開始服務(wù)器維護，屆時游戲無法登錄。其實就是發(fā)布程序迭代應(yīng)用，因為這個時間既要發(fā)布程序，同時也要進行測試，所以這段時間不會讓玩家上線。

如何破解這個難題呢？

其中一個方法藍綠發(fā)布，兩套應(yīng)用同時部署，線上一套，測試一套，新版本會在測試這套充分驗證之后，后端將Nginx指向新版本程序，這樣用戶基本上無感知，一般刷新下頁面，新應(yīng)用即刻生效。




這個方式在安全性上有保障，因為同時存在兩套程序，新程序和舊程序并存，當(dāng)發(fā)生問題時，可以立即將程序切換到舊程序。保證不會因為新版程序不符合用戶體驗而導(dǎo)致用戶流失。

另一個方法就是金絲雀發(fā)布，和藍綠發(fā)布的區(qū)別就是不會按照生產(chǎn)環(huán)境完整部署一套環(huán)境，經(jīng)常用于集群形式，會發(fā)布到其中幾臺來驗證服務(wù)的形式，部署新版的服務(wù)器就是金絲雀。如果正常就將其它的服務(wù)器全部部署，如果異常迅速將已部署的服務(wù)回滾到原來版本。

比如我們熟知的A/B測試其實就是灰度發(fā)布的一種變種形式。兩套方案可以隨意切換。驗證用戶體驗。

我們經(jīng)常使用的QQ空間，他們在迭代時采取的就是灰度形式，通過不斷的驗證新功能是否符合用戶習(xí)慣，不斷的迭代和優(yōu)化，不斷的放到線上讓用戶來驗證，從而讓QQ空間這顆老樹長出了新枝，收獲一大批的00后用戶群。




這個方法的缺點就是比較耗費資源，畢竟等同于部署了兩套生產(chǎn)環(huán)境。




二、GTM（推薦）

GTM是個很強大的工具，它可以讓運營也可以去操作應(yīng)用，不需要程序員協(xié)助，他的官方解釋：管理所有網(wǎng)站標(biāo)簽，而無需編輯代碼。Google Tag Manager免費提供了簡單，可靠，易于集成的跟蹤代碼管理解決方案。

主要原理其實就是在我們的應(yīng)用上做了一個JS埋碼，這樣你在GTM上面寫的代碼就可以通過GTM的js來拉取到我們的網(wǎng)站上，并且立刻執(zhí)行，他的好處就是非常靈活，并且不需要修改我們程序本身的代碼，通過JS來修改我們網(wǎng)頁上的元素，比如修改顏色，文本內(nèi)容等等。

因為這個靈活的特性，當(dāng)我們接受到臨時性緊急修改時，這個就非常好用了，比如你們老板在外面談客戶，突然發(fā)現(xiàn)首頁沒有這個客戶的logo，現(xiàn)在急需增加這個，現(xiàn)在發(fā)包影響很大，但是又比較緊急，怎么辦呢？你打開GTM后臺，立刻向首頁追加這個圖片即可，非?？焖俣野踩＠习鍖δ愕南鄳?yīng)速度也非常滿意。

比如這次我們?yōu)榱司拺言诳挂咧袪奚挠⑿酆褪湃サ耐?，我們需要將網(wǎng)頁顏色改為灰色，我們只需要在GTM后臺新增這樣一段代碼即可：




非常方便不是嗎？另外他還提供了預(yù)覽功能，讓我們及時糾偏，防止改出毛病來，真的非常體貼了。如果對這個感興趣大家可以搜索下，現(xiàn)在這方面的教程和文章比較多。




這個缺點呢就是需要一個翻墻工具，因為是Google的產(chǎn)品，在國內(nèi)訪問不是很方便。但是我相信這個不是你不用他的原因。




三、前端化工程

近些年前端技術(shù)發(fā)展非常迅速，各種架構(gòu)層出不窮，讓原來只是負責(zé)頁面渲染和切圖的前端工程師搖身一變，成為了一個單獨應(yīng)用的負責(zé)者。

現(xiàn)在的前端可以不依賴后端程序，單獨開發(fā)應(yīng)用，本地開發(fā)使用node服務(wù)，自啟一個開發(fā)環(huán)境。研發(fā)完成，將程序打包為供瀏覽器瀏覽的普通文件包，發(fā)布到服務(wù)器。

這個過程和后端的交互主要是API接口，所以現(xiàn)在很多公司包括大廠的應(yīng)用，都是前后端分離模式。

后端工程師負責(zé)數(shù)據(jù)輸出，前端工程師負責(zé)客戶交互，無論是研發(fā)效率還是工作分工，都比以前的混合開發(fā)提效很多。

那么為什么前端工程化可以保證我們的頁面可以隨時可變呢？他有什么過人之處？

首先前端頁面是獨立于后端工程的，前端研發(fā)完成打的包是靜態(tài)文件，發(fā)布也是發(fā)布這個靜態(tài)文件包，等同于一個復(fù)制動作。這樣后端工程的頁面文件可以指向一個目錄即可，不需要把文件放到自己的工程里面。

每次前端文件的修改，刷新頁面即可看到效果。這樣就避免了前后端混合研發(fā)那種一定要后端發(fā)包才生效的尷尬情況。

另外一種是前端單獨依賴Node服務(wù)，是有一套單獨的后臺來支撐應(yīng)用的訪問，不是純靜態(tài)文件，每次發(fā)包也是需要啟動Node服務(wù)才生效的。

雖然這里也涉及到了重啟，但是node的重啟要快于Java服務(wù)很多，這也就保證了發(fā)包時前端工程可以快速的響應(yīng)和生效，不會出現(xiàn)長時間等待的情況。

這個相比GTM來說可以處理的功能更多，畢竟是直接修改代碼了，運營同學(xué)的需求還是下發(fā)到了工程師這里。在及時性和方便上面輸于GTM，高于灰度發(fā)布。

在日常工作中，我們建議小的修改還是用GTM比較好。他比較適合處理臨時性和突發(fā)性的簡單修改。盡量將我們的業(yè)務(wù)工程改為前端工程化，這樣分離研發(fā)不管是提效還是靈活性都提升很多。

好了，咱們就聊到這里，這次我們主要針對如何做一個隨時可變的網(wǎng)頁列舉了三種方法，有更好方法的也歡迎在下方留言，咱們一起交流學(xué)習(xí)。如果您覺得這個有用，也希望能點贊支持，萬分感謝。