企业官网建设流程全解析

怎样撰写企业网站建设方案,室内设计联盟官方网站下载,手机建站程序,苏州专业做网站的公司有哪些从 2020 年至今#xff0c;已经参与过 6 次 年终活动#xff0c;但今年这次是最狼狈的#xff0c;发生了太多状况。以至于#xff0c;我每个节点都要盯到 0 点多#xff0c;生怕又报错#xff0c;这个活动会持续 20 天。 一、活动前在活动前的周五的晚上 23 点#xff0…从 2020 年至今已经参与过 6 次 年终活动但今年这次是最狼狈的发生了太多状况。以至于我每个节点都要盯到 0 点多生怕又报错这个活动会持续 20 天。一、活动前在活动前的周五的晚上 23 点两个运营先后反馈充值页面在微信内显示白屏就算只剩下一个提示没有业务呈现。年终活动会与充值相关当即就引起了我们的重视。迅速响应当时运营以为是大范围的因为同时收到但事后发现是个别的人同一个人反馈了两个运营。根据 IP 地址将 Nginx 请求的日志和前端监控的日志对应起来后确认是请求脚本出错了。查看行为轨迹的日志发现就算点击了重新加载也没用。但我将地址复制到自己的浏览器中又是能正常访问的。在 Nginx 日志中发现此类脚本的请求响应码都是 304。也就是说页面请求的是缓存中的脚本。分析后得出一个在微信环境中问题发生的步骤但比较难复现。首次访问微信浏览器从服务器下载资源beanPay-77cc09a6.js并完整地记录下响应头中的 ETag 或 Last-Modified 标识符以及缓存规则如 Cache-Control。微信清理缓存你或系统为节省空间在微信的“设置-通用-存储空间”中清理了缓存。这删除了资源文件本身beanPay-77cc09a6.js 文件实体但可能没有完全删除或重置与该URL关联的缓存元数据特别是 ETag。再次请求微信浏览器发起请求时依然根据内存或数据库中保留的记录在请求头中带上了之前缓存的 If-None-Match (对应ETag) 标识。服务器检查发现该ETag对应资源未修改便正常返回 304 Not Modified。结果微信浏览器收到304后试图使用本地缓存但文件已被清理找不到资源实体最终导致页面加载错误如脚本加载失败。我们想到的策略就算完善刚刚白屏中的提示文案提醒用户去更换浏览器试试。并且在页面出错时动态的添加脚本并为其自动增加时间戳期望在重新请求后可以破坏资源缓存。scriptsrc/static/js/beanPay-58a0f5a9.js?v1766545846752/script在实际页面访问中还会访问到已经删除了的脚本文件那么就算加时间戳也无济于事。但是通常提示和加载优化后绝大部分的用户还是能正确将页面加载出来。二、活动中1数据库连接报错活动开始后的一天凌晨1点半后年终活动和充值页面打不开了一直加载中。插个背景由于历史原因我们很多活动的接口是用 Node 编写的而 Node 接口内部还会调用服务端的接口在凌晨 3 点 20 的时候就有监控组的客服同事打我电话我马上起来排查第一感觉就是非代码问题。排查 1 个小时候后果然在 Node 日志中发现了错误重启了服务器后故障恢复。Error [SequelizeDatabaseError]: read ECONNRESETyear_end_list Error [SequelizeDatabaseError]: read ECONNRESET凌晨没有联系到运维就给他留言了早上回复了说是内存水位线过高导致数据库重启。服务端其实也影响了但是因为会自动重连没有大范围报错。而我们使用的sequelize3.30没有重连机制所以数据库在异常重启后就断连了。2026 年的一个重点就是升级 sequelize.js现在的版本实在太旧最新版本已经到 6 了。而造成数据库重启的原因是服务端的 pod 数量增加占用的数据库连接也增加pod 连接数据库的默认连接也翻倍。高峰期相当于日常的 4 倍持续增高慢慢将数据库内存磨光出现了内存水位线过高导致的 OOM 报错。在大活动之前服务端升级了资源结果出现了意外。其实他们升级的太晚了在活动开始前一天才升级如果是我绝对要提前一周观察升级后的变化。在知道原因后我在白天写了份重连的逻辑就是加个定时器定时的去执行语句当出错时重新连接。不过在测试环境没有模拟出那个报错所以无法验证后面就想到直接监控错误日志。一旦有这个错误就自动重启服务器也可以重新连接数据库并且要将错误加到飞书告警中让我们第一时间知道。2接口大量挂起3 天后的周五晚上有个两个活动的赛段结点结束后就有大量的请求刷新去看结果。结果持续 5 分钟接口无响应五分钟内有 5000 多次请求涉及 268 个 IP第 6 分钟自动恢复。查看 Node 的监控发现并发量也不是很大QPS 最多 38 左右服务器的 CPU、内存等指标都不高。马上联系运维结果又没联系到我第一反应可能还是服务端的内部接口出问题了。周六早上运费回消息开始排查那一天没出门一直在推运维、测试、服务端的人排查和修改加校验。下午让测试组对活动的接口进行压测之前是对活动页面压测没有发现问题。对接口压测后马上暴露了问题出现了大量 499 请求服务端的两个内部接口也超时严重。原来是个订阅同步的功能将 CPU 拉高影响了服务的调用于是将该功能拆分单独运行。与此同时我们也对活动接口做了一轮优化内部有个单查询的 SQL 语句改成了批量查询。SELECT*FROMapp_userWHEREid?;SELECT*FROMapp_userWHEREidIN(?, ?);接口慢响应比例从万分之 8 降低至万分之 2并且关闭了预请求。原来会在页面呈现的 30 秒后自动去拉取页面内的其他 Tab 栏内的接口初衷是个体验优化。但实际上线后就发现并不是很需要预请求在某个阶段的活动结束后用户并不会再去切换 Tab 栏浏览。所以大部分的请求都浪费掉了而且结点时请求过多有可能出现性能问题。故而关闭了此优化关闭后每日的接口数量从最高 3.7W 稳定在 4K 浮动。3页面数据异常4 天后又到了一个赛段的结束蹲到 0 点没有发现异常。结果早上上班运营上报说某个用户的数据变成了 0。排查后发现是服务端内部的一个接口少了个参数也就是说漏需求了。我没发现服务端没发现测试也没发现然后上线后运营发现了。服务端的人没有仔细阅读需求文档开发全依赖我写的一个技术文档我就变成了瓶颈。这里面有些历史原图一般是服务端出接口文档前端协商修改我们这边是反着来的。我的文档一旦出错就会连着出错。而测试其实少了一个用例场景这次发生后也进行了补充。本次问题妥妥的就是个人祸后续需要大家对需求有更仔细的理解。