「架构师训练营 4 期」 第十一周 - 001&2
作业一:
(至少完成一个)
导致系统不可用的原因有哪些?保障系统稳定高可用的方案有哪些?请分别列举并简述。
请用你熟悉的编程语言写一个用户密码验证函数,Boolean checkPW(String 用户 ID,String 密码明文,String 密码密文),返回密码是否正确 boolean 值,密码加密算法使用你认为合适的加密算法。
作业二:
根据当周学习情况,完成一篇学习总结
答案一
题目一
导致系统不可用的原因有哪些?保障系统稳定高可用的方案有哪些?请分别列举并简述。
导致系统不可用原因从来源分类:
第一 人为变更导致 (70%)
第二 其他原因(30% )
硬件故障
软件 BUG
系统变更
并发压力
网络攻击
外部灾害
之前在进行混沌工程项目的时候简单梳理了故障分类如下:
保证高可用的方案
解耦:设计高内聚低耦合实现应用解耦
隔离:资源隔离/逻辑隔离/线程隔池离等
异步:异步降低耦合,削峰
备份:做好备份,通过集群或者主从/多副本等
负载均衡 &失效转移:依赖于网关/注册中心实现服务发现和失效转移。
幂等:避免重试引起脏数据
事务性:保障数据宕事务性,避免脏数据
重试:合理重试保证生效,避免学霸
熔断:下游出现熔断,上游降级处理不调用
限流:网关限流及应用框架自适应限流
异地多活:单元化
题目二
doing……
答案二
安全架构:WEB 攻击与防护
常见攻击方式及应对方式
XSS 攻击
跨站点脚本攻击的攻击方式,通过 js 脚本来实现扩散,攻击过程示例如下:
用户自己登陆需要浏览的网页
攻击者推送攻击脚本
用户点击执行该脚本
脚本像服务器提交请求攻击
主要防御手段:主要是 html 的语言危险字符转义来实现防攻击。
SQL 注入攻击
sql 提交的时候不是最常见的用户名,而是后面增加 sql 命令的字符串来实现自己需要的命令。
通常来说,如果网站采用开源软件搭建,网站的数据结构或者表信息是公开的,能够借此找到,另外就是 sql 端的错误会写,如果 sql 的错误会写到了浏览器端可以借此来获取数据库信息进而进行攻击。
防止 sql 注入攻击:
进行请求的消毒和过滤,非法攻击字符的攻击
使用预编译的方式,通过 PrepareStatement,可以使用带有占位符的 SQL 语句预先生成执行计划,当给定占位符参数时,就可以直接交给执行引擎执行。
CSRF 攻击
跨站点请求伪造攻击,主要是用户处于登录态的情况下,提交 http 请求来实现攻击,跟 XSS 的区别是 XSS 主要是依赖于脚本,CSRF 主要是依赖于钓鱼网站等方式(网站访问响应包含攻击命令),更具有针对性,攻击的流程如下:
用户登录正常站点
用户访问攻击者的服务器返回响应
用户执行攻击者服务器响应(内含另外的请求)
请求攻击了正常站点
CSRF 攻击防御手段:
在网站页面包含另外的表单 token 来验证有效性,这个 token 需要根据响应页面进行随机构造,这样子避免了攻击者预先构造的请求中包含这些 token。
另外是验证码操作,但是这个会更加复杂,在移动互联中,APP 中包含一些用户特征(指纹、人脸等)通过加密算法构造的签名来进行请求处理,更加安全。
记录 refer 信息,特别是跨域的情况下。
其他需要关注的安全漏洞
错误 node 回显
html 注释
文件上传限制
路径遍历请求
注意 error code 的错误回显,需要关闭。
加密与解密
在攻击和防护之外,黑客更多的是想针对于攻击获取信息进而获利(直播这种为了礼物抽奖而生或者是电商的优惠券玩法在业务场景下另外考虑),针对于信息获利的情况,除了安全防范之外,加密和解密更是一个非常重要的要求。
信息加密技术及秘钥安全管理
加密技术可以分为三类
单列散列加密
对称加密
非对称加密
单项散列加密
整个加密过程单项,通过加盐的方式加密不支持解密。
这种加密不需要知道明文,只需要进行身份确认不需要知道真实的密码,只需要进行校验即可。
劣势:单项散列的密码宕加密算法固定的,如果明确知道明文-密文的对应关系,或者是通过碰撞能够依赖密文映射到明文。
处理方案:在进行加密之外,通过加盐(自定义字符串或者用户 id 等)的方式来进行额外的加密。
常用场景:无需解密只需要校验的场景,例如用户密码。
对称加密
通过密钥能够对明文进行加密,依赖于解密算法进行解密。
常用场景:信用卡/银行卡卡号等
非对称加密
跟对称加密相比,非对称加密主要的区别是加密密钥和解密密钥是不同的。
常用场景:
加密公钥,解密私钥 - https 协议,这个要求加密密钥是公开的公钥,所有的客户端浏览器使用(证书中)加密密钥进行加密请求,解密密钥是私钥,只有后端服务器拥有来解密。
加密私钥,解密共钥 - 区块链的数据签名场景,某个人对于信息加密并发出来,外界可以用公钥进行解密,可以明确信息来源的准确性。
注意
🔲【任务】其实 HTTPS 在内容传输的加密上使用的是对称加密,非对称加密只作用在证书验证阶段
① 证书验证阶段:
1)浏览器发起 HTTPS 请求;
2)服务端返回 HTTPS 证书;
3)客户端验证证书是否合法,如果不合法则提示告警。
② 数据传输阶段:
1)当证书验证合法后,在本地生成随机数;
2)通过公钥加密随机数,并把加密后的随机数传输到服务端;
3)服务端通过私钥对随机数进行解密;
4)服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输。
🔲【任务】问题来了,为什么数据传输是用对称加密?
首先:非对称加密的加解密效率是非常低的,而 http 的应用场景中通常端与端之间存在大量的交互,非对称加密的效率是无法接受的。
另外:在 HTTPS 的场景中只有服务端保存了私钥,一对公私钥只能实现单向的加解密,所以 HTTPS 中内容传输加密采取的是对称加密,而不是非对称加密。
密钥安全管理与加解密服务系统架构
主要模块
加解密服务接口:对应用来根据密钥进行加解密
密钥服务:进行真正的加密和解密服务
密钥管理:通过密钥申请/管理和安全三方审核来管理
密钥存储:不同人员分片管理和分片存储来进行管理
处理流程
开发申请密钥,申请到 token
审核通过后,密钥分片存储
应用携带 token 进行认证,跟密钥服务获取密钥返回给应用 sdk
应用依赖 sdk 进行加密和解密
反垃圾与风控
反垃圾邮件
历史邮件分类并处理,区分正常邮件和垃圾邮件用于训练
提供分类算法进行训练,确定分类模型
后续邮件依赖于分类识别算法进行分类
持续进行分类模型的训练和优化
贝叶斯算法
概率论中的一个问题解决算法,不走赘述。
公式说明:P(B|A)在 A 发生的情况下,B 发生的概率是多少
模型训练及应用过程
计算特征概率
样本提取特征
以来特征计算概率
输出概率建议
布隆过滤器
场景说明:发送垃圾邮件的邮箱地址作为用户黑名单,这里使用布隆过滤器黑名单来计算并存储,以实现较小的黑名单存储大量的订单信息的场景∂。
通过八个函数来计算转换成二进制,如果计算出来都是 16 个 bite (2GB)的 8 个地址都是 1,来用少量的空间通过概率的方式统计,可能存在误判的情况。
风控系统
以电商为例,常见的风控场景举例如下。
账户风险:盗号,恶意账号等
买家风险:下单占用库存这种不正当竞争,利用促销抢占低价商品,拒绝收货/欺诈退款/虚假询盘等
卖家风险:恶意欺诈,炒作信用,虚假发货,违禁和侵权等
交易风险:信用卡盗刷,支付欺诈,洗钱等
规则引擎
依赖一些规则条件指标来判断,根据行为特征来判断。
机器学习
规则引擎适合于初期风险防控,但是随着体量和规则的增加,会出现规则错误,耗时严重等各种问题,解决这个的方案就是通过机器学习来判断风险的分值来进行计算。
高可用及度量
可用性指标 99.999%
故障分管理
依赖于故障权重来计算整体可用性
业务分级 &权重
故障分级及升级
故障分计算流程
故障原因
硬件故障
软件 BUG
系统变更
并发压力
网络攻击
外部灾害
高可用架构
解耦
高内聚/低耦合的设计原则 - 6 种
面向对象基本设计原则 - 5 种
面向对象设计模式 - 23 种
领域驱动设计建模
隔离
异步
多线程编程
反应式编程
异步通信网络编程
事件驱动异步架构
备份
集群设计
多节点
主备
N 副本
数据库复制
cap 原理
失效转移 &负载均衡
有状态服务
无状态服务
幂等
超时/响应丢失 &重试
异步消费 ack
事物性
ACID:原子性(atomicty),一致性(consistency),隔离型(独立性 isolation),持久性(durability)
BASE:基本可用(basic availability),软状态(soft-stat),最终一致性(eventual consistency)
事物补偿:通过执行业务逻辑的逆操作,使事物状态会滚到事务前的状态。(类似 redo 和 undo)
重试
为什么会有重试?错误常见,垃圾回收/网络抖动/垃圾回收/请求放大。
上游调用超时时间大雨下由调用的超时时间之和
熔断
断路器三种状态:关闭,打开,半开
限流
计数器算法(固定窗口)
计算器算法(滑动窗口)
令牌桶算法
漏桶算法
自适应限流
异地多活
高可用架构运维
CICD
持续集成
持续交付
持续部署
发布流程
自动化测试
代码管理
主干开发,分支发布 a
分支开发,主干发布
灰度发布
系统监控
用户行为日志
服务器性能监控
自动控制
高可用故障案例分析
1.日志等级不合理导致日志过多,磁盘空间被占满引起系统故障。
2.平台架构不合理,在首页加载动态接口,每次请求首页会触发应用查询数据库,导致数据库异常
3.应用单例对象加锁不合理,某个远程调用也进行枷锁,导致每次执行远程调用就会被锁定引起系统告警
4.数据库服务器突然 load 飙高直到崩溃,是因为运维不合理操作导致缓存不可用,穿透到数据库引起数据库负载飙升和异常
应用发布之后服务崩溃,启动顺序不合理先启动前台服务后启动后台服务导致请求堆积引起异常
上传图片非常慢,查看是因为存储服务器中存在不合理的大文件操作导致磁盘 IO 被占用
某个时间段内应用访问满,网卡流量降低,排查发现是同机柜宕压测导致带宽被耗尽引起的异常
数据库操作没有进行审批订正导致应用异常
应用发布 load 飙高,应用没有从缓存读取,在开发的时候为了方便进行注释导致的问题
空指针异常导致偶发报错。
版权声明: 本文为 InfoQ 作者【凯迪】的原创文章。
原文链接:【http://xie.infoq.cn/article/d243b09ca9ff29335c6b96ec1】。文章转载请联系作者。
评论