架构师第十一周总结

本周学习了一下七点

一、安全架构-Web 攻击与防护

二、安全架构-加密与解密

三、安全架构：反垃圾与风控

四、高可用：可用性度量

五、高可用：提高系统可用性的架构方案

六、高可用：架构运维方案

七、高可用故障案例分析

了解了一些通用的黑客攻击方式：xss 攻击，sql 注入，csrf 攻击

加密方式以及应用场景：单项加密（密码等不需要知道明文的加密），对称加密（身份证，手机号等需要知道明文的加密），非对称加密又根据加密和解密秘钥顺序分为 2 种：公钥加密，私钥解密，如 https；

私钥加密，公钥解密，如数据签名，比特币转账。

反垃圾邮件可以根据贝叶斯分类算法来确认这封邮件是垃圾邮件的概率。

布隆过滤器可以存储大量黑名单信息，也可以存储大量的订单信息，大量需要做标记的信息都可以使用。

交易时候的风控系统也是可以根据制定规则并判断该条订单是否是风险高的订单，机器学习在这方面也又了用武之地。

业界常用的可用性指标：两个 9 是基本可用， 年度停机时间小于 88 小时；3 个 9 较高可用，年度停机时间小于 9 小时；4 个 9 是具有自动回复能力的高可用，年度停机时间小于 53 分钟；5 个 9 是及高可用性，年度停机时间小于 5 分钟。

如果在公司中，可以使用可用性作为 kpi 考核指标，督促大家对自己的代码负责。

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

如何提高可用性

隔离：业务与子系统隔离；微服务与中台架构；生产者与消费者隔离；虚拟机与容器隔离

异步：多线程编程；反应式编程；异步通信网络编程；事件驱动异步架构

备份：集群设计；数据库复制：cap 原理

failover 失效转移：数据库主主失效转移；负载均衡失效转移；如何确认失效，需要转移？zookeeper 选主服务器的方式；设计无状态的服务

幂等：应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但是因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。

服务重复调用有时候是无法避免的，必须保障服务重复调用和调用一次产生的结果相同，即服务具有幂等性。有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都一样。但是对于交易等操作，问题就会比较复杂，需要通过简易编号等信息进行服务调用有效性校验，只有有效的操作才继续执行。

事务补偿：传统事务的 acid；原子性 atomicity，一致性 consistency，隔离性 isolation，持久性 durability；分布式事务的 base；基本可用 basic availability，软状态 soft-state，最终一致性 eventual consistency；事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态

重试：远程服务可能由于线程阻塞，垃圾回收或者网络抖动，而无法及时返还响应，调用者可用通过重试的方式修复单词调用的故障；上游调用者超时时间要大于下游调用者超时时间之和

熔断：当某个服务出席那故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用；断路器三中状态：关闭，打开，半开

限流：在高并发的场景下，如果系统的访问量超过了系统的承载能力，可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保障整个系统可用，保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是好过整个系统崩溃的，所有的用户都不可用要好

限流的几种算法：计数器算法：固定窗口，滑动窗口；令牌桶算法；漏捅算法

降级：有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，比如说在电商系统中有确认收货这个功能，即便我们不去确认收货，系统也会超时自动确认收货。

但实际上确认收货这个操作是一个非常重的操作，因为它会对数据库产生很大的压力：它要进行更改订单状态，完成支付确认，并进行评价等一系列操作。如果再系统高并发的时候去完成这些操作，那么会对系统雪上加霜，使系统的处理能力更加恶化。

解决办法就是在系统高并发的时候，比如像淘宝双 11 的时候，当天可能整天系统都处于一种极限的高并发的访问压力之下，这时候就可以将确认收货，评价这些非核心的功能关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易

异地多活：如果整个数据中心都不可用，比如说数据中在所在的城市遭遇了地震，机房遭遇了火灾或者停电，这样的话，不管我们的设计和系统多么高可用，系统依然是不可用的

为了解决这个问题，同时也为了提高系统的处理能力和改善用户体验，很多大型互联网应用都采用了异地多活的多机房架构策略，也就是说将数据中心分布在多个不同地点的机房里，这些机房都可以对外提供服务，用户可以连接任何一个机房进行访问，这样诶各级防都可以提供完整的系统服务，即使某一个机房不可使用，系统爷不会宕机，依然保持可用。

异地多活的难点是数据一致；问题：数据同步，数据冲突怎么办？

高可用运维想关内容：

自动化测试；持续集成；测试环境运行后进行预发布验证；代码版本控制；灰度发布；网站运行监控；自动运维等。

理念：保持简单，是问题易于发现，快速解决；目标明确，解决特定环境下的具体问题；价值回归，成本收益要合理