week11 安全稳定
作业一：
（至少完成一个）
导致系统不可用的原因有哪些？保障系统稳定高可用的方案有哪些？请分别列举并简述。
从软件到硬件的层面来看，导致系统不可用的原因有如下几点：
软件本身的 bug
软件的更新发布
高并发请求导致软件无响应或者崩溃
硬件故障
网络故障或者攻击
外部自然灾害
针对上述的问题，我们可以分别制定不同的保障方案：
软件本身的 bug:
分两方面考虑。第一从开发本身入手，通过制定合理的开发流程和规范，尽可能减少 bug 出现的概率。如常见的 code review,单元测试，和 SRE 规范等等，都可以有效减低 bug 出现的频率。第二是从 bug 的影响范围入手，构建快速的问题发现，定位和响应的运维平台，可以有效降低 bug 对业务产生的不良影响。如快速回滚，全链路追踪，预警平台等，都是比较有效的手段。
软件的更新发布
如果是服务器只有一个节点，软件的更新发布肯定是导致系统的不可用的。所以为了规避软件更新发布导致的系统不可用情况，常用的手段就是基于集群进行部署，然后通过滚动升级的方式来达到用户端的操作无感知。如果软件的规模足够大，还可以采用灰度发布这样的手段，通过流量切换的方式验证更新的功能，降低业务的影响。
高并发请求导致软件无响应或者崩溃：
在高并发的情况下面，一旦超过了软件正常的承受范围，软件就往往会表现出无响应甚至崩溃的情况。由于单个节点的处理能力总有上限，所以如果都要一个节点抗住所以的并发请求是不切实际的。通常是采用分流，截断和异步三种手段来解决这个问题。首先是分流，通过负载均衡的技术，将请求分发到集群的不同服务器，降低每个单点服务器的请求压力。其次在服务器节点有限的情况下面，通过熔断和断路器的机制，拒绝部分请求，保证系统总是可用的，防止被压垮。最后就是异步话，通常就是引入异步处理机制，比如消息队列，异步处理线程等，对瞬间高的并发流量进行削峰填谷，保证系统工作问题。
硬件故障：
硬件故障是常见的故障。硬件的损坏，比如内存错误，磁盘错误，网卡错误等等，在系统的运行过程中都是有可能会出现的。解决这个问题的基本思路就是备份。比如存储基于 RAID 进行，分布式存储 HDFS，服务节点集群化等等，都是通过备份的思路解决该问题。
网络故障或者攻击
网络故障或者攻击，属于我们只能被动防御的部分，因为我们无法从源头去解决这些问题。针对网络故障，比较常用的手段是，多运营商网络接入，如果其中有一个运营商的线路出现问题，可以通过 DNS 切换的方式，保证网络接入的高可用。针对网络攻击，一般的手段就是防火墙，包括硬件防火墙和软件防火墙，过滤掉非法的伪造的情况，保证正常客户可以将请求发送到服务器。
外部自然灾害
外部自然灾害通常指地震，洪水，战争等不可抗力，通常影响的访问就是某一个数据中心。对于大型的互联网应用来说，为了保证严苛的高可用要求，通常会选择两地三中心的方案对应用进行部署，然后通过其他的技术手段对数据进行跨机房的同步。
请用你熟悉的编程语言写一个用户密码验证函数，Boolean checkPW（String 用户 ID，String 密码明文，String 密码密文），返回密码是否正确 boolean 值，密码加密算法使用你认为合适的加密算法。
作业二：
根据当周学习情况，完成一篇学习总结
作业提交链接
第 11 周 安全稳定
11.1 安全架构-web 攻击防护
XSS 攻击
对 HTML 危险字符转义
SQL 注入攻击
正则匹配 SQL 关键字
SQL 预编译参数绑定
CSRF 攻击
表单增加 token，后台校验
要求用户输入验证码
检查请求头里面的 Referer 字段
其他常见漏洞的预防
关闭错误回显
清理 HTML 注释
只允许上传特定的文件
资源独立服务器，不要暴露文件路径
Web 应用防火墙 ModSecurity
网站安全漏洞扫描
11.2 安全架构 加密与解密
加密类型
单向散列加密
对称加密
非对称加密
密钥服务系统架构
密钥分片存储
密钥管理
开发申请密钥获取到 token
应用通过 token 获取完整的密钥
11.3 安全架构：反垃圾与风控
贝叶斯分类算法
布隆过滤器黑名单
风险控制
规则引擎
机器学习
11.4 高可用：可用性度量
可用性指标 = （1 - 网站不可用时间 / 年度总时间）* 100%
故障分管理 - 拆解可用性指标到团队和个人
11.5 高可用：提升系统可用性的架构方案
解耦 - 降低模块的耦合度
隔离
子系统隔离
微服务与中台架构
生产者消费者隔离
虚拟机与容器隔离
异步
多线程编程
反应式编程
异步通信网络编程
事件驱动异步架构
备份
负载均衡集群
数据库复制
失效转移
幂等
事务补偿
传统事务的 ACID
分布式事务的 BASE
通过执行业务逻辑逆操作，使事务回滚到事务前状态
重试
熔断
限流
固定窗口算法
滑动窗口算法
令牌桶算法
漏桶算法
自适应限流
降级
异地多活
11.6 高可用：架构运维方案
发布
自动化测试（测试脚本，测试内容，自动化测试和单元测试的关系）
持续集成，持续交付，持续部署
预发布验证（预发布服务器）
代码版本控制
主干开发，分支发布
分支开发，主干发布
自动化发布
提交发布请求-确认（QA，DBA，安全）->代码 merge->预发布验证->正式发布
灰度发布
分批发布（无故障-发布成功，有故障->故障回滚）
网站运行监控
用户行为日志收集，报警（阈值），自动控制
监控系统
监控系统架构（被监控系统，监控服务），大数据流计算技术
高可用架构
保持简单，目标明确，价值回归
11.7 高可用故障案例分析
故障一：
现象：
发布后，多台服务器告警，硬盘可以空间低于预警值
原因分析：
dubug 模式
经验教训
关闭不必须要的日志
合理的日志级别
故障 2:
现象：
应用发布后，数据库 Load 居高不下
原因分析：
某条 sql 引起，首页访问
经验教训
首页不应该访问数据库，静态，服务器，搜素服务器
首页是静态
故障三：
不定时响应超时，但是很快又接触，恢复正常，反复
原因：
程序中某个但例对象中对歌方法使用了 synchronized 修饰符，由于 this 对象只有一个，锁
经验教训
锁使用要谨慎，特别是长时间 IO
故障 4
现象
没有新发布，数据库 Load 飙升，很快失去响应
原因：
缓存服务器疏于管理，缺乏经验的工程师管理缓存服务器中全部的几十台 Memcached 服务器，导致了网站全部瘫痪的重要事故
经验教训
缓存服务器的管理上升的高度
故障 5
某应用发布后，服务器立即奔溃
原因：web 环境：Apache+JBoss（JBoss 启动耗时长，没有完全启动），JBoss 奔溃
经验教训：后台准备好后，前台再启动
故障 6:
用户投诉，上传图片非常满
原因：图片需要存储，个别文件非常大
经验教训：大小文件分别管理，根据不通文件类型和用途进行管理（隔离）
故障 7
某个应用突然变慢，网络带宽
原因：工程师压力测试
经验教训：线上环境要规范，报备，走正规变更流程
故障 8
现象：
应用发布后，数据库 Load 迅速飙升，超过报警值，回滚发布后，报警消除
原因分析
大量的数据库读操作，缓存的代码被注释掉了
经验教训
代码发提交使用 diff，交叉检查
故障 9
应用发布后，少量用户投诉无法正常访问功能，一点击显示出错信息
原因分析：
新用户，历史记录构造对象，新用户 null，导致 NullPointException
经验教训
空指针处理，输入对象尽量保证不是 null
11.8 课后练习
导致系统不可用的原因又那些？保证系统稳定高可用的方案又那些？请分别距离论述。
还未添加个人签名 2020.03.17 加入
还未添加个人简介
评论