从头替换一个2000万pv的站点,需要注意些什么?

举报
且听风吟 发表于 2019/12/17 16:03:31 2019/12/17
【摘要】 正确的评估你需要多少台机器现有一个网站pv在2000万左右,最高峰值的访问是五分钟一百万,相当于每秒3000左右,现有部署十六台web后台机器,每台每秒二百多,考虑到机器上另有差不多访问量级的服务在,暂时无压力。这个量级的访问对静态资源一定要使用CDN了,在正确使用CDN的前提之下,两台QPS在2k左右的静态资源服务器不会成为瓶颈。在一些关键的页面的关键接口上,需要使用wrk工具进行压测性能...

正确的评估你需要多少台机器

现有一个网站pv在2000万左右,最高峰值的访问是五分钟一百万,相当于每秒3000左右,现有部署十六台web后台机器,每台每秒二百多,考虑到机器上另有差不多访问量级的服务在,暂时无压力。

这个量级的访问对静态资源一定要使用CDN了,在正确使用CDN的前提之下,两台QPS在2k左右的静态资源服务器不会成为瓶颈。

在一些关键的页面的关键接口上,需要使用wrk工具进行压测性能,从而避免后端的存储服务发生问题。

善用缓存

缓存是解决高性能问题的利器,但是缓存同时也比直接的落地存储如Mysql要贵很多。所以,选择将什么样的内容进行缓存以及缓存的命中率就是使用缓存的重要考量。

一般而言,主动缓存相比于被动缓存更加的可靠。被动缓存是先尝试缓存,如果没有内容还是会向后端存储请求。而主动缓存可以理解成缓存和后端存储为一个整体,只需要放心大胆的请求缓存即可,保证数据是有效的。

热点数据肯定是缓存的重点,这个根据不同的业务形态而异。详情页肯定比积分页更容易达到访问高峰,而热门书也比冷门书的pv要高,这些都是根据业务产生的缓存需求。

缓存命中率的评估,需要有强有力的运维工具的支持。比如大量使用memcache的reddit,他们就有命中率统计工具diamond以及自研的追踪memcache的slads的工具,保证缓存命中率。对于Redis而言,我了解的有facebook在用的redis-faina,来查看redis的请求状态。

善用负载均衡

负载均衡的层面有很多,我们使用核心的主要有几个:

  • DNS解析的负载均衡

  • 反向代理的负载均衡

  • 后台服务的负载均衡

DNS解析的负载均衡

所谓dns解析的域名负载均衡,能解决的最大问题,一个是尽量的放置运营商的劫持,腾讯自建了一套GSLB的域名解析统一服务,通过与运营商的紧密合作,可以保证qq域名最大限度的不被运营商恶意劫持,而是通过GSLB的域名解析服务,顺利的进入腾讯的统一接入层TGW。

还有一个是进入了统一接入层之后,需要就近接入。即根据不同的运营商,分流到不同的接入机器中,如移动、联通、电信这三家,就要分别接入到不同的运营商的接入机器,然后再通过内网的方式进入腾讯的机房,保证请求链路的最优化。

反向代理的负载均衡

反向代理的负载均衡是提的最多的,也是部署和维护的成本最低的一种负载均衡的方式。最常用的方式就是使用nginx,对于一大批无状态的web服务器进行基于权重的请求分发和负载均衡。稍微复杂一点会增加nginx的模块,对web服务进行自动的端口监测,如果不通就会自动下线,一段时间后重试如果通了,再重新上线。不过这个需要一些适当的策略决策,防止临时的异常,导致机器被下掉太多,最终雪崩。

后台服务的负载均衡

后台服务的负载均衡,使用的是腾讯的L5方案,这套方案基本使用起来与外面通用的LB方案比较类似,就是支持tcp四层和http的透明代理。一个虚拟ip和端口对应后面多台机器,这样对业务来说就是透明的。同时它的中央决策机制更为复杂一些,调用者可以进行服务状态的上报,这再由中央服务器统一调度,剔除不可靠的机器。

动静分离

动静分离的理念已经深入人心了,主要分离的原因无非如下:

  • 减少不必要的cookie传输

  • 接入CDN需要区分域名

  • 防止遍历攻击

  • 静态资源单独配置压缩和编码

  • 独立部署,团队职责划分清晰

我们也是基本按照这个思路在做,静态资源方面,接入CDN,同时前端架构上做好刷新CDN的工作。再引入前端资源的压缩,以及接入统一的图片平台和小文件平台。再加上该静态化的页面果断的静态化,基本上能够支撑一个中大型网站的日常运营。

支撑系统

一个中大型的网站,对应的额支撑系统肯定少不了。我们使用的支撑系统包括而不限于:

  • 数据监控与告警平台

  • 数据上报与统计平台

  • 日志上报与分析平台

  • 发布系统(可回滚,可追溯,可前后置脚本,可独立文件发布,四可准则)

  • 机器监控平台

  • 服务发布、监控与重启平台

  • 配置维护与发布平台

  • CDN

  • 项目管理系统

  • 用户反馈系统

支撑越多,上线之后的系统,越放心!

做好运营支持与SEO

好的网站需要运营,其中运营系统和SEO专项的优化非常重要。有的时候可以说是至关重要的。 我们的运营系统主要包括了常规的推荐位处理,运营活动的配置,以及UGC内容的审核,针对网站的功能,快速的迭代出运营系统,就能为网站的发展提供不断的助力。

SEO专项优化,十分重要,基本思路就是按照百度的站长平台撸一遍。

  • 设计清晰的网站架构,

  • 在每个页面进行单独的SEO内容埋入,

  • 主动推送sitemap,

  • 持续的产出高质量的内容,

  • 与百度进行商务合作,

  • 尽量规避死链的出现,

  • 与其他高权重网站合作。

这些都是利器,同时在进行域名切换的时候,尤其要注意SEO的权重转移:

  • 首先将新网站上线,进行自然流量和自然权重的积累

  • 排名攀升之后,将老站进行301跳转

  • 在搜索引擎后台进行改版配置,保证权重的最大化转移

做好信息架构与数据上报

一个好的网站,它的信息架构一定是十分突出的。用户想去哪,该去哪儿,从哪儿返回,这都对于用户的留存和使用都非常的重要。所以在设计一个网站的时候,一定要对网站的信息架构进行充分的讨论,以及对优秀网站的信息架构进行借鉴。同时如果有条件的话,选取一部分用户进行灰度,通过数据埋点的方式追踪用户的行为,从而决定什么样的信息架构是最适合网站的发展的。

数据上报方式有很多,前端埋点是最基本的,对用户点击和行为的追踪,更接近用户本身。

测试与不断的回归测试

测试这块的话,还是手工测试的成分最多。但是同时也在做一些基本的代码检查、以及接口自动化测试和页面逻辑自动化测试。老实说,做的还是非常不够的。对于网站的持续优化而言,如果能做到每一个特性上线,都能将核心功能自动的check一遍,那么对于人力成本和开发成本而言,都能得到很大的优化。

本文转载自异步社区。

原文链接:https://www.epubit.com/articleDetails?id=NC7E3EF93B3800001D36C18DE10581B95

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。