SEO外包平台,我们为您提供专业的企业网站SEO整站优化外包服务 SEO设置

SEO外包平台

专注于企业网站SEO整站优化外包服务

读《大型网站技术架构 核心原理与案例分析》总结

作者:jcmp      发布时间:2021-05-08      浏览量:0
如题,就不废话了,本人只是做的一个文章总

如题,就不废话了,本人只是做的一个文章总结,方便知识点学习,并没有详细去讲某个知识点,这本书也是这样,是在“面”上给大家普及了“架构”。也推荐给大家去读,真的很好。

以下的知识点其实是我最早的时候总结了一个思维导图,但是知乎并不能上传那个大图,所以又做了稍微的修改,总结了以下的内容,有什么不对的地方可以指点相互学习,排版可能不是很好,敬请原谅。

一.大型网站的架构的演化过程:

1.阶段一 :应用服务器中包含:1.应用程序。2.数据库。3.文件。

2.阶段二 :应用服务与数据库,文件存储分离,三个模块各在一个服务器。

3.阶段三 :使用缓存改善网站的性能:

(1)缓存部署在应用程序的服务器:

优点:本地缓存访问速度快。

缺点:受应用服务器内存限制,与应用程序争内存。

(2)缓存单独部署在一个缓存服务器集群上:

优点:1.几乎不受内存的限制(集群可以添加)。2.有效缓解高并发服务器压力。

缺点:访问速度不如本地缓存快。

4.阶段四 :在阶段三的基础上,应用服务器也使用集群的模式:

5.阶段五 :在阶段四的基础上,使数据库“读写分离”:

6.阶段六 :使用反向代理和CDN加速网站的响应:

原理:和缓存一样,使数据不从数据库返回给用户,而是从反向代理或者CDN服务器。

(1)反响代理:部署在网站的机房,用户的请求先访问反向代理服务器,如有用户要的数据,直接返给用户,加快相应并且缓解数据库压力。

(2)CDN:和反响代理的作用是一样,区别在于部署在网络提供商的机房,用户请求时可以在离自己近的网络提供商处获取数据。

7.阶段七 :在阶段六的基础上,使数据库和文件系统采用分布式集群模式:

8.阶段八 :在阶段七的基础上,使用nosql和搜索引擎:

9. 阶段九 :在阶段八的基础上,对业务进行拆分(横向分割)或者对系统纵向分层,采用分布式集群的模式。

最终目的:提高用户满意,解决并发,服务器压力,保证7*24运作。

二.网站架构模式:

1.纵向分层 :将网站软件系统划分,可分布式部署在不同的服务器上:

(1)应用层

(2)服务层

(3)数据层

2.横向分割 :将网站的业务进行拆分,将不同的功能模块进行拆分,不同的团队进行管理部署在不同的分布式服务器上。

优点:部署在不同的服务器上,那么CPU,内存,存储资源就越多,能够处理并发访问,提供好的服务。

3.分布式:

优点:很多,可以自己度娘。

缺点:列举几点

(1)通过网络进行连接,对性能造成影响。

(2)服务器多,难以维护和部署。

(3)分布式的数据很难保持一致性。

综合来说优点是远远大于缺点的。

4.集群: 通过负载均衡服务器,使用户请求平均给服务器集群,解决并发问题。

注意,集群和分布式是2个概念。

5.缓存 :改善软件性能的第一手段:

(1)本地缓存

(2)分布式缓存

(3)反向代理

(4)CDN

6.异步 :如activemq:

(1)消除访问高峰的并发

(2)加快网站的响应速度

(3)提高系统的可用性

7.数据库冗余:

(2)热备份

(3)灾备数据中心

8.自动化:

(1)发布过程自动化

(2)自动化代码管理

(3)自动化测试

(4)自动化安全检测

(5)自动化部署

(6)自动化监控

(7)自动化报警

(8)自动化失效转移

(9)自动化失效恢复

(10)自动化降级

(11)自动化分配资源

9.安全:

攻击类:

(1)SQL注入

(2)XSS攻击

(3)CSRF攻击

(4)WEB应用防火墙

(5)其他漏洞攻击

信息加密:

(1)单向散列加密

(2)对称加密

(3)非对称加密

(4)密钥安全管理

电子商务风险控制:

(1)风险

(2)风控

三.网站架构要素:

1、性能:

( 1)网站性能测试:

用户视角下:在浏览器上直观的感受网站响应的快慢。

开发人员视角下:响应延迟,系统吞吐量,并发处理能力,系统稳定等技术指标。

运维人员视角下:基础设施性能和资源利用率等。

响应时间:直观的反应出系统的快慢,采用平均值的测试方式测试。

并发数:系统能同时处理并发的数目,也反应了系统的负载特性。

吞吐量:单位时间内系统处理请求的数量,体现了系统的整体处理能力。

性能计数器:描述服务器或操作系统的一些数据指标。

性能测试:对系统不断施压,验证系统在资源范围内是否达到预期性能。

负载测试:对系统不断施压,直到系统到安全临界值。

压力测试:超过最大安全负载的情况下,继续施压,以此获得系统的最大承受能力。

稳定性测试:在特定的硬件,软件,网络环境下,给系统加载一定的业务压力,使系统运行一段时间,以此检测是否稳定。

(2)性能优化策略:

1.web前端性能优化:

(1)浏览器访问优化:1.减少http请求。2.使用浏览器缓存。3.启用压缩。4.CSS放在页面最上面,JS放在页面最下面。5.减少cookie传输。

(2)CDN加速。

(3)反向代理。

2.应用服务器性能优化:

(1)分布式缓存:

1.合理使用缓存:

不保存频繁修改的数据,不保存没有访问热点的数据(2-8定律),数据不一致与脏读,缓存可用性,缓存预热,缓存穿透。

2.分布式缓存架构:

3.更新同步的分布式缓存:企业级应用经常使用:JBOSS Cache。

4.不互相通信的分布式缓存:大型网站通常使用:Memcached:优点:简单的通信协议,丰富的客户端程序:支持JAVA等很多语言,高性能的网络通信,高效的内存管理,互不通信的服务器集群架构。

(2)异步操作:“任何可以晚做点的事情都应该晚点再做”,但是要根据业务进行调整,避免产生纠纷,比如并发时期的下单业务。

(3)使用集群:解决高并发访问的问题。

(4)优化代码:

1.多线程:将对象设计为无状态对象(从JAVA面向对象的思想上看,无状态对象是一种不良设计)。使用局部对象。并发访问资源时使用锁。

2.资源复用:单例,对象池

3.数据结构优化

4.垃圾回收

(5)存储性能优化:

1. 机械硬盘和固态硬盘

2. B+树和LSM树

3. RAID和HDFS

总结:性能优化可能降低了高并发时期的响应延迟,但却增加了低并非时的响应时间,设计者要心中有数。

2.可用性:

可用性,即为网站服务的可使用。

( 1)网站可用性的度量与考核

1. 网站可用性度量:通常用多少个9来衡量可用性。

2. 网站可用性考核:根据自己公司的政策制度去考核,行业内也有一般的规则。

(2)高可用的网站架构

典型的设计:

1. 应用层(集群):功能1,功能2,功能N

2. 服务层(集群):Session服务,账户服务,服务N

3. 数据层(集群):缓存服务,搜索服务,文件服务,数据库服务等。

(3)高可用的应用:

1. 通过负载均衡进行无状态的服务失效转移。

2. 应用服务器的Session管理:

A. Session复制:只适用于集群规模比较小的情况,大规模集群的时候需要大量的通信复制Session占用资源,会出现内存不足的情况。

B. Session绑定:利用源地址Hash算法使用户总是请求集群里的特定的一个服务器,当这个服务器挂掉时,session就失效了,很少有网站用这个方法。

C. 利用cookie记录session:

受cookie大小限制,每次请求都要传输占用资源,用户关闭浏览器cookie就不能访问了。

cookie简单易用,可用性高,大部分cookie存储的session比较小,去多网站或多或少都使用cookie记录session。

D. Session服务器:

独立的Session集群服务器进行session管理,一般采用这种方式和cookie相结合的方式。

(4)高可用的服务:

1. 分级管理:运维上将服务器分级管理,核心服务和应用用更好的硬件,部署上进行单独部署隔离,避免故障的连锁反应。

2. 超时设置:用户请求长时间不能影响,根据策略,选择继续等待还是将请求转移到别的服务器上。

3. 异步调用:消息队列,如activemq。解决并发访问,提高用户响应,但是需要看业务情况使用,避免产生下单失败,用户却收到成功信息这样的情况。

4. 服务降级:

A. 拒绝服务:拒绝低优先级的服务调用,把资源让给高优先级的服务。

B. 关闭功能:在高并发的时候,关闭一些非核心的服务,让出资源。

5. 幂等设计:

由于一些延迟情况,一些服务或者应用会被重复调用,这样的情况是不可避免的,但是我们要保障重复调用和执行一次的结果相同,也有服务具有天然的幂等性,比如设置性别男,一次和多次结果是相同的。

(5)高可用的数据:

1. 数据的存储手段:数据备份和失效机制转移

2. 缓存服务:

(A)目前主流有2种观点:

a. 目前主流网站的数据都在缓存中读取,所以,缓存和数据库一样重要,要实现同样的高可用。

b. 缓存不是数据存储服务,缓存数据丢失,导致服务器压力过高应该通过别的手段去解决,而不是提高缓存本身的高可用。

(B) CAP原理:

a. 数据持久性:保证数据持久的存储,任何情况下不会丢失数据,复制存放在多个不同的物理存储设备上。

b. 数据可访问性:如果一个数据存储设备损坏,使访问快速的转移到另一个设备上,如果过程不是很快,会造成数据不能访问。

c. 数据一致性:

1. 数据强一致性:各个副本的数据总是一致的,更新的时候要么同时成功,要么失败。

2. 数据用户一致性:如果各个副本中的数据不一致,通过纠错和校验机制,返回给用户一个正确的数据。

3. 数据最终一致性:物理存储的数据不一致,终端不同用户访问的数据不一致,但是通过系统一段时间的自我恢复和修正,数据最终会达到一致性。

(C) 数据备份:

a. 冷备:简单,廉价,古老,数据的最终一致性不能保证,不能保证数据可用性。

b. 热备:

1.异步热备:数据库写的操作同步到几个数据库同时操作

2.同步热备:数据写操作只写到主数据库,写完之后返回用户成功,用线程等方法使主数据库的数据同步到从数据库。

(D)失效转移:

a. 失效确认:确认服务器宕机:1.心跳检测。2.应用程序访问失败报告。

b. 访问转移:当确认某个服务器宕机时,使请求路由到其它服务器上,几台存储数据库的数据几乎完全一致。

c. 数据恢复:要将宕机的服务器的数据进行恢复,不然在有服务器宕机的时候可能出现无法转移的现象。

(6)高可用网站的软件质量保证

1. 网站发布:相当于给飞行中的飞机更换引擎,但是不能让飞机坠毁。可以更新集群服务器中的一部分服务器,在用户不知情的状况下,慢慢渗透更新全部的服务器。

2. 自动化测试:在发布之前,用自动化测试技术对代码进行测试,确保无误之后才发布。

3. 预发布验证:

a. 即使通过了自动化测试,也不要把其发布到正式环境上,在预发布环境下发布,并且进行一定的业务流程来测试是否正常。

b. 预发布的环境可以和正式环境部署在一起,也是就同一个环境。

c. 预发布连接的是真实的生产环境,所以做测试的时候要谨慎,如下单不要随意更改商品的价格。

d. 预发布如果遇到一些错误要立即排查,而不要带着错误启动

4. 代码控制:

a. 主干开发,分支发布

b. 分支开发,主干发布

5. 自动化发布

6. 灰度发布:

a. 可以在服务器集群的一部分服务器上更新版本,可以测试新版本的功能,而且出现错误需要回归版本的时候只需要更新这几个服务器即可,避免了大规模服务器回滚耗时很长的情况。

(7)网站运行监控

1. 不允许没有监控的系统上线:

(A) 监控数据采集:

a. 用户行为日志收集:服务器端日志收集,客户浏览器日志收集

b. 服务器性能监控:收集服务器性能指标,如系统LOAD,内存占用,磁盘IO,网络IO等,及时预警,防患于未然。

c. 运行数据报告:需要检测一些具体的业务,比如业务的响应延迟,缓冲命中率,待处理任务总数等。

(B)监控管理:

a. 系统报警:当某个值到达一个值的时候可以报警联系值班人员。

b. 失效转移:监控系统发现故障后主动通知应用进行失效转移。

c. 自动优雅降级:当高并发访问时,自动关闭部分功能,让出资源给核心功能。

总结:系统架构的可用性关系到生存死亡,对个人而且,可用性关系到个人的升迁,也许你对系统进行了很多改善,但是别人未必能直观的感受到,也许你的上司都不知道,但是如果系统出现重大故障,连公司CEO都会知道你的名字。

3.伸缩性:

总的来说,网站都是往外“伸”的,“缩”的网站可能是快运营不下去的网站。

(1)网站架构的伸缩性设计:

1. 根绝功能进行物理分离实现伸缩,不同的服务器部署不同的功能:

a. 纵向分离:将业务处理流程上的不同部分分离部署,实现伸缩性。

b. 横向分离:将不同的业务模块分离部署,实现伸缩性

2. 单一功能通过集群模式实现伸缩,集群内的多台服务器提供相同的服务,功能:

a. 应用服务器集群

b. 数据服务器集群:缓存数据服务器集群,,存储数据服务器集群。

(2)应用服务器集群的伸缩性:

1. http重定向负载均衡

2. DNS域名解析负载均衡

3. 反向代理负载均衡

4. IP负载均衡

5. 数据链路层负载均衡

6. 负载均衡的算法:

a. 轮询

b. 加权轮询

c. 随机

d. 最少连接

e. 源地址散列

(3)分布式缓存集群的伸缩性设计:

1. 不同于应用服务器集群的伸缩性设计,不能用简单的负载均衡的手段来实现。

2. 缓存数据的访问不能是服务器中的任意一台,而应该是有这个特点数据的缓存服务器。

3. 新加入的缓存数据库应该对集群的影响很小,使已经存在的缓存数据还被平均的访问到。

4. memcached分布式缓存的集群访问模型

5. memcached分布式缓存集群的伸缩性挑战

6. 分布式缓存的一致性HASH算法

(4)数据存储服务器集群的伸缩性设计

1. 关系数据库集群的伸缩性设计

2. 非关系型数据库集群的伸缩性设计

总结:一个具有良好的伸缩性的网站,其设计总是走在业务的前面的,在业务需要处理更多访问和服务之前,就已经做好了准备。反之业务走在技术的前面,采购来的服务器无法加入集群,即使勉强加入后,发现瓶颈却不在这里,导致技术天天加班,拖公司发展的后腿。

4.扩展性:

遵循开闭原则,即对扩展开放,对修改关闭

(1)构建可扩展的网站架构:

通过分层或者分割的方式进行架构伸缩,分割为若干个低耦合的独立的组件模块,独立的模块部署在独立的服务器上,之后,模块间聚合的方式主要有分布式消息队列和分布式服务。

(2)利用分布式消息队列降低系统耦合性:

1. 事件驱动架构:

a. 经典的EDA架构

b. 具有良好的响应延迟,减少后端负载的数据压力

2. 分布式消息队列:如activemq

(3)利用分布式服务打造可复用的业务平台:

1. 传统“巨无霸”系统的弊端:

a. 编译,部署困难

b. 代码分支管理困难

c. 数据库连接耗尽

d. 新增业务困难

解决方式:进行拆分:1.横向拆分,2.纵向拆分。

2. web service 与企业级分布式服务:技术成熟,产品规范,成功案例多。

缺点:

a. 臃肿的注册与发现机制

b. 低效的xml序列化手段

c. 开销相对较高的HTTP远程通信

d. 复杂的部署与维护手段

导致了其难以满足大型网站对系统高性能,高可用,易部署,易维护的要求。

3. 大型网站分布式服务的需求与特点

a. 负载均衡

b. 失效转移

c. 高效的远程通信

d. 整合异构系统

e. 对应用最少侵入

f. 版本管理

g. 实时监控

4. 分布式服务架构设计:可查看阿里开源的dubbo为例

(4)可扩展的数据结构:

1. 传统的关系型数据库数据结构僵硬

2. NOSQL数据库使用的ColumnFamily设计就是一个解决方案。

(5)利用开放平台建设网站的生态圈

1. API接口

2. 协议转换

3. 安全

4. 审计

5. 路由

6. 流程

5.安全性:

(1)xss攻击:跨站点脚本攻击:

通过篡改网页,注入恶意HTML脚本,控制用户浏览器进行恶意操作。

1. 类型:

a. 反射型:攻击者诱使用户点击一个嵌入恶意脚本的连接,进行攻击,偷取用户cookie,密码,伪造交易,盗取用户财产,窃取情报。

b. 持久型:黑客提交含有恶意脚本的请求,保存在被攻击的WEB站点的数据库中,攻击论坛,微博等web应用。

2. 预防手段:

a. 消毒:对某些HTML危险字符转义,可以防止大部分的攻击

b. httpOnly:浏览器禁止页面JS访问带有httpOnly属性的cookie。

(2)注入攻击:

1. SQL注入:在http请求中注入恶意的SQL命令(drop table users;),攻击者要对数据库结构有所了解才能进行攻击。

a. 攻击者了解数据库结构的途径,可进行预防。一般需要注意:

1.开源项目 2.错误回显 3.盲注

b. 预防:

1.消毒:通过正则表达式过滤请求数据中可能注入的SQL。

2.参数绑定

2. OS注入

(3)CSRF攻击:

1. 跨站点请求伪造,攻击者通过跨站点请求,以合法的用户的身份进行非法操作。

2. 核心:是利用了浏览器cookie或者服务器session策略,盗取用户身份。

3. 预防手段:

a. token

b. 验证码

c. Referer check

(4)其他漏洞和攻击:

1. 错误回显

2. HTML注释

3. 文件上传

4. 路径遍历

(5)web应用防火墙:

一些收费或者免费的web应用防火墙产品,如ModSecurity:可以统一拦截请求,过滤恶意参数,自动消毒,添加token,并且能够根据最新的攻击和漏洞情报,不断升级策略,处理掉大多数攻击。

(6)网站安全漏洞扫描:

模拟黑客对网站进行攻击,查漏补缺。

(7)信息加密技术及密钥安全管理

1. 单向散列加密

2. 对称加密

3. 非对称加密

4. 密钥安全管理:

a. 把密钥和算法放在一个独立服务器上

b. 将加密算法放在应用系统中,密钥放在独立的服务器中

(8)信息过滤与反垃圾:

1. 文本匹配

2. 分类算法

3. 黑名单

(9)电子商务风险控制:

1. 风险:

a. 账户风险:账户被盗,恶意注册等

b. 买家风险:买家恶意下单占用库存不正当竞争

c. 卖家风险:不良卖家恶意欺诈的行为

d. 交易风险:盗刷信用卡,支付欺诈,洗钱套现等

2. 风控:

a. 规则引擎:当一些交易满的某些指标满足一定条件时,会被认为具有较高风险的欺诈可能性。

b. 统计模型

总结:

1.所有的网站都是从小到大,从简单到复杂,不要妄想一下就设计出一个大的网站架构,淘宝,阿里,腾讯亦是如此从小到大。

2.不要一味追随大公司的解决方案,只有根据自己本身网站的需求去灵活应对。

3.不要为了技术而技术,一味的追求时髦的新技术可能会将网站引入崎岖小道。

4.驱动网站技术发展的是网站的业务发展,同时业务的发展也促进了新的技术产生。

5.不要企图用技术解决所有的问题,技术是用来解决业务的,而业务的问题也可以通过业务的手段去解决。

这本书最后还有对大型有名网站当初问题案例的分析,无非也是遵循了以上的规则。最后也有对一个“合格”架构师的看法,仁者见仁智者见智,我在这里也就不总结自己的看法了,还是希望大家自己去读一下这本书。