中大型网站调优之架构优化策略

最近在一些域名群里看到有些新手站长对于服务器/云计算机的选购疑问。所以,我开篇还是以硬件基础为切入点,毕竟硬件也大型网站调优的一部分。

硬件基础知识

其实,对于计算机硬件大家都不会陌生,无非是CPU、RAM、Disk、Network Card. 对于服务器而言,道理也是一样的。首先,我们还是要掌握一个基本原则,协调不浪费。下面我就各个主要硬件设备做一个简单说明吧。

  • CPU: 刚学计算机,老师都会说这玩意就像人脑。其重要性不言而喻。服务器常用的CPU是Intel至强系列,志强E5多见一些。志强E3基本跟我们家用PC的I7性能类似,主要区别在于志强E3不带GPU显卡相关指令,所以它是不支持主板集成显卡的。大家可以通过http://product.pconline.com.cn/hot/server_cpu/查看一下排名。 CPU具体的指标是看主频和核数,主频高说明运算更快。
  • RAM: 内存大自然是好,但是我们要把握不要浪费,因为根据整体配置,到了一定的内存量级服务器整体性能也不会再有提升。服务器专用内存是具有容错性的,也就是奇偶校验机制。这是我们家用PC内存不具备的特性。而且服务器的内存是支持热拔插的,以便于更换。下面说到的硬盘也一样。
  • DISK:硬盘是硬件优化的一个重要项。因为往往磁盘的读写会跟不上整个系统的速度,I/O速率往往是瓶颈。因为毕竟机械盘手臂特定转速下寻找文件位置的时间是固定的。我们往往会使用RAID阵列,通过叠加硬盘达到提示I/O速度。同时,RAID还具备容错性。常见的RAID种类有RAID 5、RAID 01、RAID 10。另外,SSD是一种非机械盘,俗称固态硬盘。随着科技发展,SSD的价格也趋于平民化,容量方面还有待提升。
  • Network Card: PC机网卡常见的有百兆,这里的单位是Bit流。如果转化为字节byte,需要除以8.换言之,百兆网卡的最高理论速度是12M字节每秒。服务器上一般都是两块千兆网卡。跟RAID磁盘阵列的道理是一样的,通过两块叠加的模式提升数据流峰值。

架构优化策略

接入优质CDN:
内容分发网络是利用全球、全国各地不同优质机房作为节点,通过合理的镜像拉取技术,采取就近节点原则,利用缓存优化提升网站速度的方法。一般都是采取动静分离的方式,我们只优化静态内容。CDN供应商是有好坏之分的,国内比较知名的是:蓝汛(老牌、收费较贵)、阿里云CDN、又拍云(自建节点)、腾讯云。
web应用程序优化:
非阻塞I/O(epoll模型)的特性让nginx拥有高并发能力,所以在应对高并发网站时,首选是NGINX。关于apache和nginx比较:http://www.360doc.com/showWeb/0/0/572056540.aspx。
配置优化可以参考:http://www.360doc.com/showweb/0/0/572057025.aspx。work_cpu_affinity其实是不用设置的,nginx可以自身就能处理很好。
内核优化:上面提到的优化配置中,有关于内核的优化。其中常用的有:net.ipv4.tcp_syncookies = 1; 它可以有效防止利用tcp/ip通讯三次握手原理的攻击(只不断发送SYN,收到ACK也不确认)。另外就是net.ipv4.tcp_tw_recycle=1和net.ipv4.tcp_tw_reuse=1,我们可以在在用服务器上用”netstat -an|grep -ic time_w”命令查看tcp_wait的数量,往往会发现有很多正在通讯的连接,上面2个内核参数的开启有利于快速回收。其他内核参数的解释可以在http://www.360doc.com/showWeb/0/0/572061954.aspx中查看。关于内核优化,一些IDC或者云计算服务商的自定义镜像是做过的,所以修改前请核对是否已有某些设置。
设置浏览器缓存:不管是APACHE,还是NGINX,都可以对静态文件做浏览器缓存设置。这个基本上算是标准配置啦。
启用压缩技术节省带宽消耗:这也是基本的配置,一般对于JS/CSS等静态文件都可以采用。Apache使用的flate模块,nginx使用的gzip。

网站架构的业务拆分

我们之前的一篇中大型网站架构演变中有过说明。详情请点击:高并发大型网站架构演变。业务拆分应该根据具体生产环境策划和测试。

网络共享存储:不适用或少使用

在选择网络共享存储时,我们可以利用NFS自建的分布式存储、专业的NAS/SAN硬件共享网络、云盘OSS(分布式对象存储集群);但是,这里我们实施的时候要注意,不要偷懒,只共享部分需要的文件,没有必要将所有应用程序代码整个共享出去。原则就是:不适用或者少使用共享存储。

毕竟,这些分布式共享存储都是通过网络来读写的,I/O速度本身就是一个瓶颈。所以,我们应该将必须共享的部分独立出来,以免影响性能。

使用NoSQL

NoSQL的特性是内存存储,读取速度自然要高出磁盘I/O,我们通常会用以作为缓存层。那么,我们是不是想过在某些特殊小场景下,它可以完全取代MySQL等关系型数据库?

这是有想像空间的,redis的整体架构存在替代mysql的可能性,只是它支持的数据类型还是过于简单,无法满足复杂生产环境的需求。

我们之前介绍MongoDB的博文中开篇就用它和关系型数据库MYSQL进行了比对,那是有原因的。因为在一些场景下,mongodb确确实实可以完全取代MySQL。 我们不妨来看一篇文章:http://www.360doc.com/showWeb/0/0/572065934.aspx

所以,我们在开发时可以尽量去衡量当前场景是否可以用nosql来取代传统的关系型数据库。

使用异步通信

我们是不是在阿里云看到过消息队列的服务?它就是用来实现异步通信的。我们可以看一遍文章:大型网站分布式消息队列

其中,原作者列出了5种应用场景:异步处理,应用解耦,流量削疯、日志处理、消息通讯。而常见的消息队列应用有:ActiveMQ,RabbitMQ(openstack集成的就是该服务),ZeroMQ,Kafka,MetaMQ,RocketMQ。

我们可以看到,消息队列应用于生产环境真是太棒了,我们需要做的就是一个消息队列中间件。对于服务器而言,一台负责处理用户请求动作,同时将动作执行交由另一台消息队列服务器去处理,这就是我们所说的实现了异步通信。

最后,我们可以通过两个小案例(小米抢购系统商城秒杀系统)来理解消息队列的实际应用场景和架构。