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

前端

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