第十一周 安全稳定 总结

XSS 攻击

XSS 攻击即跨站点脚本攻击（Cross Site Script)，指黑客通过篡改网页，注入恶意 HTML 脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。攻击类型有两种：

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

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



XSS 攻击 危害



• 窃取网页浏览中的 cookie 值。

• 劫持流量实现恶意跳转。



XSS 攻击防御手段



• 消毒：XSS 攻击者一般都是通过在请求中嵌入恶意脚本达到攻击目的，这些脚本是一般 用户输入中不使用的，如果进行过滤和消毒处理，即对某些 HTML 危险字符转义，如 “>”转义为“&gt”、“<”转义为“&lt”等，就可以防止大部分攻击。为了避免对不 必要的内容错误转义，如“3<5”中的“<”,需要进行文本匹配后再转义，如“<img src=”这样的上下文中“<”才转义。事实上，消毒几乎是所有网站最必备的 XSS 防攻 击手段。

• HttpOnly,设置 Cookie 的 HttpOnly 属性，禁止 Js 访问 Cookie 信息。



SQL 注入攻击

注入攻击有两种形式：sql 注入攻击和 OS 注入攻击。

SQL 注入攻击需要攻击者对数据库结构有所了解才能进行，攻击者获取数据库表结构信息的手段有如下几种



• 开源：如果网站采用开源软件搭建，如用 Discuz!搭建论坛网站，那么网站数据库结构就是公开的，攻击者可以直接获得。

• 错误回显：如果网站开启错误回显，攻击者故意构造非法参数，服务端异常信息会输出到浏览器端，为攻击猜测数据库表结构提供了便利。

• 盲注：网站关闭错误回显，攻击者根据页面变化情况判断 SQL 语句的执行情况，据此猜测数据库表结构，此种方式攻击难度较大。



SQL 注入攻击防御



• 消毒：和防 XSS 攻击一样，请求参数消毒是一种比较简单粗暴又有效的手段。通过正则 匹配，过滤请求数据中可能注入的 SQL 文。 如“drop table”、“\b(?:update\b.?\bset|delete\b\W?\bfrom)\b”等。

• SQL 预编译参数绑定：使用预编译手段，绑定参数是最好的防 SQL 注入方法。目前许 多数据访问层框架，如 myBatis，Hibernate 等，都实现 SQL 预编译和参数绑定，攻击 者的恶意 SQL 会被当做 SQL 的参数，而不是 SQL 命令被执行。



CSRF 攻击

CSRF(Cross Site Request Forgery，跨站点请求伪造），攻击者通过跨站请求，以合法用户的身份进行非法操作。其主要的手段是利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。其核心是利用了浏览器 Cookie 或者服务器 Session 策略，盗取用户身份。



CSRF 攻击防御



• 表单 Token：CSRF 是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才 可以。表单 Token 就是阻止攻击者获得所有请求参数的可能，在页面表单中增加一个随 机数 Token，每次请求的 Token 都不相同，请求提交后检查 Token 的值是否正确以确 定请求提交者是否合法。

• 验证码：相对说来，验证码则更加简单有效，即请求提交时，需要用户输入验证码，以 避免在用户不知情的情况下被攻击者伪造请求。但是输入验证码是一个糟糕的用户体验， 所以必要的时候才使用，如支付交易等关键页面。

• Referer check：HTTP 请求头的 referer 域中记录着请求来源，可通过检查请求来源， 验证其是否合法。但是该方法有一定局限性，referer 也并不一定总能得到。



其他需要关注的攻击与漏洞



• Error Code：也称作错误回显，许多 Web 服务器默认是打开异常信息输出的，即服务器 端未处理的异常堆栈信息会直接输出到客户端浏览器，这种方式虽然对程序调试和错误 报告有好处，但同时也给黑客造成可乘之机。通过故意制造非法输入，使系统运行时出 错，获得异常信息，从而寻找系统漏洞进行攻击。防御手段也很简单，通过配置 Web 服 务器参数，跳转 500 页面（HTTP 响应码 500 表示服务器内部错误）到专门的错误页面即 可，这个功能 Web 应用常用的 MVC 框架也可以做到。

• HTML 注释：为了程序调试方便或其他不恰当的原因，有的时候程序开发人员会在 PHP、 JSP 等服务器页面程序中使用 HTML 注释语法进行程序注释，这些 HTML 注释就会显 示在客户端浏览器，给黑客造成攻击便利。程序最终发布前需要进行代码 review 或自动 扫描，避免 HTML 注释漏洞。

• 文件上传：一般网站都会有文件上传功能，设置头像、分享视频、上传附件等。如果上 传的是可执行的程序，并通过该程序获得服务器端命令执行能力，那么攻击者几乎可以 在服务器上为所欲为，并以此为跳板攻击集群环境的其他机器。最有效的防御手段是设 置上传文件白名单，只允许上传可靠的文件类型。此外还可以修改文件名、使用专门的 存储等手段，保护服务器免受上传文件攻击。

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



-----



Web 应用防火墙

开源 Web 应用防火墙 ModSecurity

ModSecurity 是一个开源的 Web 应用防火墙，探测攻击并保护 Web 应用程序，既可以 嵌入到 Web 应用服务器中，也可以作为一个独立的应用程序启动。ModSecurity 最早只 是 Apache 的一个模块，现在已经有 Java、.NET 多个版本，并支持 Nginx。

ModSecurity 采用处理逻辑与规则集合分离的架构模式。处理逻辑负责请求和响应的拦 截过滤，规则加载执行等功能。而规则集合则负责对具体的攻击的规则定义、模式识别、 防御策略等功能。处理逻辑比较稳定，规则集合需要不断针对漏洞进行升级，这是一种 可扩展的架构设计。



商业产品也有实现 Web 应用防火墙功能，如 NEC 的 siteShell。



网站安全漏洞扫描

和计算机安全漏洞扫描一样，网站也需要安全漏洞扫描。

网站安全漏洞扫描工具是根据内置规则，模拟黑客攻击行为，用以发现网站安全漏洞的工具。许多大型网站的安全团队都有自己开发的漏洞扫描工具，不定期的对网站的服务 器进行扫描，查漏补缺。

目前市场上也有很多商用的网站安全漏洞扫描平台。



-----



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

2011 年 12 月被曝的 CSDN 密码泄露事故中，网站安全措施不力，导致用户数据库被黑 客“拖库”并不稀奇，令人错愕的是数据库中的用户密码居然是明文保存，导致密码泄 露，成为地下黑市交易的商品。

通常，为了保护网站的敏感数据，应用需要对这些信息进行加密处理，信息加密技术可分为三类：单项散列加密，对称加密，非对称加密。



单向散列加密

单向散列加密是指通过对不同输入长度的信息进行散列计算，得到固定长度的输出，这个散列计算过程是单向的，即不能对固定长度的输出进行计算从而获取输入信息。



特定情况下，通过彩虹表（密码与密文关系表）等手段可以进行猜测式破解。

为了加强单向散列计算的安全性，会给散列算法加点盐（salt)，salt 相当于加密的密钥，增加破解的难度。

常用的单向散列算法有 MD5,SHA 等。其特点比较适用用户密码场景



对称加密

对称加密是指加密与解密使用的是统一密钥（或者可以互相推算）。

其通常用在信息需要安全交换或者存储的场景，如 Cookie 加密、通信加密等。



对称加密的优点是算法简单，加解密效率高，系统开销小，适合对大量数据加密。

缺点是加解密使用同一密钥，远程通信的情况下如何安全的交换密钥是个难题，如果密钥丢失，那么所有的加密信息也就没有秘密可言。

常见的对称加密算法有 DES 算法，RC 算法等。其是常用的加密手段，适用于绝大多数需要加密的场合。



非对称加密

不同于对称加密，非对称加密加密于解密用的不是同一把密钥，其中一个对外界公开，被称为公钥，另一个只有所有者知道，被称作私钥。



常用的算法有 RSA 算法等。HTTPS 传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密的公钥。

另外，数字签名的过程，签名者用自己的私钥对信息进行加密，然后发送对方，接收方用签名者的公钥对信息解密，获得原始明文信息，由于私钥只有签名者拥有，因此改信息是不可抵赖的，具有签名的性质。



密钥安全管理

一种方案是把密钥与算法放在一个独立的服务器上；系统开销大，会成为应用的瓶颈。

另一种方案是将加解密算法放在应用系统中，密钥放在独立服务器中，为了提高密钥安全性，实际存储时，密钥被切分成数片，加密后分别保存在不同存储介质中，兼顾密钥安全性的同时改善性能。



-----



信息过滤与反垃圾

反垃圾手段



• 文本匹配

• 分类算法



反垃圾邮件



贝叶斯分类算法

贝叶斯算法解决概率论中的一个典型问题：一号箱子放有红色球和白色球各 20 个，二号 箱子放有白色球 10 个，红色球 30 个，现在随机挑选一个箱子，取出来一个球的颜色是红 色的，请问这个球来自一号箱子的概率是多少。

利用贝叶斯算法进行垃圾邮件的识别基于同样原理，根据已分类的样本信息获得一组特 征值的概率（如“茶叶”这个词出现在垃圾邮件中的概率和非垃圾邮件中的概率），就 得到分类模型，然后对待处理信息提取特征值，结合分类模型，判断其分类。

贝叶斯公式



布隆过滤器黑名单



有误判的可能，如果需要精确的判断，则不适合使用布隆过滤器。



----

电子商务风险控制



电子商务网站在给人们代理购物交易的极大便利的同时，也将风险带给了对网络安全一 无所知的人们。由于买卖双方的信息不对等，交易本来就存在风险，而当交易在网上发 生的时候，买卖双方彼此一无所知，交易风险也就更加难以控制。如果一个电商网站骗 子横行，诚信的交易者屡屡被骗，那么网站就到了最危险的时候，可以说，交易安全是 电子商务网站的底线。



电子商务具有多种形式，B2B，B2C，C2C 每种交易的场景都不相同，风险也各有特点， 大致可分为以下几种：

• 账户风险：包括账户被黑客盗用，恶意注册账号等几种情形。

• 买家风险：买家恶意下单占用库存进行不正当竞争；黄牛利用促销抢购低价商品；此外还有 良品拒收，欺诈退款以及常见于 B2B 交易的虚假询盘等。

• 卖家风险：不良卖家进行恶意欺诈的行为，例如货不对板，虚假发货，炒作信用等，此外还 有发布违禁商品、侵权产品等。

• 交易风险：信用卡盗刷，支付欺诈，洗钱套现等。

大型电商网站都配备有专门的风控团队进行风险控制，风控的手段也包括自动和人工两 种方式。机器自动识别为高风险的交易和信息会发送给风控审核人员进行人工审核，机 器自动风控的技术和方法也不断通过人工发现的新风险类型进行逐步完善。

机器自动风控的技术手段主要有规则引擎和机器学习



规则引擎

当交易的某些指标满足一定条件的时候，就会被认为具有高风险的欺诈可能性。 比如： • 用户来自欺诈高发地区；

• 交易金额超过某个数值；

• 和上次登录的地址距离差距很大；

• 用户登录地与收货地不符；

• 用户第一次交易；

• ……

大型网站在运营过程中，结合业界的最新发现，会总结出数以千计的此类高风险交易规则。一 种方案是在业务逻辑中通过编程方式使用 if…else…代码实现这些规则，可以想见，这些代码 会非常庞大，而且由于运营过程中不断发现新的交易风险类型，需要不断调整规则，代码也需 要不断修改…



机器学习



规则引擎虽然技术简单，但是随着规则的逐渐增加，出现规则冲突，难以维护等情况， 而且规则越多，性能也越差。大型互联网应用更倾向于使用机器学习模型进行风控。



-----

高可用的度量

可用性指标



业界通常用多少个 9 来衡量网站的可用性，如 QQ 的可用性是 4 个 9，即 QQ 服务 99.99% 可用，这意味着 QQ 服务要保证其在所有运行时间中，只有 0.01％的时间不可用，也就 是一年中大约 53 分钟不可用。



• 网站年度可用性指标＝（1－网站不可用时间/年度总时间）×１００％



• 网站不可用时间（故障时间）＝故障修复时间点－故障发现（报告）时间点



对可用性的定性描述，两个 9 是基本可用，年度停机时间小于 88 小时；3 个 9 较高可用， 年度停机时间小于 9 小时；4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分 钟；5 个 9 是极高可用性，年度停机时间小于 5 分钟。由于可用性影响因素很多，对于网站 整体而言，达到 4 个 9，乃至 5 个 9 的可用性，除了过硬的技术、大量的设备资金投入和工 程师的责任心，还要有个好运气。

故障分管理



故障处理流程及考核



引起故障的原因

• 硬件故障

• 软件 bug

• 系统发布

• 并发压力

• 网络攻击

• 外部灾害



-----

高可用系统的架构

解耦

• 高内聚、低耦合的组件设计原则

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模



隔离

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离

• 虚拟机与容器隔离



异步

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

备份

• 集群设计

• 数据库复制

• CAP 原理

Failover（失效转移）

数据库主主失效转移

负载均衡失效转移

如何确认失效，需要转移？

设计无状态的服务



幂等

应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假 的失败。比如服务已经处理成功，但是因为网络故障应用没有收到响应，这时应用重新 提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。

服务重复调用有时候是无法避免的，必须保证服务重复调用和调用一次产生的结果相同， 即服务具有幂等性。有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置 多少次，结果都一样。但是对于交易等操作，问题就会比较复杂，需要通过交易编号等 信息进行服务调用有效性校验，只有有效的操作才继续执行。



事务补偿



1. 传统事务的 ACID

• 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性 （Durability）

1. 分布式事务的 BASE • 基本可用（Basic Availability ）、软状态（Soft-state）、最终一致性（Eventual consistency）

2. 事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态



重试

远程服务可能会由于线程阻塞、垃圾回收或者网络抖动，而无法及时返还响应，调用者 可以通过重试的方式修复单次调用的故障。

上游调用者超时时间要大于下游调用者超时时间之和。

熔断

当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求 阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务 的调用。

• 断路器三种状态：关闭，打开，半开



限流

在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行 保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处 理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问 系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是好过整个系 统崩溃，所有的用户都不可用要好。

限流的几种算法

• 计数器算法（固定窗口，滑动窗口）

• 令牌桶算法

• 漏桶算法



###### 计数器（固定窗口）算法

使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一个周期开始 时，进行清零，重新计数。



固定窗口算法的临界点问题：假设 1min 内服务器的负载能力为 100，因此一个周期的访问量限 制在 100，然而在第一个周期的最后 5 秒和下一个周期的开始 5 秒时间段内，分别涌入 100 的访问 量，虽然没有超过每个周期的限制量，但是整体上 10 秒内已达到 200 的访问量，已远远超过服务 器的负载能力。

###### 计数器（滑动窗口）算法

将时间周期分为 N 个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除 过期的小周期。



假设时间周期为 1min，将 1min 再分为 2 个小周期，统计每个小周期的访问数量，则可以 看到，第一个时间周期内，访问数量为 75，第二个时间周期内，访问数量为 100，超过 100 的访问则被限流掉了



###### 令牌桶算法

以固定的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如 获取到令牌则通过请求，否则触发限流策略。



###### 漏桶算法

访问请求到达时直接放入漏桶，如当前容量已达到限流值，则进行丢弃。漏桶以固定的 速率进行释放访问请求，直到漏桶为空。



###### 自适应限流

没有提前的人工评估，便没有提前的评估过时与人的评估疏漏/错误! • 实时自动评估 QPS • 业务流量的不确定性与技术方案的自适应性天生一对!



降级

有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，比如说在电商系统 中有确认收货这个功能，即便我们不去确认收货，系统也会超时自动确认收货。

但实际上确认收货这个操作是一个非常重的操作，因为它会对数据库产生很大的压力： 它要进行更改订单状态，完成支付确认，并进行评价等一系列操作。如果在系统高并发 的时候去完成这些操作，那么会对系统雪上加霜，使系统的处理能力更加恶化。

解决办法就是在系统高并发的时候，比如说像淘宝双 11 的时候，当天可能整天系统都处 于一种极限的高并发访问压力之下，这时候就可以将确认收货、评价这些非核心的功能 关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易。



异地多活

如果整个数据中心都不可用，比如说数据中心所在城市遭遇了地震，机房遭遇了火灾或 者停电，这样的话，不管我们的设计和系统多么的高可用，系统依然是不可用的。

为了解决这个问题，同时也为了提高系统的处理能力和改善用户体验，很多大型互联网 应用都采用了异地多活的多机房架构策略，也就是说将数据中心分布在多个不同地点的 机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问，这样每 个机房都可以提供完整的系统服务，即使某一个机房不可使用，系统也不会宕机，依然 保持可用。

异地多活的难点是数据一致。



----



高可用系统的运维

发布

网站需要保证 7×24 高可用运行，同时网站又需要不断的发布新功能吸引用户以保证在激 烈的市场竞争中获得成功。许多大型网站每周都需要发布一到两次，而中小型网站则更 加频繁，一些处于快速发展期的网站甚至每天发布十几次。

不管发布的新功能是修改了一个按钮的布局还是增加一个核心交易功能，都需要在服务 器上关闭原有的应用，然后重新部署启动新的应用，整个过程还要求不影响用户的使用。 这相当于是要求给飞行中的飞机换个引擎，既不能让飞机有剧烈的晃动，也不能让飞机 降落，更不能让飞机坠毁。

既然网站的发布过程事实上和服务器宕机效果相当，那么就可以用服务器宕机的高可用 方案来应对网站的发布。所以设计一个网站的高可用架构的时候，需要考虑的服务器宕 机概率不是物理上的每年一两次，而是事实上的每周一两次。也许你认为这个应用不重 要，重启也非常快，用户可以忍受每年一到两次的宕机故障，因而不需要复杂的高可用 设计。事实上，由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。用 户哭了。



自动化测试

代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有 系统功能上的小幅增加，但是为了保证系统没有引入未预料的 BUG，网站测试还是需要 对整个网站功能进行全面的回归测试。此外还需要测试各种浏览器的兼容性，在发布频 繁的网站应用中，如果使用人工来进行，成本和时间都难以承受。

目前大部分网站都采用 Web 自动化测试技术，使用自动测试工具或脚本完成测试。比较 流行的 Web 自动化测试工具是 ThoughtWorks 开发的 Selenium。Selenium 运行在浏 览器中，模拟用户操作进行测试，因此 Selenium 可以同时完成 Web 功能测试和浏览器 兼容测试



手工测试和自动化测试的总体成本



雇个测试工程师，测试工程师在每次发布前进行应用测试。开始的时候，这种成本是非常小的， 但是增长却很快。每次开发新功能都需要对新功能进行测试，而前面已经发布的各种功能也需 要进行测试，确保开发新功能不会破坏现有的产品功能。也就是说，每次发布的测试成本都比 前一次发布的测试成本更高（测试效率随时间推移逐步降低）。这也会使软件的版本的发布周 期逐渐变长，因为随着软件规模的增长，测试需要越来越长的时间。



自动化测试需要一些前置投资，你需要安装自动化测试工具，部署持续集成服务器，但是后续 投入却是相对便宜的。一旦完成初始安装，只需要为新功能创建测试就可以了，测试已经存在 的功能几乎不需要花费任何成本。随着时间的推移，测试会变得越来越高效，每一次发布测试， 已测试的代码和待测试的代码之比都在增加。最终，会到达一个平衡点，然后自动化测试的总 体成本会低于手工测试的成本。



自动化部署



持续部署三步走



1. 持续集成

• 允许工程师随时向公共分支提交代码，并立即进行自动化测试。

1. 持续交付

• 除了跑单元测试及软件打包，持续交付机制会将软件部署到各种测试环境中

1. 持续部署

• 代码在没有人工干预的情况下被测试、构建、部署并推送到生产环境。



持续部署流程



预发布验证

即使是经过严格的测试，软件部署到线上服务器之后还是经常会出现各种问题，甚至根 本无法启动服务器。主要原因是测试环境和线上环境并不相同，特别是应用需要依赖的 其他服务，如数据库，缓存、公用业务服务等，以及一些第三方服务，如电信短信网关、 银行网银接口等。也许是接口变化导致的通信失败；也许是配置错误导致连接失败；也 许依赖的服务在线上环境还没有准备好；这些问题都有可能导致应用故障。

因此在网站发布的时候，并不是把测试通过的代码包直接发布到线上服务器，而是先发 布到预发布机器上，开发工程师和测试工程师在预发布服务器上进行预发布验证，执行 一两个典型的业务流程，确认系统没有问题后才正式发布。

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没有配 置在负载均衡服务器上，外部用户无法访问。



代码版本控制

对于大型互联网系统，核心应用系统和公用业务模块涉及许多团队和工程师，需要对相 同的代码库进行共同开发和维护，而这些团队对同一个应用的开发维护，其开发周期和 发布时间点各不相同。如何进行代码管理，既能保证代码发布版本的稳定正确，同时又 能保证不同团队的开发互不影响



• 主干开发、分支发布： 代码修改都在主干上进行，需要发布的时候，从主干上拉一个分支发布，该分支即成为一个 发布版本，如果该版本发现 Bug，继续在该分支上修改发布，并将修改合并（merge）回主 干，直到下次主干发布。

• 分支开发，主干发布： 任何修改都不得在主干上直接进行，需要开发一个新功能或者修复一个 bug 的时候，从主 干拉一个分支进行开发，开发完成测试通过后，合并回主干，然后从主干进行发布，主干上 的代码永远是最新发布的版本。

两种方式各有优缺点。主干开发、分支发布方式，主干代码反应目前整个应用的状态， 一目了然，便于管理和控制，也利于持续集成。分支开发，主干发布方式，各个分支独 立进行，互不干扰，可以使不同发布周期的开发在同一应用中进行。 目前互联网应用开发中主要使用的是分支开发、主干发布的方式。

自动化发布

网站的版本发布频繁，整个发布过程需要许多团队合作，发布前，多个代码分支合并回 主干可能会发生冲突（conflict），预发布验证也会带来风险，每次发布又相当于一次宕 机事故。因此网站发布过程荆棘丛生，一不小心就会踩到



灰度发布

应用发布完成功后，仍然可能会发现因为软件问题而引入的故障，这时候就需要做发布 回滚，即卸载刚刚发布的软件，将上一个版本的软件包重新发布，使系统复原，消除故 障。

大型网站的主要业务服务器集群规模非常庞大，比如 QQ 的服务器数量超过一万台。一 旦发现故障，即使想要发布回滚也需要很长时间才能完成，只能眼睁睁看着故障时间在 不断增加干着急。为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分 成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部 分服务器，持续几天的时间才把整个集群全部发布完毕，期间如果发现问题，就只需要 回滚已发布的一部分服务器即可。



网站运行监控

“不允许没有监控的系统上线”，这是许多网站架构师在做项目上线评审的时候常说的 一句话。网站运行监控对于网站运维和架构设计优化至关重要，没有监控的网站，犹如 盲人骑瞎马，夜半临深渊而不知。生死未卜，提高可用性、减少故障率就更无从做起了。



监控数据采集

广义上的网站监控涵盖所有非直接业务行为的数据采集与管理，包括供数据分析师和产 品设计师使用的网站用户行为日志，业务运行数据和系统性能数据等。

用户行为日志收集

用户行为日志指用户在浏览器上所做所有操作及其所在的操作环境，包括用户操作系统 与浏览器版本信息，IP 地址，页面访问路径，页面停留时间等，这些数据对统计网站 PV/UV 指标，分析用户行为，优化网站设计，个性化营销与推荐等非常重要。

具体用户行为日志收集手段有两种



• 服务器端日志收集，这个方案比较简单，Apache 等几乎所有 Web 服务器都具备日志记 录功能，可以记录大部分用户行为日志，开启 Web 服务器的日志记录功能即可。其缺点 是可能会出现信息失真，如 IP 地址是代理服务器地址而不是用户真实 IP；多个链接指 向同一个页面的情况下无法分辨访问路径等。

• 客户端浏览器日志收集，浏览器可以收集用户真实的操作行为，因此比服务器日志收集 更加精准。其缺点是比较麻烦，需要在页面嵌入特定的 JS 脚本来完成。



服务器性能监控

收集服务器性能指标，如系统 Load，内存占用，磁盘 IO，网络 IO 等对尽早做出故障预 警，及时判断应用状况，防患于未然，将故障扼杀在萌芽时期非常重要。此外根据性能 监控数据，运维工程师可以合理安排服务器集群规模，架构师及时改善系统性能及调整 系统伸缩性策略



目前网站使用比较广泛的开源性能监控工具是 Ganglia，支持大规模服务器集群，并支 持以图形的方式在浏览器展示实时性能曲线。



• ganglia 采用 rrd 文件存储，可以结合分布式文件系统存储更多的历史数据；配置简单不用每台机器添加配置，但是功能单一；支持分层管理上万机器。监控只有表格和图像两种，比较单一；没有告警机制和消息通知机制；



• grafana 与 prometheus 结合使用，可以满足大多数监控场景；



• zabbix 使用比较广泛(开源的监控中)，部署比较简单支持多平台，可以实现复杂的告警。但是有一个缺点是当数据量变大或者集群规模变大的时候容易出现性能瓶颈；



• open-falcon 功能强大，在开源项目中有与 zabbix 争锋的趋势，没有 zabbix 的性能瓶颈的问题。但是 open-falcon 的架构比较复杂，并且开源时间还较短，功能还需要进一步完善，比如 dashboard 的维度是 60s,没有其他粒度。



以上基本是四个开源的集群监控框架的优缺点总结。在中小型项目中 grafana+Prometheus 和 zabbix 使用的比较多，open-falcon 慢慢的也比较多起来。但是随着公司的发展或者项目的发展，不可避免的需要自研集群监控平台。



业务运行数据报告

除了服务器系统性能监控，网站还需要监控一些具体业务场景相关的技术和业务指标， 比如缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务总数等。不 同同于服务器性能监控，网站运维人员可以在初始化系统的时候统一部署，业务运行数 据需要在具体程序中采集并报告，汇总后统一显示。



监控管理

监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等，还可以根据实时监 控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有 机器的资源



• 报警

服务器运行正常的情况下，其各项监控指标基本稳定在一个特定水平，如果这些指标超 过某个阀值，就意味着系统可能将要出现故障，这时候就需要对相关人员报警，及时采 取措施，在故障还未真正发生就将其扼杀在萌芽状态。

监控管理系统可以配置报警阀值和值守人员的联系方式，报警方式除了邮件，即时通讯 工具，还可以配置手机短信，语音报警，保证发生报警时，工程师即使在千里之外、夜 里睡觉也能及时通知，迅速响应。



• 自动控制

1. 自动失效转移：除了应用程序访问失败时进行失效转移，监控系统也可以在发现故障的 情况下主动通知应用，进行失效转移。

2. 自动扩容：如果因访问压力大而导致服务性能指标下降，监控系统自动触发服务集群扩容。

3. 自动限流：根据监控指标，自动控制访问流量。

监控系统架构



高可用的价值观

保持简单，使问题易于发现，快速解决。

目标明确，解决特定环境下的具体问题。

价值回归，成本收益要合理。