导图社区 互联网架构
无数据
关于互联网架构的思维导图, 互联网架构4高:据一致性 > 高可靠(高可用)> 高并发 > 高性能,一起来看、
编辑于2023-04-27 16:31:41 江西互联网架构
看待互联网架构视角
大型互联网公司架构演进史
术与道,术:各种框架,道:理论和方法论
功能性需求与非功能性需求
组织架构与系统架构的关系(生产关系与生产力)
互联网架构4高概述
据一致性 > 高可靠(高可用)> 高并发 > 高性能
高并发” 与 “高性能” 的区别?
QPS 与 响应时间 的关系
高可用 与 高可靠 的区别与联系?
高可靠:减少出故障的次数 高可用:出了故障之后,减少修复时间
技术理念与技术价值观
不能脱离组织架构来谈业务架构和技术架构
性能优化是个永无止境的事:从语言 -》编译器(解释器) -》 操作系统 -》 硬件资源
技术栈一直在快速变化,永远追不上
术业有专攻,不存在什么领域都精的架构师
不存在包打天下的架构方法论、架构模式
T型人才
高并发
高并发问题的互联网场景
决高并发“读”的几个套路:
(1)动静分离 - 分布式文件系统与CDN
(2)主从
(3)在线/离线的分离(OLTP/OLAP的分离)
(4)缓存:本地缓存/中央缓存
(5)并发读:异步RPC
(6)重写轻读
高并发”写“的几个套路
1.数据分片 Mysql分库分表、ES的分布式索引、JDK7之前的ConcurrentHashMap、Kafka的Partition
2.任务分片 CPU指令流水线、Map/Reduce、网络的1+N+M模型
3. 异步 业务层面搞后台任务、异步RPC
4. 批量 、Kafka的客户端批量写入、各种批量接口:KV,Mysql, 业务API、Mysql内核的多个小事务合并扣减(阿里修改的Mysql内核)
5.串行化 + 异步IO Redis的单线程模型、C++开发里面多进程单线程
数据库水平扩展的2大技术路线
分布式数据库(Oceanbase/Tdsql/TiDB)
Mysql + 自己做分库分表
架构设计2.0:大型分布式系统架构方法论与实践:现实世界不存在强一致,就好比物理学中没有永动机
高可用
减少故障修复时间
主要通过多副本进行容灾、Failover
高可靠
减少故障发生次数
可用手段非常多,包括但不限于下面: 容量规划与压测 限流、降级、熔断 容灾备份 完善的测试 灰度发布与回滚 变更管理 DevOps 完善的监控体系
高性能
行锁解决思路
产品设计方向
分批汇总处理
多账号处理
微服务拆分方式
按组织架构拆
按领域模型拆(高内聚、低耦合)
按读写分离拆
按软件架构模式拆(高内聚、低耦合)
按流量大小拆
按技术复杂度拆
引用GitHub前CTO的一篇文章:全面微服务是最大的架构错误!
常用业务架构模式与案例
分层模式
本质:分离“变”与“不变性” 越底层越不变,越上层越易变(类似房子:装修能经常变,但地基下面的柱子基本动不了) 越底层零部件越小,功能越单一;越上层,功能越多样 整个体系自底往上应该是一个倒三角
管道-过滤器模式
(1)Java的Servlet规范,一个标准化的HttpRequest和HttpResponse对象,流 经各式各样的Filter,最后到达Servlet。作为一个开发者,只需要定制自己的 Filter,加入这个管道的链条上面就可以。 (2)大数据流行的Storm流式计算。 该模式的核心: (1)标准化的数据格式,每个系统见到同样的数据 (2)系统本身无状态
状态机模式(协调者模式)
核心:状态机存储了每条数 据的状态,根据状态来驱动 所有系统和流程
业务切面
例1:SSO单点登录 例2:统一权限管理
.规则引擎
站在业务角度来看,规则其实是一个蛮抽象的词,形式很多样。 但站在技术角度来看,抽象出来,规则就是一条条的If..Then…语 句,如下所示: If x > 1 and y < 5 then z = 0 If x > 1 and y >= 5 then z = 1 If x < 1 or m = true then z = 0
工作流引擎
建模
现实世界与计算机世界
计算机建模:现实问题 -> 计算机模型 (1)开发语言:所有逻辑,最终都映射成3种结构,顺序、选择、循环 (2)DB:所有数据,最终都映射成一张张2维关系表 (3)算法模型:LR,决策树,神经网络... (4)业务建模:UML 与 DDD
自然语言建模 构造块:常用的几千个汉字(或者英语的10多万个单词)。 语法规则:主谓宾定状补。 构造块:加、减、乘、除、if-else、for、while…… 语法规则:程序员很熟悉,此处不再展开。 构造块:函数。 语法规则:整个系统描述成函数的层层调用 构造块:对象。 语法规则:整个系统描述成对象与对象之间的关系。 构造块:实体、值对象、领域服务、领域事件、聚合根、工厂 、仓库、限界上下文。 语法规则:“构造块”之间的联系 建模的粒度:由细到粗,逐层构建
思考点之1:深刻理解专业名词 专业名词 实体/属性 Class、属性 表、字段 探讨个哲学问题,也是语言学问题:“概念”如何形成的? 也即“实体”和“属性”的区分问题? 例子1: 苹果和梨子的杂交问题 1棵小树苗,10年后,还是不是同1棵树? 生物学上的物种命名? 古希腊哲学:种加属差,属加种差
思考点之2:重要信息显性化 很多时候会遇到这样的情况:一个函数写了几百行代码,里面的if-else写了很多,计 算各种业务规则。另一个人接手之后,分析了好几天,才把业务逻辑彻底理清楚。 这个问题从表面来看是代码写得不规范、要重构,把一个有几百行代码的函数拆成一 个个小的函数。从根本上来讲,就是“重要逻辑”隐藏在代码里面,没有“显性”地 表达出来。 显性化就是“命名”,“造新概念” 变量名字 函数名字 类名字 模块名字 微服务名字 设计的过程就是一个不断造新概念、不断命名的过程
架构的4+1视图
功能视图
对于B端的复杂业务系统,往往会画用例图,但对于C端产品,往往直接 看交互设计稿或最终的UI原型图。
逻辑视图
系统的逻辑模块划分,数据结构、面向对象的设计方法论里面的类图、 状态图等。
物理视图
整个系统所在的机房、各类机器数目、机器配置和网络带宽等。
开发视图
代码所在的工程结构、目录结构、Jar包、动态链接库、静态链接库等。
运行视图
系统的多进程、多线程之间的同步。 除了4+1视图,还有一个常见的视图叫作“数据视图”,我称为5+1视图。这里涉及一个容易混淆的问题:逻辑视图和数据视图
不机械套用任何一种软件方法论,取各家所长,结合实践, 形成一个实际可采纳的方法。
需求分析
从整体上去看需求,不要一上来钻入细节:利益相关者分析、上下游分析
领域知识的深刻理解,识别真需求 vs. 伪需求
产品与技术的PK问题,需求的闭环性
金字塔原理 - 需求的正交分解
需求分析核心
需求分析需要的不是计算机专业知识,而是”通识“,“哲学思维”:
(1)整体性/系统性看问题:点 -》线 -》 面 -》体
(2)看问题看本质:找到根因,识别真伪
(3)分清主次:主要矛盾 与 次要矛盾
(4)MECE原则:讲条理,讲逻辑