架构师的 36 项修炼

原视频地址

这是B站上的一个教程，大概讲述了技术人员的大体学习的要求，架构的能力提升。从总体> 上提出了一个框架性的范围，我个人觉得还是蛮拥有的，尤其现在网上的知识太多，容易让人眼花缭乱，有了一个系统性的概念在学习的时候就会少一些迷茫，多一点方向。

提升技术实力和架构思维

00-开篇

技术人应具备的特点

• 强烈好奇心
• 敏锐的嗅觉
• 扎实的技术基础
• 出色的编程能力
• 深刻领悟主流技术产品和模式

架构知识体系

01- 大型架构的演进之路

1.1 大型互利网系统的特点

1. 高并发大流量
2. 高可用
3. 海量数据
4. 用户分布广泛、网络情况复杂
5. 安全环境恶劣
6. 需求快速变更，发布频繁

1.2 系统处理能提升的两种途径

一 垂直伸缩

单台服务器能力提升

• 缺点：
  1. 达到某程度后，增加计算能力需要更多的花费
  2. 有物理极限
  3. 操作系统的设计或者应用程序自身制约着垂直伸缩

二 水平伸缩

增加服务器

1.3 大型互联网架构演化过程

• 单机系统 ： 少量用户
  • 应用程序
  • 文件
  • 数据库
• 数据库与应用分离： 万级用户
  • 单机系统上三个部分分开发部署
• 使用缓存改善性能、应用服务集群化 ： 十万级用户
  • 分布式缓存服务器
  • 本地缓存
• 使用反向代理和CDN加速响应、数据库读写分离 ： 百万级用户
  • CDN服务器
  • 负载均衡调度服务器
  • 应用服务器集群
  • 数据库主从读写分离
• 使用分布式文件系统和分布式数据库系统 ： 千万级用户
  • 分布式文件系统
  • 分布式数据库服务
• 使用搜索引擎、Nosql、消息队列与分布式服务 ： 亿级用户
  • 搜索引擎服务器
  • noSql服务器
  • 分布式服务
  • 分布式消息队列

总结：

• 大型互联网系统的挑战 →
• 提升系统处理能力的两种手段 →
• 单机系统到分布式系统 →
• 使用各种缓存 →
• 分布式存储 →
• 微服务与异步架构

02- 分布式缓存

2.1 缓存的特点

• 技术简单
• 性能提升显著
• 应用场景多

缓存为什么能显著提升性能

1. 缓存数据通常来自内存，比磁盘访问速度快
2. 缓存降低数据库、磁盘、网络的负载压力，使这些I/O设备获得更好的响应特性
3. 缓存存储数据的最终结果形态，不需要中间计算，减少CPU资源消耗

2.2 缓存的关键指标

• 缓存键集合大小：高效使用、减少数量
• 缓存可使用空间：可用内存大小
• 缓存寿命：缓存对象的生存时间TTL
  • 超时失效
  • 实时清除

缓存数据存储（hash表）

• 通常是一个顺序表

缓存的关键指标：命中率

• 缓存是否有效依赖于多少次重用同一个缓存响应业务请求，这个度量指标称作缓存命中率；
• 若查询一个缓存，诗词查询就此能够得到正确的结果，那么它的命中率是90%；
• 影响缓存命中率的三个重要因素：缓存键集合大小、内存空间和缓存寿命

2.3 缓存类型

• 代理缓存：如页面缓存，一般不受管理
• 反向代理缓存: 存在于数据中心， 多层反向代理缓存
• CND缓存：来源网络CDN服务商
• 对象缓存：

通读缓存（read-through）

• 代理缓存、反向代理缓存、CDN缓存都是通读缓存

• 若通读缓存给客户端返回缓存资源，或在请求未命中缓存时获取实际数据

• 客户端连接的通读缓存而不是生成响应的原始服务器。

旁路缓存（cache-aside）

旁路缓存通常是一个独立的键值对（k-v）存储，对象缓存就是一种旁路缓存。

各种介质数据访问延迟

合理使用对象缓存

1. 频繁修改的数据 （读取比例2：1以上）
2. 没有热点的访问
3. 数据不一致与脏读： 一般通过失效时间解决，可接受的失效时间，不能接受就进行失效通知
4. 缓存雪崩： 数据库的设计是在强缓存的情况下设计的，所以缓存的可用性非常重要

2.4 分布式缓存

• 分布式缓存架构
• 分布式缓存模型
• 一致性hash算法：
  • 扩容效果较好， 只影响hash环上的一小段
  • 缺点：hash值是一个随机值，放在环上可能是不均衡的，导致各个服务器的压力不一致
    • 希望新增节点的时候能分摊所有节点的压力，而不是只影响就近的节点
    • 算法改进：使用虚拟节点的方法，把一个服务器化成若干个虚拟节点， 把若干的虚拟节点的hash值放在hash环上。
    • 在实践中一般把一个节点虚拟成200个虚拟节点

分布式对象缓存个

• 数据读写的时候怎么找到正确的缓存服务器？路由算法（取模算法/一致性hash算法）

2.5 缓存注意事项

• 频繁修改的数据：
• 没有热点的数据： 命中率差
• 数据不一致
• 缓存雪崩：

总结回顾：

• 缓存的优点： 简单、提升明显

• 影响缓存的关键指标：命中率（key大小，内存大小，寿命）

• 缓存的主要类型：通路缓存：代理、反向代理、CDN；旁路缓存：对象缓存
• 合理使用缓存的关注点： 频繁修改/热点/一致性/雪崩
• 分布式对象缓存：路由算法实现（一致性hash）
• 缓存无处不在：性能优化的重要手段

03 分布式消息队列

• 同步与异步
  • 同步调用方法
  • 异步调用方法
• 异步架构
  • 异步调用实现框架
  • 消息生产者
  • 消息消费者
  • 分布式消息队列
  • 点对点架构模型
  • 发布订阅模型
• 常用消息队列产品
  • RabbitMQ
  • ActiveMQ
  • RocketMQ
  • Kafka
• 消息队列异步架构的反模式
  • 阻塞式调用
  • 生产者消费显式依赖
  • 缺乏坏消息处理机制
• 消息队列异步架构的挑战
  • 消息无序
  • 消息重入队列
  • 竞态条件
  • 复杂度

3.1 同步调用与异步调用

同步调用

异步调用

3.2 消息队列构建异步调用框架

三个重要的角色：

消息生产者

是客户端的一部分代码， 用来初始化异步处理 ；创建一个合法的消息，发送给消息队列

消息队列

是消息发送的目的地和发给消费者的缓冲。

• 共享文件夹
• 关系数据库
• NOSQL
• 分布式消息队列服务器

消息消费者

由应用开发者实现，主要职责是从消息队列中接收并处理消息

2个重要的模型

点对点模型

• 每个消息只会被一个消费者消费

• 每个消费者只会消费队列中的一部分数据

• 适合：
  • 耗时比较长，相对比较独立的业务
  • 比如发送邮件

发布订阅模型

• 消费可能被发送到不止一个消费者
• 消息发送到一个主题，而不是队列中
• 发送到主题后，被克隆给每一个订阅者
• 每个消费者复制一份到自己的私有队列， 可独立其他消费者，不会产生竞争
• 适合：
  • 比如新用户注册就适合按主题发布消息

3.3 消息队列好处与挑战

消息队列的好处

1. 异步处理， 提升处理性能
   • 比如一些耗时处理
2. 易伸缩：多台消费者方便添加
3. 使峰值变平缓 ： 平衡流量分子，削峰填谷，
   • 可持续的接收请求，虽然生产大于消费，但可放与消息队列中，作为缓冲
4. 隔离失效及其及自我修复：发布者不直接依赖消费者，两者隔离。消费者服务器可以任意时间重启发布，而不影响生产者
5. 解耦：代码解耦，多个生产者和消费者共同完成业务，但相互都是解耦的

消息队列相关的挑战

1. 消息无序：
   • 异步处理，可把消息处理的逻辑放在异步处理中
2. 消息重新入队列
   • 有可能被处理完的，则会被多次消费
   • 解决办法：实现幂等性，消费者多次处理同一条消息而不影响最终结果
3. 竞态条件
   • 并发执行的时候不同的执行顺序导致不同的结果。主要是由于对共享资源的不同的访问顺序造成。
4. 复杂度风险
   • 架构设计更复杂

消息队列有关的反模式

模式：当解决方案被一次又一次证明是成功的

反模式：如果方案发福被证明带来问题

消息队列常用的反模式

1. 阻塞式调用
   • 生产者阻塞：等待消息队列返回结果之后再处理
     • 如此同步，丧失异步的意义
2. 耦合消息生产者和消费者
   • 比如在消息中包含处理逻辑：在消息中约定消息该如何处理，或者使用特定化的序列化协议编码消息，则消费者必须按照特定序列化才能解码消息。
   • 这样都产生了耦合
3. 缺少坏消息处理
   • 不能假定消息总是消费正确
   • 对于引起消费者崩溃的消息应该是丢弃而不是重新处理
     • 如果引起错误的是消息本身，那么每次重新处理依然会引起错误

常用消息队列产品

kafka

• 专门对分布式场景进行了优化，分布式伸缩性较好
• 互联网企业得到更多的应用

RabbitMQ

• 性能好，社区活跃
• Erlang开发，不便于二次开发

ActiveMQ

• 影响广泛，java开发，跨平台

apache RocketMQ

• 阿里开发，java开发

总结回顾：

• 异步调用架构方法：消息队列
• 点对点与发布点阅：一个消费者/多个消费者
• 消息队列实现更好的架构目标
• 关注异步架构带来的挑战
• 正确使用异步架构
• 挑选合适的消息队列产品

04 分布式数据存储

• mysql复制
  • 主从复制
  • 主主复制
• 数据分片
  • 分片原理
  • 分片方案
  • 分片扩容
• 数据库部署
  • 单一部署
  • 分库
  • 分片
• nosql
  • CAP原理
  • 最终一致性

4.1 MYSQL主从复制

• 读写分离
• binlog → relaylog

MYSQL一主多从复制

优点

• 分摊负载
  • 只读: 从数据库
  • 写：主库
• 专机专用
  • 不同的查询不同的从库
• 便于冷备
  • 只需要关闭数据的复制进程，不需关机
• 高可用
  • 某一台宕机影响不大

MYSQL主主复制

主主之间相互复制，写操作的高可用

MYSQL主主失效恢复

• 当主服务器A失效的时候，写操作会发送到主服务器B， 数据从B服务器复制到A
• 写操作正常的时候会写到主服务器A， 数据从A服务器复制到B
• 正常操作，读取A的从库，A失效读B的从库

MYSQL主主失效的维护过程

1. 所有主服务都功能正确
2. 第一主服务器A失效，故障开始
3. 检测到失败（失效开始几秒或几分钟）
4. 失效转义，
   1. 将写操作发送到第二主服务器B
   2. 将读操作发送到它的从服务器检测到失败
5. 故障结束
6. 开始重建失效的主服务器A及其从服务器
7. 完全恢复
8. 所有主服务器都正确运行，主服务器A和主服务器B之间保持复制及待机

MYSQL主主复制注意事项

1. 主主复制的两个数据库不能并发写入
2. 复制只是增加了数据的读并发处理能力，并没有增加写并发能力和存储能力
3. 更新边结构会导致巨大的同步延迟（即关闭表结构更新的binlog）

4.2 数据分片

1 分片目标

将数据集切分成较小的分片，以便于将它们分散存储在多台服务器上，避免一台机器处理整个数据集

2 分片特点

服务器之间相互独立，不共享任务信息，通过分片键定位分片

3 分片原理

将数据一某种方式切分，以便每台服务器都只存储一部分数据

4 硬编码实现数据分片

用户id%2 → 服务器A/B，

缺点：耦合代码，不利于扩展

5 映射表外部存储

• 根据外部映射结果连接到不同的服务器

6 数据分片的挑战

1. 需要大量的额外代码，处理逻辑因此变得更加复杂
2. 无法执行多分片的联合查询
3. 无法使用数据库的事物
4. 随着数据的增长，如何增加更多的服务器

7 分布式数据库中间件

• mycat

8 分片数据库伸缩扩容

• 分片规则改变
• 数据迁移
• 一般实践：
  • 数据分片使用逻辑数据库
  • 扩容时数据库数据库迁移到物理数据库

4.3 数据库部署方案：

单一服务与单一数据库

主从复制实现伸缩

两个web服务及两个数据库（业务分库）

综合部署

不同数据访问特点使用不同的解决方案

4.4 NOSQL数据库

大规模的数据分布式存储

分布式系统CAP原理

CAP只能同时满足两个。

A:数据可用性- 一般也需要满足

任何时候任何应用程序都可读写访问

• 某些节点失效的时候，系统依然可用

C:数据一致性

数据的多个备份任何时候都是一致的

P：分区耐受性：必须要满足

系统可以跨网络分区线性伸缩

• 网络失效、节点无法通信的时候 系统依然是可以使用的

CAP原理与数据一致性冲突

解决方案：最终一致性

一个分布式系统中，不一致的时间不影响应用的正确性，数据最终是一致的

多个数据备份有冲突的时候如何解决：

• 时间戳解决冲突：
  • 根据时间戳判断，最后写入的覆盖
• 客户端解决冲突
• 投票解决冲突（cassandra）

总结：

• 数据库复制
• 提升性能与可用性
• 数据分片
• 数据部署
• NOSQL
• cap 与最终一致性
• 一致性冲突解决方案

05 微服务架构

5.1 微服务知识架构图

• 单体系统的困难
  • 编译部署困难
  • 数据库连接耗尽
  • 服务复用困难
  • 新增业务困难
• 微服务框架
  • Dubbo
  • spring cloud
• 微服务最佳实践
• 微服务模式
  • 事件溯源
  • CQRS
  • 断路器
  • 超时

5.2 巨无霸单体应用系统带来的问题

• 编译、部署困难
• 代码分支管理困难
• 数据库连接耗尽
• 新增业务困难
  • 耦合 、庞大复杂
• 发布困难

5.3 SOA架构

5.4 微服务拆分

• 根据服务的粒度和可复用的级别拆分为独立服务
• 应用系统，依赖可复用的服务，进行逻辑组合

5.5 微服务架构-Dubbo

5.6 微服务架构 -spring cloud

5.7 微服务架构策略

• 业务先行， 先理顺业务边界和依赖，技术是手段而不是目的
• 先有独立的模块，后有分布式的服务
• 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎
• 要搞清楚实施微服务的目的是什么？
  • 业务复用？
  • 开发边界清晰？
  • 分布式集群提升性能？

5.8 最重要的是需求

微服务具有极强的业务属性

如果本身架构混乱、目标不清晰，仓促使用微服务只会使得系统变得更加复杂和难以控制。

在使用微服务之前

最重要的是明确需求，想要使用服务方达到什么目的。

需求清晰了，再考虑方案和技术。

选择架构的：倒三角如下

• 需求 ： 根据需求考虑价值
• 价值 ： 根据价值构建设计原则
• 原则 ： 根据原则寻找最佳实践
• 实践 ： 根据最佳实践选择合适的工具
• 工具 ：

5.9 微服务的使用模式：事件溯源

• 概念：将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储；

• 作用：

  • 利用事件溯源，可以精确复现任何用户状态，进行复核审计；
  • 利用事件溯源，可以有效监控用户状态变化，并在此基础上实现分布式事务；

5.10 微服务的使用模式： 命令与查询职责隔离（CQRS）

• 概念：在服务接口层面将查询（读操作）与命令（写操作）隔离，，服务层的读写分离
• 作用：
  • 更清晰的领域模型
  • 针对读写分别优化，实现更好的性能
    • 比如读操作： 利用缓存
    • 比如写操作：利用队列异步操作
  • 查询服务不会修改数据，更好地被保护数据

5.11 断路器

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

• 实现：

  • 三种状态： 关闭、打开、半开
  • spring cloud断路器实现：Hystrix （阿里：Sentinel）

5.12 超时

上游调用者超时时间要大于下游调用者超时时间之和

总结：

• 单体系统的困难
• 微服务架构
• 分布式服务架构
• 业务驱动模块化
• 微服务最佳实践

06：高性能系统架构设计 ★

系统高性能架构知识架构图

• 性能测试
  • 性能指标
  • 测试方法
  • 性能曲线
• 硬件优化
  • 机房与骨干网络优化
  • 服务器与硬件配置优化
• 中间件优化
  • 操作系统优化
  • 虚拟机优化
  • 基础组件优化
• 代码优化
  • 多线程
  • 数据结构
  • 设计模式
  • 资源复用
• 架构优化
  • 缓存
  • 集群
  • 异步

6.1 系统性能测试

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

• 你不能优化一个未经测试的系统
• 也不能优化一个你不了解的系统

6.2 性能测试指标

• 主观视角：
  • 使用者体验上的快慢
    • 做好交互设计的优化 主观上感觉会更好点
• 客观视角：
  • 性能指标的优劣

6.3 网站性能测试的主要指标

• 响应时间

  • 最重要
  • 发送请求开始到收到响应的时间

• 并发数

  • 同时处理的请求数，反应了系统的负载
  • 并发用户数/在线用户数/总用户数

• 吞吐量

  • 单位时间内系统处理请求的数量，体现的是处理能力
  • 每秒请求数 / 每秒事务数TPS /QPS每秒查询数

  响应时间快，则单位时间吞吐量就提高

• 性能计数器

  • 服务器或操作系统的一些指标。
  • 包括系统负载/用户线程数/内存/磁盘/IO等

6.4 性能测试方法

1. 性能测试
   • 是否达到设计预期
2. 负载测试
   • 不断的施加负载压力，寻找最大
3. 压力测试
   • 超出安全负载的情况下，继续施加压力，直到崩溃
4. 稳定性测试
   • 较大压力情况下，运行较长一段时间，检测是否稳定

6.5 性能测试结果表

不断的加大并发

6.6 系统性能优化的分层思想

1. 机房与骨干网络性能优化
   • 异地多活的多机房架构
   • 专线网络与自主CDN建设
2. 服务器与硬件性能优化
   • 使用更优的CPU、磁盘、内存、网卡、对软件的性能优化可能是数量级的，有时候远远超过代码和架构的性能优化。
3. 操作系统性能优化
   -
4. 虚拟机性能优化
   • 比如JVM的垃圾回收器( 串行/并行/并发CMS/G1)
5. 基础组件性能优化
   • 比如TOMCAT/JETTY
6. 软件架构性能优化 ★
   • 三板斧：缓存/异步/集群
   • 缓存：
     • 从内存获取数据，减少响应时间
     • 减少数据库访问，降低存储设备负载压力
     • 缓存结果对象，而不是原始数据，减少CPU计算
     • 缓存主要优化读操作
   • 异步：
     • 即时响应，更好的用户体验
     • 控制消费速度，合适的负载压力
     • 异步主要优化写操作
   • 集群：
     • 通过负载均衡
     • 更多的用户需要更多的计算资源，随着用户访问量不断增加，单一服务器的计算能力达到极限，不能满足用户需求，需要增加更多的服务器
     • 集群的技术目标只有一个：如何让用户觉得，自己使用的不是多台服务器而是一台服务器
7. 软件代码性能优化
   1. 遵循面向对象的设计原则与设计模式编程，避免“烂代码”；
   2. 并发编程，多线程与锁；
   3. 资源复用，线程池与对象池；
   4. 异步编程，生产者消费者；
   5. 数据结构，数据、链表、hash表、树；

总结：

• 性能测试
• 性能曲线分析
• 优化的整体思维
• 硬件优化
• 中间件优化
• 架构优化
• 代码优化

07 高可用系统架构

高可行架构知识图谱

• 可用性度量
  • 可用性指标
  • 故障分
• 高可用架构
  • 负载均衡
  • 备份与失效转义
  • 消息队列隔离
  • 限流与降级
  • 异地多活
• 高可用运维
  • 自动化部署
  • 自动化监控
  • 自动化测试
  • 预发布测试

7.1 系统高可用的挑战

• DNS被劫持
• CDN服务不可用
• 应用服务器级数据库服务器宕机
• 网络交换机失效
• 硬件故障：硬盘损坏、网卡松掉…
• 环境故障：机房停机、空调失灵、光缆被挖断…
• 代码bug
• 黑客攻击
• 促销引来大量用户访问
• 第三方合作伙伴的服务不可用

7.2 互联网应用可用性的度量

• 通常用N个9来说明互联网的可用性

  | 几个9 | 可用性 | 年度停机时间 |
  | ——- | —————————— | —————— |
  | 2 | 基本可用 | 小于88小时 |
  | 3 | 较高可用 | 小于9小时 |
  | 4 | 具有自动恢复的高可用 | 小于53分钟 |
  | 8 | 极高的可用性 | 小于5分钟 |

• 年度可用性指标 = (1 - 不可用时间 / 年度总时间) × 100%

• 我们熟悉的互联网产品的可用性大多是4个9，也即99.99%

故障分 = 故障时间 × 故障权重

故障处理流程

1. 客服报告故障或监控系统发现故障（故障开始时间）
2. 提交故障给相关部分接口人
3. 故障接手 & 处理
4. 故障处理完毕 故障归档 （故障结束时间）
5. 确认故障归属记入绩效考核

7.3 系统高可用的一半策略

1 、应用服务器负载均衡

• 请求分发、提高性能、并实现高可用

负载均衡实现方法

1. http重定向负载均衡： 设计简单、一次访问两次请求、响应重定向暴露应用服务器
2. DNS负载均衡：域名访问、（DNS域名解析负载均衡）、还是要暴露IP，不在我们控制内
3. 反向代理负载均衡：小规模
4. IP层负载均衡：效率较高，需要负载均衡服务器，响应数据的流量瓶颈
5. 数据链路层负载均衡：

2 、数据库复制与失效转移

3、消息队列隔离

• 应用程序A（系统发送者） →
• 分布式消息队列 →
• → 应用程序B（消息接受者）
• → 应用程序C（消息接受者）
• → 应用程序D（消息接受者）

4、 限流、降级

• 限流： 通过对并发访问进行限流，降低并发请求的数量
• 降级：关闭部分非核心功能，降低对系统的资源消耗，保证系统在高并发的情况下仍然保持可用

5、 异地多活多机房架构

• 如何分发到不同的机房：域名解析的时候
• 每个机房都独立对外提供服务：数据实时同步、数据冲突（类似mysql主主复制的解决方案）

7.4 可用用运维

• 自动化测试（尤其是回归测试）
• 自动化监控：业务指标、系统指标、自动化修复
• 预发布：线上有一台是专门用于预发布的，但是外部无法访问的
• 灰度发布：每天只发布一部分服务器，方便回滚

总结：

• 可用性指标与故障分
• 负载均衡
• 备份与失效转义
• 消息队列隔离
• 限流与降级
• 异地多活
• 自动化运维

08 系统的安全架构

系统安全架构知识图谱

• web攻击
  • xss攻击
  • sql注入攻击
  • csrf攻击
• web防护
  • 过滤响度
  • sql参数绑定
  • 验证码
  • web防火墙
• 加密
  • 单项散列加密
  • 对称加密
  • 非对称加密
• 信息过滤反垃圾
  • 分类算法
  • 布隆过滤器

8.1 web攻击与防护

攻击方式：XSS攻击

通过构造一个非法的浏览器脚本，让用户跨站点去执行，达到攻击的目的。

• 过程 例1：

1. 用户登录 了 被攻击的服务器
   1. 执行了攻击者推送含有恶意脚本的url给用户
   2. 用户点击该url，恶意脚本被浏览器解析
   3. 向服务器提交非用户意愿的请求

• 过程 例2：

1. 攻击者发送含有恶意脚本的请求
   1. 服务器将恶意脚本保存数据库
   2. 用户浏览服务器页面
   3. 从数据库获取恶意脚本数据
   4. 将恶意脚本构造到用户响应页面
   5. 浏览器解析页面，恶意脚本被执行

XSS攻击防御手段：消毒/httpOnly

• 消毒： 检查用户提交的请求中是否包含可执行的脚本 （html转义）
• 限制脚本获取cooklie，在cookie上设置httpOnly, 使得恶意脚本无法获取cookie

攻击方式：SQL注入攻击

1. 攻击者发送含有恶意sql命令的http请求，

SQL注入防御手段：消毒/参数绑定

• 消毒：请求数据正则表达式匹配
• 参数绑定：通过sql预编译

攻击方式：CSRF攻击

1. 用户登录收信任服务器
2. 用户访问攻击者（或被攻击了的）服务器
3. 响应消息中包含访问受信任服务器的请求
4. 在用户不知情的情况下，执行来自攻击者的请求

CSRF攻击防御手段：表单token/验证码

• 表单token：利用时间戳等生成
• 验证码：敏感操作输入验证码

8.2 Web应用防火墙

大部分的攻击都可以在请求和响应阶段进行拦截处理，设置统一的web应用防火墙即可，如考员防火墙ModSecurity.

8.3 信息加密技术

1. 单向散列加密
2. 对称加密
3. 非对称加密

单向散列加密

明文 + salt = 密文
如用户密码加密；

对称加密

一般加密一些敏感数据，如信用卡卡号

非对称加密

如Https；数字签名(私钥加密，公钥解密)

8.4 信息过滤与反垃圾

• 分类算法： 贝叶斯分类算法

  • 使用贝叶斯分类算法构件垃圾邮件分类系统
    • 统计现有邮件：分正常邮件/垃圾邮件
    • 统计文本概率 - 分类算法训练
    • 计算垃圾邮件的概率

• 黑名单：布隆过滤器

  • 开辟出一块巨大的连续存储空间， bit位都设置为0
  • 对每个邮箱地址使用多个（如8个）hash算法， 每个hash值都落在空间内，标为1
  • 对于新的邮箱地址，计算出是否8个下标都是1，则存在于黑名单中
  • 存在误杀情况

总结：

• xss攻击

• sql注入

• csrf攻击

• web防火墙

• 加密

• 信息过滤与反垃圾

09 -架构实战案例分析

1. 初创公司架构演化案例
2. 分布式存储系统Doris架构案例
3. 反应式编程框架Flower架构案例

9.1 初创互联网公司架构演化案例：应用架构

01 万级日订单之时

• 移动App 移动App ↓
• 负载均衡 ↓
• web服务器集群： nginx、nginx ↓
• 应用服务器集群：买家系统集群、卖家系统、供应链系统集群、运营系统集群 ↓
• mysql(主)

02 十万级订单之时

• 前端静态资源：cdn
• 图片：分布式文件系统
• 应用集群：加redis集群作为缓存
• mysql：主从读写分离，
• 大数据平台：数据分析在从库和kafka

03 百万级日订单之时

十万级日订单之后的两个挑战：

• 业务复杂，新功能开发困难，维护困难
• MYSQL数据库的存储空间难以满足

解决方案：

• 微服务重构拆分：可复用业务拆分为独立的微服务，分布式部署，供以调用；如用户服务、商品服务、订单服务、红包服务、短信服务
• 冷热分离：数据库在主从分离的基础上做了冷热分离,(比如把已关闭一个月以上的订单写入到nosql中， )
  • 写主库
  • 一个月内查从库
  • 一个月之前查mongdb

9.2 分布式存储系统Doris架构案例：组件的架构

• Doris架构设计
  • 海量存储：透明集群管理，存储可替换
  • 伸缩性：线性伸缩，平滑扩容
  • 高可用：自动容错和故障转移
  • 高性能：低响应时间，高并发
  • 扩展性：灵活扩展新功能
  • 低运维成本
  • 易管理
  • 可监控

Doris整体架构

• 客户端
• 控制中心：配置信息、路由算法
• 数据存储

Doris数据分区架构与分区算法

• 对新增的虚拟节点进行余数哈希，（较大的数取模），得到虚拟节点
• 对虚拟节点和物理节点进行关系映射

Doris的调用时序

• 多个服务器分多个组，及序列

Doris高可用架构-失效转移

doris的高可行解决两种问题

• 临时失效：
• 永久失效：

9.3 反应式编程框架Flower架构案例：编程框架架构

反应式系统的四个特性

1. 回弹性
2. 弹性
3. 即时响应
4. 消息驱动

为什么Flower可以显著提升系统性能

• 传统：一个请求一个线程，会彼此阻塞
• flower：少数容器线程，把请求交给flower，自身立即返回，这不就是多路复用吗

…..异步非阻塞

总结：

三种不同的互联网架构

• 系统整体架构
• 分布式数据库架构
• 编程框架架构

10 致未来的架构师

从普通程序员到顶尖专家之路

金字塔：

• 0-普通程序员：80%
• 1- 团队影响着：16% 架构师，技术骨干，技术经理 ： 技术选型，关键技术实现，排查，设计
• 2-公司影响着：3.2%； 大的技术方向，
• 3-全国影响者：0.64%， 技术布道师
• 4-全球影响者：0.12%
• 5-关键开创者：0.0256%； log4j, junit
• 6-领域开创着：0.00512% spring
• 7-行业开创者 0.001024% Hadoop，java

通过努力有机会升至3-5级技术人员

逐步跨越

• 0级技术人：学习实践新技术，试着解决技术难题，设计些简单架构
• 1级技术人：跨团队合作时，对相抵团队进行技术指导
• 2级技术人员：通过演讲、写博客、出书等方式打造技术形象
• 3级技术人员：参与或主动一些开源技术产品的实现

如何逐步成为技术专家

• 勇于承担责任：
  • 遵循指令行事，你永远不会洞悉事物的真相，
  • 当你对结果负责时，你会看透事务的本质
• 在实践中保持技能：
  • 技术领域遵循 一万小时定律；
  • 适当难度摘跳起来够得着的果子；
  • 积极从环境中吸收反馈
• 警惕银弹陷阱，关注问题场景
  • 没有万能的方案，一切方法都有实用场景
  • 专家就是善于根据场景发现方法的那个人
  • 解决问题的方法也许很简单，但是适用防范的场景一定不简单

架构师阅读清单

• 1 《Effective java 中文版》
  • 感受代码之美
  • java编程思想
  • java编程技巧
  • 关于编程的思维方式
• 2 《设计模式》
• 不懂设计模式，就不懂面向对象编程
• 3 《敏捷软件开发：原则、模式与实践》
• 易于维护和扩展才是好的软件
  • 敏捷开发最重要的是软件设计本身
  • 软件开发的设计原则，设计模式与最佳实践
• 4 《企业应用架构模式》
  • 模式是可重复使用的解决方案
  • 架构不是堆砌工具和技巧
  • 做架构需要对业务需求和技术先转透彻理解
• 5《卓有成效的管理者》
  • 读经典，跟大师学管理
  • 软件开发管理并不特别

总价：

• 技术人员的进阶之路

  • 勇于承担责任
  • 持续训练，逐步提高难度
  • 关注问题场景

• 如何逐步成为专家

  • 一点一滴积累，量变引起质变
• 架构师阅读清单

2022-12