读书笔记《大型网站技术架构核心原理与案例》-李智慧

花时间读了前阿里巴巴人称教授的李智慧老师的《大型网站技术架构和心原理与案例》一书，将笔记记录在此，有需要原作的可私信

一.发展

1.应用服务器和数据服务器分离
2.使用缓存
3.应用服务器集群改善并发
4.数据读写分离-master数据库写》同步到slave》从slave读
5.反向代理和cdn（内容分发网络）
6.分布式文件系统和数据库系统（nosql数据库和搜索引擎）
7.业务拆分

二.架构模式

2.1模式
2.1.1分层，横向，逻辑和物理的层（应用层，服务层，数据层），禁止跨层调用
2.1.2分割，即纵向分离
2.1.3分布式，a. 优点：分布式意味着使用更多的计算机完成同样的功能，计算资源越多，性能就越大b. 缺点：ⅰ. 通过网络调用，网络可能会成为瓶颈ⅱ. 服务器越多，故障的概率越大ⅲ. 事务，数据一致性难保证，影响业务正确性和流程ⅳ. 依赖复杂维护成本大c. 常用分布式方案：a.分布式应用和服务b.分布式静态资源c.分布式数据和存储d.分布式计算e.分布式配置，分布式锁，分布式文件
2.1.4集群，多台服务器部署相同的服务，通过负载均很共同对外提供服务，提高并发
2.1.5缓存，CDN，反向代理，本地缓存，分布式缓存
2.1.6异步
2.1.7冗余
2.1.8自动化，发布过程自动化，自动化代码管理，自动化测试。自动化部署，自动化监控，自动化运维
2.1.9安全

2.2新浪架构
基本架构图：

三.核心要素

3.1.性能，架构和代码优化
3.2.可用性，冗余，一台或多台宕机，系统依旧可用
3.3.伸缩性，可以不断添加集群中的节点来缓解业务上升的压力
3.4.扩展性，增加新业务不影响现有的业务
1. 消息队列，只需产生新的消息topic和可消费新topic的消费者
2. 分布式，服用和服务调用
3.5.安全性

四.网站性能

4.1.网站性能

4.1.1.前端性能优化，html页面式样优化，浏览器并发和异步，调整缓存策略，CDN服务，反向代理，
4.1.2.应用层，响应延迟，吞吐量，并发，稳定性，使用缓存，使用集群，异步消息
4.1.3.性能指标：
ⅰ. 响应时间
ⅱ. 并发数
ⅲ. 吞吐量
ⅳ. 负载，线程数，内存，cpu，I/O

4.2.前端性能优化

4.2.1.浏览器访问优化ⅰ. 减少http请求，合并CSS，合并javascript，图片减少http请求，合并CSS，合并javascript，图片ⅱ. 使用缓存ⅲ. 压缩ⅳ. css放在最上面，javascript放在最下面ⅴ. 减少cookie
4.2.2.CDN加速
4.2.3.反向代理

4.3.服务器优化

4.3.1. 分布式缓存1.原理：hash表，k-v对2.合理使用a.读写比2:1b.热点数据c.数据不一致，脏读d.缓存雪崩，缓存过期或缓存不可用，导致数据库压力增大，数据库服务器宕机e.缓存预热，重建缓存时系统和数据库负载都会增大，此时需要预热f.缓存穿透，将不存在的数据保存value为null3.分布式缓存架构a.JBoss cache，所有缓存的集群保持同步，消耗大，多用于企业网站b.memcached互不通信

4.3.2.异步操作

消息队列削峰

4.3.3.使用集群

分担负载

4.3.4.代码优化

ⅰ. 多线程

• 将对象设为无状态
• 使用局部变量
• 并发时使用锁的机制ⅱ. 资源复用，单例（全局只有一个类的实例）和对象池（数据库链接资源，http链接，线程，复杂对象）ⅲ. 优化数据结构ⅳ. 优化垃圾回收

4.4.存储性能优化

4.4.1机械硬盘，固态硬盘
4.4.2

五.高可用架构

5.1可用性的度量与考核1.可用性计算：故障时间=修复时间-发现事件网站年度可用性指标=（1-不可用时间/年度总时间）×100%2.可用性考核：故障分=故障时间（分钟）×故障权重权重：事故级----严重故障，整体不可用----100%A类    ----访问不顺畅，核心功能不可用----20%B类    ----次要功能不可用，核心功能部分用户不可用----5%C类    ----其他故障----1%

5.2高可用架构

冗余备份和失效转移

5.3高可用的应用

不保存业务的上下文，多个集群之间对等，处理结果一致

5.3.1通过负载均衡进行无状态服务和失效转移

负载均衡服务器通过心跳检测集群状态，不响应则从服务器列表删除，失效立即转移服务

5.3.2应用服务器集群的session管理

web应用将多次请求修改使用的上下文对象陈祚seeeion会话，管理方式如下：1.session复制，session同步，使用集群少的网站2.session绑定，同意来源的ip请求发送到同一服务器，服务器可能宕机，可用性不高3.利用cookie记录session，cookie存在客户端，访问时将session带在cookie发送给服务器4.部署session服务器统一管理session，将无状态的应用服务器和有状态的session服务器分离，应用服        务器通过访问session服务器读写session

5.4高可用的服务

5.4.1分级管理，核心业务部署在性能好的服务器
5.4.2超时设置
5.4.3异步调用
5.4.4服务降级，高并发时拒绝和关闭低优先级的服务，保证核心服务顺畅
5.4.5幂等性设计（如一些业务需要多次调用同一接口返回数据一致）

5.5高可用的数据

方法：数据备份和失效转移，同时缓存服务也要保证同样的高可用性

5.5.1CAP原理，（即数据的可用性，数据的一致性，数据的分区耐受性）

1. 数据的持久性----数据不丢失
2. 数据的可访问性----一个存储节点不可用时可以快速切换到另一个节点
3. 数据的一致性----多个副本之间数据同步
这三个特性很难同时满足，一般选择可用性和扩展性，放弃一致性
数据一致性范围一下几点：a. 数据强一致性----物理存储中一定时一致的（如passport问题）b. 数据用户一致----物理存储中可能不一致，但通过纠错和校验，最终返回给用户是一致的c. 数据最终一致----不保证物理存储和用户数据的一致，而是经过一段时间系统的自我回复和修正

5.5.2数据备份（冷备份和热备份）

冷备----备份到物理存储
热备----异步热备和同步热备
异步：应用服务器只链接主存储（master）主存储写入从存储（slave）
同步：应用服务器同时将多份副本写入多个存储节点，没有主从之分（并发写入保证性能）
关系型数据库的热备就是通常所说的master-slave同步机制，不但可以解决数据备份，还能改善性能，采用读写分离，写操作访问master，读操作访问slave

5.5.3失效转移（集群中若出现服务器宕机，针对这个节点的访问重新路由到其他节点，保证数据访问不会失败）

1.失效确认---心跳检测
2.访问转移
3.数据恢复

5.6高可用网站的质量保证

1. 网站发布通过脚本发布，对用户的影响减小到最少，过程如下关闭负载均衡服务器上的部分服务器路由--》关闭这些服务--》同步代码--》启动这些服务器--》打开负载上的路               由，重复次过程直到所有节点都部署
2. 自动化测试
3. 预发布验证将代码部署到专门的预发布服务器，预发布服务器与生产环境的物理环境一致
4. 代码控制主线（trunk），分支（branch）
5. 自动化发布脚本执行，减少认为干预
6. 灰度发布先将代码部署到一部分服务器，有问题回滚快
7. 运行监控

7.1数据采集

a.用户行为日志收集i.服务端日志收集ii.浏览器日志收集
b.服务器性能监控
c.运行数据报告

7.2监控管理

 a.系统报警b.失效转移c.自动优雅降级

六.伸缩性架构

不需要改变网站的软硬件设计，通过改变部署服务器数量改变服务器的处理能力，
技术上做到向服务器增加服务器的数量和集群的处理能力形成线性关系，就可以不断提升网站规模

6.1伸缩性架构的设计

1. 不同功能实现物理分离
2. 单一功能通过集群实现伸缩
3.

6.2应用服务器集群的伸缩性设计，一般通过负载均衡实现

 1.  http重定向• 优点：实现简单• 缺点：需要两次访问2. DNS域名解析• 优点：DNS可以实现就近访问• 缺点：多级解析，上下线生效时间长；控制权在域名服务商那里3 反向代理配置在服务器端，提供对外服务的接口，接收到请求后，通过负载均衡算法将请求发送给目标服务器，获得响应数据再返回给前端• 优点：部署简单• 缺点：请求的中转站，性能会影响整个系统的响应4. Ip负载均衡在内核完成数据的分发，负载均衡服务器修改目标ip，不需要用户再次发送请求• 优点：处理性能好• 缺点：吞吐量会成为系统的瓶颈5. 数据链路层负载均衡在通信协议是数据链路修改Mac，负载均衡服务器与目标服务器的ip一致，响应结果由目标服务器直接返回给前端，• 优点：没有瓶颈• 缺点：6. 负载均衡算法：*轮询RR----依次分发*加权轮询WRR----轮询基础上加权重*随机random----随机分发*最少连接least connections----优先分发到目前连接数最少的服务器上*源地址散列source hashing----同一来源分发到同一服务器

6.3分布式缓存集群的伸缩性设计

1.列表计算
2.余数hash
3.一致性hash--hash环（将集群的节点放入环中，计算key的hash，顺时针找到环中最近的节点），增加节点只影响环的一段

6.4数据存储服务器的集群伸缩性设计

6.4.1.关系型数据库的可伸缩设计

• 关系型数据库，主从复制，主服务器只写入，从服务器只读取，实现读写分离，只需新增从服务器优点：数据一致性强，可以保证读写的性能，
• 分库，分表，分片，不同的业务部署在不同的数据库集群优点：解耦，各业务数据互不影响，缺点：不能跨库进行join操作
• 主从复制和分片结合，适用于数据量大的业务cobar的模型：sql请求如select *from user where id in (12,22,23),路由模块根据排至规则分解sql为：select *from        user where id in (12,22)和select *from user where id =23，分别提交给奇偶两个库查询，再将查询结果合并后返回
cobar以schema为单位，通过mysql的数据迁移功能实现集群的新增，迁移完成后更新路由服务器的配置

6.4.2非关系型数据库的可伸缩设计

非关系型数据库放弃了以关系代数为基础的结构化查询语言（SQL）和事务一致性（ACID），
强化了高可用性和伸缩性
当一个Hregion写入的数据达到一个阈值后，HRgion分裂，已达到负载均衡和可伸缩性
七.可扩展性网站架构设计扩展性：在不影响现有框架下可以增加新的功能（增加新功能）
伸缩性：不改变现有框架，服务器数量和集群一提高系统的处理能力（提高处理能力）

7.1构建可扩展的网站架构

$低耦合低耦合是衡量一个系统优劣的尺度，优秀的架构师在于将一个大型的系统分割成横向的业务模块，纵向的基础计数模块，核心思想是模块化，解耦，提高复用。分层，分割的思想也可用于可扩展性设计，
$解耦--》聚合通过消息传递和调用的方式将独立解耦的模块聚合成一个完整的系统，分布式部署后还可以通过分布式消息队列和分布式服务聚合
优点：扩展性强，模块容易复用，开发维护容易，

7.2利用分布式消息队列降低系统耦合性

1.事件驱动架构EDA通过在模块之间传递事件消息，保持模块之间的松散耦合，并借助事件的通信完成模块间合作，即生产者-消费之模式，常见的是分布式消息队列，消息队列利用发布-订阅模式工作，生产者将消息发送到队列，接收这从队列获取订阅的消息并处理，生产者和消费者之间是解耦和的，只有订阅和取消订阅的关系，以此实现扩展
消息队列优点：具有很好的响应延迟，可以根据自身的负载能力处理读取队列，减轻数据库等后端的压力2.分布式消息队列分布式消息队列的特点：分布式消息队列的伸缩性：消息队列服务器上的数据可以看做是被即时处理的，将新的服务器加入到消息队列集群中。通知生产者更改消息队列服务器列表即可分布式消息队列的可用性：消息队列服务器内存写满后可以写到磁盘，消息保留到消息被处理之后再删除，检测到集群中一台服务器宕机，将消息发送到其他服务器也可以用mysq当做分布式消息队列，生产者将消息当做数据写入数据库，消费者通过select查询并按时间排序获取消息，有成熟的mysql运维手段，可以很好的达到要求。

7.3利用分布式服务打造可复用的业务平台

 *分布式服务通过接口分解系统的耦合性，不同子系统通过相同的接口描述进行服务的调用*业务拆分：1纵向拆分：梳理业务，相关性少的业务进行剥离，将一个大的应用拆分成多个小应用，2横向拆分：将复用的业务拆分出来，独立部署，新增的业务只需调用这个服务，

7.3.1Web-service与企业级分布式服务

难以满足大型网站对系统高可用，高性能，易部署，易维护的要求

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

 • 负载均衡• 失效转移• 高效的远程通信• 整合异构系统，网站服务需要整合不同开发语言和不同部署平台的异构系统• 对应用最少的侵入，服务模块支持分布式部署，也要支持集中式部署• 版本管理，分布式框架需要支持服务多版本发布，即提供新接口的版本服务，也支持旧接口的版本服务• 实时监控

7.3.3分布式服务框架设计

 facebook利用thrift管理分布式服务（跨语言的rpc服框架）阿里巴巴采用Dubbo管理Dubbo架构：DUbbo远程通信模块使用NIO通信框架附：NIO和IO到底有什么区别？有什么关系？首先说一下核心区别：ⅰ. NIO是以块的方式处理数据，但是IO是以最基础的字节流的形式去写入和读出的。所以在效率上的话，肯定是NIO效率比IO效率会高出很多。ⅱ. NIO不在是和IO一样用OutputStream和InputStream 输入流的形式来进行处理数据的，但是又是基于这种流的形式，而是采用了通道和缓冲区的形式来进行处理数据的。ⅲ. 还有一点就是NIO的通道是可以双向的，但是IO中的流只能是单向的。ⅳ. 还有就是NIO的缓冲区（其实也就是一个字节数组）还可以进行分片，可以建立只读缓冲区、直接缓冲区和间接缓冲区，只读缓冲区很明显就是字面意思，直接缓冲区是为加快 I/O 速度，而以一种特殊的方式分配其内存的缓冲区。ⅴ. 补充一点：NIO比传统的BIO核心区别就是，NIO采用的是多路复用的IO模型，普通的IO用的是阻塞的IO模型，两个之间的效率肯定是多路复用效率更高

7.4可扩展的数据结构

 • 关系型数据库：设计之初考虑留出将来需要的字段• 非关系型数据库：如google的bigtable，使用Columnfamily设计，设计时只需指定Columnfamily的名称，column可以随意扩展

7.5利用开放平台建设网站生态圈

 开放平台：大型网站为了更好的服务自己的用户，开发更多的增值服务，把网站内部的服务封装成调用接口开       放，供给外部发第三方开发者使用，这个提供开放接口的平台称为开放平台开放式平台的基础架构：×API接口：对外提供服务的一组接口，可以是rest，webservice，rpc等×协议转换：数据格式化，封装×安全：身份识别，权限控制，（token），分级访问等×审计：记录访问情况，监控，计费等×路由：将访问路由映射到具体的内部服务×流程：将分散的服务组成包含上下文的服务，隐藏细节，提供接口

八网站的安全架构

8.1网站应用的攻击与防御

8.1.1XSS攻击，

 cross site script跨站点脚本攻击，通过篡改网页，注入恶意脚本攻击• 反射型：诱使用户点击达到攻击目的• 持久型：提交含有恶意的脚本请求，保存在目标的web站点数据库，达到攻击防御XSS攻击：1.对危险字符转义，如“>”<"转义为“&gt”“&lt”等，即可防御部分xss攻击2.设置httpOnly属性禁止javescript访问带有httponly属性的cookie，避免窃取cookie敏感信息

8.1.2注入攻击

1.SQL注入：在http请求中注入恶意sql命令，一般有一下几种方式了解目标的数据结构：• 开源软件：开源软件暴露数据结构• 错误回显：通过返回错误判断• 盲注：根据页面变化判断sql执行情况进行猜测防御SQL注入：• 正则匹配过滤sql语句中可能的恶意命令，如drop，delete等• 参数绑定，预编译，将注入的sql语句当做参数而非sql命令执行
2.OS注入：注入OS代码，利用程序漏洞攻击

8.1.3CSRF攻击

跨站点请求伪造：用户登录网站A，浏览器保存网站A返回occkie信息，
用户打开网站B，B盗取浏览器cookie信息登录网站A防御CSRF：
• 表单token，校验token辨别用户身份
• 验证码
• 验证referer，验证来源是否合法

8.1.4其他攻击

 error code，防御：业务错误码统一，不透传HTML注释，防御：代码review，自动扫描文件上传，防御：白名单，审核，修改文件名，专门存储路径遍历，防御：资源文件部署在独立服务器，使用独立域名，不使用静态url（不带参数的url）访问，参数不包含文件路径信息

8.1.5web应用防火墙

modsecurity开源web应用防火墙

8.1.6网站安全漏洞扫描

模拟黑客，发现网站安全漏洞

8.2信息加密技术和秘钥安全管理

 敏感数据加密处理，加密方法：
散列加密，对称加密，非对称加密

8.2.1单项散列加密

通过对不同输入长度的信息进行散列加盐计算得到固定长度的的输出，如MD5，SHA算法

8.2.2对称加密

加密和解密使用的同一个秘钥，如DES算法，RC算法

8.2.3非对称加密

公钥加密，私钥解密，如RSA算法

8.2.4秘钥安全管理

• 将秘钥和加密算法放在独立的服务器，应用通过调用这个服务实现加解密
• 将加解密算法放在应用系统中，秘钥放在单独的服务器中，存储时秘钥切分成片，分别保存

8.3信息过滤和反垃圾

8.3.1文本匹配

敏感词过滤：正则过滤，Trie树匹配如上Trie树包含{inn，int，tea，ten，to}有时候为了绕过检查，某些信息会被加干扰信息如“阿_拉_伯”，还需要做降噪处理，然后进行匹配

8.3.2分类算法

 为了识别垃圾信息，广告，对内容进行进行审核，需要分类算法贝叶斯分类算法：如，对邮件进行分析，提取到含有“茶叶”的20%时垃圾邮件，1%不是垃圾邮件，得到分类模型，以“茶叶”作为特征对邮件进行分类

8.3.3黑名单

布隆过滤器

8.4电子商务风险控制

8.4.1电子商务风险

• 账户风险：账户被盗，恶意注册帐户等
• 买家风险：恶意下单占用库存，
• 卖家风险
• 交易风险

8.4.2风控

自动审核，人工审核1.规则引擎：如用户来自欺诈高发区，交易金额过大，和上次登录距离大，登录与收货地不同等等，网站一般用规则引擎处理此类问题，规则引擎时一种将业务规则和处理逻辑相互分离的技术，业务规则有运营人员通过管理界面编辑，而规则处理逻辑则调用规则处理输入的数缺点：随着规则增加，可能出现规则冲突，难以维护，性能差
2.统计模型：统计模型使用分类算法或机器学习算法进行智能统计，根据历史交易中的欺诈交易训练分类算法，

---------------------------------------------------The End------------------------------------------------------

读书笔记《大型网站技术架构核心原理与案例》-李智慧相关推荐

读书笔记：大型网站技术架构-核心原理与案例分析
李智慧<大型网站技术架构-核心原理与案例分析> 性能可用性伸缩性扩展性安全性总结这本书组织的很不错,语言精练,篇幅也不长,对网站架构的要点讲的狠清楚透彻,思路清晰.主要围绕架构 ...
读书笔记之大型网站技术架构(核心原理与案例分析)
前言坚持看了十几天的书,终于完成了毕业后第一次静下心来,利用业务时间看书并做笔记的成就了.废话不多说,这回看的是一直很膜拜的李智慧大神写的大型网站技术架构-核心原理与案例分析. 简短的读后感极其推 ...
大型网站技术架构核心原理与案例分析学习笔记（理论篇）
大型网站软件系统的特点高并发.大流量高可用海量数据用户分布广泛,网络情况复杂安全环境恶劣需求快速变更,发布频繁渐进式发展大型网站架构演化发展历程所有资源在一台服务器上,使用免费开源的 ...
大型网站技术架构核心原理与案例分析学习笔记（实践篇）
Wikipedia性能优化策略前端性能优化 80%以上的用户请求可以通过前端服务返回 CDN缓存的几条准则: 内容页面不包含动态信息,以免页面内容缓存很快失效或者包含过时信息每个内容页面有唯一的R ...
大型网站技术架构:核心原理与案例分析 mobi_阿里面试官：你会高并发技术吗？...
前言据有关数据统计,无论是游戏行业还是互联网行业,无论是软件开发公司还是大型网站,都对高并发技术人才有着巨大的需求.因此,无论为了是面试还是为了工作,学习高并发技术刻不容缓. 当然,高并发相关岗位的 ...
大型网站架构模式【大型网站技术架构.核心原理与案例分析】(阅读分享)
这本书分几个章节,其中有一个值得和大家分享的技术知识. 大型网站架构模式中引入了模式概念:每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心.这样,你就能一次又一次地使用该方案而不 ...
读《大型网站技术架构核心原理与案例分析+李智慧-高清》有感
其实作为一个刚入职场的小白(今年才毕业),对于java的领域一开始我是特别喜欢.从一开始的学习ssm框架培训,到现在真正的去公司参加项目.目前为止我进公司快一个月了,先从写测试类开始,用的是testn ...
【撸码师读书笔记】大型网站技术架构——核心原理与案例分析
2019独角兽企业重金招聘Python工程师标准>>> 合理的预估系统的瓶颈及制定有效伸缩性架构预案: 架构设计应从性能,可用性,伸缩性,扩展性及安全这五个要素方面出发: 与传统企业 ...
大型网站技术架构:核心原理与案例分析 mobi_大数据技术经典学习路线
如果你看完有信心能坚持学习的话,那就当下开始行动吧! 点击链接加入群聊[大数据学习交流群]:想要在大数据这个领域汲取养分,让自己壮大成长.分享方向,行动以前先分享下一个大数据交流分享资源,欢迎想学习, ...
把书读薄:大型网站技术架构-核心原理与案例分析(第四篇架构师)
14 架构师领导艺术职能:架构设计,软件开发,管理职能(规划产品,估算人力资源,估算时间资源,安排人员职责分工,确定计划里程碑,指导工程师工作,过程风险评估与控制). 是工程师的榜样,要做好表率. ...

读书笔记《大型网站技术架构核心原理与案例》-李智慧

读书笔记《大型网站技术架构核心原理与案例》-李智慧相关推荐

最新文章

热门文章