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

用户头像
诺乐
关注
发布于: 2020 年 12 月 07 日

(课程笔记+个人小结)



安全架构之——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、服务器性能监控

 

监控系统架构:





高可用的价值观:

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

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

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



用户头像

诺乐

关注

还未添加个人签名 2018.12.01 加入

还未添加个人简介

评论

发布
暂无评论
【架构师训练营 1 期】第十一周学习总结