架构师训练营第 1 期 - 第 11 周学习总结

本周学习了系统安全稳定相关的技术，包括 Web 攻击与防护、加密与解密、反垃圾与风控、可用性度量、高可用架构方案、高可用运维方案

一、Web 攻击与防护

XSS 攻击

比如有以下几种方式：

• 1. 攻击者推送含有恶意脚本的 URL 给用户 2. 用户点击该 URL，恶意脚本被浏览器解析 3. 浏览器向服务器提交非法请求，服务器被攻击了

• 1. 攻击者向服务器发送含有恶意脚本的请求 2. 用户浏览含有恶意脚本的页面 3. 浏览器执行恶意脚本 4. 恶意脚本攻击服务器或者用户电脑

防御 XSS 攻击的有效手段是消毒：

通过对 HTML 字符转义，比如">"转义为"&gt"、"<"转义为"&lt"等，但是真实的比如 3<5 这种，需要进行文本匹配后再转义。消毒是所有网站最必备的 XSS 防攻击手段。

SQL 注入攻击

SQL 注入攻击是指攻击者把含有 SQL 命令的数据提交到网站，这样 SQL 命令拼接到网站的 SQL 之后触发恶意操作，比如删表，删数据等。

一般这样做需要提前获取数据库表结构信息，有以下途径：

• 开源：如果网站使用开源软件搭建，比如 Discuz!搭建的网站论坛，数据库表结构就是公开的

• 错误回显：有些网站开启了错误回显，攻击者可能故意构造非法请求触发错误回显，由此猜测表结构信息

• 盲注：这种难度比较大，攻击者根据页面变化猜测 SQL 的执行情况，从而推测表结构

防止 SQL 注入的方式有：

• 消毒：跟防 XSS 攻击一样，把请求数据中含有的 SQL 语句过滤掉，简单粗暴

• SQL 预编译：使用 SQL 预编译，用绑定参数的形式调用 SQL 语句，这样恶意的 SQL 语句就不会当成 SQL 执行了

CSRF 攻击

CSRF 攻击是指用户访问了攻击者的服务器，攻击者返回含有访问信任服务器请求的响应数据，从而触发访问信任服务器的操作，执行攻击者的意图

防止 CSRF 攻击的手段：

• 表单 token：每次生成表单时，表单中都含有一个服务器生成的 token，用户提交表单请求时也会把 token 提交，服务器端验证 token 的合法性。

• 验证码：验证码的手段简单高效，用户提交请求时，需要输入验证码，避免发送用户不知道的非法请求。但是输入验证码影响用户体验，在必要的时候可以用。

• Referer check：http 头中含有 referer 指向了请求的来源，通过验证请求来源，验证请求是否合法。

其他攻击方法和漏洞

• Error code：错误回显，当服务器默认开启打印错误日志到浏览器时，通过制造非法请求，迫使网站出现错误堆栈信息，通过查看异常信息，寻找网站的漏洞并进行攻击。可以通过配置专用的 500 页面，任何错误异常发生时，都跳转到 500 页。

• HTML 注释：开发人员在 JSP、PHP 等程序中输入 HTML 注释，这样黑客看到这些 HTML 注释时，可能就会抓住漏洞进行攻击。需要避免直接输出 HTML 注释到页面中。

• 文件上传：如果网站的上传功能允许上传可执行程序时，那么攻击者可能会通过可执行文件攻击服务器。可以通过增加上传文件白名单进行防御。

• 路径遍历：攻击者通过在浏览器中输入相对路径，遍历系统未开放的目录和文件。可以把 Javascript、CSS 等资源文件部署在独立服务器、独立域名上，其他非静态文件动态访问。

二、加密与解密

系统的敏感数据应该进行加密保存，这样即使黑客攻入系统，也不能立马获取到敏感数据。一般的信息加密技术有：

• 单向散列加密

定义一个单向散列函数，把明文作为输入，得到密文作为输出，来对数据进行加密。如 MD5、SHA1 等，但是这些算法是公开的，通过不停的尝试，或者收集常用密码知识库，还是有可能破解。可以在单向散列函数的基础上，增加 SALT，来混淆输出，比如可以通过 HMAC 加密方式，指定密钥，然后再通过 SHA 算法对数据进行加密

• 对称加密

对称加密是可逆的，就是加密的过程是以明文和密钥作为输入，密文作为输出。解密的过程是以密文和密钥作为输入，明文作为输出。加密和解密过程中的密钥都是同一个密钥，所以叫做对称加密。比如 AES 就是对称加密

• 非对称加密

对称加密因为密钥都是同一个，不容易进行共享，所以一般采用非对称加密。非对称加密中，密钥有 2 个，一个是公钥，一个是私钥。通过公钥加密的话，那么需要通过私钥解密。通过私钥加密的话，那么需要通过公钥解密。比如 RSA 就是非对称加密

一般信息敏感的行业，都会有密钥安全管理系统和加解密服务系统。应用程序通过访问专门的密钥服务器请求密钥，而密钥是被分成多个部分分别存储在不同的存储中，只有所有的部分同时一起，才能起作用。

三、反垃圾与风控

贝叶斯分类算法

一般系统都会面临反垃圾的需求，比如反垃圾邮件。当收到一封邮件时，如何判断邮件是否是垃圾邮件，这个是由分类算法识别出来的，而分类算法一般会采用经典的贝叶斯公式，根据对已有的样本信息获取一组特征值的概率，得到分类模型，然后对待处理的信息提取特征值，结合分类模型，判断其分类。

布隆过滤器黑名单

在判断一个邮箱地址是否是黑名单时，可以把所有的黑名单邮箱地址收集起来，然后保存在存储中，当新的邮件来的时候，可以判断邮箱是否在黑名单列表中。如果这个黑名单有几亿或者几十亿时，这样做比较耗时和占用存储空间。可以通过布隆过滤器，定义一个连续的 bit 存储空间，然后再定义一组函数，每个函数对黑名单列表求值，然后对应到这个连续存储空间的下标，对应到的下标标记为 1，没有对应到的下标为 0。这样当要判断新的邮箱地址是否是黑名单时，同样的，根据这一组函数，求出对应的下标，如果所有的下标都是 1，那么表示这个地址就属于黑名单。注意布隆过滤器可以会存在误判的情况，就是判断是黑名单可能并不是黑名单，但是不是黑名单的，肯定不是黑名单。

电子商务风险控制

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

• 账户风险：比如账户被黑客盗用，恶意注册账号等

• 买家风险：买家恶意下单占用库存进行不正当竞争；黄牛利用促销抢购低价商品；良品拒收，欺诈退款等

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

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

规则引擎

通过规则引擎，可以识别高风险的交易。比如：用户来自欺诈高发地区、交易金额大于某个数值、和上次登录地址相差很大等，当交易满足这些条件时，就触发风控。

机器学习

规则引擎虽然技术简单，但是随着规则的增加，难以维护。大型互联网应用更倾向于使用机器学习模型进行风控。

四、可用性度量

可用性指标

业界通常用多少个 9 来衡量网站的可用性。

网站年度可用性指标 = （1 - 网站不可用时间 / 年度总时间）* 100%

网站不可用时间 = 故障修复时间 - 故障发现（报告）时间

定性描述可用性，2 个 9 是基本可用，年度停机时间小于 88 小时；3 个 9 是较高可用，年度停机时间小于 9 小时；4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分钟；5 个 9 是极高可用，年度停机时间小于 5 分钟。影响可用性的因素很多，要达到 4 个 9、5 个 9，则需要投入大量的人力、物力、资金、技术等，还需要好运气。

故障分管理

一般网站把故障分为几大类，有事故级故障（严重故障，网站整体不可用）、A 类故障（网站访问不顺畅，或核心功能不可用）、B 类故障（非核心功能不可用，或核心功能少数不可用）、C 类故障（其他故障），每个类别有不同的权重，故障越严重，权重越重。每个部门/每个团队/每个人每年给定故障分，然后根据故障发生时的级别扣除故障分，到年底时，根据剩余的故障分来评判每个人在高可用这个指标上的绩效。

故障处理流程及考核

1. 客服报告故障或监控系统发现故障（故障开始时间）

2. 提交故障给相关部门接口人

3. 故障接手和处理

4. 故障处理完毕和故障归档（故障结束时间）

5. 确认故障归属并记入绩效考核

引起故障的原因

• 硬件故障

• 软件 bug

• 系统发布

• 并发压力

• 网络攻击

• 外部灾害

五、高可用架构方案

解耦

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

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

隔离

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离

• 虚拟机与容器隔离

异步

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

备份

• 集群设计

• 数据库复制

• CAP 原理

失效转移

• 数据库主主失效转移

• 负载均衡失效转移

• 尽量设计无状态的服务，可以便利地失效转移

幂等

应用程序调用服务失败时，会重新发送请求到服务器上，但是有可能之前的请求服务器已经接收到了，只是网络断了，应用程序没有接收到请求，这个时候，重新发送请求到服务器，会重新触发操作，如果这个操作是转账操作，那么后果不堪设想。

因为服务重复调用有时候是无法避免的，为了保证服务多次调用和一次调用产生同样的效果，那么服务需要具备幂等性。这个需要根据具体情况来设计，比如有些操作就是天然具有幂等性，比如设置账户余额，不管设置多少次，都是一样的，但是交易类就比较麻烦，比如支付，重复扣款会导致余额变少，应该判断是否已经处理过，如果已经处理过，就不再处理，来保证幂等。

事务补偿

事务补偿是指通过执行业务逻辑逆操作，使事务回滚到事务发生前的状态

重试

由于网络原因，或者 JVM 发生 GC 等原因，导致远程服务调用失败，这个时候应该允许应用程序重新发送远程服务调用来尽可能保证服务调用成功。设置超时时，需要注意上游调用者超时时间要大于下游调用者超时时间之和。

熔断

当某个服务出现故障时，继续调用该服务将导致资源耗尽，调用者服务也会阻塞，这种情况下可以考虑使用断路器来阻断对故障服务的调用。断路器的三种状态有：关闭，打开，半开

限流

在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行保护。具体就是对系统流量进行限制，只允许不超过最大流量的请求被处理，超过最大流量的部分的请求直接丢弃，保证整个系统可用。虽然部分用户不能使用系统，但也好过整个系统奔溃进而所有用户不能使用。

限流的算法有：

• 计数器算法

• 令牌桶算法

• 漏桶算法

自适应限流

自适应限流是指系统实时采集系统 CPU、内存、网络等指标，检测当前系统负载，如果负载过高，设置流量限制，当系统流量下降时，系统检测到负载降低，从而关闭流量限制，系统恢复正常，整个过程没有人工评估，全部自动调节流量

降级

降级就是当系统处于高并发访问时，为保证系统的核心功能正常运转，可以关闭一些非核心功能，比如双 11 当天，可以关闭商品评价、确认收货等功能，以节省宝贵的系统资源给核心的购物功能。通过系统降级，来应对高并发流量访问。

异地多活

如果整个数据中心所在的城市遭遇地震，机房遭遇火灾或停电等，那么无论系统设计的多么高可用，系统也是不能使用的。通过采用异地多活的多机房架构策略，把数据中心备份到多个不同城市的机房里，这样即使有一个机房不可用时，系统可以切换到其他机房，仍然对外提供服务。异地多活的难点是数据一致。

六、高可用运维方案

发布

网站对外提供 7 * 24 小时的服务，同时网站又需要不断的发布新功能来吸引用户。每次发布时，需要关闭原有的应用，然后重新部署新的应用，整个过程要求不影响用户使用。所以设计网站的高可用架构时，需要考虑到发布时的网站可用性问题，可以把发布当成服务器宕机来处理。

自动化测试

代码在发布之前都需要进行严格的测试，即使只发布一点小的改动，为保证不引入新的 bug，还是需要进行回归测试。如果每次都进行人工回归测试，随着网站的功能越来越多，这个时间和成本是难以承受的。可以采用自动化测试技术，使用自动化测试工具或脚本完成测试。相对于手工测试，自动化测试前期投入比较大，但是随着网站的功能越来越多，自动化测试的成本相对于手动测试的成本是节省很多的。

自动化部署

自动化部署利用自动化部署脚本，自动发布应用程序，但是脚本也是人写的，为谨慎起见，脚本需要经过严格的测试并实践，才好在生产环境使用。

持续部署三步走

持续集成

• 开发人员提交代码之后，自动触发自动化测试

持续交付

• 持续交付机制将软件自动部署到各种测试环境中

持续部署

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

预发布验证

因为测试环境和生产环境毕竟不一样，即使在测试环境没有问题，部署到生产环境还是会遇到各种各样的问题。因此在网站发布的时候，一般先把代码发布到预发布机器上，开发人员和测试人员在预发布机器上进行验证，可以通过修改本地 hosts 文件来绑定域名到预发布服务器，通过执行几个典型的业务场景，确认没有问题之后再正式发布。

代码版本控制

大型互联网应用，由许多团队和工程师共同开发和维护，每个团队的开发周期和发布时间都不一样，如何进行代码管理，保证发布的代码版本是正确的，同时又不影响不同团队的并行开发，就显得格外重要。有下面 2 种方式：

• 主干开发、分支发布

• 分支开发、主干发布

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

目前互联网应用开发中主要使用的是分支开发、主干发布的方式

灰度发布

大型网站的业务功能多，服务器集群大，如果发布遇到故障回滚时，也会需要很长的时间。为了应对这种情况，大型网站会采用灰度发布的方式，先发布新的版本到一部分服务器上，观察新版本的运行情况，确认没有故障时，然后再分批发布其他的服务器，直到所有的集群都更新成最新的版本。如果运行过程中发生问题，也只需要回滚一部分服务器。

网站运行监控

网站运行监控对于网站运维和架构设计优化至关重要，没有监控的网站，就无法得知系统的运行情况，当发生问题时，也无法提前判断或者无法诊断问题。

监控数据采集

监控采集是指采集网站的运行数据，包括非功能性的数据采集、用户行为日志、业务数据和系统性能数据等。

用户行为日志收集

用户行为日志是指收集用户在浏览器上所有的操作及其所在的操作环境，包括操作系统、浏览器版本、IP 地址、页面访问路径、页面停留时间等，这些数据有助于分析用户行为，优化网站设计，个性化营销与推荐。

可以采用服务器端日志收集和客户端浏览器日志收集。

服务器性能监控

收集服务器性能指标，比如系统 CPU、内存使用、磁盘 IO、网络 IO 等，及时判断系统运行状况，提前发现故障。根据性能监控数据，运维人员也可以合理安排服务器集群规模，架构师也可以及时调整架构方案改善系统性能和伸缩性策略。

业务运行数据报告

除了服务器性能监控，网站还要监控具体业务场景相关的技术和业务指标，比如缓冲命中率、平均响应延迟时间、每分钟发送邮件数目、待处理的任务数等。

监控管理

除了采集数据进行系统性能评估、集群规模伸缩性预测等，还可以根据监控数据进行风险预警。

• 报警

服务运行正常时，系统各项指标比较平稳，如果指标超过某个阈值，那么系统可能发生了故障，这个时候，可以通知相关人员，邮件报警、短信报警、语音报警，工程师可以人工干预，及时把故障扼杀在萌芽状态

• 自动控制

自动失效转移、自动扩容、自动限流

高可用的价值观

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

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

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