《大型网站技术架构 核心原理与案例分析》笔记

大型网站技术架构核心原理与案例分析》读书笔记一、大型网站架构演化1、大型网站特点高并发，大流量高可用海量数据用户分布广泛，网络情况复杂安全环境恶劣需求快速变更，发布频繁渐进式发展2、大型网站架构发展历程文件服务器，数据库服务器，应用服务器分离应用服务器增加本地缓存，本地缓存优先，增加分布式缓存服务器使用应用程序服务器集群提高网站的并发，由负载均衡服务器统一调度分发使用分布式文件系统和分布式数据库系统使用CDN网络加速和反向代理服务器：基本原理都是缓存，CDN部署在网络提供商的机房，是用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据。而反向代理是部署在中心机房，当用户的请求到达中心机房后，首先访问的是反向代理服务器，如果反向代理服务器中缓存这用户请求的资源，就将其直接返回给用户，目的都是尽早返回数据给用户，加快用户访问速度，减轻后端服务器的压力。使用Nosql和搜索服务器业务拆分，根据不同的产品，不同的业务，将一个网站拆分成不同的应用，每个应用独立部署维护，各个应用之间通过消息中间件或者访问同一个数据存储系统来构成一个相互关联的完整系统分布式服务，将公用的业务提取出来，独立部署，为其他应用服务器提供可复用的共用业务服务（可以通过dubbo和zookeeper集群实现）3、网站架构的价值观和设计误区架构的选取随网站所需灵活应对主要驱动力量是网站的业务发展不可一味追随大公司的架构设计，照搬照抄网站技术是为了业务存在的，不可为了技术而技术不要企图使用技术解决一切问题。技术是用来解决业务问题的，同样业务问题也可以采用业务手段，通过修改业务架构来解决二、大型网站架构模式1、分层将系统在横向纬度上分成几个部分，每个部分负责单一职责，通过上层对下层的依赖和调用组成一个完整的系统。网络的7层通讯协议，计算机硬件、操作系统、应用软件，都采用了分层的思想。将网站系统分为应用层、服务层、数据层，三层结构分别部署在不同的服务器上应用层：负责具体业务和视图展示服务层：为应用层提供服务支持，如用户管理服务、购物车服务数据层：提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等2、分割在纵向方面对系统进行划分，比如应用层，可以将不同业务分割，将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责。部署在不同的服务器上。3、分布式分层和分割的目的就是为了切分后的模块便于分布式部署，将不同的模块部署在不同的服务器上。同时，分布式也带来了很多问题，不同服务器之间的通信对网络依赖很大保持数据一致性比较困难网站依赖错综复杂，开发维护困难常见的分布式方案有以下几种分布式应用和服务。分布式静态资源分布式数据和存储分布式计算分布式文件系统分布式锁分布式配置。支持网站线上服务配置实时更新4、集群虽然分布式已经将各个应用分开部署，但是对于用户集中访问的模块，还需要独立部署服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。并且支持线性扩展，发生故障时的失效转移。即使是访问量很小的分布式应用和服务也至少要部署两台构成小的集群，提高系统的可用性5、缓存缓存是改善软件性能的第一手段。大型网站很多方面都使用了缓存设计：CDN，即内容分发网络。在这里缓存网站的一下静态资源（较少变化的数据），可以就近以最快速度返回给用户。如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN反向代理。当用户的请求到达数据中心时，最先访问到的是反向代理服务器，这里缓存网站的静态资源，无需继续将请求转发给应用服务器，直接返回给用户本地缓存。在应用服务器本地缓存这热点数据，应用程序可以在本地内存中直接访问，无需访问数据层分布式缓存。将数据存储在专门的分布式缓存集群中，应用服务器通过网络通讯访问缓存数据。缓存同时也存在着缓存击穿、缓存雪崩、缓存热点不集中的问题6、异步在单一服务器内部可通过多线程共享内存队列的方式实现异步，在分布式系统中，多个服务器集群通过分布式消息队列实现异步。异步架构是典型的生产者-消费者模式。使用异步消息队列能够带来如下好处：提高系统可用性提高系统响应速度消除并发访问高峰。消息队列能够把突然增加的访问请求数据放入到队列中，等待消费者处理，不会对网站造成太大压力7、冗余为了提高系统的可用性，防止某些服务器宕机的情况下系统依然可以继续服务，需要一定的服务器冗余运行、数据冗余备份。数据库除了定期备份实现冷备份之外，还需要主从分离，实时同步实现热备份。为了抵御海啸、地震等不可抗力，还需要在全球范围内部署灾备数据中心。8、自动化发布过程自动化：自动化代码管理，自动化测试，自动化安全测试，自动化部署。系统运行过程中还有：自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化资源分配。9、架构模式在新浪微博的应用新浪微博系统分为三层：最下层是基础服务层，提供数据库、缓存、搜索、存储等基础服务中间层是平台服务和应用服务层，微博的核心是微博、用户、关系，这些服务被分割成独立的模块，通过依赖调用和对共享基础服务构成微博的业务基础API层，是微博的业务层，包括网站、app、第三方应用，通过调用API集成到微博系统中，共同组成一个生态系统微博的发布，早起使用同步推模式，用户发表微博后会立即将这条微博插入到数据库所有粉丝的订阅列表中，用户量比较大时，会引起大量的数据库写操作，超出负载，导致系统性能下降。后来改用异步推拉方式，用户发表微博之后立刻写到消息队列中然后立刻返回，消息队列消费者将微博推送给当前在线粉丝的订阅列表中，非在线用户等登录后在根据关注列表拉取微博订阅列表由于微博频繁刷新，微博使用多级缓存策略，热门微博和明星微博缓存在所有的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群中三、大型网站核心结构要素1、性能。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间QPS（TPS）：每秒钟request/事务数量并发数：系统同时处理的request/事务数响应时间：一般取平均响应时间QPS（TPS）=并发数/平均响应时间2、高可用指的是网站可以保证大部分时间系统都是可用的，一些知名大型网站可以得到99.99%的时间都是可用的。高可用的设计目标是当有部分服务器宕机时，整体的服务或者应用依然可用。保证网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供访问，数据存储在多个服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用。网站的高可用还需要软件开发过程的质量保证，通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能。3、伸缩性衡量的主要指标就是是否可以用多台服务构架集群，是否容易向集群中添加新的服务器，加入的新的服务器是否可以提供和原来服务器无差别的服务，集群可容纳的总服务器数量是否有限制。应用服务器，通过使用合适的负载均衡设备，就可以向集群中不断加入服务器缓存服务器集群，加入新的服务器可能会导致缓存路由失效，如果对缓存的依赖严重，可能会导致系统崩溃。关系数据库。虽然支持主从复制，主从热备，但是很难做到大规模集群的可伸缩性。因此关系型数据库的可伸缩性方案必须在数据库之外实现，通过路由分区等手段，将多个部署的数据库服务器集成一个集群。NoSql数据库。由于其先天就是为了海量数据而生的，因此对可伸缩性的支持非常好。4、扩展性衡量的主要标准就是网站增加新的业务产品时，是否会对现有产品产生影响，不需要改动或很少改动既有业务就可以上线新产品，不同产品之间很少的耦合，一个产品改动对其他产品没有影响。网站的可扩展架构的主要手段是事件驱动架构和分布式服务事件驱动，通常利用消息队列实现，把消息的生产者和消费者分开，这样可以透明的增加新的生产者和消费者分布式服务则是将业务和可复用服务拆分开，通过分布式服务调用可复用服务。可复用服务升级变更的时候，也可以通过提供多版本服务实现透明升级，不需要强制应用同步变更。5、安全性网站的安全架构需要保证网站不受恶意访问和攻击、保护网站的重要数据不被窃取。四、网站的高性能架构1、网站性能测试性能测试指标。主要指标有响应时间、并发数、吞吐量、性能计数器2、Web前端性能优化浏览器访问优化减少http请求。合并css、JavaScript、图片，将浏览器一次访问需要的资源合并成一个文件使用浏览器缓存。通过设置http头部中的Cache-Control和Expires属性，设置浏览器缓存。将css、javascript、图片等静态资源通过浏览器缓存起来，如果需要静态资源及时应用到客户端浏览器，可通过改变文件名实现。启用压缩。在服务端对文件进行压缩，在浏览器端对文件进行解压缩，有效减少通讯传输的数据量，会对服务器和浏览器产生一定的压力，通信宽带良好，服务器资源不足的情况下，不适合采用减少cookie传输，cookie包含在每次请求和响应中，太大的cookie会影响数据传输。深入了解，cookie和session的区别CDN加速CDN，内容分发网络，本质上也是缓存，而且将缓存在里用户最近的地方。部署在网络运行商的机房，CDN缓存的是一些静态资源反向代理反向代理服务器位于网站机房一侧，代理网站web服务器接受http请求。具有保护网站安全的作用代理服务器可以通过配置缓存功能加速web请求，当用户第一次请求静态内容的时候，就被缓存在反向代理服务器上也可以实现负载均衡的功能3、应用服务器性能优化分布式缓存合理使用缓存，频繁修改的数据不适合缓存，读写比在2:1之上，缓存才有意义没有热点访问的数据，不适合做缓存数据不一致，数据库修改了数据并不会立即修改缓存，存在时间差分布式缓存服务器，提高缓存的可用性缓存预热，启动时就把热点数据放入缓存中。热点数据是利用LRU（最近最久未用算法）对不断访问的数据筛选淘汰出来的缓存穿透，大量请求不存在的数据，绕过缓存直达数据库。一个简单的策略：将不存在的数据也缓存起来分布式缓存架构：一种是需要同步更新的分布式缓存，规模较大时，缓存更新数据需要同步到所有缓存服务器，代价惊人。另一种是以memcache为代表的互不通信的分布式缓存架构，应用程序通过一致性hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，集群规模可以很容易的扩容，具有良好的可伸缩性。异步操作，可以晚点做的事情都应该晚点做使用集群代码优化多线程充分利用多CPU和解决IO阻塞问题，利用多线程IO阻塞与执行充分利用CPU资源。同时需要解决线程安全问题，将对象设计成无状态对象，使用局部变量，在修改共同资源时加锁资源复用。尽量复用开销很大的资源，比如数据库连接、线程、复杂对象优化数据结构，比如hash表，要尽量减少hash冲突，hashcode越散列，冲突越少，读写性能也就越好，目前比较好的字符串Hash散列算法有Time33算法和指纹加密算法md5结合使用。先对字符串指纹加密，对加密后的字符串进行Time33。垃圾回收，JVM调优，尽量减少FullGC，甚至从不进行FullGC4、存储性能优化SSD固态硬盘vs机械硬盘机械硬盘，每次访问数据，都需要移动磁头臂，顺序访问和随机访问性能差别很大SSD固态硬盘，没有机械装置，数据存储在可持久记忆的硅晶体上，可以像内存一样随机访问B+树vsLSM树为了改善数据访问特性，文件系统和数据库系统会对数据排序后存储，加快数据检索速度，需要保证新的数据插入、更新、删除后依然有序。传统关系型数据库通常采用B+树目前许多NoSQL产品采用LSM树最为主要数据结构，可以看做是一个n阶合并树五、网站的高可用架构1、高可用的应用层服务负载均衡服务器通过心跳检测机制发现故障服务器失去响应，就会把它从服务器列表中剔除，而将请求发送到其他服务器上。服务器集群的session管理，分布式缓存服务器，负载均衡服务器通过hash算法总是将来源于同一ip的请求分发到同一台服务器上2、高可用的基础公共