2025年高性能网站架构设计与优化攻略

七、网站的安全架构-固若金汤

1.XSS袭击

XSS袭击即跨站点脚本袭击(CrossSiteSeript)指黑客通过篡改网页，注入恶意HTM

L脚本，在顾客访问网页时，控制顾客浏览器进行恶意操作的一种袭击方式。

常见的XSS袭击类型有两种，一种是反射型，袭击者诱使顽客点击一种嵌入恶意脚本的链接，到

达袭击的目的(盗取顾客Cookie、密码来伪造交易、盗窃顾客财产等)。另一种XSS袭击是持久型

XSS袭击，黑客提交具有恶意脚本的祈求，保留在被袭击的Web站点的数据库中，顾客浏览网页时恶

意脚本被包括在正常页面中，到达袭击的目的。

(1)消毒

对某些html字符转义如">"转义为">"等。

(2)HttpOnly

即浏览器严禁页面JavaScript访问带有HttpOnly属性的Cookie,可通过对Cookie

添加HttpOnly属性防止被袭击者运用Cookie获取顾客皆息。

2.注入袭击

注入袭击重要有两种形式，SQL注入袭击和OS注入袭击。SQL注入袭击的原理如下图所示。

袭击者在HTTP祈求中注入恶意的SQL命令，服务器用祈求构造数据库SQL命令时，恶意SQL被

一起构造,并在数据库中运行。

袭击者获取数据库表构造信息的手段有如下几种：

(1)开源,假如网站采用开源软件搭建，那么网站数据库就是公开的；

(2)错误回显，假如网站启动了错误回显，即服务器内部500错误会显示到浏览器上，袭击者可以通过

故意构造非法数据，使服务器异常信息输出到浏览器端，为袭击猜测数据库表构造提供了便利；

(3)盲注，袭击者根据页面变化状况判断SQL语句的执行状况来猜测数据库表构造；

除了SQL注入，袭击者还根据详细应用，注入OS命令、编程语言代码等到达袭击目的。

防御措施：

(1)消毒

和防XSS袭击同样，过虑祈求数据中也许注入的SQL,如'dr。ptable"等。此外还可以运用参

数绑定来防止SQL注入。

(2)参数绑定

使用参数绑定是最佳的防SQL注入措施。目前请多数据层访问框架，如MyBatis、Hibernat

e者映现了SQL预编译和参数绑定，袭击者的恶意SQL会被当做SQL的参数而不是SQL命令插

入。

3.CSRF袭击

CSRF即CrossSiteRequestForgery(跨站点祈求伪造)，袭击者通过跨站点祈求，以合

法顾客的身份进行非法操作。CSRF的重要手段是运用跨站祈求，在顾客不知情的状况下，以顾客的

身份伪造祈求。其关键是运用了浏览器C。。kie或服务器Session方略，盗取顾客身份。

CSRF的防御手段重要是识别祈求者身份：

(1)表单Toke

CSRF是一种伪造顾客祈求的操作，因此需要构造顾客祈求的所有参数才可以，表单T。ken通

过在祈求参数中增长随机数的措施来组织袭击者获取所有祈求参数。

(2)验证码

愈加简朴高效，即祈求提交时，需要顾客输入验证码，以防止在顾客不知情的状况下被袭击者伪造祈

求。

(3)RefererCheck

HTTP祈求头的Referer域中记录着祈求来源，可通过检查祈求来源，验证其与否合法,还可以

运用这个功能来实现突破防盗链。

4.其他袭击和漏洞

(1)ErrorCode(错误回显)：获取异常信息进行袭击。

通过配置Web服务器参数国纸500页面到专门的错误页面。

(2)HTML注释,HTML注释会显示在客户端浏览器中。

(3)文献上传，上传病毒文献.

设置上传白名单，只容许上传可靠的文献类型。还可以修改文献名、使用专门的存储等。

(4)途径遍历，在URL中使用相对途径，遍历系统未开放的目录和文献。

防御措施是将JS、CSS等资源布署在独立服务器、使用独立域名，其他文献不使用静态URL访

问。

5.WEB应用防火墙

ModSecurity是一种开源的Web应用防火墙(拦截祈求、过滤恶意参数，自动消毒、添加T

oken),探测袭击并保护Web应用程序，既可以嵌入到Web应用服务器中，也可以作为一种独

立的应用程序启动。ModSecurity最早只是Apache的一种模块，目前已经有Java、NET多

种版本，并支持Nginx。

ModSecurity采用处理逻辑与袭击规则集合分离的架构模式。处理逻辑(执行引擎)负载祈求

和对应的拦截过滤，规则加载执行等功能。而袭击规则集合则负责描述对详细袭击的规则定义、模式

识别、防御方略等功能。处理逻辑比较稳定，规则集合需要不停针对漏洞进行升级，这是一种可扩

展的架构设计。

6.信息加密技术

为了保护网站的敏感数据，应用需要对某些数据进行加密处理。

(1)单向散列加密(MD5、SHA)

给散列算法加点盐(sa1t)增长破解难度。

(2)对称加密(DES)

(3)非对称加密(RSA)

非对称加密使用的加密和解密不是同一密钥，其中一种对外界公开，被成为公钥，另一种只有所有者

懂得,被称作私钥。用公钥加密的信息必须用私钥才能解开，反之，用私钥加密的信息只有用公钥才

能解开。

数字签名的过程则相反，签名者用自己的私钥对信息进行加密，然后发送给对方接受者用签名者

的公钥信息进行解密，获得原始明文信息，由于秘钥只有签名者拥有，因此该信息是不可抵赖的，

具有签名的性质。

HTTPS传播中浏览器使用的数字证书实质上是通过权威机构认证的非对称加密的公钥。

(4)密钥安全管理

把密钥和算法放在一种独立的服务器上，甚至做成一种专用的硬件设施，对外提供加密和解密服

务。但这种方式成本较高，并且有也许成为应用的瓶颈，每次加密、解密都需要进行一次远程服务

调用，系统件能开销也较大.

另一种方案是将加解密算法放在应用系统中，密钥则放在独立的服务器中，为了提高密钥的安全

性，实际存储时，密钥被切提成数片,加密后保留在不一样存储介质中。

7.信息过滤与反垃圾

(1)文本匹配

重要处理敏感词过滤的问题，通过Trie树、多级Hash表进行文本匹配。

(2)分类算法

重要处理识别垃圾信息，分类算法先将批量已分类的邮件样本(5000正常，垃圾)输入分类算法

进行训练彳导到一种垃圾邮件分类模型，然后运用分类算法结合分类模型看待处理出险的进行识别。

如贝叶斯分类算法，如“茶叶”出目前垃圾邮件中的概率为20%,出目前正常邮件的概率为1%,就得

到了这个分类模型,会存在误判和漏判。

(3)黑名单

8.电子商务风险控制

账户风险:账户被盗、恶意注册等；

买家风险：恶意下单占用库存，良品拒收，欺诈退款等；

卖家风睑：货不对板、虚假发货、炒作信用、发售违禁品、侵权产品；

交易风险:盗刷卡、洗钱等

Q)风控

规则引擎:当交易的某些指标满足一定条件时，就会被认为具有高风险的欺诈也许性。例如顾客来

自欺诈高发地区；交易金额超过某个数量，和上次登陆的地址8目离差距很大，顾客登陆地与收货地不

符,顾客第一次交易等。

(2)记录模型

根据历史交易中的欺诈交易信息训练分类算法，然后将通过采集加工后的交易信息输入分类算法,

即可得到交易风险分值。

八、网购秒杀系统架构设计案例分析

1.秒杀活动的技术挑战

(1)对既有网站业务导致冲击

秒杀活动只是网站营销的一种附加活动，特点是:时间短、并发访问量大，假如和网站原有应用布署

在一起，必然会对既有业务导致冲击。稍有不慎也许导致整个网站瘫痪。

(2)高并发下的应用、数据库负载

顾客在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些祈求假如按照一般的网站应

用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器导致负载压力。

(3)忽然增长的网络及服务器带宽

假设商品页面大小200K(重要是商品图片大小)，10000个祈求的带宽就是2G。

(4)直接下单

秒杀的游戏规则是到了秒杀才能开始对商品下单购置，在此时间点之前，只能浏览商品信息，不能下

单。而下单页面也是一种一股的URL,(触口得到这个URL,不用等到秒杀开始就可如下单了。

2.秒杀系统的应对方略

(1)秒杀系统独立布署

将秒杀系统独立布署，甚至使用独立域名，使其与网站完全隔离。虽然秒杀系统瓦解也不会对网站导

致停可影响。

(2)秒杀商品页面静态化

重新设计秒杀商品页面，不使用网站本来的商品详细页面，页面内容静态化(将商品描述、商品

参数、成效记录和顾客评价所有写入一种静态页面)，顾客祈求不需要通过应用服务器的业务逻辑

处理，也不需要访问数据库。因此秒杀商品服务不需要布署动态的Web服

务器和数据库服务器。

(3)租借秒杀活动网络带宽

由于秒杀新增的网络带宽，必须和运行商重新购置或者租借。为了减轻网站服务器的压力，需要

将秒杀商品页面缓存在CDN,同样需要和CDN服务商临时租借新增的出口带宽。

(4)动态生成随机下单页面URL

为了防止顾客直接访问下单页面URL,需要将改URL动态化，虽然秒杀系统的开发者也无法在秒

杀开始前访问下单页面的URL。措施是在下单页面URL加入由服务器端生成的随机数作为参数在

秒杀开始的时候才能导到。

3.秒杀系统架构设计

(1)怎样控制秒杀商品页面购置按钮的点亮

购置按钮只有在活动开始的时候才能点亮，在此之前是灰色的。假如是动态页面，可以很轻易处理

这个问题，但为了减轻服务器负载压力，该页面设计为静态页面，缓存在CDN、反向代型艮务器

上，甚至顾客浏览器上。秒杀开始时,顾客刷新页面，祈求主线不会抵达应用服务器。

处理方案是使用JavaScript脚本控制，在秒杀商品静态页面中加入一种JavaScript文献

引用，该JavaScript文献中加入秒杀与否开始的标志和下单页面URL的随机数参数，当秒杀开始

的时候生成一种新的JavaScript文献并被顾客浏览器加载，控制秒杀商品页面的展示。这个

JavaScript文献使用随机版本号，并且不被浏览器、CDN和反向代理服务器缓存。这个JS文献非

常小，虽然每次器刷新都访问JS文献服务器也不会对服务器集群和网络带宽导致太大压力.

A

(2)怎样只容许第一种提交的订单被发送到订单子系统

由于最终可以成功秒杀到商品的顾客只有一种，因此需要在顾客提交订单时，检有与否已经有订单

提交。

为了减轻下单页面服务器的负载压力，可以控制进入下单页面的入口，只有少数顾客能进入下

单页面，其他顾客直接返回秒杀结束页面。

活动开始：

祈求发送至下单服务器；

下单服务器检直本机已处理的下单祈求数目；

假如超过10条，直接返回已结束页面给顾客。假如未超过10条，则顾客可进入填写订单

及确认页面；

检查全局已提交订单数目，已超过秒杀商品总数，返回已结束页面给顾客。未超过秒杀商品

总数，提交到子订单系统。

九、大型网站经典故障案例分析

大型网站的架构师最有价喳的地方不在于他们掌握了多少技术，而在于他们经历过多少故障.

1.写日志也会即起故瞪

故障现象：某应用服务器集群公布后很快就出现多台服务器相继报警，硬盘可用空间低于警戒值，并

且很快有服务器宕机，登录到线上服务器，发现1。g文献夹里的文献迅速增长，不停消耗磁盘空间。

原因分析:查日志内容发现开发人员将I。g输出的level全局配置为Debug，这样一次简朴的web

祈求就会产生大量的1og文献输出,在高并发的顾客祈求下很快就消耗完磁盘空间。

经验：线上的日志输出级别至少为Warn。

2.高并发访问数据库引起故障

故障现象：某应用公布后，数据库Load居高不下，远超正常水平，持续报警。

原因分析：检蛰数据库,发现报警是由于某条SQL引起，这条SQL是一条简朴的有索引的数据查询,

不应当引起报警。继续检查，发现这条SQL执行频率非常高,远超正常水平。追查这条SQL,发现

被网站首页应用调用，首页是被访问最频繁的网页，这条SQL被首页调用，也就被频繁执行了。

经验：首页不应当访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取；

首页最佳是静态的。

3.高并发状况下锁引起的故障

故障现象：某应用服务器不定期由于响应超时而报警，不过很快又超时解除，恢复正常，如此反复，

让运维人员非常苦恼。

原因分析：程序中某个单例对象(Sing1etonobject)中多处使用了synchronized(this),

由于this对象只有一种，所有的并发祈求都要排队获得这唯一的一把锁。一般状况下，都是某些简

朴操作，获得锁，迅速完毕操作，释放锁,不会引起线程排队。不过某个需要远程调用的操作也拗口了

synchronized(this)，这个操作只是偶尔被执行,不过每次执行都需要较长的时间才能完毕，这

段时间锁被占用，所有的顾客线程都要等待，响应超时，这个操作执行完后释放锁，其他线程迅速执

行，超时解除。

经验:谨慎使用锁。

4.缓存即起的故障

故障现象:没有新应用公布，不过数据库服务器忽然Load飙升，并很快失去响应。DBA将数据库访

问切换到备机，Load也很快飙升,并失去响应。最终引起网站所有瘫痪。

原因分析:缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器

要低某些。人们都认为缓存是改善性能的手段，丢失某些缓存也没有什么问题，有时候关闭一两台缓存

服务器也确实对应用没有明显影响，因此长期疏于管理。成果这次一种缺乏经验的工程师关闭了缓

存服务器集群中所有的十几台Mencached服务器，导致了网站所有瘫痪的重大事故。

经验：当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时,对缓存的管理就需要

提高到和其他服务器同样的级别。

5.应用启动不一样步引起的故障

故障现象：某应用公布后，服务器立即瓦解。

原因分析:应用程序Web环境使用Apache+JBoss的模式，顾客祈求通过Apache转发JBos

s。在公布时，Apache和」Boss同步启动，由于JB。ss启动时需要加载诸多应用并初始化，花

费时间较长，成果JBoss还没完全启动，Apache就已经启动完毕开始接受顾客祈求，大量祈求阻

塞在JB。ss进程中，最终导致JBoss瓦解。除了这种Apache和JBoss启动不一样步的状况，

网站尚有诸多类似的场景，都需要后台服务准备好，前台应用才能启动,否则就会导致故障。这种状

况被戏称："姑娘们还没穿好衣服，老鸨就开门迎客了。"

经验:就本例来说，在应用程序中加入一种特定的动态页面（例如只返回。K），启动脚本先启动

JBoss,然后在脚本中不停用curl命令访问这个特定页面，直到收到0K,才启动Apache.

6.大文献读写独占磁盘引起故障

故障现象:某应用重要功能是管理顾客图片，接到部分顾客投诉,表达上传图片非常慢，本来只需要一

两秒，目前需要几十秒，有时等半天成果浏览器显示服务器超时。

原因分析：图片需要使用存偌，最有也许出错的地方是储存服务器。检杳存储服务器,发现大部分文

献只有几百KB,而有几种文献非常大，有数百兆，读写这些大文献一次需要几十秒，这段时间，磁盘

基本被这个文献操作独占，导致其他顾客的文献操作缓慢。

经验:存储的使用需要根据不一样文献类型和顾客进行管理，图片