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

前端

• 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的运用，必然是未来主流的架构思想，作者正在努力学习。关于本文内容，欢迎大家积极补充。