大型网站技术架构—架构要素和高性能架构

为了使网站的可以应对高并发访问，海量数据处理，高可靠运行等一系列问题，咱们能够选择横向或纵向两个方向来入手

基本思路

首先能够对整个架构进行分层，通常能够分为 应用层，服务层，数据层；实践中，大的分层结构中还能够继续分层，好比 应用层还能够继续分为 视图层 和 业务逻辑层，服务层也能够继续细分为 数据接口层 逻辑处理层 等

经过分层，咱们把一个庞大的系统切分为不一样的部分，便于分工开发和维护；各层之间相互有必定的独立性，在网站的开发中能够根据不一样的需求进行相应的调整

逻辑上分层以后，在物理部署上也能够根据需求制定不一样的策略，刚开始能够部署在同一台物理机上，可是随着业务的发展，必然要对不一样的模块进行分离部署

分层架构不只仅是为了规划软件的逻辑结构以便于开发维护，随着网站的发展，分层架构对网站的高并发分布式架构来讲尤其重要

进行了分层之后，接下来能够从纵向进行业务分割

根据不一样的业务模块一个项目划分红不一样的模块交给单独的团队去开发部署，完成后分别部署在不一样的服务器上，经过连接进行互联

再根据不一样状况来对不一样的节点进行冗余来保证网站的高可用性

接下来进行缓存，CDN，反向代理等等的优化，这里之后再细说

好了，如今咱们开始进入正题

架构要素

首先，对于一个高访问量，大数据量的网站咱们须要考虑什么呢？

性能

首先就是性能了，性能是一个网站的的重要指标，除非是没得选择，就这一个网站，否则用户是绝对不会忍受一个超级慢的网站

正由于性能问题无处不在，解决性能问题的方式也各类各样，从用户请求一个 url 开始，进行的每个环节均可以进行优化；根据上面的分层，能够大体从三个方面进行优化，应用层优化，服务层优化，数据层优化

涉及到的知识就是 web 前端的优化，应用服务器端的优化和数据的存储，索引，缓存等，这些在后面的内容里会分别展开细说

但性能只是一个网站的必要条件，除此以外，由于没法预知网站可能会面临的压力或是攻击，咱们还要保证网站在各类情境下（高并发，高负载，持续压力不均匀等）保持稳定的性能

可用性

对于大型网站而言，出现宕机的状况是可怕的，由于你可能有上千万的用户量，短短几分钟的宕机都有可能致使网站声誉扫地，若是是电商类的网站，更可能会致使用户的财产损失，甚至会摊上官司，那时候损失的就不只是金钱和用户了

所以咱们要保证可以提供天天 24 小时的可用，但实际中服务器并不能保证天天 24 小时都能平稳的运行，可能出现硬件问题，也可能出现软件问题，总之问题老是会有的

因此咱们高可用设计的目标就是在某些服务器宕机的状况下，也可以保证服务或应用正常运行

网站高可用的主要手段是 冗余，应用部署在多台服务器上同时提供访问，数据存储在多台数据服务器之间互相进行热备份，这样任何一台服务器宕机都不会影响服务或应用的总体，也不会产生数据丢失

对于应用服务器而言，多台应用服务器经过一个负载均衡设备组成一个集群同时对外提供服务，当一台服务器宕机后，服务切换到其余服务器上继续执行，这样就能够保证了网站的高可用性，前提是应用服务器不容许存储用户会话信息，不然将会丢失，这样即便用户请求转接到其余服务器上面也没法继续执行

对于数据存储服务器，要提供服务器之间的实时备份，这样当一台服务器宕机的时候，将数据访问切换到其余服务器上，并进行数据恢复和备份

衡量一个系统架构设计是否知足高可用的目标，就是假设其中一台或多台服务器宕机以及出现各类不可预期的问题时，系统总体是否依然可用

伸缩性

面对着大量用户的高并发访问和海量的数据存储，不可能只用一台服务器就可以知足所有需求，存储所有数据

经过 集群 的方式将多台服务器组成一个总体共同提供服务，所谓 伸缩性 就是指经过不断向集群中加入服务器的手段来应对不断上升的用户并发访问压力和不断增加的数据存储需求

对于应用服务器集群，只要服务器上不存储数据，全部的服务器都是对等的，经过使用合适的负载均衡设备就能够向集群中不断加入新的服务器

对于缓存服务器而言，加入新的服务器可能会致使缓存路由失效，从而致使大部分的缓存数据都没法访问，须要改进缓存路由算法来保证缓存数据可访问

关系数据库虽然支持数据复制，主从热备份等机制，可是很难实现大规模集群的可伸缩性

可扩展性

网站的扩展性直接关系到网站功能模块的开发，网站快速发展，功能也不断的增长

网站架构的可扩展性的主要目的是使其可以快速的应对需求变化

是为了可以在增长新业务时，尽可能实现对现有产品无影响，不须要改动或是改动不多现有业务就可以上线新产品；不一样的产品业务之间的耦合度很小，一个产品或业务的改动不会对其余形成影响

大型网必定会吸引到第三方开发者，调用网站服务，开发周边产品，扩展网站业务，这都须要网站提供开放平台接口

安全性

最后的就是安全性了，互联网是一个开放的平台，任何人在任何地方均可以访问网站，安全架构就是保护网站不受恶意的访问和攻击，保护数据不被窃取

性能，可用性，伸缩性，扩展性，安全性使网站架构的几个核心要素，咱们网站架构的目的主要就是为了解决这几个问题，接下来都会分别进行介绍

高性能架构

说到高性能，在不一样角色的眼中对于性能的定义也不一样

• 用户视角： 用户感觉到的性能，就是从提交后到看到页面的时间，不一样计算机性能的差别，不一样浏览器解析 HTML 的速度，不一样网络提供商提供的互联网服务的速度，这些差别都会致使实际时间远大于服务器处理请求的时间
  实践中，咱们能够用一些前端架构优化的手段，经过优化 HTML 样式，利用浏览器异步和并发的特性，调整缓存策略，使用 CDN 服务，反向代理等，使用户可以尽快的看到内容，即便不对应用服务优化，也可以很好地改善用户体验

• 开发者视角： 开发者更关注的是应用服务器的性能，包括响应延迟，系统吞吐量，并发处理，系统稳定性等> 主要优化手段能够利用缓存加速数据读取，使用集群提升吞吐量，使用异步加快请求响应，优化代码改善程序等

• 运维人员视角： 对于运维人员，会更关注一些基础设施的性能和利用率，这里再也不多说

性能测试指标

主要的性能测试指标有 响应时间 并发数 吞吐量 性能计数器 等

• 响应时间
  指的是从发出这个请求开始到接收到数据的时间，通常状况下这个时间都很是很是的小甚至小于测试的偏差值，因此咱们能够采用重复请求的方式来获取具体的响应时间，好比请求十万次，记录总时间，而后计算出单次请求的时间

• 并发数
  指可以同时处理的请求数目，对于网站而言，即并发用户数> 有几个词可能会产生混淆，这里解释一下

网站系统用户数 > 网站在线用户数 > 网站并发用户数

• 吞吐量
  是单位时间能可以处理的请求数，体现的系统的总体处理能力> 衡量指标有不少，能够是 请求数/秒 页面数/秒 访问人数/天 处理业务数/小时 等> 经常使用的量化指标有 TPS（每秒事务数） HPS（每秒 HTTP 请求数） QPS（每秒查询数） 等

• 性能计数器
  描述服务器或操做系统的一些性能指标，包括系统负载（System Load），线程数，内存使用，磁盘和网络 I/O 等，当这些值超过警告值（安全临界值）时，就会想开发运维人员报警，及时处理异常

性能测试方法

性能测试是一个统称，具体能够分为 性能测试，负载测试，压力测试，稳定性测试

• 性能测试
  以初期设计的指标为预期目标，不断对系统施压，看系统在预期的范围内，可否达到预期的性能

• 负载测试
  对系统不断增长并发请求以增长系统压力，直到系统某项或多项指标达到安全临界值，这时继续对系统施加压力，系统的处理能力会有所降低

• 压力测试
  在超过安全负载的状况下，继续施压，直到系统崩溃或再也不可以处理任何请求，以此来计算系统的最大压力承受能力

• 稳定性测试
  在必定的压力（不均匀施压）下，系统可以稳定的运行较长时间

如上图所示，a-b 区间内就是网站平常的运行区间，绝大多数时间都处于这一区间内；而 c 点至关于系统的最大负载点，b-c 段就是因某些缘由访问量超过了平常访问压力；超过了 c 点后，继续增长压力，这时候系统的性能就开始降低，可是资源消耗会更多，直到 d 点，系统的崩溃点，超过这个点继续加压的话，系统将不能处理任何请求

性能测试反映的是系统的处理能力，与其对应的是用户的等待时间（响应时间），以下如所示：

各点与上面的性能测试图都相互对应，直到系统崩溃，用户失去响应

性能优化策略

首先要定位问题产生缘由，排查不一样环节的日志，分析哪一个环节的响应时间与预期不相符，而后分析影响性能的缘由，是代码问题仍是架构设计不合理，或者系统资源不足

而后就是性能优化，根据网站的分层架构，能够大体的分为 web 前端性能优化，应用服务器性能优化，存储服务器性能优化三大类