目录
大型网站架构演化
大型网站软件系统的特点
- 高并发、大流量：需要面对高并发用户，大流量访问。
- 高可用：系统7×24小时不间断服务。
- 海量数据：需要存储，管理海量数据。
- 用户分布广泛，网络情况复杂：许多大型互联网都是为全球用户提供服务，用户分布范围广，各地网络情况千差万别。
- 安全环境恶劣：由于互联网的开放性，使得互联网站更容易受到攻击，大型网站几乎每天都会被黑客攻击。
- 需求变更快，发布频繁：和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，产品发布频率极高。
- 渐进式发展：与传统软件产品或企业应用系统一开始就规划好全部功能需求不同，几乎所有互联网站都是从小网站开始，一步步渐进发展而来。
大型网站架构演化发展历程
- 初始阶段网络架构：访问人少，一台服务器足以。传统的LAMP（Linux+Apache+MySQL+PHP）。
- 应用服务和数据服务分离：随着业务发展，一台服务器逐渐不能满足需求，数据量增大导致存储空间不够，将文件服务器和数据库服务器与业务服务器分离。
- 使用缓存改善网站性能：使用缓存存储热点数据，提高性能，分为本地缓存和分布式缓存服务器的远程缓存。
- 使用应用服务器集群改善网站的并发处理能力：使用集群时网站解决高并发、海量数据的常用手段。
- 数据库读写分离：大部分主流数据库都提供主从热备功能，利用这个特点实现读写分离，改善数据库负载压力。
- 使用反向代理和CDN加速网站响应：为了提高用户体验，使用CDN和反向代理缓存静态数据加快响应，同时减少服务端压力。
- 使用分布式文件系统和分布式数据库系统：只有在单表数据规模非常庞大时使用。一般更常用业务分库。
- 使用NoSQL和搜索引擎：互联网常用手段，对伸缩性有较好支持。
- 业务拆分：根据产品线，将一个网站拆分成许多不同的应用，独立部署维护，通过RPC和消息队列进行通信。
- 分布式服务：将公共业务抽取出来，利用RPC远程调用。
大型网站架构模式
为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。这些解决方案又被更多的网站重复使用，从而逐渐形成大型网站的架构模式。
分层
分层是企业应用系统中最常见的一种架构模式：将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
大型网站一般分为：
- 应用层：负责具体业务和视图展示，如网站首页及搜索输入和结果展示
- 服务层：为应用层提供服务支持，如用户管理服务，购物车服务等。
- 数据层：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等。
通过分层，可以更好的讲一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护，各层之间具有一定的独立性，只要维护调用接口不变，各层可以根据具体问题独立演化发展而不需要其它层做出调整。
分割
如果说分层是将软件横向反面进行切分，那么分割就是在纵向方向对软件进行切分。网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于维护，另一方面有助于分布式部署，提高网站的并发处理能力和功能扩展能力。
比如：在应用层，将不同业务分割，如购物，论坛，广告，搜索等。
分布式
对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU越多，内存，存储资源越多，能够处理的并发就越多。
但分布式也带来了很多问题，首先分布式必须经过网络传输，而网络不可靠，其次，服务器越多，有服务器宕机的概率就越大，可能导致网站某些功能不可用，甚至网站崩溃，另外，分布式环境保持数据一致性也非常困难，可能会影响业务正确性。
常用的分布式方案有以下几种：
- 分布式应用和服务：将分层和分割后的应用和服务模块分布式部署
- 分布式静态资源：将网站的静态资源如JS、CSS、Logo图片等资源独立分布式部署，并采用独立的域名，即常说的动静分离。
- 分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的空间，这些数据分布式存储。
- 分布式计算：例如应用，服务，实时数据处理等都是计算，当计算量庞大时，采用Hadoop和MapReduce分布式计算框架进行批处理。
集群
使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块（如首页）还需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
集群可以提供更好的并发处理能力，并且可以解决单点故障问题，提高系统可用性。当某台服务器宕机时，负载设备或者系统的失效转移机制会将请求转发到集群中的其他服务器上。
缓存
缓存就是将数据存储在距离计算最近的位置以加快处理速度。
- CDN：即内容分发网络，部署在距离终端用户最近的网络服务商，用来缓存一些静态资源。
- 反向代理：反向代理属于网站前端架构部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问反向代理服务器，这里缓存一些静态资源。
- 本地缓存：在应用服务器本地缓存热点数据，应用可以直接从本机内存访问，而无需访问数据库。
- 分布式缓存：大型网站的数据量非常庞大，即使只缓存一小部分，需要的内存空间也不是单机能承受的，所以除了本地缓存，还需要分布式缓存，专门搭建一个分布式缓存服务器集群，应用通过远程调用访问缓存数据。
使用缓存的两个条件：一是数据访问不均衡，存在热点数据。二是数据在某个时间段内有效，不会很快过期。
异步
计算机软件发展的一个重要目标和驱动力是降低软件耦合性。而异步就是系统解耦的一个重要手段，业务之间通过消息传递而不是同步调用。
在单一服务器内部可通过多线程共享内存队列的方式实现异步，在分布式系统中，多个服务器集群通过分布式消息队列实现异步。
异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化而互不影响。除此以外，异步消息队列还有以下特性：
- 提高系统可用性：消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务，系统整体表现无故障。消息服务器恢复后，继续处理消息队列中的数据。
- 加快网站响应速度：生产者服务器处理完业务请求后，只需要把消息存到消息队列，不需要消费者服务器响应，加快速度。
- 消除并发访问高峰：网站并发访问突然增大时，使用消息队列将突然增大的访问请求数据存储，等待消费者服务器依次处理，就不会对网站负载造成太大压力。
冗余
网站需要7×24小时服务，但是服务器可能随机出现故障，特别是当规模比较大时，要保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要进行一定程度的服务器冗余运行，数据冗余备份。
冷备份：数据库定期备份，存档保存。
热备份：对数据库实现主从分离，实时同步。
自动化
在无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。自动化架构目前大多集中在发布运营方面：
- 自动化发布
- 自动化代码管理
- 自动化测试
- 自动化安全监测
- 自动化部署
- 自动化监控
- 自动化报警
- 自动化失效转移
- 自动化失效恢复
- 自动化降级、分配资源等
安全
互联网的开放特性使得其从诞生开始就面对巨大的安全挑战，网站在安全架构方面也积累了很多模式：
- 通过密码和手机效验进行身份认证
- 登录、交易等网络通信加密
- 使用验证码识别机器人程序的滥用网络资源
- 对XSS攻击、SQL注入进行编码转换等
- 对垃圾信息、敏感信息进行过滤
大型网站核心架构要素
一般来说，除了当前系统功能需求外，还需要关注性能，可用性，伸缩性，扩展性和安全性这五个架构要素。
性能
性能是网站的一个重要指标，除非没得选择，否则用户都不会忍受一个响应缓慢的网站。常用的性能优化手段如下：
- 在浏览器端，可以通过浏览器缓存，使用页面压缩，合理布局页面，减少Cookie传输等手段改善性能。还可以使用CDN、反向代理服务器等。
- 在应用服务端，可以使用服务器本地缓存和分布式缓存，通过缓存热点数据，减少数据库压力，加快响应速度。也可以通过异步操作将请求发送给消息队列。也可以通过集群改善并发处理能力，提升性能。
- 在代码层面，可以通过多线程，改善内存管理等手段优化性能。
- 在数据库服务端，索引，缓存，SQL优化等优化手段。
衡量性能有一系列指标，重要的有响应时间，TPS，系统性能计数器等。
可用性
对于大型网站，网站宕掉，服务器不可用是重大事故。一般衡量网站可用性，用故障时间除以7×24小时来计算，一般用几个9表示，一些大型网站可以做到4个9以上，即99.99%。
高可用的设计目标：当服务器宕机的时候，服务依然可用。
网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上相互备份，任何一台服务器宕机都不会影响整体可用，也不会使数据丢失。
- 对于应用服务器而言，多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务，任何一个服务器宕机，只需要把请求切换到其他服务器即可实现高可用。前提是应用服务器不能保存会话信息，否则服务器宕机，别的服务器没有当前服务器的会话，无法处理业务。
- 对于存储服务器，由于其上存储数据，需要对数据进行实时备份，当服务器宕机时需要将数据访问转移到可以的服务器上，进行数据恢复以保证继续有服务器宕机的时候数据依然可用。
除了运行环境，网站的高可用还需要软件开发过程的质量保证。通过预发布验证，自动化测试，自动化发布，灰度发布等手段减少将故障引入线上的可能。
伸缩性
伸缩性是指通过不断的向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群添加新的服务器。加入新的服务器是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。
- 对于应用服务器集群，只要服务器上不存储数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。
- 对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中的大部分缓存无法访问，如果网站严重依赖缓存，可能导致网站崩溃。因此需要改进缓存路由算法保证缓存数据的可访问性。
- 关系型数据库虽然支持数据复制，主从热备等机制，但很难做到大规模集群的可伸缩性，因此关系型数据库集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成集群。
- 至于大部分NoSQL数据库，由于天生就是为海量数据而生的，因此其对伸缩性的支持通常都非常好。
扩展性
网站扩展性架构直接关注网站的功能需求。网站快速发展，功能不断扩展，如何设计一个网站的架构使其能快速响应需求的变化，是网站可扩展架构的主要目的。
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。
网站可扩展架构的主要手段有事件驱动架构和分布式服务。
事件驱动架构在网站中通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消费者从消息队列中获取消息进行处理。通过这样将消息生产和消息消费分离开来，可以透明的增加新的消息生产者任务或者新的消费者任务。
分布式服务则是将业务和可复用服务分离开，通过分布式服务框架调用。新增的产品可以通过调用可复用的服务实现自身的逻辑，而对现有产品没有任何影响。可复用服务升级变更的时候，也可以通过多版本服务对应用实现透明升级。
安全性
网站的安全性架构就是保护网站不受恶意的攻击和访问，保护网站的重要数据不被窃取。
衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。
2708
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
