Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

前端服务降级

  服务降级本来是一个后端的概念,当客户端的请求数多到服务器的极限时服务器可能采取降级措施,关闭掉一些非必要的功能来保证核心功能可以正常运行。但后端的降级只是对某些服务,对 http 服务是无法降级的。如果必要时在前端做一些降级处理也许更能保护服务器。
  比如「秒杀」程序,它会在某一个时间点产生大量请求。如果为这离散时间点的大量的请求添加大量机器来支持显然是一种产能浪费。前端降级就可以缓解这个问题。在每次前端调用秒杀的接口时,把大部分用户的调用直接在前端拦下来,只让少部分用户的请求发送到服务器。这样即使同时有大量请求涌入也不会全量被发送到服务器。
  上面这个「秒杀」的例子其实也挺多坑的,因为这对于用户而言是比较关键的行为,用户可能会去下载「秒杀软件」之类的东西来绕过前端降级程序。所以前端降级无法完全保护服务器,但我相信大部分用户的访问依然来自浏览器,所以这样的降级肯定是会带来一定作用的。
  「秒杀」算是一个比较特殊的例子了,因为它是针对一个时间点的。其实不仅是「秒杀」,所有的服务都可以前端降级。比如在服务器资源不够时阻止掉前端对一些带有慢查询的接口调用,这也属于前端服务降级的范畴。
  也许有人会有这样的疑问,客户端如何知道何时改开启服务降级?这个配置在哪里读取?读取这个配置文件的请求开销怎么计算?其实前端对页面的请求总是存在一个无缓存或短时间缓存的资源,因为前端程序必须为自己检查版本更新。也就是说前端的访问总是有一个有效请求的,我们可以利用这个请求来传输配置,不需要发起额外的配置请求。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^