作为前端，工作中处理过什么复杂的需求？，web前端开发入门学习

1.4 前端考验四——IMPush

IMPush是前端团队自研的消息通道，承接了所有socket消息转发。这个系统承接了聊天区所有的消息服务，与后台保持全双工长连接通道，利用Redis进行数据缓存，整体agent与center都会受到比较大的压力挑战。

这个服务如果挂了，所有的聊天区、弹幕都将面临瘫痪，影响也是非常大的。

同样的手段，借助于现有的负载均衡L5体系和资源，需要抗住巨大的并发量。

1.5 前端考验五——监控、日志与灰度

我习惯将监控、日志和灰度称为前端三板斧，是衡量一个前端团队是否专业的重要指标。很多前端并不注重这点，最多只有一个脚本报错的监控，最基本的测速返回码等监控都没有。

单论脚本报错监控，我们其实已经准备三套方案，BadJS+Sentry+FullLink，在超高的访问量下，可以预计所有的平台基本上都会挂，而脚本监控对于前端来说是非常重要的，三套系统的降级方案保证了我们在外网出问题的时候第一时间定位到问题所在，快速响应bug。

日志上报是前端最容易忽略的，当用户量多了你就会发现，很多问题是没有脚本报错的，如果只依赖于报错监控，很多外网问题两眼一抹黑，无从下手了。作为专业的前端，我们需要全链路的日志定位。

前端团队在这里借用开源的ELK方案，与后台全链路系统打通，在基础上通过DC通道上报落地，Agent代理不同监控系统，做成了上报中台方案，在Kibana系统上统一查询和定制报表。

灰度方案其实相对是比较难做的，最简单的是按照机器灰度，但这种方案在实际环境中基本上是不可用的，对于一个需求来说，如果同时修改了老页面和新页面，会导致用户前后访问不一，甚至出现404情况。更好的方式是按照登录态灰度，这时候我们需要统一接入层，Nginx、TSW都是可以的选择，在白名单内用户进行灰度。

<