架构师训练营 -week11- 总结
本周重点学习了以下几个方面的内容：
安全架构设计的关键点
高可用架构设计的关键点
安全架构设计：从安全防护、加解密、风控和反垃圾几个方面进行了设计：
常用的攻击手段有
XSS 攻击
CSRF 攻击（注意 CSRF 和 XSS 的区别）
CSRF 相对于 XSS 漏洞的危害程度更高一些。
XSS 有局限性，而 CSRF 则不。
CSRF 相当于是 XSS 的基础版，CSRF 能做到的 XSS 都可以做到。
XSS 主要指向客户端，而 CSRF 针对服务端。
XSS 是利用合法用户获取其信息，而 CSRF 是伪造成合法用户发起请求。
zhihu 上有个帖子可以作为参考
通过错误回显寻找漏洞攻击
通过 HTML 注释寻找漏洞攻击
SQL 注入攻击
文件上传攻击
路径遍历
相关防御手段有
Web 应用防火墙
网站安全漏扫
信息加密和密钥安全管理
单向散列加密
对称加密
非对称加密
密钥安全管理与加解密服务系统架构
信息过滤与反垃圾
贝叶斯分类算法
布隆过滤器黑名单
风控系统：反欺诈、反黄牛、反洗钱、反黑客盗号、反竞争对手恶意下单占用库存等等。风控的手段包括机器自动识别和人工识别。机器自动识别的方式主要有规则引擎和机器学习。
另外，除了技术本身的安全架构之外，还需要加强安全管理，包括制定安全管理制度，提高人员的安全意识，防止社会攻击等等，毕竟每年都有很多通过社会攻击入侵到政府系统的惨痛案例。
高可用架构设计
高可用架构设计从生产环境中可以遇到的故障原因，以及解决方案进行的讲述：
可用性指标：
业界用多少个 9 来衡量网站的可用性，如 QQ 服务 99.99% 可用，一年中只有 0.01% 的时间不可用，也就是一年中大约 53 分钟不可用。
网站年度可用性指标 = (1 - 网站不可用时间/年度总时间) * 100%
网站不可用时间 = 故障回复时间点 - 故障发现时间点
2 个 9 是基本可用，年度停机时间小于 88 小时
3 个 9 较高可用，年度停机时间小于 9 小时
4 个 9 是具有自动恢复能力的高可用，年度停机时间小于 53 分钟
5 个 9 是极高可用性，年度停机时间小于 5 分钟
一般 3 个 9 和 4 个 9 比较常见。
导致系统不可用的原因可能有如下这些（包括但不限于）：
内部原因导致：
应用系统的配置错误（发布过程中可能出现）
系统 bug（例如：慢 SQL、缓存中存在大对象、Java 应用的内存泄露造成频繁的 FullGC 等）
系统中的中间件故障(网关, MQ 等中间件不可用)
系统超过容量
外部原因导致：
大并发请求造成应用系统过载
硬件和网络故障
系统漏洞被黑客攻击, 比如 SQL 注入后删除了关键业务表或者数据库, XSS 攻击造成系统的页面执行恶意的脚本
不可抗拒的自然灾害, 如数据中心被破坏, 到数据中心的网络光纤被挖掘机挖断
保证系统高可用的方案有:
系统间解耦：通过减少依赖，逻辑上减小故障的影响范围，一方面从软件设计层面来进行优化；一方面从架构设计层面来优化，例如引入消息队列等中间件。
冗余： 避免系统应用集群的单点故障问题，小规模系统采用负载均衡，大规模系统可以考虑使用异地多活。
引用灰度发布机制：在版本升级的过程中引入预发环境发现和避免验证系统配置问题。
引入监控系统：监控系统的关键参数: 应用服务宿主机的负载, 内存, CPU, 硬盘, Linux 服务的 INode 信息; 应用服务的堆栈信息, 线程池信息，Java 进程的 GC 状况，接口的异常信息， 接口服务的调用链路节点耗时信息, 中间件和数据存储的关键参数等。
性能测试：了解系统容量的瓶颈, 在监控系统中设置合理的关键参数的预警阈值。
安全防护：防止系统被攻击，比如在网关中引入 WAF 等设备， 在 Java 应用数据库访问层适用 PrepareStatement 防止 SQL 注入，并且对系统要定期做漏扫，补丁升级等工作。
限流熔断：在系统过载的时候引入服务的限流和降级的机制防止系统过载。
其他为了提高系统可用性而衍生出的流程：
持续部署三步走：
持续集成，向公共分支提交代码并触发自动化测试。
持续交付，除了跑单元测试及打包，持续交付还会将软件部署到测试环境。
持续部署，代码在没有人工干预的情况下，被测试、构建、部署并推送生产环境。
发布流程：
预发布验证
灰度发布
全量发布
大道至简，知易行难 2017.12.27 加入
想成为合格架构师的架构师
评论