大型网站技术架构-第3篇 案例

读书笔记 摘自：《大型网站技术架构：核心原理与案例分析-李智慧》

---

9 淘宝网的架构演化案例分析

9.1 淘宝网的业务发展历程

业务驱动着技术不得不往前走

9.2 淘宝网技术架构演化

Linux+Apache+MySQL+PHP（LAMP）架构

作为一个刚刚起步的小网站，使用开源、免费、简单的技术产品搭建网站是明智之举，可谓一举多得：免费的技术降低网站的成本，成熟的开源技术可以从开源社区获取文档和技术支持；网站发展初期，业务不明确，需求变化多，简单的技术方案可以快速响应需求变化；简单的技术也可以让工程师快速上手，缩短学习周期；退一步，如果业务发展不顺利，及时关闭网站止损，亦可减少沉没成本，促使管理层和投资者快速决策。

电子商务网站特有的业务复杂性和PHP易开发、难维护的特性产生了难以调和的冲突

业务快速发展，宝贵的开发资源应该投入到新业务开发上，而不是解决这些可以用付费产品搞定的基础技术问题上；成熟的付费产品和售后支持令业务和市场没有后顾之忧，可以全力以赴地拓展市场；对于一个快速发展的网站，特别是电子商务网站而言，严重宕机、重要用户数据丢失可能会极大地打击消费者信心，令网站发展平生波澜，而这些业界领先的产品经过多年的洗练，有较强的可用性保证。

在合适的场景下使用合适的产品，而不是最好的产品，所谓小脚穿大鞋，不但跑不快，还可能会摔跤。

验证了辩证法关于事物发展的否定之否定及螺旋式上升的普遍规律，仿佛回到原点，但一切已经完全不同了。

9.3 小结

随着业务的飞速发展，用户、数据、流量、业务复杂度都呈指数级增长，飞速接近甚至突破Oracle、IBM这些企业提供的解决方案的有效范围，在开源领域虽有Google、Yahoo等先驱在探索道路，并有一些开源产品，但是在大规模集群实践上，大家都在摸索，淘宝必须走自己的路，路上也许有烛光照明，但是没有人指路。

10 维基百科的高性能架构设计分析

wikipedia.org不过只有区区数百台服务器，并仅由十余名技术人员维护，不得不说是一个奇迹。Wikipedia对资源的利用，对性能的优化很具有典型性，有许多值得学习的地方。

10.1 Wikipedia网站整体架构

目前Wikipedia网站建立在LAMP（Linux+Apache+MySQL+PHP）之上，其他基础技术组件也全部采用免费的开源软件。

Wikipedia架构的主要组成部分如下。

GeoDNS：基于开源域名服务器软件BIND（Berkeley Internet Name Domain）的增强版本，可将域名解析到离用户最近的服务器。

LVS：基于Linux的开源负载均衡服务器。

Squid：基于Linux的开源反向代理服务器。

Lighttpd：开源的应用服务器，较主流的Apache服务器更轻量、更快速。实践中，有许多网站使用Lighttpd作为图片服务器。

PHP：免费的Web应用程序开发语言，最流行的网站建站语言。

Memcached：无中心高性能的开源分布式缓存系统，稳定、可靠、历久弥新，是网站分布式缓存服务必备的。

Lucene：由Apache出品，Java开发的开源全文搜索引擎。

MySQL：开源的关系数据库管理系统，虽被Oracle收购，但开源社区将其继续开源发展的决心不动摇。

10.2 Wikipedia性能优化策略

作为一个百科服务类网站，Wikipedia主要面临的挑战是如何应对来自全球各地的巨量并发的词条查询请求。

10.2.1 Wikipedia前端性能优化

对Wikipedia而言，80%以上的用户请求可以通过前端服务返回，请求根本不会到达应用服务器，这也就使得网站最复杂、最有挑战的应用服务端和存储端压力骤减。

在反向代理Squid之前，则是被Wikipedia技术团队称为“圣杯”的CDN服务，CDN服务对于Wikipedia性能优化居功至伟。

Wikipedia CDN缓存的几条准则为：
内容页面不包含动态信息，以免页面内容缓存很快失效或者包含过时信息。每个内容页面有唯一的REST风格的URL，以便CDN快速查找并避免重复缓存。
在HTML响应头写入缓存控制信息，通过应用控制内容是否缓存及缓存有效期等。

10.2.2 Wikipedia服务端性能优化

除了硬件改善，Wikipedia还使用许多其他开源组件对应用层进行如下优化。

• 使用APC，这是一个PHP字节码缓存模块，可以加速代码执行减少资源消耗。
• 使用Imagemagick进行图片处理和转化。
• 使用Tex进行文本格式化，特别是将科学公式内容转换成图片格式。
• 替换PHP的字符串查找函数strtr()，使用更优化的算法重构。

10.2.3 Wikipedia后端性能优化

后端服务通常是一些有状态的服务，即需要提供数据存储服务，这些服务大多建立在网络通信和磁盘操作基础上，是性能的瓶颈，也是性能优化的重灾区。

后端优化最主要的手段是使用缓存，将热点数据缓存在分布式缓存系统的内存中，加速应用服务器的数据读操作速度，减轻存储和数据库服务器的负载。

Wikipedia通过约束业务获得更大的技术方案选择余地，很多时候业务后退一小步，技术就可以前进一大步。

11 海量分布式存储系统Doris的高可用架构设计分析

对于一个数据存储系统而言，高可用意味着两个意思：

• 高可用的服务：任何时候，包括宕机、硬盘损坏、系统升级、停机维护、集群扩容等各种情况，都可以对系统进行读写访问操作。
• 高可靠的数据：任何情况下，数据可靠存储，不丢失。

高可用的架构设计也就是在各种软硬件故障的情况下，系统如何保障数据可靠存储，服务可用。

11.1 分布式存储系统的高可用架构

在系统架构层面，保证高可用的主要手段是冗余：服务器热备，数据多份存储。使整个集群在部分机器故障的情况下可以进行灵活的失效转移（Failover），保证系统整体依然可用，数据持久可靠。

• 应用程序服务器：它们是存储系统的客户，对系统发起数据操作请求。
• 数据存储服务器：他们是存储系统的核心，负责存储数据、响应应用服务器的数据操作请求。
• 管理中心服务器：这是一个由两台机器组成的主-主热备的小规模服务器集群，主要负责集群管理，对数据存储集群进行健康心跳检测；集群扩容、故障恢复管理；对应用程序服务器提供集群地址配置信息服务等。

其中数据存储服务器又根据应用的可用性级别设置数据复制份数，即每个数据实际物理存储的副本数目，副本份数越多，可用性级别越高，当然需要的服务器也越多。

一般而言，服务器之间通信越少，就越少依赖，发生故障时互相影响就越少，集群的可用性就越高。

11.2 不同故障情况下的高可用解决方案

11.2.1 分布式存储系统的故障分类

对于一个分布式存储系统而言，影响系统整体可用性的故障可以分成以下三类。

• 瞬时故障：故障时间短，在秒级甚至毫秒级系统即可自行恢复正常响应。
• 临时故障：主要特点是需要人工干预（更换硬件、重启机器等）才能恢复正常。通常持续时间需要几十分钟甚至几小时。故障时间可分为两个阶段：临时故障期间，临时故障恢复期间。
• 永久故障：硬盘损坏，数据丢失。故障时间可分为两个阶段：永久故障期间和永久故障恢复期间。

11.2.2 正常情况下系统访问结构

应用程序在写数据时，需要路由计算获得两台不同的服务器，同时将数据写入两台服务器；而读数据时，只需要到这两台服务器上任意一台服务器读取即可。

11.2.3 瞬时故障的高可用解决方案

当然也有可能是应用服务器自己的故障，比如系统文件句柄用光导致连接不能建立等，这时需要请求管理中心服务器进行故障仲裁，以判定故障种类。

11.2.4 临时故障的高可用解决方案

临时服务器是集群中专门部署的服务器（根据可用性规划，临时服务器也可以部署为多台机器的集群），正常情况下，该服务器不会有数据写入，处于空闲状态，只有在临时失效的时候，才会写入数据。任何时候该服务器都不会提供读操作服务。

11.2.5 永久故障的高可用解决方案

永久故障是指服务器上的数据永久丢失，不能恢复。由于故障服务器上的数据永久丢失，从临时服务器迁移数据就没有意义了，必须要从其他序列中正常的服务器中复制全部数据才能恢复正常状态。

12 网购秒杀系统架构设计方案分析

12.1 秒杀活动的技术挑战

1. 对现有网站业务造成冲击
2. 高并发下的应用、数据库负载
3. 突然增加的网络及服务器带宽
4. 直接下单

12.2 秒杀系统的应对策略

1. 秒杀系统独立部署
2. 秒杀商品页面静态化
3. 租借秒杀活动网络带宽
4. 动态生成随机下单页面URL

12.3 秒杀系统架构设计

1. 如何控制秒杀商品页面购买按钮的点亮
   解决办法是使用JavaScript脚本控制，在秒杀商品静态页面中加入一个JavaScript文件引用，该JavaScript文件中加入秒杀是否开始的标志和下单页面URL的随机数参数，当秒杀开始的时候生成一个新的JavaScript文件并被用户浏览器加载，控制秒杀商品页面的展示。这个JavaScript文件使用随机版本号，并且不被浏览器、CDN和反向代理服务器缓存。

2. 如何只允许第一个提交的订单被发送到订单子系统

13 大型网站典型故障案例分析

一位网站资深架构师曾经说过：在互联网公司呆一年，相当于在传统软件公司呆三年。他的意思大概是在互联网公司一年遇到的问题比传统软件公司三年遇到的问题还多。而且随着网站业务的快速发展，问题也层出不穷，每年遇到的问题都不同。遇到问题，解决问题，经历了这个过程，技术才能升华，人和技术才能融为一体，才知道什么技术是真正有用的，什么技术是花拳绣腿。

大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。

13.1 写日志也会引发故障

经验教训：
应用程序自己的日志输出配置和第三方组件日志输出要分别配置。检查log配置文件，日志输出级别至少为Warn，并且检查log输出代码调用，调用级别要符合其真实日志级别。
有些开源的第三方组件也会不恰当地输出太多的Error日志，需要关闭这些第三方库的日志输出，至于哪些第三方库有问题，只有在遇到问题时才知道。

13.2 高并发访问数据库引发的故障

经验教训：
首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。首页最好是静态的。

13.3 高并发情况下锁引发的故障

经验教训：
使用锁操作要谨慎。

13.4 缓存引发的故障

经验教训：
当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。

13.5 应用启动不同步引发的故障

经验教训：
老鸨开门前要检查下姑娘们是否穿好了衣服。就本例来说，在应用程序中加入一个特定的动态页面（比如只返回OK两个字母），启动脚本先启动JBoss，然后在脚本中不断用curl命令访问这个特定页面，直到收到OK，才启动Apache。

13.6 大文件读写独占磁盘引发的故障

经验教训：
存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。

13.7 滥用生产环境引发的故障

经验教训：
访问线上生产环境要规范，不小心就会导致大事故。

13.8 不规范的流程引发的故障

经验教训：
代码提交前使用diff命令进行代码比较，确认没有提交不该提交的代码。加强code review，代码在正式提交前必须被至少一个其他工程师做过code review，并且共同承担因代码引起的故障责任。

13.9 不好的编程习惯引发的故障

经验教训：
程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象（使用空对象模式）。

13.10 小结

有位软件技术前辈曾经说过“软件设计有两种风格，一种是将软件设计得很复杂，以使其缺陷没那么明显；一种是将软件设计得很简单，以使其没有明显的缺陷”。

设计软件时就会设计得简单些，如果问题能够很快被发现，要解决也相对容易。

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls