第 11 周学习总结

安全架构

XSS：跨站脚本（浏览器可执行的脚本）。解决：用户提交的数据不能包含脚本，如果包含则使用HTML字符转义，比如"<"转成"&gt"。

SQL注入

CSRF 解决：表单token，验证码

文件上传 解决：上传文件白名单，存储时不用源文件名

路径便利: 根据URL猜文件路径，直接访问系统文件 解决：静态服务器



Web应用防火墙。ModSecurity中的正则表达式用来识别危险内容



安全防护模块第一天就应该有，至少可以识别http攻击。

网站安全漏洞扫描。



安全架构师-- 安全报告、日志分析、安全预案

性能架构师-- 当前状况、当前瓶颈、预估、功能方案性能评估



信息安全

单向散列加密：

常用于用户密码保存。防止撞库，需要加盐。



对称加密：

敏感信息保存在数据库、日志、网络传输时，经常使用对称加密。

非对称加密：

为了保证只有自己和数据生产者知道信息（比如https），加密使用公钥，解密使用私钥。

当加密使用私钥，解密使用公钥，就是电子签名模式。



加密架构：

1. 秘钥本身分段存储

2. 应用程序没有办法接触到完整的秘钥



反垃圾邮件

贝叶斯分类、布隆过滤器（用来在大量数据中判断某个值是否存在）黑名单



电商风控：规则引擎，机器学习



高可用系统

可用性指标：业界通常用多少个9来衡量可用性。两个9基本可用，年度停机88小时。3个9较高可用，年停9小时。4个9高可用，年停53分钟。当局部不可用，需要根据局部占比计算停机时间。

故障分管理：根据故障轻重，给责任人和团队评分。

故障处理流程：先处理故障，后评分。



引起故障的可能原因：硬件故障、软件bug、系统发布、并发压力、网络攻击、外部灾害。

高可用的架构策略

解耦：高耦合度的系统很难找到出问题的地方，导致故障排除时间提高。

隔离: 使故障不要扩散

异步：互不影响的事务异步处理

备份：任何一个应用应该有至少两个服务器对外提供服务

失效转移

幂等：必须保证服务调用一次和多次的结果是一样的。

事务补偿：为了一致性。ACID vs. BASE

重试：多级调用，顶层超时时间要大于底层超时时间之和

熔断：使用断路器。断路器状态：关闭（正常）、打开、半开（服务不对外服务）。响应延迟活部分失败，断路器半开，当问题进一步恶化，断路器打开。

限流：处理高并发场景，系统收到的压力超过服务能力，限制系统处理的流量。固定窗口计数器、滑动窗口、令牌桶算法、漏桶算法、自适应限流。

降级：将某些不关键的功能降级，暂时停用，腾出有限的资源给当前最需要的服务使用。

异地多活：应对地区性灾害。



发布时期的高可用：与负载均衡相关，分批次发布。

自动化的测试：软件早期（比如刚完成上线）使用自动化测试不合适，这是因为软件功能变化比较大，自动测试成本高。随着系统稳定，手工测试与自动测试的平衡点开始使用自动测试会在后续的时间里带来更低的测试成本。



持续部署（中小团队）：持续集成、持续交付、持续部署。提交代码->单元测试->打包->重新部署->集成测试->上线部署

预发布验证

代码测试分支、开发分支、发布分支及主干需要有一套管理标准。

自动化发布



高可用价值观：1. 保持简单，使问题易于发现。2. 目标明确，解决特定环境下的具体问题。3. 价值回归，成本收益要合理。