28 前台页面版本化管理：如何实现搭建页面的迭代策略？
你好，我是杨文坚。
上节课我们学习了怎样把页面发布出去，给生产环境的外部客户使用，在页面功能维度的功能链路里，就是“页面发布流程”这一功能环节。那下一步什么是最重要呢?
很多人会想到是“页面在前台服务的渲染”，其实不是。发布页面后，最重要的事项是“保证页面的长期稳定可用”。即使页面出现异常问题，客户不能使用了，如果能在最短时间内，快速解决问题，也算符合稳定可用的要求。
例如，从客户反馈问题到解决问题，只花了几分钟，一般对客户影响不会太大。但是如果页面被反馈不可用，同时也不能短时间内解决问题，导致客户好几个小时都不能使用，这时候，再好的前台渲染方式也是白搭，毕竟客户是长时间使用不了功能，而不是功能体验不好。
所以，在页面进入发布流程后，我们就要做好页面高可用的措施。一般，高可用措施有监听页面错误、及时反馈报警和页面快速回滚恢复等等，其中，最重要的是“页面快速回滚恢复”，因为页面出问题了，如果不能及时解决问题，再好的报错和反馈措施也是没用的。
那这节课，我们就围绕着“页面回滚”这一措施，来学习搭建平台怎么实现页面高可用。
什么是高可用
前面我们反复提到“高可用”，很多人可能不太理解究竟什么是高可用，我们简单解释一下。
高可用，英文是High Availability，可以简称HA。在技术领域，通用解释是这样的：
“系统无中断地执行其功能的能力，代表系統的可用性程度。”
这句话是不是听起来比较抽象。我们举一个例子，你就能明白这个指标的含义。
假设，运营搭建平台发布了一张页面给客户使用，那么，页面全年在线可用的理论时间是 365 x 24 = 8760小时。
如果这张页面某天不能用了，从被客户反馈问题，到程序员修改对应问题代码，重新执行搭建流程来解决问题，期间花了10小时，那么这张页面的全年可用性就按这个公式计算。
（8760-10）/ 8760 = 99.8858 %
计算结果 99.8858% 就是张页面整年维度里的可用性结果。如果涉及多张页面，就把多张页面全年可用的时间进行换算。
通常，互联网企业里要求的可用性，是按照时间维度来计算的，一般要求至少是“四个9”，就是可用时间占全年时间的99.99%。如果有些技术业务比较重要敏感，例如一些云服务提供商，甚至要求可用性达到“六个9”，也就是99.9999%。项目的可用性关乎安全和稳定，所以，通常作为程序员的绩效考量指标，而且是“红线级别”和“底线级别”的考核指标。
我们课程的“页面可用性”和“高可用页面”，指的是搭建平台生产出来的页面的可用性。因为产出的页面是面向给外部客户使用，所以这个指标非常重要（至于整个运营搭建平台的全栈服务的功能，以及服务端代码可用性，我们后面会专门讲解Node.js服务的代码质量、运维稳定等可用性保障）。
那搭建平台页面高可用的设计和实现，我们具体如何开展呢？
前面说过，我们基于“页面回滚措施”来实现页面的高可用，页面回滚，就必须要回滚到某次正常发布运行的状态。去哪找页面每次发布的状态呢？
这就需要用到页面快照了，也就是每次发布页面后存储在快照中的版本数据。所以，我们面临的第一个问题就是，页面多版本管理要如何设计和实现。
如何设计和实现页面的多版本管理
每次走完发布流程后，我们发布到生产环境的内容，就是搭建出来页面的“页面布局数据”和“页面Bundle文件”，其中，Bundle文件包括JavaScript和CSS文件。这就意味着，每次发布页面后的版本内容就是“数据”和“Bundle文件”。
那这两个内容在哪里呢？
回忆上节课“后台发布流程”，我们在设计运营搭建平台数据库的时候，已经设计了数据库的“页面快照表”，在流程的最后节点，页面发布到生产环境的同时，把当时页面版本的数据记录一次快照，存到页面快照表中。这也就是说，页面版本的“数据”存在了“页面快照表”中。
版本的数据有了，剩下的就是版本“Bundle文件”。
其实，我们之前在“页面编译”和“后台发布流程”两节课中，已经把页面按版本增量编译了。你可以启动执行上节课“页面发布流程”的源码案例，在发布流程中，能发现每次版本迭代发布后，生成的预览页面都带有版本号，同时，Bundle文件路径也带有版本号，而且生产环境的预览页面的JavaScript和CSS的Bundle都带有版本号。
所以，这时候版本的Bundle文件也有了，结合版本的快照数据，就构成了完整的页面版本内容。
接下来，我们要做的就是进行页面内容管理版本的设计，大致的功能设计效果，你可以参考这张截图。
我们把页面版本管理和发布流程聚合在一个页面上，基于快照数据，来管理页面版本数据和版本Bundle文件。
因为页面快照数据就等于页面版本数据，而且，页面快照数据有当前页面的版本号和页面uuid，可以通过这两个信息，间接管理到页面Bundle文件的路径，或者是CDN的URL链接。所以，我们管理页面快照，就等于是管理了页面的版本数据，也间接管理了页面版本的Bundle文件。
现在，技术实现就变得很清晰了。
管理页面的快照数据，就是在页面发布流程中，每次发布到生产环境时，备份一份生产环境的页面布局数据，同时，要携带操作者的用户uuid，按页面版本维度，存在快照数据表里。这样，我们就可以知道某次发布页面操作的生产环节的页面数据和操作者。
页面快照的列表实现，你可以按照第23课中学过的“列表页面及前后端分页管理”的技术方案，实现页面快照的列表分页实现。
我们已经有了页面的版本内容，可以提供给页面回滚措施使用，通过指定回滚版本，恢复搭建页面的完整内容。那么我们面临的第二个问题就是，如何设计和实现回滚措施呢？
如何设计和实现回滚措施
要基于多版本的内容来设计和实现回滚措施，首先，我们要理解的一个核心点就是，回滚是把页面恢复到指定版本，其实，就是把对应版本的页面布局数据和Bundle文件，重新转入发布流程中。
我画了一张具体的流程图，“数据”和“文件”重新投入到发布流程中，再次经过测试、预发和生产三个流程节点，把页面内容恢复到生产环境里。可以分成两步。
- 复制内容和提升版本号
- 执行页面发布流程
第一步，复制内容和新增版本号，触发了指定版本的内容的回滚，把指定版本的数据和Bundle文件分别复制一份，然后新增一个小版本，进入一次新的发布流程执行操作。
你可能有困惑，为什么要新增一个新版本号呢？
这是因为在回滚过程中，恢复页面版本操作也是一种发布行为，也需要新增版本号，所以这个时候在复制页面数据过程中，我们也要附加上使用恢复版本号。
第二步，执行发布流程，跟原来的发布流程一致，以一个新的页面版本进行发布，并且最后发布到生产环境，也要把这次新版本页面内容再一次备份页面快照。其中，页面快照数据也要携带恢复的版本号信息。
到这里，方案看起来已经完善了，但是，很多人会漏掉一个细节问题，回滚版本需要重新进行页面Bundle编译吗？
目前的场景和方案看起来不需要，只需要复制Bundle文件就好。但是，注意，如果回滚到某个版本的同时，需要重新编辑页面布局或者物料数据源，就需要重新进行页面的Bundle文件编译了。
举个例子，有个长期的营销活动页面，“双十一”电商活动期间发布了一个页面版本，其中，广告模块的数据源是“双十一”相关的，到了“双十二”活动期间，当时页面版本出问题了，想利用回滚方式，用双十一的成功的页面内容版本。但是在回滚过程中，我们不可能直接使用带有“双十一”的数据源，必须基于双十一的版本，再次经过页面搭建的编辑，修改数据源后，才能进入发布流程。
在这个案例里，我们就要支持对应的“回滚”加“编辑”的功能，把回滚的操作步骤，从“页面发布流程”提前到“页面搭建”。
也就是说，触发了回滚操作后，复制数据和新增版本号，执行的下一个步骤就是“页面搭建”，让用户自己选择是否要重新编辑。在页面布局操作之后，复用“页面搭建”后的发布流程，不管是否重新编辑过页面，都只认传过来的页面布局数据，再编译一次页面Bundle文件编译，最后执行发布流程。
所以，我们要添加一个环节，在回滚的过程中，支持基于恢复的数据重新编辑。
看修改后的步骤图，回滚和重新页面搭建编辑的步骤分成三步。
- 第一步：复制内容和更新版本号
- 第二步：重新进行页面搭建的编辑
- 第三步：复用执行页面发布流程
具体的技术实现都是复用和串联原有存在的功能，我们就不再多说。
如何实现“页面多版本管理”和“页面回滚措施”，我们就学得差不多了。这两者，本质目的就是要打造高可用的搭建页面，结合的功能链路，就是搭建页面出问题后的快速补救措施，让我们在发现页面出问题不可用的时候，迅速恢复到指定可用的版本，尽量快速保障页面在线的长时间可用，避免出现客户使用不了页面功能的情况。
所以，回滚措施，也属于一种“兜底”措施，或者叫“保底”措施。
一般有了高可用的兜底措施后，我们就要往前推进，让页面出问题后，尽量用不到最后一步的兜底措施，争取在前置环节发现问题，及时定位和解决问题。
那么还有哪些前置型的高可用的措施，能尽量避免走到回滚恢复版本这一个兜底步骤呢？
还有哪些前置型高可用的措施
前置型的高可用措施，我们可以两个视角思考。
- 避免项目出现问题
- 避免项目问题扩大化
第一个视角，避免出现问题，就是尽量不要让问题出现，这就要在搭建页面的每个环节，做好严格把关。例如，物料组件开发代码质量、页面搭建拼接代码质量的严格审查等等，更多是在进入发布流程的前置阶段，做好质量把关。
第二个视角，避免问题扩大化，保证在出问题的苗头时，第一时间扑灭，减少问题影响面和影响时间。
因为没有任何程序员能保证代码是十全十美没问题的，有些问题，可能要在特定时间、特定场景出现，例如一些活动倒计时组件，可能要在活动当天才会触发隐藏的问题。所以，出现问题，在所难免，我们要做的是尽量第一时间发现问题和解决问题。
所以，这个角度我们需要做的措施一般都是进行页面监控。这里的“监控”指的是定时收集产线页面的报错信息，上报到服务器形成日志，并且，自动归类报错日志，某类日志报错超过一定警戒线时候，就触发警报，通过短信、邮件、甚至是机器人语音电话通知。
很多云服务厂商，都提供了很多类似的收费服务，例如前端日志上报功能、错误日志分析功能和预警通知功能。如果你负责的项目需要做前置的措施，而且预算充足，可以考虑直接购买相关服务。
如果项目预算不够，或者因为其它原因不能购买云厂商的服务，那么你可以尽量让服务端程序员帮忙开发功能。其中，问题警告通知功能可以用最低成本操作，例如服务端触发自动邮件通知。如果面临最糟糕的情况，需要前端自己开发，你可以参考我们后面会讲的关于Node.js服务的日志收集与问题排错。
总结
我们从“高可用”的概念开始，学习了什么是高可用，以及如何基于页面回滚措施，提升运营搭建平台页面的可用性。
高可用，用来表示系統的可用性程度，实际使用的时候，我们需要定义一个可用性的维度和标准，例如用时间。
页面多版本的快照管理，就是指发布生产环境的内容都需要版本化备份。数据可以存快照，静态资源可以复制备份。实际项目逻辑中，只要上产线的内容，我们要尽量做好版本备份，以备不时之需，出问题可以有迹可循，把产线内容恢复到指定备份版本的内容。
回滚措施的设计和实现，就是基于备份多版本的产线数据快照，选择恢复到指定稳定版本。注意，恢复过程不是简单覆盖内容，也是新增一个版本，把指定版本的备份，以新版本的形式进行发布。
今天我们主要学习了如何做好搭建生产页面的高可用性，核心还是在传达一个概念“要对生产环境保持敬畏之心”。任何内容，一旦上了生产环境，就要负责到底，包括保障客户能稳定使用、出问题能快速解决等等。
很多大厂的技术面试，无论前端还是服务端，面试官都或多或少会考察候选人对项目稳定性或高可用的思考。所以通过今天的学习，除了掌握项目“稳定性建设”和“高可用”的技术思维，也希望你能增强对“产线稳定”的敬畏之心。
思考题
运营搭建平台，除了用多版本回滚的措施外，还有其它的措施来快速对问题页面进行恢复吗？
期待在留言区看到你的思考，对于“产线稳定”如果你有一些感想，也欢迎留言分享。我们下节课再见。
完整的代码在这里
- ifelse 👍（0） 💬（0）
学习打卡
2024-09-30