如何做一个随时可变的网页？

时间：2023-07-04 01:24:02 | 来源：网站运营

时间：2023-07-04 01:24:02 来源：网站运营

如何做一个随时可变的网页？：我们在日常运营中会经常碰到突发情况，需要快速修改一段文字或者调整下网页的颜色，比如这次我们为了缅怀在抗击疫情中牺牲的英雄和逝去的同胞，我们需要将官网调整成灰色，这个操作对待技术人员来说，不算什么技术性工作，但是如果市场人员临时接到这样的修改需求，临时联系技术时，可能会没那么快速的相应。

所以今天我们聊一聊如何把网页做成可以随时响应这种突发需求呢？

我们从以下几个点来阐述：

1、灰度发布，快速修改，客户无感知

2、GTM（tagmanager）无技术参与，快速修改

3、前端化工程，不停服务发布版本




一、灰度发布

灰度发布（又叫金丝雀发布或者蓝绿发布），指的就是在黑与白之间，能够平滑过渡的一种发布方式。字面上理解也比较清晰，黑切换到白时自然是灰色，所以灰度发布主要体现的就是旧版切换到新版时的这个过程。

这个主要针对的是前后端混合开发的项目，比如后端服务为Java这种重型架构，采用的是MVC形式，前端页面没有独立于后端服务，每次修改之后需要后端服务重新打包发布才可以生效。

这种架构相对来说灵活性会降低很多，因为每次发布会有10-20秒的服务宕机时间。如果服务多的话可能会持续2分钟都有。

大家肯定都不希望看到自己的服务会产生宕机情况，所以每次发版一般都安排在晚上20点以后，这个时间段使用人较少，影响也小。有的会安排在凌晨，大家玩游戏的时候经常会接到这样的通知，凌晨2点开始服务器维护，届时游戏无法登录。其实就是发布程序迭代应用，因为这个时间既要发布程序，同时也要进行测试，所以这段时间不会让玩家上线。

如何破解这个难题呢？

其中一个方法蓝绿发布，两套应用同时部署，线上一套，测试一套，新版本会在测试这套充分验证之后，后端将Nginx指向新版本程序，这样用户基本上无感知，一般刷新下页面，新应用即刻生效。




这个方式在安全性上有保障，因为同时存在两套程序，新程序和旧程序并存，当发生问题时，可以立即将程序切换到旧程序。保证不会因为新版程序不符合用户体验而导致用户流失。

另一个方法就是金丝雀发布，和蓝绿发布的区别就是不会按照生产环境完整部署一套环境，经常用于集群形式，会发布到其中几台来验证服务的形式，部署新版的服务器就是金丝雀。如果正常就将其它的服务器全部部署，如果异常迅速将已部署的服务回滚到原来版本。

比如我们熟知的A/B测试其实就是灰度发布的一种变种形式。两套方案可以随意切换。验证用户体验。

我们经常使用的QQ空间，他们在迭代时采取的就是灰度形式，通过不断的验证新功能是否符合用户习惯，不断的迭代和优化，不断的放到线上让用户来验证，从而让QQ空间这颗老树长出了新枝，收获一大批的00后用户群。




这个方法的缺点就是比较耗费资源，毕竟等同于部署了两套生产环境。




二、GTM（推荐）

GTM是个很强大的工具，它可以让运营也可以去操作应用，不需要程序员协助，他的官方解释：管理所有网站标签，而无需编辑代码。Google Tag Manager免费提供了简单，可靠，易于集成的跟踪代码管理解决方案。

主要原理其实就是在我们的应用上做了一个JS埋码，这样你在GTM上面写的代码就可以通过GTM的js来拉取到我们的网站上，并且立刻执行，他的好处就是非常灵活，并且不需要修改我们程序本身的代码，通过JS来修改我们网页上的元素，比如修改颜色，文本内容等等。

因为这个灵活的特性，当我们接受到临时性紧急修改时，这个就非常好用了，比如你们老板在外面谈客户，突然发现首页没有这个客户的logo，现在急需增加这个，现在发包影响很大，但是又比较紧急，怎么办呢？你打开GTM后台，立刻向首页追加这个图片即可，非常快速而且安全。老板对你的相应速度也非常满意。

比如这次我们为了缅怀在抗疫中牺牲的英雄和逝去的同胞，我们需要将网页颜色改为灰色，我们只需要在GTM后台新增这样一段代码即可：




非常方便不是吗？另外他还提供了预览功能，让我们及时纠偏，防止改出毛病来，真的非常体贴了。如果对这个感兴趣大家可以搜索下，现在这方面的教程和文章比较多。




这个缺点呢就是需要一个翻墙工具，因为是Google的产品，在国内访问不是很方便。但是我相信这个不是你不用他的原因。




三、前端化工程

近些年前端技术发展非常迅速，各种架构层出不穷，让原来只是负责页面渲染和切图的前端工程师摇身一变，成为了一个单独应用的负责者。

现在的前端可以不依赖后端程序，单独开发应用，本地开发使用node服务，自启一个开发环境。研发完成，将程序打包为供浏览器浏览的普通文件包，发布到服务器。

这个过程和后端的交互主要是API接口，所以现在很多公司包括大厂的应用，都是前后端分离模式。

后端工程师负责数据输出，前端工程师负责客户交互，无论是研发效率还是工作分工，都比以前的混合开发提效很多。

那么为什么前端工程化可以保证我们的页面可以随时可变呢？他有什么过人之处？

首先前端页面是独立于后端工程的，前端研发完成打的包是静态文件，发布也是发布这个静态文件包，等同于一个复制动作。这样后端工程的页面文件可以指向一个目录即可，不需要把文件放到自己的工程里面。

每次前端文件的修改，刷新页面即可看到效果。这样就避免了前后端混合研发那种一定要后端发包才生效的尴尬情况。

另外一种是前端单独依赖Node服务，是有一套单独的后台来支撑应用的访问，不是纯静态文件，每次发包也是需要启动Node服务才生效的。

虽然这里也涉及到了重启，但是node的重启要快于Java服务很多，这也就保证了发包时前端工程可以快速的响应和生效，不会出现长时间等待的情况。

这个相比GTM来说可以处理的功能更多，毕竟是直接修改代码了，运营同学的需求还是下发到了工程师这里。在及时性和方便上面输于GTM，高于灰度发布。

在日常工作中，我们建议小的修改还是用GTM比较好。他比较适合处理临时性和突发性的简单修改。尽量将我们的业务工程改为前端工程化，这样分离研发不管是提效还是灵活性都提升很多。

好了，咱们就聊到这里，这次我们主要针对如何做一个随时可变的网页列举了三种方法，有更好方法的也欢迎在下方留言，咱们一起交流学习。如果您觉得这个有用，也希望能点赞支持，万分感谢。