大型网站架构设计总结

大型网站架构设计是一个循序渐进的过程,围绕“性能、可用性、伸缩性、扩展性、安全性”展开,下面是个人关于网站架构方面的一些总结,不到之处请大家多多批评。

前端

  • CDN加速:CSS/JS/图片等静态资源使用CDN加速,设置缓存时间、Referer限制(防盗链)等进行流量优化;
  • 减少HTTP请求:将CSS/JS/图片等静态资源合并,可以利用webpack等前端构建工具进行处理
  • 启用浏览器缓存和文件压缩:压缩图片、JS/CSS混淆压缩、Web服务器开启Gzip压缩&设置文件expire缓存时间;
  • 异步加载:动态接口通过Ajax异步加载,减少网络请求(可以通过JSONP或者设置Access-Control-Allow-Origin进行跨域);
  • 使用验证码:使用短信或图像验证码,提高验证码的复杂度及多样性,缓解羊毛党带来的流量冲击;
  • 减少Cookie传输:Cookie包含在每次请求和响应中,太大的Cookie会严重影响数据传输,例如针对CDN采用独立域名,可以减少静态资源加载携带Cookie信息;

缓存

关于缓存,永远要记住二八定律:80%的业务访问集中在20%的数据上。将热点数据进行缓存,可以降低网络I/O和磁盘I/O,极大提升响应速度,除了前端本地资源缓存外,服务端缓存常见做法如下:

  • 页面静态化:缓存整个页面,或者局部缓存,减少数据读取和运算频率;
  • 数据缓存:充分利用NoSQL数据库,例如memcached、redis、mongodb等,可以部署集群或分布式缓存,提高缓存命中率,减少数据访问的压力,可以进行缓存预热、预先加载热点数据,同时需要防止缓存穿透

消息队列

  • 异步解耦:利用Httpsqs、RabbitMQ、Kafka等队列或消息中间件,将耗时/非即时性操作通过队列进行异步处理,提高服务器响应速度,以此降低对资源的并发访问。遵循一个原则:任何可以晚点做的事情都应该晚点再做
  • 削峰填谷:由于流量是波动变化的,高峰和低谷差距很大,可以将一些操作存储到MQ队列中,消费端通过拉取的方式,并且拉去速度有消费端来控制,则就可以控制流量趋于平稳,达到了削峰填谷的目的,或者说起到了流控的目标。

数据库

使用缓存后,大部分数据读取操作都不用通过数据库完成,但是在缓存不命中、缓存过期和全部的写操作时需要访问数据库。当用户达到一定规模后,数据库会因为负载压力过高而成为瓶颈,常见做法如下:

  • 读写分离:利用Mysql主从复制机制搭建读写分离集群,在客户端实现或者服务端利用中间件(例如MyCAT)实现读写分离;
  • 分库分表:针对不同业务类型,进行分库,部署到不同服务器上,减少单服务器压力,同时针对大表,根据一定条件(如用户ID取模、ID范围)进行水平分表,减少单表读写压力;
  • 数据库连接池:充分利用连接复用,解决数据库连接过程需要占用资源,影响响应速度等问题,PHP本身没有连接池,可以利用第三方框架实现(例如SMProxy);
  • 硬件优化:利用磁盘阵列(RAID)提升数据可靠性,资金充足的话可以换SSD硬盘;

负载均衡

  • 业务拆分:根据URL拆分业务,分发流量到不同的服务器组,防止单一功能模块卡住,而影响整个业务,主要遵循SOA的架构思路,将业务模块打散(鸡蛋不要放在一个篮子里面)
  • 反向代理负载均衡:充分利用Nginx/Haproxy/LVS反向代理负载均衡,搭建服务器集群,提升并发处理能力;
  • DNS负载均衡:DNS解析可以依据不同网络运营商、地区进行分别解析、从而实现DNS层面负载均衡;

代码

  • 多线程:充分利用多CPU优势进行数据批处理
  • :在高并发情况下,对统一资源读写访问容易出现脏读、幻读,这个时候需要对核心资源枷锁,利用Redis或者Zookeeper等可以实现分布式锁;
  • 设计模式:充分利用设计模式,实现逻辑解耦、分层和资源服用,例如单利模式、观察者模式等;
  • 数据结构和算法:好的数据结构和算法可以给程序性能带来很大提升、例如链表查找、快速排序等;
  • 垃圾回收:良好的编程习惯,例如即时清理内存占用大的变量、避免操作的数据量大等都可以避免出现内存泄漏(OOM)的情况发生。
  • SQL查询优化:SQL执行效率一般是影响响应速度的关键,可以开启SQL慢查询日志,对执行效率慢的SQL语句进行优化;
  • GIT多分支:良好的分支管理对于CI/CD、版本测试有很好的作用,建议参考git-flow进行日常Git协作。
  • 日志:统一的日志输出标准,有利于进行数据追踪和问题排查。

冗余

  • 数据定期备份:定期全量备份+主从同步增量备份,例如MySQL/Redis主从复制进行增量备份、Mysqldump全量备份、Redis利用RDB或者AOF进行备份;
  • 集群:一定数量的备用服务器,可以保障系统的高可用,防止单点故障,可以结合Keepalived+LVS/HAProxy/Nginx等实现数据库/Web服务器/缓存/消息中间件高可用集群;

自动化

  • CI/CD:利用成熟的CI/CD机制实现自动化测试、代码检测,自动化发布,例如可采用Git+Jenkins+Docker搭建CI/CD工作流。
  • 自动化部署:针对超过30台的服务器部署,可以采用ansible进行批量管理
  • 自动监控/报警:监控用户行为日志、服务器日志等 ,可结合zabbix+ELK进行实施;
  • 自动降级和资源调度:微服务架构范畴,作者也在努力学习中。

安全

  • 二次验证:充分手机验证/人脸识别进行二次验证,保障操作的真实性;
  • web防火墙:传统防火墙仅限于包过滤,网络和端口地址转换(NAT)和VPN等功能。它根据端口,协议和IP地址做出决策;Web防火墙(WAF)则提供了HTTP/HTTPS访问请求监控、自定义过滤规则、Web攻击防护、安全合规等功能;可以利用阿里云等提供的WAF服务或者基于Nginx+lua等实现的类似API网关实施类似功能;
  • 内外网隔断:暴露出来的IP和端口越少,安全系数越高;例如数据库服务、缓存服务、中间件等尽量只允许内外访问,如果确实需要可以通过路由转发或反向代理实现;
  • 数据加密:充分利用非对称加密,例如启用https, rsa加密等,保障数据传输的安全性;
  • 网络攻击:需要防止DDOS攻击、XSS攻击、SQL注入、CSRF等,常见手段CDN加速、高仿IP、Linux内核优化、数据输入输出过滤、Referer限制、表单添加随机token/验证码等;
  • 信息安全:对于垃圾信息、敏感信息可以采用第三方解决方案(例如网易云盾、百度AI等)对文本、图片、音频、视频等进行过滤和审核。

总结

架构的演变,遵循着”分层->分割->分布式”的思路不断深入,是随着业务的增长,不断积累经验、优化、改良的过程。业务发展是架构发展的主要力量,架构的核心价值是服务业务的灵活发展。所有的架构设计必须以了解业务特点作为出发点,需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库、安全性等层面,这些层面看似一个整体,任何一个环节出问题都可能导致整个崩溃,所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。

大型网站的架构设计,作者也在不断的学习和实践,特别是微服务架构和K8S的运用,必然是未来主流的架构思想,作者正在努力学习。关于本文内容,欢迎大家积极补充。

有用就打赏一下作者吧!