首页 > 技术文章 > 看书笔记:大型网站技术架构

AlmostWasteTime 2018-03-26 15:44 原文

一、性能

从内存、磁盘、网络、CPU、代码等因素分析
性能优化第一定律:优先考虑缓存;   

  1、web前端性能优化    

    a、浏览器访问优化:
      1)、减少HTTP请求:HTTP请求为无状态,每个HTTP请求都需要启用独立的线程。主要是合并CSS和JavaScript和图片(页面的并发数固定,域名的解析尽量少,页面的对象尽量少,两者之间相平衡);
      2)、启动压缩:在浏览器端对图片、文件等进行压缩再传输(文件变小后耗时减少);
      3)、减少Cookie传输:静态资源用独立域名访问,减少Cookie传输;
    b、CDN加速(内容分发网络,CDN部署在网络运营商的机房):缓存网站的静态资源(图片、文件、静态网页等),在离用户最近的地方;
    c、反向代理(nginx代理):代理服务器接受HTTP请求再分发给Web服务器集群,有网络安全的作用。并且可以缓存静态资源,或者常用的动态资源在代理服务器上,这样其他HTTP请求访问时可以从,代理服务器直接返回。当动态资源有改变,通知代理服务器,资源失效,代理服务器会重新缓存动态资源;

  2、应用服务器性能优化(代码以及部署的服务器):
    a、分布式缓存(遵循二八定律):减少响应时间(缓存读取速度快)、减少数据计算时间(例如某数据是经过计算得到,保存到缓存后,再次拿取的时候,就不用再次计算该数据)。缓存的本质:内存hash表hashcode唯一标识符,通过Hash表的计算值可以直接拿到Key---Value;
      1)、合理使用缓存:频繁修改的数据。没有热点的数据(不遵循二八定律)。数据的不一致和脏读。缓存的可用性(例如缓存集群,某服务器宕机后,丢失的缓存数据较少,影响较小)。缓存预热,启动项目时,将数据库中所有数据加载到缓存中进行预热。缓存穿透,将经常被访问不存在的数据,value值设置为null;
      2)、分布式缓存架构:一种是更新同步的缓存架构(JBoss Cache),一种是不互相通信的缓存架构(Memcached,缓存集群单独部署在某服务器上,应用通过hash算法计算去远程调用某个缓存服务器);
    b、异步操作:消息队列(消息队列服务器 快于 直接写入数据库,所以当高并发情况下,使用异步消息队列,可以减轻数据库的压力),具有很好的削峰作用;
    c、集群:负载均衡服务器(经过算法,分发请求到集群的某个服务器上);
    d、代码优化:
      1)、多线程:多个cpu充分利用。 需要解决线程安全问题,将对象设为无状态对象(不注入实体类),或使用局部对象,或并发访问资源使用“锁”机制;
      2)、资源复用:使用单例对象和对象池()
      3)、数据结构
      4)、垃圾回收

  3、存储性能优化
    a、海量数据的读写对磁盘访问造成巨大的压力,磁盘存储了项目的数据,所有磁盘的可用性和容错性也至关重要;
      1)、机械硬盘和固态硬盘:
      2)、B+树和LSM树:文件系统和数据库系统对数据进行排序后存储


二、网站架构的高可用

  1、应用层:负载均衡(集群情况下,session管理);
    a、session复制:集群中同步session对象(同一时刻的值相同,适用于小集群);
    b、session绑定:将同一IP请求的session绑定到同一台应用服务器(基本不用);
    c、用cookie记录session:适用于很多情况;
    d、session服务器:应用服务器每次读写session都访问session服务器;

  2、高可用的服务
    a、核心应用和服务:优先使用更好的硬件;
    b、异步请求:消息队列;
    c、服务降级

  3、高可以的数据:数据备份和失效转译机制
    a、数据的一致性:写入存储时,数据备份到一个或者多个副本。保证可用性和伸缩性,放弃一致性;
    b、数据备份:冷备份(常规导出sql文件等)。热备份:异步(主从同步数据库),同步(同步向多个数据库写入(会有延迟));
    c、失效转移:

三、网站架构的伸缩性

  1、伸缩性设计:
    a、不用的功能,进行物理分离实现伸缩:将数据库、缓存、静态资源分
离到新增的服务器上;
      1)纵向分离:将业务处理流程上的不同部分,分离部署,例如(网站具体产品、可复用业务、基础技术服务、数据库);
      2)横向分离:将不同的业务模块分离部署,例如(买家前台、买家后台、卖家后台、静态图片等)。可以一个大型网站的很小一个功能,例如首页单独部署到服务器;
    b、单一功能用集群实现伸缩:将相同服务部署在多台服务器上(集群);

  2、应用服务器集群的伸缩性
负载均衡(HTTP请求分发装置):向刚上线的服务器分发请求,向已下线的服务器停止分发请求
    a、HTTP重定向负载均衡:先向HTTP服务器请求,得到一个服务器具体的IP,返回给用户后,再重定向到该IP的服务器上(很少用);
    b、DNS域名解析负载均衡:每次域名解析,都会根据负载均衡算法计算得到一个IP,再将该IP返回给浏览器,然后浏览器再访问该IP(缺点是商家自己维护,网站无法做更多改善和管理);
    c、反向代理负载均衡:浏览器访问外部IP,到反向代理服务器后,得到真实服务器内IP。获取到数据后又返回给反向代理服务器,再返回给前端(优点:部署简单等,缺点是请求和响应中转站,可能会有性能瓶颈);
    d、IP负载均衡:
    e、数据链路层负载均衡:
    f、负载均衡算法:根据算法得到集群中某一台服务器地址,再将请求数据发送到该地址的服务器;
      1)、轮询:依次分发到每台服务器,每台服务器处理的请求数目相同(每台服务器性能一样);
      2)、加权轮询:按配置的权重将请求发送到每个服务器(性能好的服务器处理的请求多一些);
      3)、随机:随机分配到每个服务器上;
      4)、最少连接:记录每个服务器的连接数,将请求发送到最少连接上(加权最少连接)
      5)、源地址散列:根据来源的IP地址进行hash算法,将某地区的请求发送到某服务器上,请求上下文信息可以存储在改服务器上,在一个会话中重复使用,实现会话粘滞;

  3、分布式缓存集群的伸缩性:集群中不同的服务器缓存的数据不同,所以不能用简单的负载均衡来实现。新上线的缓存服务器对分布式缓存集群影响最小。并且整个缓存集群中的数据,已缓存的数据尽可能被获取到。
    a、Memcached为代表分布式缓存:路由算法根据应用程序的缓存KEY计算应该讲数据读(或写)到哪台服务器;
      1)、普通的路由算法是计算hashcode/服务器数量的余数,对伸缩性来说是个很大挑战,不太实用;
      2)、一致性Hash算法:0~2的32次方,根据KEY的hashcode的值按顺时针靠近最近服务器的hash值,添加服务器越多,命中率越高(缺点:新增的服务器与被分摊的服务器的压力小于原来的服务器);
      3)、针对2)提出改进,将物理服务器,虚拟为一组虚拟缓存服务器,分散添加到一致性算法中,这样新添加物理服务器,算一组虚拟服务器,会较为均匀的分摊到集群意见存在的服务器中(一个物理服务器分为150个虚拟服务器较好);

  4、数据存储服务器集群的伸缩性:主要是对持久性和可用性、准确性有更高的要求(关系型数据库和nosql集群);
    a、关系型数据库集群伸缩性设计:读写分离和数据分库能满足基本的集群伸缩,Cobar为分布式关系数据库访问代理。Cobar为无状态服务器,所以可以用负载均衡实现。例如mysql的迁移就复杂的多,具体情况具体分析;
    b、NoSQL数据库的伸缩性设计:具体看书籍;

四、随需应变:网站的可扩展架构

  1、模块直接不存在直接调用,耦合性最低,那就使用消息队列;

  2、事件驱动架构:基于(消息对象)驱动业务架构。消息发布者---消息队列---消息接受者(可以为多个)

  3、分布式消息队列:
    a、伸缩性:消息队列服务器数据即时处理,可以看做无状态服务器,集群添加服务器影响较小;
    b、可用性:如果消息队列满了,新生产的消息会写入磁盘中,待消息队列中消息减少时再写入消息队列中;
    c、避免宕机影响:消息发送到消息队列后,依然会保存在消息生产者服务器,待消息消费者消费后才删除消息。如果宕机,则消息生产者会重新选择集群中的其他消息队列服务器;

  4、分布式打造可复用的业务平台:纵向拆分和横向拆分;
    a、特点:负载均衡,失效转移、高效的远程通信、整合异构系统、对应用最少入侵、版本管理、实时监控;

  5、可扩展的数据结构:NoSQL的扩展

  6、利用开发平台建设网站生态圈:

五、网站的安全架构

推荐阅读