互联网架构

关于互联网架构的思维导图， 互联网架构4高：据一致性 > 高可靠（高可用）> 高并发 > 高性能，一起来看、

互联网架构

看待互联网架构视角

大型互联网公司架构演进史

术与道，术：各种框架，道：理论和方法论

功能性需求与非功能性需求

组织架构与系统架构的关系（生产关系与生产力）

互联网架构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原则：讲条理，讲逻辑