大型网站技术架构核心原理与案例分析
2022-08-19 11:39:20 16 举报AI智能生成
登录查看完整内容
书籍整理
作者其他创作
大纲/内容
1.分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成 一个完整的系统
2.在大型网站架构中也采用分层 结构，将网站软件系统分为应用层、服务层、数据层
3.通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整
4.但是分层架构也有一些挑战，就是必须合理规划层次边界和接口，在开发过程中， 严格遵循分层架构的约束，禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）
5.在实践中，大的分层结构内部还可以继续分层，如应用层可以再细分为视图层（美工负责）和业务逻辑层（工程师负责）；服务层也可以细分为数据接口层（适配各种输入和输出的数据格式）和逻辑处理层
6.分层架构是逻辑上的，在物理部署上，三层结构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，使网站拥有更多的计算资源以应对越来越多的用户访问
7.所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向发展至关重要。因此在网站规模还很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对。
a.分层
1.网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力
2.大型网站分割的粒度可能会很小。比如在应用层，将不同业务进行分割，例如将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上
b.分割
1.分布式应用和服务：将分层和分割后的应用和服务模块分布式部署，除了可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外；还可以使不同应用复用共同的服务，便于业务功能扩展。
3.分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据需要分布式存储
4.分布式计算支持网站线上服务器配置实时更新的分布式配置分布式环境下实 现并发和协同的分布式锁；支持云存储的分布式文件系统等
5.一个业务拆分为多个子业务，部署在多个服务器上
c.分布式
1.同一个业务，部署在多个服务器上
2.即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务
d.集群
1.缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件 设计中，缓存几乎无处不在
2.CDN：即内容分发网络，部署在距离终端用户最近的网络服务商，用户的网络请求总是先到达他的网络服务商那里，在这里缓存网站的一些静态资源（较少变化的数据）， 可以就近以最快速度返回给用户，如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN
3.反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问到的就是反向代理服务器，这里缓存网站的静态资源， 无需将请求继续转发给应用服务器就能返回给用户
4.本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库
5.分布式缓存：大型网站的数据量非常庞大，即使只缓存一小部分，需要的内存空间也不是单机能承受的，所以除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据
6.使用缓存有两个前提条件，一是数据访问热点不均衡，某些数据会被更频繁的访问， 这些数据应该放在缓存中；二是数据在某个时间段内有效，不会很快过期，否则缓存的 数据就会因已经失效而产生脏读，影响结果的正确性。网站应用中，缓存除了可以加快 数据访问速度，还可以减轻后端应用和数据存储的负载压力，这一点对网站数据库架构 至关重要，网站数据库几乎都是按照有缓存的前提进行负载能力设计的
e.缓存
提高系统可用性
加快网站响应速度
消除并发访问高峰
但需要注意的是，使用异步方式处理业务可能会对用户体验、业务流程造成影响， 需要网站产品设计方面的支持
f.异步
网站需要7x24小时连续运行，但是服务器随时可能出现故障，特别是服务器规模比 较大时，岀现某台服务器宕机是必然事件
需要一定程度的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上
访问和负载很小的服务也必须部署至少两台服务器构成一个集群
数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份
g.冗余
在无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。目前大型网站的自动化架构设计主要集中在发布运维方面
网站需要对线上生产环境进行自动化监控，对服务器进行心跳检测，并监控其各项性能指标和应用程序的关键数据指标
h.自动化
通过密码和手机校验码进行身份认证
登录、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理
为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别；对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理
对于垃圾信息、敏感信息进行过滤；对交易转账等重要操作根据交易模式和交易信息进行风险控制
i.安全
2.1网站架构模式
1.系统分为三个层次，最下层是基础服务层，提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了新浪微博的海量数据和高并发访问， 是整个系统的技术基础
2.中间层是平台服务和应用服务层，新浪微博的核心服务是微博、关系和用户，它们是新浪微博业务大厦的支柱。这些服务被分割为独立的服务模块，通过依赖调用和共享 基础数据构成新浪微博的业务基础
3.最上层是API和新浪微博的业务层，各种客户端（包括Web网站）和第三方应用， 通过调用API集成到新浪微博的系统中，共同组成一个生态系统
新浪微博
2.2架构模式在新浪微博的应用
2.大型网站架构模式
网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标，同时也是主观的感受
4.1.1不同视角下的网站性能
响应时间
并发数
吞吐量
System Load即系统负载
性能计数器
4.1.2性能测试指标
性能测试
负载测试
压力测试
稳定性测试
4.1.3性能测试方法
4.1.4性能测试报告
1.性能分析
2.性能优化
4.1.5性能优化策略
4.1网站性能测试
1.减少HTTP的主要手段是合并CSS、合并JavaScript.合并图片。2.将浏览器一次访问 需要的JavaScript. CSS合并成一个文件，这样浏览器就只需要一次请求。图片也可以合 并，多张图片合并成一张，如果每张图片都有不同的超链接，可通过CSS偏移响应鼠标 点击操作，构造不同的URL
减少http请求
静态文件资源变化这个时候应该同步缓存
使用浏览器缓存策略的网站在更新静态资源时，应采用批量更新的方法
使用浏览器缓存
启用压缩
CSS放在页面最上面、JavaScript放在页面最下面
减少Cookie传输
浏览器访问优化
CDN 加速
安全性
缓存起到加速作用
负载均衡
反向代理
4.2Web前端性能优化
频繁修改的数据(不适合作为缓存)
没有热点的访问
数据不一致与脏读
缓存可用性
缓存预热
缓存穿透
分布式缓存架构
合理使用缓存
分布式缓存
多线程
单例
对象池
资源复用
数据结构
垃圾回收
代码优化
削峰作用
异步操作
使用集群
4.3应用服务器性能优化
机械硬盘
固态硬盘
磁盘
B+树
LSM 树
树
Raid （廉价磁盘冗余阵列）
文件存储
4.4存储性能优化
4.网站高性能架构
1.1大型网站软件系统的特点
应用程序、数据库、文件等所有的资源都在一台服务器上
1.2.1初始阶段的网站架构
应用服务器(需要处理大量的业务 逻辑，因此需要更快更强大的CPU)
文件服务器(需要存储大量用户上传的文件，因此需要更 大的硬盘)
数据库服务器(需要快速磁盘检索和数据缓存，因此 需要更快的硬盘和更大的内存)
1.2.2应用服务和数据服务分离
80%的业务访问集中在20% 的数据上
缓存在应用服务器上的本地缓存(本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况)
缓存在专门的分布式缓存服务器上的远程缓存(可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务)
1.2.3使用缓存改善网站性能
使用集群是网站解决高并发、海量数据问题的常用手段
如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈
1.2.4使用应用服务器集群改善网站的并发处理能力
目前大部分的主流数据库都提供主从热备功能
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更 新同步到从数据库这样当应用服务器读数据的时候，就可以通过从数据库获得数据
1.2.5数据库读写分离
CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据
反向代理 则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理 服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户
1.2.6使用反向代理和CDN加速网站响应
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候 才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据 库部署在不同的物理服务器上
1.2.7使用分布式文件系统和分布式数据库系统
NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的 支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦
1.2.8使用NoSQL和搜索引擎
大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线
具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过一个超链接建立关系（在首页上的导航链接每个都 指向不同的应用地址），也可以通过消息队列进行数据分发，当然最多的还是通过访问同 一个数据存储系统来构成一个关联的完整系统
1.2.9业务拆分
1.2.10分布式服务
1.2大型网站架构演化发展历程
1.大型网站都是从小型网站发展而来。网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的，所以在网站还很小的时候就去追求网站的架构是舍本逐末，得不偿失的
2.大型网站架构技术的核心价值是随网站所需灵活应对
3.驱动大型网站技术发展的主要力量是网站的业务发展创新的业务发展模式对网站架构逐步提出更高要求，才使得创新的网站架构得以发 展成熟。是业务成就了技术，是事业成就了人
1.3大型网站架构演化的价值观
一味追随大公司的解决方案
为了技术而技术
企图用技术解决所有问题(技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决)
1.4.网站架构设计误区
a.演化
每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心
1.模式
b.大型网站架构模式
1.大型网站架构演化
在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力
在应用服务器端，可以使用服务器本地缓存和分布式缓存，通过缓存在内存中的热 点数据处理用户请求，加快请求处理过程，减轻数据库负载压力
通过异步操作将用户请求发送至消息队列等待后续任务处理，而当前请求直接返回响应给用户
在网站有很多用户高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能
在代码层面，也可以通过使用多线程、改善内存管理等手段优化性能
在数据库服务器端，索引、缓存、SQL优化等性能优化手段都已经比较成熟。而方兴未艾的NoSQL数据库通过优化数据模型、存储结构、伸缩特性等手段在性能方面的优势也日趋明显
衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过测试这些指标以确定系统设计是否达到目标
对于网站而言，性能符合预期仅仅是必要条件，因为无法预知网站可能会面临的访问压力，所以必须要考察系统在高并发访问情况下，超出负载设计能力的情况下可能会出现的性能问题。网站需要长时间持续运行，还必须保证系统在持续运行且访问压力不均匀的情况下保持稳定的性能特性
1.性能
网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储 在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失
对于存储服务器，由于其上存储着数据，需要对数据进行实时备份，当服务器宕机时需要将数据访问转移到可用的服务器上，并进行数据恢复以保证继续有服务器宕机的时候数据依然可用
网站的高可用还需要软件开发过程的质量保证。通过预发布验证、 自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范围扩大
衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及岀现各种不可预期的问题时，系统整体是否依然可用
2.可用性
网站通过集群的方式将多台服务器组成一个整体 共同提供服务
衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制
对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中 大部分缓存数据都无法访问。虽然缓存的数据可以通过数据库重新加载，但是如果应用已经严重依赖缓存，可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性
关系数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群
3.伸缩性
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响
网站可伸缩架构的主要手段是事件驱动架构和分布式服务
事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消 息发布到消息队列
分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响。可复用服务升级变更的时候，也可以通过提供多版本服务对应用实现透明升级，不需要强制应用同步变更
大型网站为了保持市场地位，还会吸引第三方开发者，调用网站服务，使用网站数 据开发周边产品，扩展网站业务。第三方开发者使用网站服务的主要途径是大型网站提供的开放平台接口
4.扩展性
衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略
5.安全性
3.大型网站核心架构要素
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度可用性指标=（1-网站不可用时间/年度总时间）xlOO%
2个9是基本可用
3个9 是较高可用
4个9是具有自动恢复能力的高可用
5个9是极高可用性
网站可用性度量
故障分是指对网站故障进行分类加权计算故障责任的方法
网站可用性考核
5.1网站可用性的度量与考核
5.2高可用的网站架构
5.3.1通过负载均衡进行无状态服务的失效转移
利用 Cookie 记录 Session一种管理Session的方式是将 Session记录在客户端受Cookie大小限制
5.3.2应用服务器集群的Session管理
5.3高可用的应用
核心应用和服务优先使用更好的硬件，在运维响应 速度上也格外迅速
在服务部署上也进行必要的隔离，避免故障的连锁反应低优先级的服务通过 启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在 不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心
超时设置
异步调用
拒绝服务拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用；或者随机拒绝部分请求调用，节约资源，让另一部分请求得以成功，避免要死大家 一起死的惨剧
关闭功能关闭部分不重要的服务，或者服务内部关闭部分不重要的功能，以节约系统开销，为重要的服务和功能让出资源
服务降级
幕等性设计
分级管理
5.4高可用的服务
5.网站的高可用架构
大型网站技术架构核心原理与案例分析
0 条评论
回复 删除
下一页
