打开一个网页，网站背后跑着的架构东西远比屏幕上看到的复杂。网站架构说白了就是网站一套分工体系——谁负责接请求，谁负责算逻辑，架构谁负责存数据。网站这套体系怎么搭，架构直接决定了网站能扛多少人、网站出故障时会不会全盘崩掉。架构

最基础的网站一层是Web服务器。Nginx和Apache是架构这里最常见的两个角色。Nginx处理静态文件特别利索，网站一个进程能扛住上万个并发连接，架构很多团队拿它当反向代理用，网站请求先到它这儿，架构再转发给后面的网站应用服务器。Apache历史更久，模块生态丰富，.htaccess配置灵活，但高并发下内存吃得比较凶。选哪个，看你的实际场景——日PV几千的小站用哪个都行，日PV几千万的就得算账了。

应用服务器跑的是业务逻辑。Java阵营里Spring Boot几乎是默认选项，PHP那边Laravel和ThinkPHP各有地盘，Python的Django和Flask也常见，Node.js适合I/O密集型的场景。这一层做的事情是：接收请求、查数据库、拼数据、返回结果。听起来简单，但真正复杂的是怎么把这一层做成无状态的——意思是任何一台应用服务器挂了，请求切到另一台就能继续跑，用户完全无感知。做法就是别在本地存session，统一丢到Redis里。

数据库层是架构里最容易出瓶颈的地方。MySQL、PostgreSQL是关系型数据库的常客，MongoDB、Redis这类NoSQL各有各的用途。读写分离是最常见的优化手段：主库负责写，从库负责读，通过binlog同步数据。再往上走就是分库分表，用户量过千万之后基本绕不开这一步。我见过一个电商系统，订单表拆成了256张，按用户ID哈希路由，查询性能直接从秒级降到毫秒级。

缓存是另一个关键环节。Redis和Memcached是主流选择。缓存的位置也有讲究——浏览器缓存、CDN缓存、反向代理缓存、应用层缓存、数据库查询缓存，每一层都能挡掉一部分请求。一个设计得好的缓存策略，能让数据库的压力降到原来的十分之一。但缓存也有坑，雪崩、穿透、击穿这三个问题，做过后端的人多少都踩过。

负载均衡负责把流量分到不同的服务器上。硬件方案有F5，软件方案有LVS、HAProxy、Nginx。算法上轮询、加权轮询、最小连接数、IP哈希各有适用场景。四层负载均衡（传输层）和七层负载均衡（应用层）的区别也值得搞清楚——四层快但不够灵活，七层能根据URL路径做更精细的转发。

消息队列在架构里扮演的是解耦和削峰的角色。RabbitMQ、Kafka、RocketMQ各有拥趸。用户下单后，订单系统往队列里扔一条消息，库存系统、积分系统、通知系统各自消费，互不阻塞。秒杀场景下，消息队列把瞬间的流量洪峰摊平，后端按自己的节奏慢慢处理。

再往外一层是CDN，把静态资源推到离用户最近的节点。图片、CSS、JS这些不变的文件，用户直接从边缘节点拿，不用回源。视频网站对CDN的依赖尤其重，没有CDN，带宽成本能把公司拖垮。

微服务是近几年架构演进的一个方向。把一个大应用拆成几十个甚至上百个小服务，每个服务独立部署、独立扩缩容。好处是灵活，坏处是运维复杂度飙升。服务发现、配置中心、链路追踪、熔断限流这些配套组件一个都不能少。小团队硬上微服务，往往是自找麻烦。

安全层也不能忽略。WAF挡SQL注入和XSS，DDoS防护扛流量攻击，HTTPS加密传输，这些是标配。架构设计时如果没把安全考虑进去，后面补窟窿的成本会非常高。

说到底，网站架构没有标准答案。一个日活几百人的内部系统，一台服务器加一个数据库就够了，搞微服务纯属折腾。日活过亿的平台，架构图能画满一面墙。关键是匹配业务阶段，在成本、复杂度、可扩展性之间找到平衡点。过度设计比设计不足更常见，也更浪费。