安全架构

XSS 攻击

防御手段

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

SQL 注入攻击

防御手段

消毒:和防 XSS 攻击一样，请求参数消毒是一种比较简单粗暴又有效的手段。通过正则匹配，过滤请求数据中可能注入的 SQL 文。

如“drop table”、“\b(?:update\b.?\bset|delete\b\W?\bfrom)\b”等。

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

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 访问，动态参数不包含文件路径信息。

网站安全扫描漏洞

和电脑安全漏洞扫描一样，网站也需要安全漏洞扫描。

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

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

加密

单向散列加密

对称加密

非对称加密

密钥安全管理与加解密服务系统架构

反垃圾邮件

贝叶斯分类

布隆过滤器黑名单

电商风控

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

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

• 买家风险:买家恶意下单占用库存进行不正当竞争;黄牛利用促销抢购低价商品;此外还有

• 卖家风险:不良卖家进行恶意欺诈的行为，例如货不对板，虚假发货，炒作信用等，此外还

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

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

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

规则引擎

机器学习

高可用系统度量

可用性指标

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

网站年度可用性指标=(1-网站不可用时间/年度总时间)×100%网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点

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

故障分类

故障处理流程及考核

引起故障的原因

• 硬件故障

• 软件 bug

• 系统发布

• 并发压力

• 网络攻击

• 外部灾害

高可用系统的架构

解耦

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

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

隔离

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离

• 虚拟机与容器隔离

异步

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

备份

• 集群设计

• 数据库复制

• CAP 理论

Failover

• 数据库主主失效

• 负载均衡失效转移

• 设计无状态服务

幂等

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

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

事务补偿

传统事务的 ACID

• 原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation，又称独立性)、持久性

(Durability)

分布式事务的 BASE

• 基本可用(Basic Availability )、 软状态(Soft-state)、 最终一致性(Eventual consistency)

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

重试

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

熔断

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

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

限流

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

计数器（固定窗口）算法

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

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

计数器（滑动窗口）算法

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

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

令牌桶

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

漏桶算法

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

自适应限流

没有提前的人工评估， 便没有提前的评估过时与人的评估疏漏/错误 !

降级

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

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

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

异地多活

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

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

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

高可用系统运维

发布

自动化测试和手工测试

自动化和手工部署

持续部署

持续集成

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

持续交付

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

持续部署

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

持续部署流程

发布验证

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

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

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

自动化发布

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

灰度发布

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

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