1. 信息加密技术及密钥安全管理

在任何公司，都可能会有数据信息的泄漏，有些可能是因为黑客攻击，有些可能是内部员工。这些都是避免不了的，数据是公司的资产，拿到外面是可以卖钱的。既然信息泄漏是避免不了的，那么就需要把数据进行加密，让泄漏出去的数据也无法使用、没有价值。除了数据库里面的数据，还需要防范日志里面的数据，日志的数据方法的可能没有那么严格。

通常为了保护网站的敏感数据，应用需要对这些信息进行加密处理，信息加密技术可以分为三类：单向散列加密，对称加密，非对称加密。

1.1 单向散列加密

这个加密是一个单向的过程，加密后的密文，不能通过任何的方式还原得到明文。例如：用户的密码，通常情况下，服务器并不会直接保存用户的密码明文，而是通过单向散列加密的方式计算出一个值来，服务器保存的是这个加密后的值。当用户登录时，使用登录时传来的密码，通过单向散列加密计算出一个值，和数据库里面保存的值进行比较，如果相同则认为用户输入的密码是正确的，否则就是错误的。密码校验的关键点是校验密码是不是正确的，而校验密码是否正确并不一定是需要对比密码（就是不需要通过明文对比），对比密码散列加密后的值也是可以的。因为加密算法的原因，不同的数据进行加密后的值是不一样的。从能知道用户输入的密码是否正确。

但是，因为加密的算法就那么几个（有限的），大家都在使用，如果只是使用算法对用户的密码进行加密是不可靠的。因为算法对同一个值计算多次得到的结果是相同的。假设：密码是 123456，经过计算后的加密数据是 78910。那么当别人拿到 78910 的时候就会猜测密码是不是 123456。因为对于那些做数据倒卖的人来说，曾经卖过的用户密码可能会保存起来，并通过不同的密码加密得到密文，当从其它渠道得到了用户信息后，并且用户的密码是密文。那就可以把这个密文和之前计算的密文作比较。如果相同，那么密码就被猜出来了。所以通常情况下，做单向散列加密的时候，输入的参数并不只是密码，而是会有用 id 或其他的信息参与计算。通常把这次额外的信息叫做盐（salt）。加盐计算。 这样因为盐的参与，加密后的数据就不一样的。即使得到密文，也很难通过密文进行对比，找到密码。

严格意义来说，加密后的数据并不能算是密文，因为还原不会去，就是类似指纹，唯一性的内容。

上图是一个用户注册和登录流程的时序，从图中可以看出，保存到数据库中的永远都是加密后的密文，而不是明文，用户登录的时候，也是通过对比密文判断用户输入的密码是否正确。通过这种方式保存的密码，不能提供取回密码的功能，因为系统里面也不知道密码。如果能做到说明系统就是脆弱的，密码被盗后，会泄漏用户的真实信息，最好的方式是谁也不知道密码。只能提供重置密码的功能。

1.2 对称加密

对于一些需要知道原文的敏感信息，可以使用对称加密的方式保护用户数据。不过这种方式需要把密钥管理好。加密密钥和解密密钥是同一个。

明文->加密>密文>解密>明文

在系统内部，大部分都是使用对称加密。

1.3 非对称加密

加密密钥和解密密钥是不一样的。一个加密密钥和一个解密密钥。

使用场景：https 多数人进行加密通信，同时数据不会被窃取。加密密钥是公开的，解密密钥是私有的。

电子签名：加密密钥是私有的，解密密钥是公有的。

2. 密钥安全管理与加解密服务系统架构

保证整个系统中没有人知道所有的信息，密钥和算法都是不同的人知道的。这样当出了事情的时候，可以自证清白。如果有一个人对整个系统所有事情都知道，密钥知道，算法知道，还能拿到数据，当出现重大事故的时候（用户信用卡被盗刷了）。那么这个人就是第一嫌疑人。

应用服务的开发者就是密钥的申请者，某个业务的数据需要加密了，就需要申请密钥，密钥申请到了以后会有多个密钥管理者，每个管理这拿到一部分密钥片段。分别存在不同的数据库或者文件系统中，由不同的这些数据库或文件系统由不同的运维人员维护。

3. 反垃圾邮件

反垃圾机器人训练模型

反垃圾，不只是邮件里面用到了，其他很多地方也用到了，如：抖音等用户可以上传数据的应用。如果用户上传数据后不审核一番，那么这个应用就会变成一个垃圾场，正常的用户就会逃离这个应用，因为上传垃圾的并不是用户，而是一些机器人（程序）。垃圾的内容包括但不限于：广告，色情，设计政治的内容。

首先是垃圾的识别，使用分类算法，对包含某个特征的数据进行训练，然后人工打标签，得到分类模型。最后使用分类算法识别垃圾。因为机器本身并不知道那些是垃圾，所以需要人工干预。

常用的分类算法：

1. 贝叶斯分类算法

训练模型：

4. 布隆过滤器黑名单

如果一个邮箱经常发送垃圾邮件，那么可以认为这个邮箱就是一个垃圾邮箱，后续如果这个邮箱发送邮

件，直接把发送的邮件当作垃圾邮件就可以了， 但是这些邮箱地址也是使用程序批量申请的，垃圾邮箱就会有很多几亿，几十亿个，甚至更多，如果把这些数据保存起来，就会浪费磁盘资源，这个时候就需要一种工具能用尽可能少的磁盘空间，更快的判断时间，判断出一个邮箱是否为垃圾邮箱，这时候布隆过滤器就派上用场了。

布隆过滤器，并不会保存所有的垃圾邮箱，而是通过算法计算后，判断某邮箱是否为垃圾邮箱的。存在误判，有可能把不是垃圾邮箱的邮箱认为是垃圾邮箱。但是不会漏判。如果一个地址是一个曾经存在的垃圾邮箱，那么一定不会出错，从认为是一个正常的邮箱地址。

布隆过滤器，功能就是能快速的判断和减少空间。在新闻推荐的场景中也可以使用，判断某文章是否曾经给用户推荐过，推荐过就不在重复推荐了。

5. 高可用指标

怎么样的系统算是高可用？ 业界一般使用多少个 9 来衡量系统的可用性。如：4 个 9，表示一年内 99.99%的时间系统是可用的。

计算公式：

系统年度可能性指标 = （1-系统不可用时间/年度总时间）* 100%

系统不可用时间（故障时间） = 故障修复时间-故障发现（报告）时间点

对可用性的定性描述：两个 9 是基本可用，年度停机时间小于 88 小时；3 个 9 较高可用，年度停机时间小于 9 小时；4 个 9 是具有自动恢复能力的高可用，段杜停机时间小于 53 分钟；5 个 9 是极高可用性，年度停机时间小于 5 分钟。由于可用性影响因素很多，对于系统整体而言，达到 4 个 9，乃至 5 个 9 的可用性，除了过硬技术，大量的设备资金投入和工程师的责任心，还要有个好运气。

故障分管理：

故障处理流程及考核：

5.1 引起故障的原因：

1. 硬件故障

2. 机器 cpu 坏了

3. 硬盘坏了

4. 风扇坏了

5. 网卡坏了

6. 路由器坏了

7. 软件 bug

8. 系统发布

9. 系统发布是系统比较脆弱的时候。版本的问题，数据库和代码不匹配，配置忘了加了，配置忘了更新。各种问题。

10. 并发压力

11. 高并发下情况下，资源好景系统崩溃了。

12. 网络攻击

13. 使系统没有足够的资源处理用户请求，导致不可用。

14. 外部灾害

5.2 高可用架构模式

5.2.1 解耦

系统越简单，出错的概率就越小。越复杂出错的可能性就大，出错了以后不能很快的定位并解决故障。

对于大多数系统而言，造成系统不可用的问题都是代码的问题，当然淘宝，google 这种量级的不在这个范畴。

• 高内聚、低耦合的组件设计原则

• 面向对象基本设计原则

• 面向对象设计模式

• 领域驱动设计建模

5.2.2 隔离

在物理层面对故障进行隔离，不扩散。

• 业务与子系统隔离

• 微服务与中台架构

• 生产者消费者隔离

• 虚拟机与容器隔离

5.2.3 异步

异步架构提升高可用，不会因为某部分功能不可能导致整个功能不可用。

• 多线程编程

• 反应式编程

• 异步通信网络编程

• 事件驱动异步架构

5.2.4 备份

任何一个应用都要有至少 2 个服务器组成集群，保证一台服务器不可用后，系统还是可用的。任何时候都要考虑当这个服务器、服务、功能、系统不可用的时候，会出现什么问题？ 当整个系统不可用的时候影响大吗？ 大的话就感仅多加几个备份的服务器。提升高可用。架构师关注的重点。

• 集群设计

• 数据库复制

5.2.5 失效转移

• 数据库主主复制

• 负载均衡失效转移

如何确认失效，需要转移？

需要一个统一的机制，确认失效。当认为失效后，整个集群都能达成共识，认为是失效的。

设计无状态的服务。

5.2.6 幂等

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

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

5.2.7 事务补偿

通过执行业务逻辑的逆操作，使事务回滚到事务前状态。

传统事务的 ACID

分布式事务的 BASE

5.2.8 重试

远程服务可能会由于线程阻塞、垃圾回收或者网络抖动，而无法及时返回响应，调用者可以通过重试的方式修复单次调用的故障。

注：上游调用者超时时间需要大于下游调用者超时时间之和。

5.2.9 熔断

当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务器的调用。

当断路器打开时，服务不可被调用。

5.2.10 限流

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

限流的几种算法：

• 计数器算法（固定窗口，滑动窗口）

• 令牌桶算法

• 漏桶算法