初遇项目网络平台架构设计方案

初遇项目网络平台架构设计方案

设计者：普金
 
目录
一 概述…4
二 引言…4
2.1 LNMP架构的概述…4
2.2 LNMP优化意义…4
三 需求分析…5
高可用…5
APP高可用(Nginx+php) …6
数据库高可用(Mysql) …6
缓存高可用(Redis) …6
消息队列高可用(RabbitMQ) …6
高性能…6
高扩展…7
安全性…7
易管理、易维护…8
四 瓶颈分析…9
4.1 网络负载…9
4.2 应用服务器性能…9
4.3 数据库服务器性能…9
4.4 其他性能瓶颈…9
五 总体架构…11
5.1 网站分层架构…11
5.2 网络拓扑架构…12
六 架构解析…12
6.1 负载均衡…12
1）GTM（Global Traffic Manager）…12
2）slb实现负载均衡…13
3）通过第三方软件实现负载均衡…13
6.2 应用集群…13
6.3 数据库集群…13
6.4 数据存储…14
6.5 消息队列…14
6.6 地域访问…14
6.7 南北互通…14
七 架构涉及技术详解15
7.1 负载均衡…15
1. 基于DNS的负载均衡…15
2. 硬件四层负载均衡…15
3. 软件四层负载均衡…16
4. 反向代理负载均衡…16
1) Nginx…17
2) HAproxy…18
3) GTM+HAproxy…18
5. Nginx+PHP集群实现负载均衡…20
7.2 缓存…21
1. 系统架构方面的缓存…21
1） Redis缓存…21
2） Nginx缓存…22
2. 应用程序方面的缓存…22
7.3 数据库集群…22
1. 数据库选择…22
2. 数据库的配置及优化…22
3. 良好的DB配置和备份…23
7.4 数据存储…23
1. 文件存储…23
2. 文件共享…23
7.5 消息队列…23
1． RabbitMQ优势…24
2． 工作机制…24
3． 消息持久化…25
4． 虚拟主机…26
7.6 Zabbix分布式监控集群…26
八 网络问题解决方案…29
智能DNS解析（GTM）…29
CDN…29
九 系统环境及优化…30
9.1 基础环境…30
9.2 系统优化…31
1. 系统内核优化…31
2. open files优化…32
3. 开启日志审计功能…32
4. 时间同步…32
5. 密钥登录…33
6. 防火墙配置…33
9.3 HAproxy优化…34
9.4 Nginx优化…35
9.5 PHP优化…35
十 服务架构测评…36
十一 配置选型…36
11.1 网络带宽…36
11.2 硬件配置…37
11.3 web架构和硬件选型…37
11.4 扩容策略…38
1. 添加服务器…38
2. 曾加存储…38
3. 升级服务器…39
4. 网络扩容…39
附录：一些主流网站的真实数据…39
一、 概述
构建一个稳定、高效、安全、冗余、可扩展的网站架构是一个项目运营成功的重要基石，基于这样的需求，就有必要提出一个经济实用的平台架构解决方案。而 LNMP架构以其开源免费的软件、低廉的硬件需求，成为了不少公司的web框架。本文着眼于社交平台构建，主要介绍如何以LNMP组建为核心，通过架构设计等技术，在保证性能和稳定的情况下提高并发量，构建一个经济实用、高效、安全、冗余、可扩展的网络架构。

本文件阐述了初遇项目系统的软件网络平台设计、系统运行配置与应用方式以及使用的关键技术等，依据多项开源技术、参考阿里云技术支持，结合公司产品实际业务情况、功能演进规划，进行技术架构设计和演进规划。

关键技术： HAproxy；nginx；mysql；PHP；Redis；RabbitMQ；GTM；SLB；OSS；NAS；CDN；VPN；

二、 引言

2.1 LNMP架构的概述

LNMP这个词是起架构的四个重要组成部分的首字母合写：Linux、Nginx、Mysql、PHP，它是一个优秀的应用架构组合。Linux作为操作系统；Nginx作WEB服务器；Mysql作为数据库；PHP作为开发语言。LNMP涵盖了一个web站点的四个重要部分：操作系统、web服务器、数据库、开发语言，他们呈分层结构，每一层为整个架构提供了各自的功能。

2.2 LNMP优化意义

在互联网行业，有个大家熟知的“8秒原则”，即用户在访问网站时，等待时间超过8秒就会感到不耐烦，如果下载速度过慢，则会放弃下载。据不完全统计表明，每一年，美国由于网站访问过慢而导致的经济损失达43.7亿美元。用户访问体验直接影响到公司的盈利，间接关系到用户对网站的粘贴度、忠诚度和依赖度。由此可见，一个高性能的应用或web站点对于企业，尤其是直接靠互联网盈利的企业的重要性。
于是，网站架构的优化就必不可少了，LNMP也不例外。如何使软件运行得能够最大限度发挥硬件的效能，这一直以来是人们为孜孜不倦的论题，人们按照自己的需求，不断对LNMP架构进行调整，以期达到安全、稳定、扩展、冗余的目标。这不仅是企业在商业上需求，也成为了不少技术人乐于探讨和研究的一个趣味性的议题。而精确到某一具体架构的优化，除了一些常规的调整，还需要技术人员对各个组件的功能和平台架构方案设计细节了解透彻，更需要深入了解企业业务需求，认真分析业务逻辑，才能够设计出符合需求的架构，才能够将优化的工作落实到每一个参数的控制，才能够讲系统调整到最佳状态。

三、 需求分析
众所周知，互联网网络平台的设计需求主要秉持三高原则，即高可用、高性能（高并发）、高扩展，在此基础上加上一个高安全就是一个非常好的应用平台了。我们一一分析讲解：

高可用
高可用HA（High Availability）是系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。如果一台系统能够不间断的提供服务，那么这台系统的可用性据说100%。那如果系统每运行100个时间单位，就会出现1个时间单位无法提供服务，那么该台系统的可用性是99%。目前大部分企业的高可用目标是4个9，也就是99.99%，也就是允许这台系统的年停机时间为52.56分钟。通俗讲就是7x24提供服务。
一个集群如果存在过多的单点故障，那也绝对是一个鸡肋架构，尤其是在重要节点没有设计备用服务器，一旦某一台机器除了问题，就可能造成整个集群的瘫痪。在此，我们采用负载均衡技术、主备冗余、主从部署、集群部署等技术对APP、数据库、缓存、消息队列服务器作高可用设计，形成关键节点的容灾备份，实现故障热迁移，有效避免单点故障。

前期因成本因素考虑使用阿里云ECS vpc服务器，阿里云不支持搭建自建高可用vip，因此我们采用如下方式设计高可用：

APP高可用(Nginx+php)
我们前期采用阿里云的HAprox+GTM实现主冗双活的方式进行负载均衡做高可用设计，实现应用层面的故障热迁移，有效避免应用单点故障，
后期采购自建服务器实现CDN+L3/L4反向代理+多组HAproxy+keepalived实现高可用设计。

数据库高可用(Mysql)
前期采用阿里云云数据库RDS-Mysql高可用版本，演进至主从复制读写分离。
后期采用自建Mysql集群

缓存高可用(Redis)
	前期使用阿里云Redis高可用版

后期采用自建Redis集群部署，4.0版本后自带集群功能，只需配置。

消息队列高可用(RabbitMQ)
	前期后期都自建：自带高可用模式

高性能
高性能主要体现方式为高并发，任何一个有责任心的SA都会想方设法提高网站的并发量，他们会在中间件的选型、配置的优化、硬件的分配、网络的拓扑等方面进行各种尝试。在我的架构中，使用开源高性能的专业反向代理服务器HAproxy来作前端的负载分流，使用高性能的轻量级nginx服务器处理后端页面，用Redis作高速缓存服务，使用RabbitMQ消息队列异步处理大幅提升程序响应速度。调整HAproxy和Nginx的进程、线程等参数，配置mysql的各种缓存参数等都是为了提高系统整体的并发量，尽量不让系统在某一点上出现瓶颈。

高扩展
目前处于初期建设中，将来整个网络系统将逐步扩大，同时随着应用系统的逐步完善，业务量用户数的急速提升，网络系统也将进行相应的扩展和升级，因此网络具有良好的可升级扩展性是非常非常重要的，在我的架构中所有应用系统都是可用横向扩展的。

安全性
安全永恒的话题，俗话说，没有钻不透的钢板，没有攻不破的城墙，放在我们IT行业同样适用，没有攻不破的网络，没有绝对的信息安全。软件开发行业里有个名词，叫“千行代码缺陷率”，意思是一千行代码中的漏洞率。绝大部分软件公司的每一千行代码就有可能存在一个漏洞。那么，可以想象一下，我们身边存在多少漏洞?我们最常使用的Windows操作系统的代码量是5000万行左右，安卓系统大概是1200万行，其中的漏洞可想而知。
网络安全的木桶原则，网络安全的木桶原则是指对信息均衡、全面的进行保护。“木桶的最大容积取决于最短的一块木板”。网络系统是一个复杂的计算机系统，它本身在物理上、操作上和管理上的种种漏洞构成了系统的安全脆弱性，尤其是多用户网络系统自身的复杂性、资源共享性使单纯的技术保护防不胜防。攻击者使用的“最易渗透原则”，必然在系统中最薄弱的地方进行攻击。因此，充分、全面、完整地对系统的安全漏洞和安全威胁进行分析，评估和检测（包括模拟攻击）是设计安全系统的必要前提条件。安全机制和安全服务设计的首要目的是防止最常用的攻击手段，根本目的是提高整个系统的"安全最低点"的安全性能。
根据初遇平台网络系统业务定位，平台应具有较高的安全性需求，特殊业务模块或项目有更高的安全性需求，安全性包括数据安全、网络安全、服务器安全等，每块都是一个永恒的话题，安全问题将单独出一套安全方案，在本案中不另行探讨。

易管理、易维护
在前期一台两台应用服务且服务不是太重要的时候我们可用使用人工管理与维护，当服务非常重要或服务形成规模集群的时候，手动管理人工维护将变得困难漏洞百出。如何高效率提升管理与维护性呢？在此涉及到自动化管理与运维的知识了。自动化运维的基本要素，准确性、实时性、完整性。
DevOps的出现有其必然性。在软件开发生命周期中，遇到了两次瓶颈。第一次瓶颈是在需求阶段和开发阶段之间，针对不断变化的需求，对软件开发者提出了高要求，后来出现了敏捷方法论，强调适应需求、快速迭代、持续交付。第二个瓶颈是在开发阶段和构建部署阶段之间，大量完成的开发任务可能阻塞在部署阶段，影响交付，于是有了DevOps。
DevOps的三大原则：
1、基础设施即代码（Infrastructure as Code）
DeveOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等
2、持续交付（Continuous Delivery）
持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署则不一定交付给用户使用。涉及到2个时间，TTR（Time to Repair）修复时间，TTM（Time To Marketing）产品上线时间。要做到高效交付可靠的软件，需要尽可能的减少这2个时间。部署可以有多种方式，比如蓝绿部署、金丝雀部署等。
3、协同工作（Culture of Collaboration）
开发者和运维人员必须定期进行密切的合作。开发应该把运维角色理解成软件的另一个用户群体。协作有几个的建议：1、自动化（减少不必要的协作）；2、小范围（每次修改的内容不宜过多，减少发布的风险）；3、统一信息集散地（如wiki，让双方能够共享信息）；4、标准化协作工具（比如jenkins）
本项目自动化将采用Jenkins + ansible实现持续部署持续交付，使用zabbix实现实时监控及简单自动化运维操作，使用微信、短信、邮件提供实时预警机制。

四、 瓶颈分析
网站的性能影响因素很多，主要从如下几个方面进行分析说明：
4.1 网络负载
a. 公网负载
b. 内网负载
4.2 应用服务器性能
a. CPU
b. 存储，I/O访问
c. 内存
d. 并发TCP/IP连接数
4.3 数据库服务器性能
a. 数据库参数配置
b. 服务器性能（CPU/内存/IO）
c. 数据结构的合理性
4.4 其他性能瓶颈
a. 静态页面
静态的HTML页面严格地由标准的HTML标识语言构成，并不需要服务端即时算生成。服务端收到静态请求后只用简单的把文档传送给客户端即可。针对CPU资源来说占用非常小。静态HTML瓶颈：网络带宽、磁盘IO以及cache。
b. 动态页面
动态页面比静态页面多了一个语言解释操作、一个数据库存储操作，这样就额外的增加了服务器性能消耗。额外的瓶颈：应用服务器的性能、数据库服务器的性能

五、 总体架构

5.1 网站分层架构

5.2 网络拓扑架构

六、 架构解析
因前期定位轻量、经济部署，考虑使用云服务部署，因云服务及云服务器有诸多三方局限和限制，本案采用阿里云云服务。架构将遵循简易、经济原则设计，最后给出演进方案，并最后附中大型企业解决方案。
为提高网站的高并发性能，提高开发效率及运营效率，主要按如下几个思路进行规划设计。

6.1 负载均衡

负载均衡集群采用GTM全局流量管理服务实现反向代理HAproxy的双活（高可用）模式，随着业务的增长HAproxy服务器的数量可持续横向扩展。

1）GTM（Global Traffic Manager）
通过GTM实现负载均衡的高可用
注：全局流量管理（Global Traffic Manager），简称GTM，它可以帮助企业实现用户访问应用服务的就近接入、高并发负载均摊、应用服务的健康检查，并能够根据健康检查结果实现故障隔离或流量切换，方便企业灵活快速的构建同城多活和异地容灾服务。
2）slb实现负载均衡
通过阿里云成熟的技术SLB负载均衡技术实现负载均衡
3）通过第三方软件实现负载均衡
通过HAproxy实现反向代理服务器集群

6.2 应用集群
Nginx作为web服务器，通过Nginx实现动静分离，静态资源对htm、html、gif、jpg、png、css、js、zip、txt、flv、swf、pdf等由Nginx处理，动态PHP资源由Nginx代理给后端php解释器处理，后端PHP前期不做单独负载，
后期php节点可往该方向扩展，Nginx节点可横向持续扩展。

6.3 数据库集群
Mysql为PHP动态服务提供持久化数据服务。此处采用采用阿里云RDS-Mysql 5.6高可用版。阿里云RDS高可用版为主备模式。实时同步数据库数据内容，保证了数据的冗余性和安全性，保护数据免受意外的损失。
中期可升级配置，添加主从库并做负载均衡扩展。
后期可自建Mysql集群，分表分库等方向扩展。

Redis集群为PHP提供高速缓存服务和session服务。在此我们采用阿里云Redis5.0社区集群版。
后期可自建Redis集群，Redis3.0版本之后支持集群部署，非常好用。

注：Redis 是一个高性能的key-value内存式数据库，并支持数据持久化。因为是内存式数据库，因此决定了Redis的超高存取速度。Redis到底有多快？Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。这个数据不比采用单进程多线程的同样基于内存的 KV 数据库 Memcached 差！

6.4 数据存储
视频、图片等数据资源使用阿里云的对象存储（OSS）服务存储，采用高速文件共享系统集中存储日志文件，方便程序员查看日志解决问题。

6.5 消息队列
消息队列（Message Queue）是一种应用间异步协作机制的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。其最重要的作用是解耦、异步、削峰。
本案采用RabbitMQ消息队列，rabbitMQ是部署最广泛的开源消息队列代理（Message Broker），采用镜像模式部署。

6.6 地域访问
1） 通过引入CDN来解决不同网络服务商的接入问题，一般只能解决静态页面的访问问题，引入CDN还可用做作分安全解决方案。
2） GTM可实现不同地区之间选择不同的服务器地址池，可解决不同地域界限的问题。

6.7 南北互通
如果使用阿里云服务是不存在南北互通的问题，因为阿里云使用的是BGP线路。如是第三方机房就需要考虑这个问题，解决这个问题的方法现在主要有如下方式：
1） 选择多线路机房然后通过规则自动识别线路进行转发
2） 选择有BGP选路的机房
3） 不同运营商机房部署服务器，通过镜像技术实现不同网络服务商的接入速度问题

七、 架构涉及技术详解

7.1 负载均衡

1. 基于DNS的负载均衡
   DNS负载均衡技术是最早的负载均衡解决方案，它是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，它们也就访问不同地址上的Web 服务器，从而达到负载均衡的目的。
   这种技术的优点是，实现简单、实施容易、成本低、适用于大多数TCP/IP应用；但是，其缺点也非常明显，首先这种方案不是真正意义上的负载均衡，DNS 服务器将Http请求平均地分配到后台的Web服务器上，而不考虑每个Web服务器当前的负载情况；如果后台的Web服务器的配置和处理能力不同，最慢的 Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用；其次未考虑容错，如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS 请求分配到这台故障服务器上，导致不能响应客户端。最后一点是致命的，有可能造成相当一部分客户不能享受Web服务，并且由于DNS缓存的原因，所造成的后果要持续相当长一段时间(一般DNS的刷新周期约为24小时)。所以在国外最新的建设中心Web站点方案中，已经很少采用这种方案了。
   我们这边采用的是阿里云GTM技术，是基于DNS类型的新型的负载均衡技术，支持地域负载、健康检测等。

2. 硬件四层负载均衡（本案不采用，仅做了解）
   在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了

3. 软件四层负载均衡（本案不采用，仅做了解）
   软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
   一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性。
   本案不采用，因为阿里云ECS暂不支持VIP配置。

4. 反向代理负载均衡
   反向代理服务器又称为 WEB 加速服务器，它位于 WEB 服务器的前端，充当WEB服务器的内容缓存器,反向代理服务器是针对 WEB 服务器设置的，后台 WEB 服务器对互联网用户是透明的，用户只能看到反向代理服务器的地址，不清楚后台 WEB 服务器是如何组织架构的。当互联网用户请求 WEB 服务时，DNS 将请求的域名解析为反向代理服务器的 IP 地址，这样 URL 请求将被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答、与后台 WEB 服务器交互。利用反向代理服务器减轻了后台 WEB 服务器的负载，提高了访问速度，同时避免了因用户直接与 WEB 服务器通信带来的安全隐患。

目前有许多反向代理软件，比较有名的有 Nginx 和HAproxy
Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的Rambler.ru 站点开发的，是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。

1. Nginx
   Nginx (“engine x”) 是俄罗斯人Igor Sysoev(塞索耶夫)编写的一款高性能的 HTTP 和反向代理服务器。
   Nginx 已经在俄罗斯最大的门户网站── Rambler Media上运行了4年时间，同时俄罗斯超过20%的虚拟主机平台采用Nginx作为反向代理服务器。
   在国内，已经有新浪博客、新浪播客、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、频道使用 Nginx 服务器。Nginx 特点如下：

2. 工作在OSI模型的第7层（应用层）

3. 高并发连接

4. 官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。

5. 内存消耗少
   在3万并发连接下，开启的10个Nginx 进程才消耗150M内存（15M*10=150M）。

6. 配置文件非常简单
   风格跟程序一样通俗易懂。

7. 成本低廉
   Nginx为开源软件，可以免费使用。而购买F5 BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币。

8. 支持Rewrite重写规则
   能够根据域名、URL的不同，将 HTTP 请求分到不同的后端服务器群组。

9. 内置的健康检查功能
   如果 Nginx Proxy 后端的某台 Web 服务器宕机了，不会影响前端访问。

10. 节省带宽
    支持 GZIP 压缩，可以添加浏览器本地缓存的 Header 头。

11. 稳定性高
    用于反向代理，宕机的概率微乎其微。

12. HAproxy
    HAproxy性能比Nginx更加强大，是专业反向代理软件。有Nginx所没有的功，支持对Mysql负载均衡，支持后端url检测，支持虚拟主机、负载算法更多。它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的
    本案采用HAproxy反向代理服务器构建。

13. GTM+HAproxy实现反向代理负载均衡及高可用
    通过GTM+HAproxy实现负载均衡如下图所示：

5. Nginx+PHP集群实现负载均衡

使用多个Nginx和多个PHP配置一个负载均衡与动静分离的后端网站，通过Nginx分流，把请求按照权重及当时负荷分配给php1、php2、php3…去处理，Nginx作为HttpServer，通过upstream连接多个PHP应用解析器，并实现负载均衡

7.2 缓存

1. 系统架构方面的缓存
   1） Redis缓存
   数据库缓存：
   sql语句时key值，查询结果resultSet是value，当同一个查询语句访问时（select * from t_product），只要曾经查询过，调用缓存直接返回resultSet，节省了数据库读取磁盘数据的时间。
   持久层缓存：
   减少了连接数据库的时间；减少了resultSet封装成对象的过程。
   业务层和控制层的缓存：
   减少调用层次。
   描述缓存在业务层的逻辑：
   查询商品信息
   判断当前查询在缓存是否有数据
   如果有数据，直接返回，当前请求结束；
   如果没有数据，查询持久层数据库数据，获取数据存储再缓存一份，供后续访问使用；
   缓存雪崩/缓存击穿：
   海量请求访问服务器,服务器的性能由缓存支撑,一旦一定范围的缓存数据未命中,请求的数据访问涌入数据库;承受不了压力造成宕机–重启–海量请求并未消失–宕机–重启,系统长时间不可用;这种情况就是缓存的雪崩。
   Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)

2） Nginx缓存
Nginx从0.7.48版本开始，支持了类似Squid的缓存功能；
缓存把URL及相关组合当作Key，用md5编码哈希后保存；
Nginx的Web缓存服务只能为指定URL或状态码设置过期时间，不支持类似Squid的PURGE指令，手动清除指定缓存页面；
采用MMAP实现，设置的缓存区大小不能超过物理内存+SWEB的值

2. 应用程序方面的缓存
   结合前端APP缓存

7.3 数据库集群

1. 数据库选择
   对生产数据库采用阿里云RDS-Mysql5.6高可用版

2. 数据库的配置及优化
   针对系统业务数据的特点，把大的表进行拆分，对于访问较多的表采用分区表。
   使用读/写数据库分离，随着系统变得越来越庞大，特别是当它们拥有 很差的SQL时，一台数据库服务器通常不足以处理负载。但是多个数据库意味着重复，除非你对数据进行了分离。更一般地，这意味着建立主/从副本系统，其中 程序会对主库编写所有的Update、Insert和Delete变更语句，而所有Select的数据都读取自从数据库（或者多个从数据库）。
   尽管概念上很简单，但是想要合理、精确地实 现并不容易，这可能需要大量的代码工作。因此，即便在开始时使用同一台数据库服务器，也要尽早计划在PHP中使用分离的DB连接来进行读写操作。如果正确 地完成该项工作，那么系统就可以扩展到2台、3台甚至多台服务器，并具备高可用性和稳定性。

3. 良好的DB配置和备份
   很多公司都没有良好的备份机制，也不知道如 何恰当地完成这项工作。只有imp是不够的，还需要进行热备份，从而得到超快的速度和超高的可靠性。
   另外，在将所有备份文件从服务器上转移出来之前要进行压缩和加密。另外还要确保拥有设计合理的、有用的关于安全、性能和稳定性问题的设定，包括防止数据败坏，其中很多设定都是非常重要的。

7.4 数据存储

1. 文件存储
   OSS对象存储是阿里云企业很成熟的产品，功能多样全面。如若不使用阿里云OSS，使用自建的服务器可以使用HDFS或FDFS分布式文件系统，在此不多做讲解

2. 文件共享
   NAS网络区域存储也使用阿里云的产品，因为服务器使用的是阿里云ECS。NAS也是一个很成熟的产品，与NFS功能类似。在此不对做详解

7.5 消息队列

消息队列是如何工作的，请看下图：

1． RabbitMQ优势
现在的市面上有很多MQ可以选择，比如ActiveMQ、ZeroMQ、Appche Qpid，那问题来了为什么要选择RabbitMQ？

1. 除了Qpid，RabbitMQ是唯一一个实现了AMQP标准的消息服务器；
2. 可靠性，RabbitMQ的持久化支持，保证了消息的稳定性；
3. 高并发，RabbitMQ使用了Erlang开发语言，Erlang是为电话交换机开发的语言，天生自带高并发光环，和高可用特性；
4. 集群部署简单，正是应为Erlang使得RabbitMQ集群部署变的超级简单；
5. 社区活跃度高，根据网上资料来看，RabbitMQ也是首选

2． 工作机制
生产者：消息的创建者，负责创建和推送数据到消息服务器；
消费者：消息的接收方，用于处理数据和确认消息；
代理：就是RabbitMQ本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。

想要真正的了解Rabbit有些名词是你必须知道的。
包括：ConnectionFactory（连接管理器）、Channel（信道）、Exchange（交换器）、Queue（队列）、RoutingKey（路由键）、BindingKey（绑定键）。
ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用；
Channel（信道）：消息推送使用的通道；
Exchange（交换器）：用于接受、分配消息；
Queue（队列）：用于存储生产者的消息；
RoutingKey（路由键）：用于把生成者的数据分配到交换器上；
BindingKey（绑定键）：用于把交换器的消息绑定到队列上；
看到上面的解释，最难理解的路由键和绑定键了，那么他们具体怎么发挥作用的，请看下图：

3． 消息持久化
Rabbit队列和交换器有一个不可告人的秘密，就是默认情况下重启服务器会导致消息丢失，那么怎么保证Rabbit在重启的时候不丢失呢？答案就是消息持久化。
当你把消息发送到Rabbit服务器的时候，你需要选择你是否要进行持久化，但这并不能保证Rabbit能从崩溃中恢复，想要Rabbit消息能恢复必须满足3个条件：
投递消息的时候durable设置为true，消息持久化，代码：channel.queueDeclare(x, true, false, false, null)，参数2设置为true持久化；
1． 设置投递模式deliveryMode设置为2（持久），代码：channel.basicPublish(x, x, MessageProperties.PERSISTENT_TEXT_PLAIN,x)，参数3设置为存储纯文本到磁盘；
2． 消息已经到达持久化交换器上；
3． 消息已经到达持久化的队列；

Rabbit会将你的持久化消息写入磁盘上的持久化日志文件，等消息被消费之后，Rabbit会把这条消息标识为等待垃圾回收。消息持久化的优点显而易见，但缺点也很明显，那就是性能，因为要写入硬盘要比写入内存性能较低很多，从而降低了服务器的吞吐量，尽管使用SSD硬盘可以使事情得到缓解，但他仍然吸干了Rabbit的性能，当消息成千上万条要写入磁盘的时候，性能是很低的。所以使用者要根据自己的情况，选择适合自己的方式。

4． 虚拟主机
每个Rabbit都能创建很多vhost，我们称之为虚拟主机，每个虚拟主机其实都是mini版的RabbitMQ，拥有自己的队列，交换器和绑定，拥有自己的权限机制。

7.6 Zabbix分布式监控集群

Zabbix 是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。
对于一个运维人员来说，不论是传统运维还是自动化运维，保证线上业务整体能够稳定运行是相当重要的，所以运维需要时长实时的关注到服务器的运行情况，关注各项指标是否正常，那么这里就用到了今天学习的zabbix技术，zabbix可以监控我们在运维工作当中遇到的大部分的硬件。并提供实时动态的web可视化结果展示，因此特别受到大家的欢迎。
假如没有zabbix，我们肯定要手写一些监控的脚本，或者类zabbix的平台，但是如果我们监控都是服务器设备，那么我们可以通过ssh或者telnet。但是作为一个完整的(高大上)监控平台，单纯的只能监控服务器是不够完美的，所以，我们首先要了解一下zabbix如何实现监控其他设备的，在这一方面，zabbix主要采用了一下几种方法：
1、 agent 毋庸置疑，这个是最常规的master/agent的模型
2、 ssh/telnet 远程操作，类似于Ansible要实现的功能了
3、 SNMP 通过SNMP协议与被监控的对象进行通讯，通常用于路由器和交换机这种硬件设备，
毕竟在他们上面安装agent太难了。
4、 IPMI 通过IPMI接口进行监控，通常用于电压、温度、风扇和电源状态的监控
5、 JMX 通过JMX进行监控，通常是针对jvm虚拟机的

八、 网络问题解决方案
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，而不同网络之间访问速度会很慢，我们可以采用镜像网站和引入CDN来解决这一问题。

智能DNS解析（GTM）
我们可以在不同的网络运营商部署web服务器，通过linux上的rsync工具自动同步到不同网络接入商的web服务器上，以作为主站的镜像。
然后通过配置智能DNS解析来引导不同网络的访问用户到对应的网络运营商的web服务器。
CDN
如果有足够的投资，也可以采用CDN(内容分发网)，把静态内容（静态页面和图片）进行CDN缓存，以减轻服务器压力。
CDN的全称是Content Delivery Network，即内容分发网络。它采取了分布式网络缓存结构（即国际上流行的web cache技术），其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度。
目前，国内访问量较高的大型网站如新浪、网易等，均使用CDN网络加速技术，虽然网站的访问巨大，但无论在什么地方访问都会感觉速度很快。而一般的网站如果服务器在网通，电信用户访问很慢，如果服务器在电信，网通用户访问又很慢。

九、 系统环境及优化
在一定的架构基础上，要提高并发处理能力则需要调整服务器的操作系统内核参数、代理服务器、web服务器（Nginx的参数、PHP的参数），以使其性能达到最优化。
9.1 基础环境
操作系统：Linux Centos7.4
数据库： Mysql5.6 （阿里云）
存 储： OSS NAS（阿里云）
缓 存： Redis5.0 （阿里云）
负载均衡： GTM（阿里云） HAproxy Nginx
消息队列： RabbitMQ
监控集群： Zabbix

9.2 系统优化

1. 系统内核优化
   Linux系统优化需要调整系统的内核参数，我的内核参数如下：
   fs.file-max = 999999
   net.ipv4.ip_forward = 0
   net.ipv4.conf.default.rp_filter = 1
   net.ipv4.conf.default.accept_source_route = 0
   kernel.sysrq = 0
   kernel.core_uses_pid = 1
   net.ipv4.tcp_syncookies = 1
   kernel.msgmnb = 65536
   kernel.msgmax = 65536
   kernel.shmmax = 68719476736
   kernel.shmall = 4294967296
   net.ipv4.tcp_max_tw_buckets = 6000
   net.ipv4.tcp_sack = 1
   net.ipv4.tcp_window_scaling = 1
   net.ipv4.tcp_rmem = 10240 87380 12582912
   net.ipv4.tcp_wmem = 10240 87380 12582912
   net.core.wmem_default = 8388608
   net.core.rmem_default = 8388608
   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   net.core.netdev_max_backlog = 262144
   net.core.somaxconn = 40960
   net.ipv4.tcp_max_orphans = 3276800
   net.ipv4.tcp_max_syn_backlog = 262144
   net.ipv4.tcp_timestamps = 0
   net.ipv4.tcp_synack_retries = 1
   net.ipv4.tcp_syn_retries = 1
   net.ipv4.tcp_tw_recycle = 0
   net.ipv4.tcp_tw_reuse = 1
   net.ipv4.tcp_mem = 94500000 915000000 927000000
   net.ipv4.tcp_fin_timeout = 75
   net.ipv4.tcp_keepalive_time = 75
   net.ipv4.ip_local_port_range = 1024 65000

2. open files优化
   优化用户open files（用户可以打开文件的最大数目）
   立马生效：ulimit –n 65535
   重启生效： /etc/security/limits.conf最后添加

• soft noproc 11000
• hard noproc 11000
• soft nofile 20480
• hard nofile 20480

3. 开启日志审计功能
   记录每个用户使用过的命令
4. Echo “readonly PROMPT_COMMAND=’{ cmd=KaTeX parse error: Expected '}', got 'EOF' at end of input: …a b c d; echo "d"; });msg=$(who am i |awk “{print $2,$5}”);logger -i -p local1.notice “$msg $USER $PWD # $cmd”; }’” > /etc/profile.d/cmd_log.sh
5. Rsyslog的local7下面添加
   local1.notice /var/log/.command_audit.log
6. 时间同步
   定时同步时间ntpdate
7. 密钥登录
   ssh使用密钥登录而关闭密码登录
8. 防火墙配置
   防火墙配置安全防御

9.3 HAproxy优化
maxconn 4000 ###最大连接数，默认4000
user haproxy
group haproxy
daemon ###创建1个进程进入deamon模式运行。此参数要求将运行模式设置为"daemon"
defaults
mode http ###默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
log global ###采用全局定义的日志
option dontlognull ###不记录健康检查的日志信息
option httpclose ###每次请求完毕后主动关闭http通道
option httplog ###日志类别http日志格式
option forwardfor ###如果后端服务器需要获得客户端真实ip需要配置的参数，可以从Http Header中获得客户端ip
option redispatch ###serverId对应的服务器挂掉后,强制定向到其他健康的服务器
timeout connect 10s #default 10 second timeout if a backend is not found
timeout client 1m ###客户端连接超时
timeout server 1m ###服务器连接超时
maxconn 60000 ###最大连接数
timeout http-request 10s#请求超时
timeout check 10s #检查超时
timeout http-keep-alive 10s#长连接超时
timeout queue 1m #队列超时
retries 3 ###3次连接失败就认为服务不可用，也可以通过后面设置
####################################################################
listen stats
mode http #模式http
bind 0.0.0.0:1080 #监听端口
stats enable #启用监控
stats refresh 30s #统计页面自动刷新时间
stats uri /haproxy #统计页面url
stats realm Haproxy Manager #统计页面密码框上提示文本
stats auth admin:admin #统计页面用户名和密码设置
#stats hide-version #隐藏统计页面上HAProxy的版本信息
frontend main
bind 0.0.0.0:80 ###绑定的监控IP与端口
mode http #模式http
acl url_static path_beg -i /static /images /javascript /stylesheets
acl url_static path_end -i .jpg .gif .png .css .js

use_backend static if url_static     ###满足策略要求，则响应策略定义的backend页面
default_backend   dynamic      ###不满足则响应backend的默认页面

#---------------------------------------------------------------------

static backend for serving up images, stylesheets and such

#---------------------------------------------------------------------

backend static
balance roundrobin ###负载均衡模式轮询
server static 127.0.0.1:80 check ###后端服务器定义

backend dynamic
balance roundrobin

balance source

cookie JSESSIONID prefix

server         websrv1 172.16.150.19:80 check maxconn 2000
server         websrv2 172.16.8.25:80 check maxconn 2000
server         websrv3 172.16.150.16:80 check maxconn 2000

errorfile 403 /usr/local/haproxy/errorfiles/403.http
errorfile 500 /usr/local/haproxy/errorfiles/500.http
errorfile 502 /usr/local/haproxy/errorfiles/502.http
errorfile 503 /usr/local/haproxy/errorfiles/503.http
errorfile 504 /usr/local/haproxy/errorfiles/504.http

9.4 Nginx优化
不贴配置了，简要说一下，优化传输Gzip，优化缓存proxy_cache,使用epoll模式，优化打开连接数，去除版本信息，优化日志输出格式，优化超时设置，优化Head头等。

9.5 PHP优化
nginx转发php类型的请求可以通过fastcgi的方式，fastcgi支持TCP和 unix domain socket两种方式。
Unix domain socket 或者 IPC socket是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信
与管道相比，Unix domain sockets 既可以使用字节流和数据队列，而管道通信则只能通过字节流。
如果nginx和php-fpm都在同一台机器，当然是选择Unix domain socket方式；但是如果nginx和php-fpm不在同一台机器，socket方式就不能用了。
在服务器压力不大的情况下，tcp和Unix domain socket差别不大，但在压力比较满的时候，用套接字方式，效果比较好
像如果我们使用Nginx做PHP负载均衡就只能使用TCP模式了。

十、 服务架构测评
需要结合实际环境进行评测（待补充…）

十一、 配置选型
11.1 网络带宽
只考虑API访问的带宽占用，后台管理页面等其他业务访问与门户访问相差2-3个数量级，这一部分网络流量占用忽略。同时考虑网络带宽利用率（70%）
根据业务设计能力，每秒网络流量=WEB网站每秒钟访问流量=（每次访问占用的带宽×每秒访问次数）/带宽利用率
=(200K8n)/0.7
注：一般首页请求大小>1M、平均200K/页面，我们以平均值来计算。

并发能力 占用的网络带宽
100次/秒 228 M
200次/秒 457 M
500次/秒 1442 M
1000次/秒 2286 M

因我们主要的视频图片存储在OSS里面，OSS是以流量包计费的，所以不需要界定最高带宽。我们只计算传入后端web服务器的流量，后端请求稍微小一些，按每个10K算，按照公式计算。
并发能力 占用的网络带宽
100次/秒 10 M
200次/秒 22 M
500次/秒 75 M
1000次/秒 100 M

11.2 硬件配置

序号 产品功能 参考型号、配置
1.1 数据库服务器 阿里云RDS mysql，采用8核16G社区高可用版，50G存储量
1.2 WEB服务器 阿里云ECS，采用4核8G 计算网络增强版，系统盘40G，数据盘100G
1.3 反向代理服务器 阿里云ECS，采用4核8G 计算网络增强版，系统盘40G，数据盘100G
1.4 消息队列 阿里云ECS，采用4核8G 计算网络增强版，系统盘40G，数据盘100G
1.5 缓存服务器 阿里云Redis5.0社区集群版，4G 4节点
1.6 数据存储 阿里云OSS对象存储，NAS网络区域存储
1.7 防火墙 阿里云DDOS基础防御，大概5G左右

注：上表为硬件的参考配置，根据业务规模的不同，在初期服务器性能也可以作适当缩减，达到一定规模后再进行扩容

11.3 web架构和硬件选型

并发能力 Web服务器架构 服务器配置 备注
<200次/秒 1个HAproxy
n个Nginx+PHP（n>=2） 1台反向代理
2台web服务
1台消息队列 web服务器同时部署Nginx和PHP
200~500次/秒 1个HAproxy
N个Nginx+PHP（n>=3）
注：同时配置缓存 1台反向代理
3台web服务
1台消息队列 增加web服务器数量

500次/秒 CDN
2个HAproxy
n个Nginx
m个PHP
注：同时配置缓存 增加CDN网络
1个GTM服务
2台反向代理
n台web服务n>=2
m台php服务器m>=6
2-4台消息队列 反向代理实现高可用双活
Web服务动静分离，PHP单独提供服务
数据库升级并配置配置集群，添加数据库实现主从复制，并实现数据库负载均衡。
数据库升级配置
Redis升级配置
消息队列升级集群
1.5万次 CDN
n个HAproxy
m个Nginx（n>=3）
k个PHP（m>=9
I个消息队列
注：同时配置缓存 CDN网络
n台反向代理n>3
m台web服务（n>5）
k台PHP服务器k>15
i台消息队列i>4 需解决
数据库瓶颈：

1. RDS mysql采用多台主从+负载均衡
2. 采用自建集群，分表分库
3. 组建多台mysql cluster
   缓存瓶颈
4. 升级阿里云Redis集群版
5. 自建集群，用6台以上redis cluster组成集群
   消息队列瓶颈：
   组建多台消息队列集群

11.4 扩容策略
当网站发展到一定阶段，随着用户量不断扩大，现有的网络资源和服务器资源不能满足用户需要的时候，就需要对平台进行服务器和网络的扩容。以下是两种平台扩容的方式：

1. 添加服务器
   对于web的并发处理有瓶颈时，新增的web服务器，把新增的web服务器填加到Web服务器集群中，以增加WEB的并发处理能力。
   对于数据库有处理压力时，可以增加数据库服务器，增加数据库服务器加入数据库的集群中。

2. 曾加存储
   对于存储不能满足要求时，阿里云提供数据盘的扩容，数据库的扩容支持

3. 升级服务器
   可以升级服务器的内存、硬盘，甚至考虑用新的性能更高的服务器来替换。

4. 网络扩容
   1） 申请更大的网络带宽
   2） 引入CDN
   3） 转为内网访问

附录：一些主流网站的真实数据

1. taobao
   服务中心200台服务器承载了70亿/天的请求
2. 维基百科
   alexa 访问量排名第 6 的维基百科，每天有 3.4 亿个 PV，但其最高峰的 HTTP 请求数也只有五六万左右。
3. facebook
   120M+ active users
   50B+ PVs per month 50B+ PVs per month
   10B+ Photos
   1B+ connections
   50K+ Platform Apps
   400K+ App Developers

LAMP + Services
AdServer
Search
Network Selector
News Feed
Blogfeeds
PHP
Memcache
MySQL Blogfeeds
CSSParser
Mobile
ShareScraper
4) Amzon的一组数据：
超过5500万活动顾客的帐号和账单信息；
世界范围内超过100万个活动零售商；
构建一个页面所需要访问的服务API在100至150个；
每天数十亿的用户访问。
这是一组庞大的数字

5. 豆瓣网的一些数据：
   2.8M注册用户，约1/4活跃用户
   千万级非注册用户
   20M动态请求/天，峰值500~600/sec
   23台普通PC服务器(1U15/2U8)
   12台提供线上服务
   38G memcached

6. ebay
   212,000,000 注册用户
   十亿
   每天十亿的PV
   每天260亿的SQL执行。

7. Yupoo
   国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：
   带宽：4000M/S (参考)
   服务器数量：60 台左右
   Web服务器：Lighttpd, Apache, nginx
   应用服务器：Tomcat
   其他：Python, Java, MogileFS 、ImageMagick 等

8. 优酷网：
   VV: 1.6亿+
   日上传视频: 6万+
   LAMP+lighttpd
   Memcached