读-大型网站架构演化（分享）

目录

 

1、大型网站软件系统的特点

2、大型网站架构演化发展历程

3、大型网站架构演化的价值观 

4、网站架构设计误区

5、小结 

---

1、大型网站软件系统的特点

• 高并发，大流量：需要面对高并发用户，大流量访问。google日均PV数35亿，淘宝2017"双十一"活动一天交易额1682亿
• 高可用：系统7x24小时不间断服务。大型互联网宕机成为新闻焦点，儒2010百度域名被黑客劫持导致不能访问。
• 海量数据：需要存储，管理海量数据，需要使用量服务器。facebook每周上传的照片接近10亿
• 用户分布广泛，网络情况复杂：各地网络千差万别 国内各大运营商网络互通难，中美光缆故障让一些网站在海外建立数据中心
• 需求变更快速，发布频繁：快速适应市场，满足用户需求，office以年为单位发布，大型网站每周都有新版本上线，小的更多
• 渐进式发展：传统软件的产品一开始规划好全部的功能。几乎所有大型网站都是从小网站开始渐进的发展起来的。feacebook是扎克伯格同学在哈佛那个大学的宿舍里开发的；goole的第一台服务器部署在斯坦福大学的实验室里；阿里巴巴则是在马云的客厅里诞生的。好的互联网产品都是慢慢运营出来的，不是一开始就开发好的。

2、大型网站架构演化发展历程

 大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，诸如跨数据中心的实时数据同步和具体网址业务相关的问题也都可以通过组合改进现有技术架构解决。

• 初始阶段的网站架构：应用服务器，文件，数据库都在同在一台。小型网站最开始没有太多人访问，一台绰绰有余，如图1.1
• 应用服务和数据服务分离：随着业务发展，越来越多的用户访问导致性能越来越差，导致存储空间不足，需要应用和数据分离：应用服务器处理大量业务逻辑，配更快更强大的CPU；数据库服务器要快速磁盘检索和数据缓存，配更快的硬盘和更大的内存；文件服务器存储大量文件，配更大的硬盘。如图1.2
• 使用缓存改善网站性能：缓存在应用服务器上（本地缓存）和缓存在专门分布式缓存服务器上（远程缓存），特点是本地缓存访问速度快，但应用服务器内存有限，其缓存数据量有限。且会出现和应用程序争内存的情况。远程分布式缓存可以使用集群的方式，部署在内存大的服务器昨为专门的缓存服务器，理论上做到不受内存容量限制的缓存服务。如图1.3
• 使用应用服务器集群改善完整的并发处理能力：对大型网站而言，不管多么强大的服务器都满足不了网站持续增长的业务需求。这种情况下更恰当的做法是增加一台服务器分担原有服务器的访问压力及存储。使用集群是网站解决高并发、海量数据问题的常用手段。通过增加服务器不断改善系统新能，应用服务器集群是网站可伸缩集群价格设计中较为简单成熟的一种。通过负载均衡调度服务器，可将访问的请求分发到应用服务集群钟的任何一台服务器上。如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。如图1.4
• 数据库读写分离：使用缓存后，绝大部分读操作可以不访问数据库，但仍有一部分读操作(缓存访问不命中，缓存过期)和写需要访问数据库，用户达到一定规模后，数据库负载压力过高而成为网站的瓶颈。这时可提供主从热备功能，配置两台数据库主从关系，主数据库通过主从复制机制将主库数据更新同步到另一台服务器上。网站利用数据库这一功能实现数据库读写分离，对应用透明，从而改善数据库负载压力。如图1.5
• 使用反向代理和CDN加速网站响应：国内复杂的网络环境，不同地区用户访问网站速度差别极大。为了提供更好的用户体验，留住用户，网站需要加速网站访问速度，主要手段有使用CDN和反向代理。CDN和反向代理的基本原理都是缓存，区别在于CDN部署在忘了提供商的机房，从距离用户最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器缓存着用请求的资源，就将其直接返回给用户。目的都是金子返回数据给用，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。如图1.6
• 使用分布式文件系统和分布式数据库系统：数据库经过读写分离后，从一台服务器拆分成两台，但随着业务增长依然不能满足需求，这时需要使用分布式数据库，文件系统也一样，需要使用分布式文件系统。分布式数据库是网站数据库拆分的最后手段，只有在单标数据规模非常庞大的时候才使用。不到不得已是，网站更常用的是数据库拆分手段是业务分库，将不同业务的数据部署在不同的物理服务器上。如图1.7
• 使用NoSQL和搜索引擎：随着网站业务越来越复杂，对数据存储和检索的需求也越来复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎，对可伸缩的分布式特性具有更换的支持。应用服务器则通过一个统一数据访问各种数据，减轻应用程序管理诸多数据源的麻烦。如图1.8
• 业务拆分：大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务粉刺不同的产品线，如大型购物交易网站就会将首页、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。具体到技术上，根据产品线划分，将一根网站拆分成许多不同的应用，每个应用独立部署维护。应用直接可以通过一个超链接建立关系，可以通过消息队列进行数据分发。当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。如图1.9
• 分布式服务：将每一个系统都需要执行的业务提前出来，独立部署，比如用户管理，商品管理等。这些可复用的业务链接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用公共业务服务完成具体业务。如图1.10

3、大型网站架构演化的价值观 

• 大型网站架构技术的核心价值是随网站所需灵活应对：能够伴随小型业务的逐步发展，慢慢演化成一个大型网站。在这个漫长的及时演化过程正，不需要放弃什么，不需要推翻什么，不需要剧烈的革命，就那么润物细无声的把一个只有一台服务，几百个用户的小网站演化成一个几十万台服务器，数十亿用户的大网站。google，facebook,taobao,baidu莫不遵循这样的及时演化路线
• 驱动大型网站技术发展的主要力量是网站的业务发展：创新的业务发展模式对网站架构逐步提出更高要求，才使得创新的网站架构得以发展成熟。是业务成就了技术，是事业成就了人。

4、网站架构设计误区

• 一味追随大公司的解决方案：由于大公司巨大成功的光环效应，再加上从大公司挖来的技术大牛的影响，网站在讨论架构决策是，最有说服力的一句话成了“淘宝就是这么搞的”。大公司的经验和成功模式固然重要，值得学习借鉴，但不应盲从。
• 为了技术而技术：网站技术是位业务而存在的，除此毫无意义。在技术选型和架构设计钟，脱离网站业务发展的时间，一味追求时髦的新技术，可能会将网站技术发展引入崎岖小道，架构之路越走越难。
• 企图用技术解决所有问题：如2012年年初12306故障时间后，软件开发技术界的反应。12306真正的问题其实不在意技术架构，而在于业务架构。它根本就不应该再几亿国人一票难求的情况下以窗口模式在网上售票，应调整业务需求，换一种方式卖票，而不要去搞促销秒杀这种鳌头式游戏。后来证明12306确实是朝这个方向发展的：在售票方式上引入了排队机制，整点售票调整为分时段售票。其实，如果能控制住并发量，很多棘手的技术问题也就不是问题了。

5、小结 

技术是用来解决业务问题的，而业务问题，也可以通过业务手段去解决。

时至今日，大型网站的架构演化方案已经非常成熟，各种技术方案也逐渐产品化。许多小型网站已经慢慢不需要再经历大型网站经历过的架构演化之路就可以逐步发展壮大，因为现在越来越多的网站从建立之初就是搭建在大型网站提供的云计算服务基层之上，所需要的一切技术资源：计算、存储、网络都可以按需购买，线性伸缩。