写点什么

架构训练营——毕业总结

用户头像
开拓纪
关注
发布于: 4 小时前

架构训练营的课程,已经好几个月了。李老师讲课融汇贯通,有一气呵成的感觉。很棒!我是 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:产业链图/业务系统图;)

用户头像

开拓纪

关注

还未添加个人签名 2019.08.14 加入

还未添加个人简介

评论

发布
暂无评论
架构训练营——毕业总结