《大型网站技术架构》 读书笔记

第一章

初始阶段：

都在一台服务器上。

应用服务和数据服务分离

应用服务器：更快更强大的CPU

数据库服务器：更快的硬盘、更大的内存

文件服务器：更大的硬盘

使用缓存改善网站性能

二八定律——>把集中访问的一小部分数据缓存在内存中

缺点：单一应用服务器能处理的请求有限。应用服务器是瓶颈

使用应用服务器集群改善网站的并发能力

通过负载均衡调度服务器，把用户请求分发到集群中的任何一台服务器上。

数据库读写分离

写数据时，主数据库通过主从复制机制将数据更新同步到从数据库。

读数据时，就可以通过从数据库获得数据。

读写分离。

使用反向代理和CDN加速网站响应

基本原理都是缓存。

CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据

反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

目的都是尽早返回数据给用户

使用分布式文件系统和分布式数据库系统

使用NoSQL和搜索引擎

非关系型数据库

非数据库查询技术

业务拆分

消息队列

分布式服务

业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度指数级增加

每个应用系统都需要执行许多相同业务操作，比如用户管理、商品管理。

把共用的业务提取出来，独立部署

误区

1. 一味追随大公司的解决方案

2. 为了技术而技术

3. 企图用技术解决所有问题

架构模式

分层

横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责。然后通过上层对下层的依赖和调用组成一个完整的系统。

挑战：必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次调用及逆向调用

分割

纵向方面的切割。把不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高软件的并发处理能力和功能扩展能力。

比如，在应用层，把不同业务如购物、论坛、搜索、广告分割成不同应用，由独立的团队负责，部署在不同的服务器上。

分布式

优点：并发访问

缺点：性能，可用性，一致性

集群

多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务

缓存

将数据存放在距离计算最近的位置以加快处理速度。是改善软件性能的第一手段

现代CPU越来越快的重要因素是使用了更多的缓存

     CDN：内容分发网络。部署在距离终端用户最近的网络服务商。视频网站和门户网站会将用户访问量大的热点内容缓存在CDN

     反向代理：属于前端架构的一部分，当用户请求到达网站的数据中心时，最先访问到的是方向代理服务器，这里缓存网站的静态资源，无需将请求继续转发给应用服务器就能返回给用户。

     本地缓存：应用服务器本地缓存热点数据

     分布式缓存：将数据缓存在一个专门的分布式缓存。

异步

异步是典型的生产者消费者模式，两者不存在直接调用

提高系统可用性，加快网站响应速度，消除并发访问高峰

冗余

冷备份：定期备份，存档保存

热备份：主从分离，实现同步

灾备数据中心

自动化

发布过程自动化

自动化代码管理

自动化测试

自动化安全检测

自动化部署

自动化监控，自动化报警，自动化失效转移，自动化失效回复，自动化降级，自动化分配资源

安全

密码和手机校验码进行身份认证

登录、交易等操作需要对网络通信进行加密

敏感数据如用户信息也进行加密

验证码识别防止机器人程序滥用网络资源攻击网站

对XSS攻击，SQL注入进行编码转换等相应处理

对于垃圾信息，敏感信息进行过滤

对交易转账等重要操作根据交易模式和交易信息进行风险控制

新浪微博

三个层次：

基础服务层，提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础技术服务

中间层是平台服务和应用服务层

API和业务层 各种客户端和第三方应用通过调用API集成到系统中

分布式部署，每个模块都部署在一组独立的服务器集群上。

由于微博频繁刷新，使用多级缓存

热门微博和明星用户的微博缓存在所有的微博服务器上

在线用户的微博和近期微博缓存在分布式缓存集群中

软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计

五个架构要素：

性能

浏览器端：

• 浏览器缓存，页面压缩，合理布局页面，减少cookie传输
• CDN，把网站静态内容分发到用户最近的网络服务商机房，使用户通过最短访问路径获取数据
• 反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力

服务器端：

• 服务器本地缓存和分布式缓存，通过缓存在内存中的热点数据处理用户请求。
• 异步操作将用户请求发送至消息队列等待后续任务处理，而当前请求直接返回响应给用户

高并发请求——>服务器集群来提高处理能力

代码层面：多线程、改善内存管理

数据库服务器端：索引、缓存、SQL优化、NoSQL数据库

衡量性能：响应时间、TPS 每秒事务处理量 - 性能测试的术语介绍  TPS (Transaction Per Second) 每秒钟系统能够处理的交易或事务的数量 、系统性能计数器

可用性

目标：当服务器宕机的时候，服务仍然可用

手段：冗余

应用服务器： 多台应用服务器通过负载均衡设备组成一个集群。服务器宕机时，切换到其他服务器。但是应用服务器上不能保存请求的会话信息

存储服务器：实时备份

软件开发过程：预发布验证、自动化测试、自动化发布、灰度发布 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test 就是一种灰度发布方式，让一部分用户继续用 A，一部分用户开始用 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

伸缩性

伸缩性：通过不断向集群中加入服务器的手段来缓解不断上升的用户并发压力和不断增长的数据存储需求

衡量标准：是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器，加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可以容纳的总的服务器数量是否有限制

应用服务器集群：只要服务器上不保存，所有服务器都对等。

缓存服务器集群：可能会导致缓存路由失效，需要改进缓存路由算法

关系数据库：集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群

NoSQL数据库：对伸缩性支持很好

扩展性

可扩展架构目的：如何设计网站的架构使其能够快速响应需求变化

衡量标准：在网站上增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品之间是否很少耦合，一个产品改动对其他产品无影响

主要手段：

• 事件驱动架构：利用消息队列，把用户请求和其他业务事件构成消息发布到消息队列，把消息产生和消息处理分离开
• 分布式服务：将业务和可复用服务分离开，通过分布式服务框架调用、新增产品可以通过调用可复用的服务实现自身业务逻辑，对现有产品没有影响

还会吸引第三方开发者，调用网站服务

安全性

安全架构：保护网站不受恶意访问攻击，保护网站的重要数据不被窃取

衡量标准：针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略

瞬时响应：网站的高性能架构

用户视角的网站性能：

前端架构优化手段：优化页面HTML式样，利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理

开发人员视角：

关注的是技术指标：响应延迟、系统吞吐量、并发处理能力、系统稳定性

优化手段：使用缓存加速数据读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码用户

运维人员：

关注基础设施性能和资源利用率

优化手段：建设优化骨干网、使用高性价比定制服务器、虚拟化技术优化资源利用

性能测试指标

响应时间：如果测试目标本身只要几微秒，重复请求，测试1w次

并发数：系统能够同时处理请求的数目（抢购并发数过高，服务器挂掉）

吞吐量：单位时间内系统处理的请求数量，体现系统的整体处理能力（系统并发数逐渐增大，系统吞吐量先是增加，到达极限后反而下降，达到崩溃点后，资源耗尽、吞吐量为0）

性能计数器：描述服务器或操作系统性能的一些数据指标。包括系统负载、对象和线程数、内存使用、CPU使用、磁盘与网络I/O。

 性能测试方法

性能测试：验证能否达到性能预期

负载测试：对系统不断增加并发请求以增加系统压力，直到系统的某项或多项指标达到安全临界值

压力测试：超过安全负载后继续加压力，直到崩溃

稳定性测试：运行一段较长时间

a~b是日常运行区间 c点是最大负载点 d点是崩溃点

性能分析：定位影响性能的因素

性能优化：

Web前端性能优化

优化浏览器访问：

     1.减少http请求（合并css、合并js、合并图片）

     2.使用浏览器缓存

     3.启用压缩（在服务器端压缩文件，在浏览器端解压文件）

     4.CSS放在页面最上面，js放在最下面

     5.减少cookie传输（CSS、script等静态资源使用独立域名访问）

CDN加速

CDN（Content Distribute Network，内容分发网络）本质是缓存

网络访问第一跳，最短路径返回响应

一般缓存的是静态资源

反向代理

传统的代理服务在浏览器一侧，代理浏览器发送HTTP请求

反向代理服务器在服务端一侧，代理服务器接受HTTP请求

安全功能

缓存来加速web请求

负载均衡

应用服务器性能优化

分布式缓存

     网站性能优化第一定律：优先考虑使用缓存优化性能

     缓存本质是一个内存Hash表 读写时间复杂度为O（1）          

     二八定律：80%的访问落在20%的数据上，缓存这20%

     缓存可用性

     缓存预热 

     缓存穿透

     分布式缓存架构 JBoss Cache（更新需要通知其他集群）、Memcached(互不通信，适合大型网站）

异步操作

     使用消息队列调用异步化，改善网站的扩展性

     消息队列有削峰作用 eg.电子商务网站促销活动

     （使用消息队列后，需要修改业务，如订单提交后，订单数据写入消息队列，不能立刻返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单，甚至商品出库后，再通知用户，以免交易纠纷）

     任何可以晚点做的事情都应该晚点再做

使用集群

     负载均衡为一个应用构建一个由多台服务器组成的服务器集群

代码优化

    1. 多线程（IO阻塞和多CPU）

     将对象设计为无状态对象（对象本身不存储状态，对象无成员变量或者成员变量也是无状态，如Servlet）  贫血模型：是指领域对象里只有 get 和 set 方法，或者包含少量的 CRUD 方法，所有的业务逻辑都不包含在内而是放在 Business Logic 层。

     使用局部对象：在方法内部创建对象

     并发访问资源时使用锁

     2.资源复用

          单例和对象池

     3.数据结构

     4.垃圾回收

          堆空间分为年轻代（Eden,From,To）

                          老年代

          新建对象总是在Eden区被创建，当Eden区满，触发一次Young GC，把还被使用的复制到From区，这样整个Eden区都是未被使用的空间，可以继续创建，当再次用完，再触发一次Young GC,将Eden和From区还在被使用的对象复制到To区，下一次Young Gc这是讲Eden区和To区还在被使用的复制到from区。经过多次在from和to区复制之后，如果超过阈值还未被释放，复制到Old Generation。如果Old Generation也用完，就会触发Full GC

存储性能优化

机械硬盘VS固态硬盘

机械硬盘：快速顺序读写，慢速随机读写

SSD:没有机械装置，数据存储在可持久记忆的硅晶体上

B+树 vs LSM树

     目前数据库多采用两级索引的B+树

     NoSQL采用LSM树

     LSM树可以看做是一个N阶合并树。数据写操作（包括插入、修改、删除）都在内存中进行，并且都会创建一个新纪录，这些数据在内存中仍然是一棵排序树，当数据量超过设定的内存阈值后，会将这棵排序树和磁盘上最新的排序树合并。当这棵排序树的数据量也超过设定阈值后，和磁盘上下一级的排序树合并

     读操作：先从内存中的排序树开始，找不到，就从磁盘上的排序树顺序查找

     数据更新：不需要磁盘访问，在内存可完成，远快于B+树

RAID vs HDFS

     RAID  传统关系数据库及文件系统

     HDFS（Hadoop分布式文件系统） 服务器集群规模上实现了类似RAID的功能

     HDFS以块为单位管理文件内容，一个文件被分割成若干个Block

     当对文件进行处理计算时，通过MapReduce并发计算任务框架，可以启动多个计算子任务

万无一失：网站的高可用架构

高可用的网站架构

大型网站的分层架构以及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点。高可用性的解决方案也差异甚大

应用层：负载均衡 集群 心跳检测

服务层：集群 被应用层通过分布式服务调用框架访问

数据层： 数据写入时进行同步复制 冗余备份

高可用的应用

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

服务器不保存请求状态，所有的服务器完全对等

负载均衡在应用层起到了高可用的作用。如果需要保证服务高可用，必须至少部署两台服务器，使用负载均衡技术构建一个小型集群。

应用服务器集群的Session管理

     应用服务器的高可用架构主要基于服务无状态这一特性

     但事实上，业务总是有状态

     集群环境下的Session管理：

     1.Session复制：同步session，当集群较大时负担很大，服务器内存不够

     2.Session绑定：负载均衡源地址Hash算法实现。用户的Session绑定在某台特定服务器上，保证Session总能在这台服务器上获取。不满足高可用性

     3.利用cookie纪录Session：把Session纪录在客户端，每次请求服务器时，把Session放在请求中发送给服务器。简单易用，可用性高。

     4.Session 服务器：利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session，都访问Session服务器。状态分离：无状态的应用服务器，有状态的Session服务器

高可用服务策略

分级管理：核心应用优先用好硬件。服务部署上隔离

超时设置：一旦超市，抛出异常

异步调用：消息队列

服务降级：拒绝服务（拒绝低优先级或随机拒绝，避免要死一起死）及关闭服务（关闭部分不重要的，双11时关闭评价，确认收货）

幂等性设计：服务重复调用（eg.重复转账）必须在服务层保证服务重复调用和调用一次产生的结果相同。（通过交易编号等信息进行有效性检验）

高可用的数据

数据备份

失效转移

CAP原理：一个提供数据服务的存储系统无法同时满足数据一致性C、数据可用性A、分区耐受性P这三个条件

大型网站通常选择可用性和伸缩性，某种程度上放弃一致性

2012年双11，存储数据较弱的数据一致性导致部分商品超卖

数据一致性：

     数据强一致：存储总是一致

     数据用户一致：当终端用户访问时，通过纠错和校验，可以确定一个正确的返给用户

     数据最终一致：存储不一定一致，访问得到的也不一定一致，但经过一段时间最终会一致

数据备份

冷备份：定期将数据复制到某种介质上物理归档保存。简单，廉价；不能保证数据最终一致，也不能保证可用性

热备份：异步热备（写入操作不同步，分主从）、同步热备（写入操作同步完成，不分主从） Master-Slave 同步机制 写操作只访问Master，读操作只访问Slave

失效转移

失效确认：心跳检测、应用程序访问失败报告

访问转移：确认宕机后，把数据读写访问重新路由到其他服务器上

数据恢复：从健康的服务器复制数据，将数据副本数目恢复到设定值

高可用性网站的软件质量保证

网站发布：给飞行中的飞机换个引擎。通常使用发布脚本来发布。每次关闭的是集群中的小部分

自动化测试：Web自动化测试技术。Selenium

预发布验证：先发布到预发布服务器上。可能会引入问题

     

代码控制

SVN

1.主干开发，分支发布（不好，AB项目时间不一致，导致不能发布）

2.分支开发，主干发布（主要使用）

Git

对分布式开发，分支开发支持更好

自动化发布

     火车发布模型

灰度发布：将集群服务器分成若干部分，每天只发布一部分。期间如果出现问题，只需要回滚一部分。

网站运行监控

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

监控数据采集

       1.用户行为日志采集

     2.服务器性能监控

     3.运行数据报告

监控管理

     系统报警、失效转移、自动优雅降级

永无止境：网站的伸缩式架构

伸缩性：不需要改变软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力

银行：一开始就订好了规模

小网站到大网站却是渐进式演化

演化中最重要的技术是使用服务器集群

伸缩性设计分为两类，

一类是根据功能进行物理分离实现伸缩（不同的服务器部署不同的服务，提供不同功能）

一类是单一功能通过集群实现伸缩（集群内的多台服务器部署相同的服务，提供相同的功能）

物理分离分为

纵向分离（分层后分离）：把业务处理流程上的不同部分分离部署

横向分离（业务分割后分离）：将不同的业务模块分离部署

随着网站访问量增加，单一服务器不能满足，必须使用服务器集群

应用服务器集群的伸缩性设计

HTTP请求分发装置：负载均衡服务器

负载均衡实现方法：

1.HTTP重定向服务器

根据用户的HTTP请求计算一台真实的Web服务器地址，并将该WEB服务器地址写入HTTP重定向响应中返回给用户浏览器。

优点：简单 缺点：浏览器需要两次请求服务器完成一次访问，性能差，使用HTTP302响应码重定向，可能使搜索引擎判断为SEO作弊，降低搜索排名

2.DNS域名解析负载均衡

在DNS服务器中配置多个A纪录，每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A纪录中配置的多个服务器就构成一个集群，可以实现负载均衡

优点：把负载均衡的功能转交给DNS,省掉了网站管理维护负载均衡服务器的麻烦，许多DNS还支持基于地理位置的域名解析，可以加快访问速度。

缺点：DNS是多级解析，每一级DNS都可能缓存A，当下线某台服务器后，即使修改了DNS的A纪录，要使其生效也需要较长时间，这段时间仍然会将域名解析到已经下线的服务器，导致用户访问失败。

3.反向代理负载均衡

反向代理服务器位于Web服务器前面。反向代理可以提供负载均衡的功能，管理一组web服务器，将请求根据负载均衡算法转发到不同Web服务器上

优点：和反向代理服务器功能集成在一起，部署简单

缺点：反向代理服务器是所有请求和响应的中转站，可能会成为性能瓶颈

4.IP负载均衡

修改数据包的IP地址 发送和返回都要经过负载均衡服务器

优点：在内核进程完成数据分发，比反向代理性能好

缺点：最大响应数据吞吐量受制于负载均衡服务器网卡带宽。对于提供下载服务或视频服务等需要传输大量数据的网站来说，难以满足

5.数据链路层负载均衡（三角传输模式，直接路由方式DR）

在数据链路层修改mac地址进行负载均衡

配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的

不修改IP地址

由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈

目前使用最广。

linux: LVS

负载均衡算法

1.轮询

2.加权轮询 高性能的服务器能分配更多请求

3.随机

4.最少连接 纪录每个应用服务器正在处理的连接数，把新的发送到最少连接的

5.源地址散列 对IP地址进行hash计算。这样来自同一个ip上的总会在一个服务器上处理。可以实现会话黏滞

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

和所有服务器都部署相同应用的应用服务器集群不同

分布式缓存服务器集群中不同服务器中缓存的数据不一样

缓存访问请求不可以在任意一台上处理

必须先找到有合适数据的服务器再访问

设计目标：新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到

Memcached分布式缓存集群访问模型

路由算法很重要

余数Hash

不好。需要扩容时，余数hash会导致读取失败了

分布式缓存一致性Hash算法

一致性Hash环的数据结构。使用二叉查找树实现。

这里没太看懂？？P111

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

对数据的持久性和可用性提出了更高的要求

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

主从读写分离

有些单表很大：淘宝商品数据库。还需要进行分片

支持分片的分布式数据库访问代理：Cobar

NoSQL数据库的伸缩性设计

Apache HBase 

随需应变：网站的可扩展架构

微信摇一摇：2个实习生用一个星期

为什么如此轻易的开发一个新产品-->可扩展性架构设计

扩展性：开闭原则（对扩展开放，对修改关闭）增加新功能时候，不需要改现有系统的结构和代码

伸缩性：利用集群的方式增加服务器数量

构建可扩展的网站架构

核心思想：模块化，降低模块间耦合性，提高模块复用性

分层、分割

分布式部署，独立的模块部署在独立的服务器上，从物理上分离模块之间的耦合关系

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

事件驱动架构（EDA）

通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，借助事件消息的通信完成模块间合作。eg.生产者消费者 实现手段：分布式消息队列

消息队列采用发布-订阅模式

分布式消息队列产品：Apache ActiveMQ

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

把巨无霸拆分

模块独立部署，降低系统耦合性

纵向拆分：把一个大应用拆分为多个小应用

横向拆分：把复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务

Web Service与企业级分布式服务

缺点：臃肿的注册与开发机制，低效的XML序列化手段，开销相对较高的HTTP远程通信，复杂的部署与维护手段

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

分布式服务框架能够支持

负载均衡、失效转移、高效的远程通信、整合异构系统，对应用最少侵入，版本管理 ，实时监控

分布式服务框架设计

开源分布式服务框架：阿里巴巴的Dubbo

服务消费者程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块，也可以是远程的服务，因此对应用较少侵入：应用程序只需要调用服务接口，服务框架根据配置自动调用本地或远程实现。

服务框架客户端模块通过服务注册中心加载服务提供者列表， 查找需要的服务接口，并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败，客户端模块会自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务，实现服务的自动失效转移，保证服务高可用。

可扩展的数据结构

使用支持ColumnFamily结构的NoSQL数据库，创建表的时候，只需要制定ColumnFamily的名字，无需指定字段，可以在数据写入时再指定，通过这种方式，可以包含数百万字段。

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

网站的价值在于为他的用户创造价值

用户却不需要为网站提供的价值而买单

网站必须提供更多的增值服务才能赚钱

QQ:钻石会员

淘宝：出卖商品排名

新浪微博：植入广告

长尾效应，增值服务的数量越大种类越多，盈利也就越多

为了开发更多的增值服务，会把内部服务封装成一些调用接口开放出去，供外部第三方使用。

网站、用户、第三方开发者互相依赖，形成一个网站生态圈

固若金汤：网站的安全架构

XSS攻击

跨站点脚本攻击（Cross Site Script）,黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式

反射型：攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击的目的

持久型：黑客提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击的目的

持久型XSS经常用在论坛，博客

XSS防攻击 主要手段

消毒： 对html危险字符转义 >转义为>等等

HttpOnly： 微 软提出的，浏览器禁止页面js访问带有HttpOnly属性的Cookie,防止XSS窃取Cookie

注入攻击

SQL注入攻击和OS注入攻击

SQL注入攻击：攻击者在http请求中注入恶意的Sql命令，服务器用请求参数构造sql时，恶意sql被一起构造，并在数据库中执行。

SQL注入攻击需要获取数据库表结构，有以下几种：

开源（攻击者直接获得）

错误回显（如果网站开启错误回显，故意构造非法参数，是服务器异常信息输出到浏览器端）

盲注（关闭错误回显后，攻击难度变大）

       防御SQL攻击：

消毒：通过正则匹配，过滤可能注入的SQL

参数绑定：通过预编译手段，绑定参数是最好的防SQL注入方法

CSRF(Cross Site Request Forgery,跨站点请求伪造）

攻击者通过跨站请求，以合法用户的身份进行非法操作，如转账交易，发表评论

核心是利用浏览器Cookie或服务器Session策略，盗取用户身份

CSRF防御手段：

表单Token ： 在请求参数中增加随机数

验证码： 简单有效，但是用户体验差

Referer check : HTTP请求头的Referer域记录请求来源，通过检查来源验证其是否合法。用来图片防盗链

其他攻击和漏洞

Error Code： 错误回显（故意制造非法输入，让系统运行出错，获得异常信息，来寻找系统漏洞攻击）

HTML注释：显示在浏览器，给黑客攻击便利

文件上传：要设置文件白名单，只允许上传可靠的文件类型

路径遍历：攻击者在请求的URL中使用相对路径，遍历系统未开放的目录和文件。防御方法是把js,css等资源文件部署在独立服务器，使用独立域名，其他文件不适用静态URL访问，动态参数不包含文件路径信息

web应用防火墙：ModSecurity

信息加密技术

单向散列加密：不可逆。MD5、SHA 

对称加密：用同一个密钥，可以互相推算。DES算法，RC算法

非对称加密：使用的密钥不同。公钥和私钥。用公钥加密的信息必须用私钥解开，用私钥加密的必须用公钥解开。不可能通过公钥计算获得私钥。用于信息安全传输，数字签名。RSA算法

密钥安全管理

方案1：把密钥和算法放在一个独立的服务器上，对外提供加密和解密服务。成本高，性能差

方案2：将加解密算法放在应用系统中，密钥放在独立服务器中

信息过滤反垃圾手段

文本匹配：敏感词-->***。Trie树，双数组Trie算法：确定一个有限状态自动机，根据输入数据进行状态转移。 双数组：base数组存储Trie树节点，check数组进行状态检查。 或者构造多级Hash表进行文本匹配。可能需要降噪预处理

分类算法：例如判别垃圾邮件。贝叶斯分类算法、增加特征值的关联依赖-->TAN算法。对管理规则聚类挖掘-->ARCS算法。

黑名单：判别垃圾邮件，信息去重。Hash表（列表不是很大时）、布隆过滤器（1/8内存，但是不是很精确）

电子商务风险控制

风险：

账务风险（账户被黑客盗用，恶意注册账号等）、买家风险（买家恶意下单占用库存进行不正当竞争，黄牛利用促销抢购低价商品，良品拒收，欺诈退款）、卖家风险（不良卖家恶意欺诈，出售违禁商品、侵权商品）、交易风险（信用卡盗刷、支付欺诈、洗钱套现）

风控

规则引擎（规则自动判断，高风险人工审核）规则增多会出现规则冲突难以维护

统计模型：大型网站倾向使用。用分类算法或机器学习算法进行智能统计

淘宝架构演化案例分析

2003年，马云家中诞生淘宝网

2004年，拍卖-->一口价交易。php-->java,mysql-->oracle,商品类目开始建立

一开始使用的是LAMP架构

业务发展后，php难以维护，转而使用JAVA

系统架构使用MVC和ORM，自己开发MVC框架（Webx）,ORM框架选择了IBati s

开发了Antx 扩展自ant

应用服务器使用Weblogic，数据库用Oracle, IBM小型机、EMC存储设备。使用了昂贵的付费产品

放弃EJB，引入Spring,用免费的JBoss替代收费的Weblogic

开源产品

网购秒杀系统架构分析

技术挑战：

应对策略

网站典型故障分析

写日志也会引发故障

现象：log输出的level全局配置为debug，消耗完了磁盘空间

教训：应用程序自己的日志输出配置和第三方组件日志输出要分别配置，日志输出级别至少为warn

高并发访问数据库引发的故障

SQL被网站首页调用，频繁执行，数据库load居高不下

教训：首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取， 首页最好是静态的

高并发情况下锁引发的故障

某个单例对象中多处使用了synchronized(this),由于this对象只有一个，所有的并发请求都要排队获得这唯一的一把锁。

缓存引发的故障

疏于管理缓存服务器

应用启动不同步引发的故障

Apache+JBoss时，要先检查JBoss启动好，再启动Apache

大文件读写独占磁盘引发的故障

小文件如图片应该使用专门的服务器，不能和大文件共同存储

不规范的流程引发的故障

本该从分布式缓存读取，工程师开发时候为了测试方便，注释掉了读取缓存的代码

代码提交前使用diff命令进行比较，确认没有提交不该提交的代码

加强codd review

不好的编程习惯引发的故障

空指针判断没做好

架构师领导艺术

关注人而不是产品。坚信一群优秀的人做一件他们热爱的事，一定能取得成功。没有懒惰的员工，只有没被激发出来的激情。所有强迫员工加班的管理者都应该为自己的无能而羞愧。

发掘人的优秀。是事情成就了人，而不是人成就事。指望优秀的人来帮自己成事，不如做成一件事让自己和参与的人都变得优秀。

共享美好蓝图。

共同参与架构。

学会妥协。 不要企图在项目中证明自己的正确的。你是来做软件的，不是来当老大的

成就他人。要想成就自己，必须首先成就他人

网站架构师职场攻略

所谓问题，就是体验-期望，当体验不能满足期望，就会觉得出了问题。

我的问题-->我们的问题

给上司提封闭式问题，给下属提开放式问题。问上司：你觉得A和B两个方案哪个更好？ 问下属：元芳，你怎么看

我非常赞同你的方案，不过我有一个小小的建议……

在解决我的问题之前，先解决你的问题。想推广数据库连接程序包，先改善数据库连接性能和易用性，解决了网站工程师的问题，就容易推广了

适当的逃避问题。我去开个会，我们回来再谈。

按作用划分

设计型架构师  一般意义上的架构师，负责系统架构设计，也要负责架构的实施，落地，演化发展，推广重构

救火型架构师  系统故障或灵异现象

布道型架构师  个人影响力。容易变成忽悠型

Geek型架构师 疯狂偏执，知识技能不够全面

按效果划分

夏尔巴人架构师 开发项目中最具技术难度的模块

斯巴达人架构师 必胜的信念

达官贵人架构师 外表光鲜但没用

按职责角色划分

产品架构师 产品整个生命周期

基础服务架构师 平台架构

基础设施架构师 负责网络、存储、数据库运维管理 如DBA

按关注层次划分架构师

只关注功能的

关注非功能的架构师

关注团队组织与管理的架构师

关注产品运营的

关注产品未来的

按口碑划分

最好的架构师 主心骨

好的架构师 深受信任

一般的架构师  承担大部分技术工作，常常因为团队成员不符合期望大发雷霆

差的架构师 没技术实力也不善于处理人际关系

最差的架构师 制造压力驱使团队成员使大家忙的注意不到他自己其实不能胜任工作

非主流方式划分

普通架构师 

文艺架构师 更前瞻的思考和别出心裁的设计

1+1架构师 设计文档宏大而不着调，面面俱到就是不解决问题

1.前端架构

浏览器优化技术：页面缓存，合并HTTP减少请求次数，使用页面压缩。

CDN：内容分发网络，部署在运营商机房，通过将静态页面内容分发到离用户最近的CDN服务器，使用户可以通过最短路径获取内容。

动静分离，静态资源独立部署：JS、CSS等文件部署在专门的服务器集群上，适用独立二级域名

图片服务：用户上传的图片，同样适用独立部署的图片服务器集群，使用独立二级域名

反向代理：部署在网站机房，在应用服务器，静态资源服务器，图片服务器之前，提供页面缓存服务

DNS：域名服务，把域名解析成IP地址，可以实现DNS负载均衡，配置CDN也需要修改DNS，使域名解析后指向CDN服务器。

2.应用层架构

开发框架

页面渲染

负载均衡

Session管理

动态页面静态化 

业务拆分

虚拟化服务器

3.服务层架构

分布式消息

分布式服务

分布式缓存

分布式配置

4、存储层架构

分布式文件

关系数据库、NoSQL数据库（HBase目前比较好）

数据同步（事务日志同步，根据Log进行数据重演）

5、后台架构

搜索引擎

数据仓库

推荐系统

6、数据采集与监控

浏览器数据采集（嵌入JS脚本）

服务器业务数据采集（用户请求操作日志，运行期业务数据）

服务器性能数据采集（系统负载，内存使用率、网卡流量）

系统监控

系统报警

7、 安全架构

web攻击

数据保护

8、数据中心机房架构

机房架构 散热良好、供电充裕

机柜架构

服务器架构

Web开发技术发展历程

早期：服务器简单响应浏览器请求，返回静态HTML

CGI（通用网关借口）出现后，服务端可以产生动态页面内容 编程语言是Perl

但是CGI业务代码和页面语法耦合在一起

PHP及ASP、JSP 服务器页面模式 擅长构造响应页面

结合起来：MVC模式

一切刚刚开始，你我正逢其时。