LA/NMP 介绍 - 网站系统架构
一个成熟的大型网站（如百度、淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、可扩展、安全等特性，它总是随着用户量的增加、业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也会发生很大的变化，技术团队也从几个人发展到一个部门甚至产品线。成熟的系统架构是由小及大、从无到有，随着业务发展渐进式完善、发展出来的，并不是一开始就全部开发好了的。
下面将简要介绍广泛运行在大型网站系统架构中一些常见的技术和手段。
内容缓存加速
- Squid - 功能全而大，磁盘缓存，适合于各种静态的文件缓存（截止至目前为止相对使用最为广泛）
- Varnish - 内存缓存（少数人的玩具），性能强，对小文件如 CSS, JavaScript, 小图片之类的支持很棒
- ATS - Apache Traffic Server - 磁盘/内存缓存，性能强，支持插件开发
- Nginx - 代理功能只是 Nginx 的一个模块功能，得益于 Nginx 强大的性能，目前适合缓存少量页面资源
服务负载均衡
现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
第一阶段：利用 Nginx 或 HAProxy 进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用 Nginx 或 HAproxy 就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用 HTTP 协议就可以。这时是第一选择。
第二阶段：随着网络服务进一步扩大，这时单点的 Nginx 已经不能满足，这时使用 LVS 或者商用 Array 就是首要选择，Nginx 此时就作为 LVS 或者 Array 的节点来使用，具体 LVS 或 Array 的是选择是根据公司规模和预算来选择，Array 的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于 F5，商用首选！但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的 LVS，已经成为首选，这时 LVS 会成为主流。
最终形成比较理想的基本架构为：Array/LVS —> Nginx/Haproxy —> Squid/Varnish —> AppServer。
Keepalived - Keepalived 主要用来防止单点故障（单点故障是指一旦某一点出现故障就会导致整个系统架构不可用）的发生
keepalived 是基于 VRRP 协议（VRRP 协议介绍）的，请一定先了解 VRRP 协议后再进行配置。keepalived 可以把多台设备虚拟出一个 IP，并自动在故障节点与备用节点之间实现 failover 切换。这样我们配置两台货多台lvs调度节点，然后配置好 keepalived 就可以做到 lvs 调度节点出现故障后，自动切换到备用调度节点。（同样适用于 MySQL，Nginx 等）
- Nginx
- HAProxy
- LVS(Linux Virtual Server) - 淘宝正明（章文嵩大大）在国防科技大学读博期间的作品，是国内最早的开源软件之一
分布式缓存系统
分布式文件系统
MySQL 数据库集群
主从复制，读写分离，分库分表
NoSQL 数据库
分布式消息队列
扩展阅读
- Queues.io - 该项目汇集整理了目前流行的各种消息队列/任务队列系统
搜索引擎技术
扩展阅读
网站/服务运行监控
服务器硬件/系统监控
日志收集、处理、可视化
- logstash - aka. ELK (Elasticsearch, Logstash, Kibana)
- Splunk - 商业版，后来者 ELK 的主要假想超越对象
- Sentry
- loggly
- papertrail
- Sumo Logic
应用/服务可用性监控
- APM - Application Performance Monitoring
- 服务或应用当前状态 - Status page for your app or website
- StatusPage
- Cachet - PHP 开源版本
- Stashboard - Python 开源版本
- App Dynamics
- ruxit
- Datadog
- Keynote
- Pingdom
- Uptime Robot
- Monitority
- 小蜜蜂
- 监控宝