架构训练营的课程，已经好几个月了。李老师讲课融汇贯通，有一气呵成的感觉。很棒！我是 dba，最初有些概念不懂，所以囫囵吞枣的时候居多。6 月份的时候，开始听大数据的课程，有比较更发觉华仔课讲的好。整个课程，我可能还需要再看 2,3 遍才能记住。

模块一---架构概念分类

1.1 概念

• 系统---关联个体；按规则运行；系统能力超越个体能力

• 子系统---更大的系统的一部分

• 模块---按逻辑拆分；职责隔离

• 组件---按物理拆分；单元复用

• 框架---软件产品；组件规范

1.2 4R 定义

• rank---架构是分层的

• role---系统包含的角色

• relation---角色之间的关系

• rule---角色的运作规则

1.3 4+1 视图

场景视图；逻辑视图；处理视图；开发视图；部署视图

1.4 架构分类

• 业务划分：业务架构图

• 领域划分：客户端架构图；前端架构图；系统架构图；应用架构图；部署架构图

1.5 常见架构设计模式

• 面向模式：应用成熟的架构模式

• 面向风险：根据系统风险大小进行架构设计

• DDD：通过领域建模来完成架构设计和代码

• 面向复杂度：降低系统复杂度；针对复杂的地方进行架构设计；具体模式高性能/高可用/可扩展/安全

• 常用方法：分库分表；缓存；集群；分片；微服务；异地多活。

1.6 架构设计 3 原则

• 合适原则：考虑资源；时间；业务背景

• 简单原则：复杂不可靠；难扩展；难处理

• 演进原则：演化优于一步到位

模块二---可扩展 &高性能 &高可用

2.1 可扩展架构

• 可扩展指的是：架构可扩展；应用可扩展；代码可扩展

• 复杂度模型；业务复杂度和质量复杂度

• 拆分：

• 拆分形态：服务；模块；插件；package

• 拆分粒度：内部复杂度；外部复杂度

• 拆分原则：平衡；先少后多

• 封装：

• 预测变化：预测 2 年内；3 次法则

• 封装变化：规则引擎；微内核；抽象层；设计模式

2.2 高性能架构设计

• 单机高性能：

• 计算高性能：进程模型；网络模型；缓存模型

• 存储高性能：B+tree; LSM

• 集群高性能：

• 任务分配：设计核心--运行形态/配置获取/分配算法

• nginx/memcached/DNS

• 任务分解：设计核心--任务拆分/运行形态/配置获取/分配算法

2.3 高可用架构

• 计算高可用：任务分配；任务分解（任务拆分/状态检测/运行形态/配置获取/分配算法）

• 存储高可用：

• 数据复制：复制命令/复制数据/复制文件；同步复制/异步复制/·半同步复制/多数复制

• 状态决策：独裁式（决策者本身高可用）；协商式（双主问题用双通道解决）；民主式（脑裂问题用 quorum 机制）

2.4 提升架构设计质量

• 成本：经济原则

• 安全：架构安全（网络隔离/流量清洗/机房切换）；业务安全（业务漏洞/安全漏洞/内部破坏）

• 可测试：架构可测试（全链路压测/手动触发系统行为）；应用可测试（变量可修改/状态可见/行为可触发）

• 可维护：架构可维护（全链路追踪/降级/下线/切换）；应用可维护（变量维护/状态可见/行为可触发）

• 可观测：信息输出（日志/API/命令行）；信息展现（运维平台/管理平台）

模块三--架构设计流程

3.1 架构师画像

• 架构师是业务和技术的桥梁

• 核心能力：判断；拆解；取舍

• 架构小组：精英团队；外科手术团队；团队讨论；专家拍板

• 主要职责：

• 架构设计前期：澄清不确定性；识别复杂性；输出业务架构图；核心场景流程图

• 架构设计中期：设计和选择备选方案；输出备选方案；方案评估；方案汇报

• 架构设计后期：细化架构；完善架构；输出最终架构文档

3.2 架构设计前期

• 利益干系人

• 投资者；监管者；构建者；维护者；使用者；评估者

• 诉求排序：

• 分组：时间/成本/范围/质量

• 排序：类别（差异性/冲突性）；原则（取舍原则/影响力）

• 沟通：点对点；开会 PK

3.3 架构设计中期

• 过程：排列组合；头脑风暴；约束和限定；红线选择；4R 设计

• 技巧：备选方案；方案要差异明显；覆盖核心场景；360 度环评

• 能力提升：关键性能指标；方案熟悉程度；比较学习法

3.4 架构设计后期

• 详细架构设计：架构规范（交互协议/数据格式/开发框架）；架构质量（可测试/可维护/可观测/成本/安全）

• 架构文档写作：业务背景/约束限制/系统边界图/架构图/序列图/架构质量设计/演进规则

• 文档分类：备选架构文档/详细设计文档/方案设计文档

模块四---存储

4.1 高性能数据库存储

• 读写分离

• 主机负责读写操作，从机负责读操作

• 复制延迟：读写绑定；二次读取；业务分级；

• 任务分解：代码封装；中间件封装

• 分库分表

• 分库：小表冗余；代码 join;字段冗余

• 分表：垂直拆分（提升单机处理性能）；水平拆分（提升集群处理性能/使用中间件来应对 join/count）

• 数据库分布式事务

• 2PC:参与者可能一直再等待；需要人工介入

• 3PC：更复杂；脑裂

4.2 高可用存储架构

• 高可用指标：RTO;RPO;WRT;MTD

• 备份架构：主备复制；主从复制；实现简单，RTO 高

• 切换架构：主备切换；主从切换

4.3 分片和分区

• 分片

• 本质通过叠加服务器来提升写性能和存储性能，使数据分布均匀。

• 分片可根据主键或时间来分。分片规则包括 hash 和范围

• 路由规则：静态路由（配置文件）；动态路由（配置中心和路由转发）

• 高可用：独立备份；相互备份

• 分区架构

• 本质通过冗余 IDC 来避免城市级别灾难，并就近访问

• 路由：DNS 和 GSLB

• 备份：集中式；独立式；互备式

4.4 存储架构设计

• 存储架构设计三步骤：性能估算；选择存储系统；设计存储方案

• 估算：用户量估算；用户行为估算；需求计算

• 估算时，考虑成本、基于既有数据，对标其他项目；考虑到用户行为频率；一般要有一定的预留量。

• 存储架构选择要根据单机是否可以支持写和读性能，单机还是集群。根据用户量的多少和分布，确定采用分区还是分片架构。

• 常见的存储系统：SQL 类的 OLTP(mysql/oracle)OLAP(Clickhouse/Hive)

• Nosql:redis/mongodb/elasticsearch/influxdb

• 大数据相关：hdfs/hbase/cassandra

• 存储方案设计三步骤

• 设计数据结构；验证读写场景；评估读写性能

4.5 常见存储系统

• redis：单机 TPS 5~10 万 性能较高；

• redis 集群：主从复制，读写分离，无自动切换功能

• Hbase:四台 32 核，7 万插入每秒，读 2.5 万每秒。

• HBase:本质分片集群；zookeeper 做 hmaster 切换，regionserver 由 hmaster 管理

• HDFS:文件存储系统；分布式；运行在低成本硬件上。

• HDFS 本质分片集群，适合大文件存储。

• clickhouse:OLAP--联机分析处理，执行少量复杂查询，关注吞吐量，很少修改数据。列式存储：表中的一列数据存储在一个数据块中。分片集群；zookeeper 管理，分片独立复制。

模块五---缓存 &负载均衡

5.1 缓存

• 缓存是协调新能差异的结构，本质是以空间换时间

• 缓冲和缓存区别，缓冲是暂存需要传播的数据的结构

• 缓存设计：缓存内容；缓存时间；缓存系统；更新机制（过期/定时/主动）

• 多级缓存：

• 本地缓存（APP 缓存/HTTP 缓存）；

• CDN（就近访问/边缘服务器/功能强大）；

• web 容器缓存（静态资源；配合 http）；

• 应用缓存（进程内/进程外/本地 SSD 磁盘）；

• 分布式缓存（redis/memcached）

5.2 分布式缓存

• 分类：

• 数据缓存：实时性要求高，且读多写少的地方，核心是保持数据的一致性（本地消息表事务/消息队列异步删除缓存）

• 结构缓存：计算量大实时性要求不高的场景；缓存有效期与结果新鲜度平衡。

• 缓存问题：

• 缓存穿透（空值缓存/当前数据缓存/缓存预热/随即失效）

• 缓存雪崩（更新锁/后台更新）

• 缓存热点（缓存副本/动态决策）

5.3 负载均衡

• 级联负载均衡：

• 分级（一级 DNS/二级 F5-LVS/三级 nginx/四级服务路由）

• 设计核心：性能；可维护性

• GLSB:应用在超大规模业务和多地部署；功能强大实现复杂；基于 DNS，基于 HTTP redirect

• DNS:应用在地理位置和机房级别的负载 均衡；使用标准协议；缺点可能出现 DNS 劫持且不够灵活。

• F5:功能强大；硬件成本高；L4 层负载均衡

• LVS:功能简单，性能较强；LINUX 内核实现；成本一般；L4 层负载均衡

• Nginx:功能单一，性能一般；程序实现；成本低；L7 层 HTTP 负载均衡。

• HTTP-DNS:使用在 APP 或客户端，灵活可定制，不太适合 WEB 业务。

5.4 负载均衡技巧

• 通用算法：

• 轮询（实现简单/不会判断服务器状态）

• 加强轮询（实现复杂/根据服务器性能来分配请求/不会判断服务器状态）

• 随机（实现简单/不会判断服务器状态）

• 负载优先（实现复杂需要管理或者获取服务器状态/可根据服务器状态进行负载均衡）

• 性能优先（实现复杂需要统计请求处理时间/根据性能进行负载均衡/服务器不经过负载均衡，不能应用这种算法）

• hash(实现简单/不会判断服务器状态/适合有状态任务分片的场景)

• 负载均衡技巧（cookie/自定义 HTTP header/url query string）

5.5 接口高可用

• 请求太多：限流，排队

• 接口故障：降级，熔断

• 降级：停用接口或服务；降级核心业务

• 熔断：一段时间内不再访问故障接口；框架或 SDK 实现

• 限流：请求端限流；接入端限流；服务限流；

• 算法：固定时间窗口；滑动时间窗口；漏桶算法（总量控制）；令牌桶算法（速率控制）

• 排队：请求缓存；同步改异步；请求端轮询

模块六---微服务和中台

6.1 微服务

• SOA: 所有业务功能都是一项服务，服务就要对外开放能力。

• 通过 ESB 将企业中各不同的异构服务连接在一起

• 减少各个服务间的依赖和相互影响

• 本质是异构服务解耦。

• 微服务是将系统拆分成小的服务。

• 服务之间通过轻量级机制通讯

• 服务可以快速自动化部署

• 轻量级的服务解耦。

• 微服务与其他可扩展架构：

• 微服务是端到端分层架构中的业务层架构

• 单个微服务架构可以是整洁架构

• 单个微服务可以是微内核架构

6.2 微服务问题

• 6 大问题：

• 拆分过细（服务关系复杂/团队效率下降/问题定位困难/系统性能下降）

• 基础设施不完善（无法快速交付/服务管理混乱）

• 4 大挑战

• 分布式事务（本地消息表/消息队列事务消息/TCC）

• 全局幂等（全局唯一 ID/状态机）

• 接口兼容（多版本接口）

• 接口循环调用

6.3 微服务基础设施选型

• 基础设施架构

• 服务接入层（服务网关/服务控流/服务降级/服务安全）

• 服务运行层（服务注册/服务发现/服务路由/服务容错）

• 技术支撑层（接口框架/分布式事务/自动化测试/容器编排/自动化部署/灰度发布/服务监控/服务跟踪）

• 基础设施层（配置中心/日志中心/分布式锁/消息队列）

• 微服务框架

• 嵌入式 SDK（架构简单高可用/应用侵入多语言重复开发 SDK/常见 Dubbo/spring cloud)

• 反向代理（应用无侵入/支持多语言/service proxy 需要集群来做高可用高性能/维护复杂/使用多语言技术栈/微服务规模小/代表 APISIX）

• 网络代理（应用无侵入/支持多语言/高性能高可用/维护复杂需要每台机器

• proxy/单台服务器 proxy 单点/全链路性能下降/代表 istio）

6.4 微服务拆分技巧

• 思路：

• 拆分方式（按业务拆分/按质量拆分）

• 基础设施要求（构建完善的基础设施/构建核心的基础设施）

• 落地方式（一步到位/逐步迭代）

• 按业务拆分

• DDD 不适合落地

• 业务边界划分（业务专家/粗分然后演进/参考已有实现）

• 服务拆分（三个火枪手/领域 1 对 1/领域多对 1/领域 1 对多）

• 按质量拆分

• 按性能拆分/按业务重要程度拆分/按可用性拆分/按稳定性拆分

6.5 中台

• 定义：业务相关；跨业务；相似业务

• 业务中台：将企业内多个相似业务的通用业务能力沉淀到平台，减少重复建设，提升开发效率的一种架构模式

• 数据中台：将企业所有业务数据沉淀到同一平台，支持业务间数据打通以及数据复用，提升企业运营效率的一种架构模式。

• 问题：业务支持粒度不同；业务边界难以确定；全流程效率不高

• 技巧：pipeline 封装不同业务流程;java spi 封装不同业务

• 共享类别

• 无共享，烟囱架构

• IaaS，共享基础设施

• Pass,共享平台能力

• SasS，共享软件能力

• 中台，共享业务能力

模块七---灾备 &异地多活 &高可用

7.1 高可用三大核心原理

• FLP

• 定义异步通信场景中，即使只允许一个节点失败，也没有任何确定算法保证非失败进程达到一致性。

• 三大约束（确定性协议/异步通讯/所有存活节点）

• 不可能三角（fault tolerance/safety/liveness）

• CAP

• 分布式数据存储系统不可能同时满足一致性，可用性和分区容忍性

• 三大约束（分布式/存储系统/同时满足）

• 不可能三角（consistency/availablity/partition tolerance）

• BASE

• 定义（basically available/soft state/eventual consistency）

• 本质 CAP 的 AP 方案落地具体技巧

7.2FEMA 排除架构隐患

• 故障模式与失效分析，分析和思考系统脚骨可用性的方法，在详细架构设计阶段进行 FMEA 分析

• 步骤：画架构图；FEMA 分析；改进

• 评估维度：

• 业务功能，用户角度

• 故障模式，故障点和故障形势

• 故障影响，故障发生后业务会收到什么影响

• 严重程度，从业务角度看故障的影响程度

• 故障原因，导致故障现象出现的原因

• 故障概率，某个具体故障原因发生的概率

• 风险程度，综合严重程度和故障概率来一起判定某个故障的最终等级

• 已有措施，针对具体的故障原因，系统现在是否提供了某些措施来应对

• 规避措施，为了价格年底故障发生概率或故障影响而采用的一些措施

• 解决措施，为了解决问题而采取的一些措施、

• 后续改进，针对 FEMA 分析表格，查漏补缺，优化系统架构

7.3 业务级灾备架构设计

• 同城多中心

• 同城双中心（延时<2ms/可当作同一逻辑机房/可应对机房级别灾难）

• 同城三中心（成本高）

• 跨城多中心

• 跨城近邻双中心（相邻城市部署/机房延时<10ms/可当作同一逻辑机房/避免城市级别灾难，无法避免区域级别灾难/可以做异地多活，不做用户分区）

• 跨城远端双中心（远端城市部署/机房延时>30ms/不能当作同一机房/可以避免城市级别和区域级别的灾难/可以做异地多活和用户分区）

• 跨城多中心（优缺点和跨城远端双中心/成本高）

• 跨国数据中心

• 全球部署；合规和监督；区域用户分区；不会做异地多活

7.4 异地多活三种模式

• 业务定制型

• 方法：优先保证核心业务异地多活；设计定制化异地多活架构；

• 优点：对基础设施无强要求；可以部署在远距离两个城市，支持区域级别故障处理

• 缺点：不通用，每个业务都需要单独来做异地多活，业务需要改造；难扩展，核心业务如果有重大变化，异地多活需要重新设计。

• 业务通用型

• 方法：通过配置服务来支持异地多活

• 优点：对硬件基础设施无强要求，一般部署在远距离的两个城市，可以支持区域级别故障处理；业务基本不用改造，只需判断业务似乎否支持 BASE

• 缺点：配套服务复杂；存在全局单点业务；机房距离较远的时候，RTo 比较大

• 存储通用型

• 方法：采用本身已支持分布式一致的存储系统来实现异地多活

• 优点：架构天然支持异地多活，业务除了切换存储系统外，其他基本不用改造

• 缺点：需要分布式一致性的存储系统支持，目前纸样的系统不多；对机房的部署有强要求，如果要异地多活，只能采用临近部署，不支持区域计备故障处理；成本高。

7.5 业务定制性异地多活

• 一个原理：异地多活本质上是 AP 方案

• 3 大原则：保证核心业务；作到最终一致性；保证绝大多数用户

• 5 大技巧：消息队列同步；库存拆分；事务合并；实时改同步；适当容忍

• 4 个步骤：

• 业务分级：按访问量分级；按重要程度分级；按收入分级

• 数据分类：数据修改量；一致性；唯一性；可丢失；可恢复

• 数据同步：消息队列同步；二次读取；回源读取；重新生成；存储系统同步

• 异常处理：业务兼容；事后补偿；人工修复

模块八---集群和分片

8.1 单机高性能网络模型

• 传统网络模型

• PPC/prefork:实现简单；PPC 模式 fork 代价高，性能低；父子进程通信要用 IPC；OS 上下文切换回见限制并发连接数，一般几百。

• TPC/prethread:实现简单；无需 IPC，线程间通讯即可；无需 fork,线程创建代价低；线程互斥和共享比 PPC/prefork 要复杂；某个线程故障可能导致整个进程退出；OS 上下文切换回限制并发连接数，一般几百，但比 ppc/prefork 要多。

• Proactor

• 优点：理论上性能要比 Ractor 高一些，但实测性能差异不大。

• 缺点：操作系统实现复杂，linux 目前对 Proactor 模式支持并不成熟；程序调试复杂。

• Reactor

• 单 Reactor 单进程/线程：

• 优点：实现简单，无进程通讯，无线程互斥和通讯；无上下文切换，某些场景下可以作到很高。

• 缺点：只有一个进程，无法发挥多核 CPU 的性能；只能采取部署到多个系统来利用多核 CPU，这样回带来运维复杂度；Handler 在处理某个连接上的业务时，整个进程无法处理其他事件，导致性能瓶颈。

• 单 Reactor 多线程：

• 优点：充分利用了多核 CPU 优势，性能高

• 缺点：Reactor 承担了所有事件的监听和响应，只在主线程中运行，瞬时高并发会成为性能瓶颈。

• 多 Reactor 单进程/线程：

• 优点：充分利用了多核 cpu 的优势，性能高；实现简单，父子进程交互简单；subreactor 子进程间无互斥共享或通讯

• 缺点：没有明显缺点

• 实现技巧：多 reactor 多线程时最好方案，实际生产中直接用开源框架

8.2 基于 zookeeper 的高可用

• zookeeper 简介：本质是分布式协调服务

• 技术特点：sequential consistency;atomicity;single system image;reliablity;timeliness;

• 数据模型：watches;data access; ephemeral nodes;sequence nodes

• 设计步骤：设计 path；选择 znode 类型；设计 znode 数据；设计 watch

• 主备切换：ephermeral 类型的 znode;两个 znode 即可，master slave

• 集群选举：

• 最小节点获胜（ephemeral_sequential 类型 znode;集群共用父节点 parent znode，集群中的每个节点在 parent 目录下创建自己的 znode）；

• 抢建唯一节点（集群所有节点中只有一个 leader znode 本质上就是一个分布式锁；epherneral 类型 znode）；

• 法官判决（集群共用父节点 parent znode，集群中的每个节点在 parent 目录下创建自己的 znode；用 epherneral_sequential 类型 znode;"法官“节点读取所有 znode 的数据，根据规则或算法选举心新的 leader）

8.3 集群架构设计技巧

• redis sentinel:

• 基本实现：sentinel 本身基于 raft 算法选举；sentinel 监控和选举

• 架构模式：双节点（只能应对 redis 节点故障不能应对服务器故障；实际应用中不推荐）；三节点（可以应对 master 节点和服务区故障/可能出现双主，可以通过参数来控制）；分离部署（可以应对 master 节点和服务区故障/可能出现双主可以通过参数来控制）

• mogodb replication:

• 基本实现（异步复制复制 oplog/基于 raft 算法选举）；新节点加入集群（寻找同步源/init sync/增量复制）；read reference(默认读 primary 指定 read preference 来读取 secondary/事务必须读 primary/可能读不到最新的数据);arbiter(只投票，不复制数据/永远是 Arbiter,相当于"仲裁者")

8.4 分片架构设计

• elastricsearch:

• 节点可以配置为不同角色，通过选举 master 管理集群；

• 数据是按索引分片，而不是按几点分片；

• 可以每个分片多个副本来保证高可用；

• 之前是 bully 算法，后面是 raft 选举算法。

• redis cluster

• cluster 分为多个分片，不同分片保持不同数据；

• 每个分片内部通过主备复制来保证高可用；

• 分片内部自动实现 master 选举，但不依赖 Sentinel ，本身不具备分片选举的能力。

• 节点之间通过 gossip 交换信息，节点变化的时候会自动更新集群信息。

• mongodb sharding

• 分为 shard mongos config server 三类角色

• 分片内部通过 replica set 保证高可用

• 当 config server 挂掉时，cluster 进入 read only

• HDFS

• 分为 namenode datanode journalNode 三类角色

• 依赖 zookeeper 做高可用

• journalnode 至少 3 个，达到多数日志复制写入才算成功

8.5 常见集群算法

• Gossip

• 定义：又叫 epidemic protocol，也叫流言算法

• 应用在分布式网络，无集中管理节点，节点间点对点传播信息。

• 优点：扩展性（网络节点可任意增加和修改）；容错性（无中心节点，任意节点宕机不影响协议运行）；去中心化，任意节点都可以发送消息。

• 缺点：需要花费一定时间来达到最终一致性；不适合超大规模集群；恶意节点传播垃圾信息；消息冗余

• 模式：社交网络；节点数量不多，实现最终一致性；节点经常变化的集群

• BULLY：存活的最大节点获胜；实现简单

• Raft：技术本质（分布式协同/replicated state machine）;特点（容易理解；算法明确划分为选举、复制、安全三个子问题）；读写 leader follower 不接受请求；选举期间不能服务；一致性保证弱于 paxos

模块九---架构重构和演进

9.1 架构重构

• 通过调整系统结构来修复系统质量问题（性能/可用/可扩展）而不影响整体系统能力

• 关键：修复质量问题，提升架构质量；不影响整体系统功能；架构本质没有发生变化

• 方法：增删改拆合，调整 role relation rule

• 技巧：先局部优化架构重构；明确目标时间和结果；参考案例；对问题进行分类排序，逐步解决

9.2 架构演进

• 通过设计新的系统来应对业务和技术的发展变化

• 应对业务和技术的发展变化带来的新的复杂度

• 关键在于新架构和新复杂度

• 业务驱动：主动演进（预判和布局）；被动演进（快速响应和拿来主义）

• 技术驱动：降本/增效/提质；新技术要带来典型的价值才考虑演进；成本，对手和环境

9.3 十万级架构设计

• 根据用户的规模计算存储需求；

• 存储架构采用 mysq（用户数据/关系数据)+redis（聊天数据）

• 计算架构根据用户数量和用户行为计算 TPS 和 QPS

• 负载均衡：使用 nginx

• 缓存架构：多级缓存架构（APP 缓存/WEB 容器缓存/分布式缓存）

• 可扩展架构设计：用户数量不是特别大情况下，服务没必要拆分的太分散

• 高可用设计：mysql 同城主备

9.4 百万规模架构设计

• 基本业务：注册登录-加好友-聊天-群聊

• 团队 30 左右

• 存储架构设计：根据用户数量分析每个业务场景的业务需求。聊天坑你会达到上亿，其他的在百万级。具体应用和十万类似，mysq 主备（用户数据+关系数据），redis 集群（聊天数据）

• 计算架构设计：根据用户数量和不同业务，分析每个业务的 TPS QPS 大部分再数千左右。

• 负载均衡：用 nginx 对多服务集群，当服务用户增加到大几百万时，可以考虑使用 LVS

• 缓存设计：缓存和十万级别类似，app 缓存 web 容器缓存 分布式缓存

• 可扩展架构设计：这个用户级别可以采用微服务，将服务进行拆分，并平台化对服务进行监控和治理。

• 高可用架构设计：可以进行同城灾备，将数据进行自动同步，当出现问题时，手动切换

• 大数据架构设计：如果业务有大数据场景需求时，可以使用 hadoop spark 或者 clickhouse 搭建基础平台。

9.5 千万级架构设计

• 技术团队规模达到 100 左右，技术栈包括大数据、风控安全等

• 业务包括：注册登录，加好友，群聊，聊天，支付。

• P9 级别的技术栈：运维平台/测试平台/存储平台/大数据平台/全链路压测/全链路追踪/异地多活

• 业务域的人数划分可以根据三个火枪手原则

• 业务粒度可以根据用户/主业务/支持业务等

• 基础平台建设：规范化/平台化/自动化/可视化

• 基础技术四个核心平台：运维平台/测试平台/存储平台/大数据平台

• 负载均衡：F5+Nginx

• 缓存架构：app 缓存+WEB 应用缓存+分布式缓存

• 高可用：同城双机房或异地双机房

9.6 亿级用户架构设计

• 技术团队规模上千人，业务分为多个业务线（聊天/用户/基础/安全/视频/营销）

• 这个规模的架构重点：

• 稳定--分区；自建机房

• 开放--稳定平台；生态建设（API/SDK/开发平台/沙箱环境/管理后台/运营后台/分析后台/结算后台）

• 照顾成本--优化（根据业务场景定制各种系统；自建代替开源）；创新（找到突破性解决方案）

模块十---架构师成长和学习

10.1 成长指南

• 架构师是业务和技术之间桥梁

• 架构师要懂得判断+取舍+创新

• 技术包括：深度+宽度+广度

• 业务：主要指对业务的理解

• 高级架构师管理：团队管理+业务管理

• 工程师：5，董工具和流程（运行环境语言网络编程）

• 高级工程师：6，基础原理（JVM 开源软件/分库分表/缓存/设计模式）

• 技术专家：7，有一定深度，熟悉开源软件

• 初级架构师：8，有一定架构方法论，参加技术交流会

• 中级架构师：8/9，业界交流会，跨域扩展

• 高级架构师：10，各种领，大数据/云计算/docker/流式处理

10.2 学习方法

• 要学会利用碎片化时间；先学会一个，然后扩展；

• 总结，技术本质/优缺点/应用场景

• 搭建模拟环境；输出倒逼输入

• 海绵学习法：

• 碎片化时间，系统化学习；

• 飞轮效应：积累的越多，学习越快

• play 学习法：

• 通过模拟实践中的场景来进行学习和训练

• 学习效果金字塔模型

• 被动；听<阅读<视听<演示

• 主动：讨论<实践<教授给他人

• Teach 学习法：

• 通过给别人讲课来提升自己的理解

• 写作；培训；演讲

• 体系化：梳理思路和体系

• 完善细节：他人的输入完善自己的盲区

• 加深记忆：写过讲过的内容，印象更深刻

• 锻炼：锻炼反应能力和抗压能力

10.3 高效学习方法

• 链式学习法：自顶向下，逐步深入，一环扣一环

• 领域分层：自顶向下，层层关联

• 细节分层：由表及里，层层深入

• 举例：netty 领域深度：linux 内核<网络调优<TCP/UDP<网络编程<java 网络编程<netty

• netty 细节分层:实现源码<设计方案<设计原理<设计接口

• 画出分层图---->明确分层深度---->确定学习方法

• 比较学习法：横向比较同一个领域中类似的技术，梳理他们不同，分析各自的优缺点和使用场景

• 链式学习法----明确比较维度-----思考总结

• 例如可以从“高可用”“数据结构”“性能”“并发方案”“持久化”等维度对 redis 和 memcache 进行比较。

• 环式学习法：按照技术或者业务维度，构建一个完整的闭环过程将多个领域的一网打尽

• 明确提升技术广度；学习业务，扩展业务领域

• 功能环：技术环；业务环：业务流程闭环

• 方法：画具体环--->由近及远--->学习核心内容

10.4 学习和应用开源系统

• 开源系统学习步骤：

• 概要学习--->安装运行--->模拟测试--->研究---->分享

• 开源系统落地技巧

• 选：聚焦是否满足业务；是否成熟；运维能力

• 用：深入研究测试；灰度发布；备份方法

• 改：包装；造轮子

10.5 面试技巧

• 考核维度：判断；拆解；取舍

• 考核关键：复杂度

• 技巧：star 方法（situation/task/action/result）;回答问题（what how why）;表达和说明（situaction:产业链图/业务系统图；）