【架构师训练营 1 期】第十一周学习总结

（课程笔记+个人小结）



安全架构之——XSS攻击（跨站点脚本攻击）

特点：用户登录之后，通过浏览器执行，恶意JS脚本，具有扩散性。

防御：对输入提交的内容进行过滤和消毒处理（对某些HTML危险字符进行转义）。





安全架构之——SQL注入攻击

特点：包含恶意SQL命令的HTTP请求，被应用程序误认为一个查询参数，拼接为SQL命令提交至数据库执行。

引申：获取数据库表结构信息的手段 1.开源软件；2.错误回显；3.盲注；

防御：对请求参数进行消毒过滤，通过正则匹配过滤SQL文本信息。对于SQL可以使用预编译参数绑定的方式。





安全架构之——CSRF攻击（跨站点请求伪造攻击）

特点：用户登录之后，用户无感知，伪造用户提交请求，该攻击具有针对性（例如伪造用户去请求执行转账业务）。

防御：通过每次提交表单Token，服务端验证Token的合法性有效性；或者通过设备指纹、数据签名的方式检查请求来源是否合法、数据是否被篡改；或通过Referer Check检查来源是否合法；也可以通过验证码来验证是否为本人操作。

生产环境使用最好关闭错误回显，针对500错误应设置一个专门错误页面，避免暴露HTTP响应信息。针对HTML注释，在生产环境中响应给客户端的页面应去除敏感注释信息。针对文件上传，应限制文件类型，屏蔽可执行文件，对文件访问路径进行严格控制。针对路径遍历问题，应将JS、CSS静态资源文件放置于独立服务器、独立的域名，其他文件不使用静态URL访问，动态参数不包含文件路径信息。





安全架构之——Web应用防火墙

通过接入统一的Web应用防火墙拦截大部分攻击（例如ModSecurity），或在开源防火墙上再根据不同场景需求进行二次开发。





安全架构之——网站安全漏洞扫描

内部进行模拟黑客攻击，测试系统的拦截程度，不定期对开放的接口进行扫描，借助第三方漏洞扫描工具，试探和评估系统的安全性。

加密技术（三类）：单项散列加密、对称加密、非对称加密。

单项散列加密：用于不需要关注密文内容的场景，例如用户登录密码，只存储加密后的密文，再通过同样的算法进而验证用户身份。是一种不可逆的加密方式。

缺点：由于常见的单项散列加密算法就几种（MD5、SHA、MAC、CRC等），可通过大量的加密密文排列组合库（映射字典库）进行映射反查，从而“暴破”密码明文。改进：对加密内容进行加盐(salt)后再加密。





对称加密：对于一些敏感信息（比如银行卡号），在“内部”业务处理中需要使用明文信息，但又不希望“对外”暴露该信息的场景。即一个加密算法对称一个解密算法，通过相同的“密钥”既能进行加密也能进行解密。

常用算法：DES、TripleDES、RC2、RC4、RC5和Blowfish等。





非对称加密：与“对称加密”唯一不同的是加密算法的“加密密钥”和解密算法的”解密密钥”是不同的。用于通过公钥（公开的公钥证书）加密，再通过私钥（非公开的私钥证书）解密的场景，例如HTTPS。另一种场景是使用私钥加密，再通过公钥解密，例如需要验证签名的场景，验证数据来源并保证数据不被篡改的一种方式。





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

密钥加解密服务、密钥存储服务（数据分片存储）、与应用服务隔离，将职责划分开，降低因部分密钥数据泄露所带来的风险。





反垃圾邮件：

垃圾邮件识别架构：通过训练分类模型，采用分类识别算法，计算出是否为垃圾邮件的概率值。





贝叶斯分类算法（参考）：







布隆过滤器黑名单：

用较少的空间记录大量的黑名单内容，通过8个函数的计算值标记为二进制位，若8位都为1则判断为垃圾邮件。例如标记垃圾邮箱地址。

问题：存在误判的可能性，但不会出现漏判的情况。





风控系统：

1、利用规则引擎（需人为制定、维护）识别业务特征，例如识别风险交易。

2、利用机器学习训练识别模型，进而识别更多场景下的风险特征。





可用性度量：

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

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

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

两个9：基本可用，年度停机时间 < 88小时

三个9：较高可用，年度停机时间 < 9小时

四个9：具有自动恢复能力，年度停机时间 < 53分钟

五个9：极高可用，年度停机时间 < 5分钟

故障分管理：

将可用性的责任细分到每一个开发团队/开发人员身上，从而促进参与开发的每一份子都重视并主动提高开发质量等细节，从而提升系统整体高可用性。





故障处理流程及考核：





引起故障的原因：

1、硬件故障

2、软件BUG

3、系统发布

4、并发压力

5、网络攻击

6、外部灾害

提升系统可用性之——解耦

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

2、面向对象基本设计原则。

3、面向对象设计模式。

4、领域驱动设计建模。

提升系统可用性之——隔离

1、业务与子系统隔离。

2、微服务与中台架构。

3、生产者与消费者隔离。

3、虚拟机与容器隔离。

提升系统可用性之——异步

1、多线程编程。

2、反应式编程。

3、异步通信网络编程。

4、事件驱动异步架构。





提升系统可用性之——备份

1、集群设计

2、数据库复制

（CAP原理）





提升系统可用性之——Failover（失效转移）

1、数据库主主失效转移。

2、负载均衡失效转移。

（确认失效—>需要转移）

（设计无状态的服务）

提升系统可用性之——幂等

一个请求多次（调用）处理的结果要相同。

提升系统可用性之——事务补偿

通过执行业务逻辑拟操作，使事务回滚到事务前状态。

提升系统可用性之——重试

由于线程阻塞、垃圾回收或网络抖动，而无法及时返回，调用者可通过重试的方式修复单次调用的故障。（上游调用者超时时间要大于下游调用者超时时间之和。换言之上游超时时间要长一点，下游超时时间要段一段）





提升系统可用性之——熔断

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

从而降低某一服务故障而对整个系统造成的影响。



提升系统可用性之——限流

高并发场景下，若访问量超过了系统承受能力，可用通过对用户请求进行流量限制，即若访问量超过系统最大处理能力，则丢弃一部分请求，保证大部分用户可访问，（舍小顾全）进而提高整个系统的可用性。

限流算法：

1、计数器算法（固定窗口算法）（改进：滑动窗口算法）

2、令牌桶算法

3、漏桶算法（流量相对均匀）

4、自适应限流（实时自动评估QPS）





提升系统可用性之——降级

在高并发时，关闭一些非核心功能（降低服务等级），将资源留给核心业务。

提升系统可用性之——异地多活

在多个地区部署数据中心，每个数据中心都是活跃的。

难点：每个数据中心如何保障数据一致

发布流程





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





自动化部署





持续部署三步走：

1、持续集成（允许随时向公共分支提交代码，并立即自动化测试）

2、持续交付（除了单元测试及软件打包，持续交付会将软件部署到各种测试环境中）

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

持续部署流程





预发布验证

预发布服务器和正式服唯一不同的是没有挂在负载均衡上，外部用户无法访问。





代码版本控制

主干开发，分支发布（个人理解：适用于个人开发）

分支开发，主干发布（团队开发主要使用）

自动化发布

问题：多个分支合并到主干可能会发送冲突。





灰度发布

分批发布，每发布一批后观察一段时间，没问题再发布到下一批服务器，否则对最近发布的这一批服务器进行回滚。





网站运行监控

能尽早地发现问题，亦能在处理问题的过程中获得监控数据的支持，从而加快处理问题的速度。

监控数据采集：

1、用户行为日志搜集

2、服务器性能监控

监控系统架构：





高可用的价值观：

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

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

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