毕业总结

A.概论

1.软件架构及目的

·什么是软件架构软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。软件架构指软件系统的顶层结构，它定义了系统由哪些角色（Role）组成，角色之间的关系(Relation)和运作规则（Rule）。

·软件架构的目的架构设计目的是为了降低软件系统的复杂度。

2.架构设计三原则

合适原则 > 简单原则 > 演化原则。第一原则：合适原则，优先满足现有业务需求；第二原则：简单原则，选择简单方案快速落地验证；第三原则：演化原则，适当预测业务发展，在问题出现时演进。三个原则是一体的，相辅相成。

┌─ 规范化：日志规范、开发规范、接口规范、代码管理规范、测试规范┼─ 平台化：运维平台、测试平台、存储平台、大数据平台┼─ 自动化：接口自动化测试、全链路压测、故障自动分析└─ 可视化：系统状态可视化、任务管理可视化、任务执行可视化

                 ┌─ 分区架构         ┌ 稳定 ┤         │      └─ 自建机房         │         │      ┌─ 开放平台亿级用户 ┼ 开放 ┤         │      └─ 生态建设         │         │      ┌─ 优化         └ 成本 ┤                 └─ 创新

2.4R 架构

（1）Rank（2）Role（3）Relation（4）Rule

3.架构师

3.1 意义

降低不确定性、降低业务和系统的复杂性

3.2 工作内容

权衡/取舍/创新

3.3 分类

（ISO/IEC 42010）：企业架构师 EA(Enterprise Architect)、基础结构架构师 IA(Infrastructure Architect)、特定技术架构 TSA(Technology-Specific Architect)和解决方案架构师 SA (Solution Architect)

3.3 画像

业务与技术的桥梁

3.4 核心能力

考察转化能力：判断、拆解、取舍，结合业务场景选择技术，并带来好的结果。

判断：业务理解力、技术能力、沟通能力拆解：技术深度、技术宽度、技术广度取舍：设计理念、说服能力、决断能力

判断（问题）：判断复杂点在哪里拆解（分析）：设计多套方案，应对这个复杂度取舍（解决）：挑选一个方案落地，并带来很好的结果

3.5 结构化思维

0.思考维度从不同角度思考问题，结构化思维：时间、空间数量、质量深度、广度方向、程度软件、硬件主观、客观主动、被动理论、实际内部、外部相同、不同投入、产出整体、细节目的、方法我的角度、别人的角度先理论、后场景现象、分析、计划、行动、总结

1.STARSTAR 法则是情境(situation)、任务(task)、行动(action)、结果(result)四项的缩写。STAR 法则是一种常常被面试官使用的工具，用来收集面试者与工作相关的具体信息和能力。Situation: 事情是在什么情况下发生（WHEN/WHERE/WHO）Task: 你是如何明确你的任务的（WHAT）Action: 针对这样的情况分析，你采用了什么行动方式（HOW）Result: 结果怎样，在这样的情况下你学习到了什么

2.5S 明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。

3.5W2H1EWhat(什么)--企划的目的、内容。Who( 谁)--企划相关人员。Where( 何处)--企划实施场所。When(何时)--企划的时间。Why(为什么)--企划缘由、前景。How(如何)--企划的方法和运转实施。How much(多少)--企划预算。Effect(效果)--预测企划结果、效果。

4.架构图

软件架构指软件系统的顶层结构（Rank），它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

```

按业务划分

┌────────────────────── 业务架构图

│

│ 按模块划分

│ ┌── 客户端 ──────── 客户端架构

│ │

系统 ┤ │ 按模块划分

│ │ ┌───────── 系统/后端架构

│ │ │

│ │ │ 按应用划分

└─ 领域架构图 ┼── 后端 ─────────┼───────── 应用架构

│ │

│ │ 按组件划分

│ └───────── 部署架构

│

│ 按模块划分

└── 前端 ───────── 前端架构

```

B.架构设计的阶段

1.

2.技术选型

• 第一步：列举指标|----- |---- ||技术复杂度 | ||团队技术储备 | ||可扩展 | ||成本 | ||安全 | ||可维护性 | ||性能 | ||成熟度 | ||硬件成本 | ||人力成本 | ||业务契合度 | ||开发周期 | |

• 第二步：排列优先级

• 第三步：打分

C.架构复杂度

复杂度来源：

• 高性能

• 高可用

• 可扩展

• 安全

• 成本

就算超前设计，也只能应付规模的变化，无法应付业务多样性和技术的变化

a.可扩展（拆分、封装）

质量复杂度↑┃ .┃ MySQL .┃ Nginx . OS┃ Redis . 支付宝┃ . 淘宝┃ . 微信┃ . 金融系统┃ .┃ .┃................................................................┃ .┃ .┃ 创业初期业务系统 . ERP┃ 后台管理系统 . 工作流系统┃ 运营管理系统 . 业务流系统┃ .┃ .┃ .┼━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━→业务复杂度

                                               ┌─ 服务      │                                               ├─ 模块      │       ┌ 架构可扩展 ── 拆分 ─┌─ 拆分形态 ┼─ 插件      │ 自顶向下拆解       │                        │            ├─ class     │       │                      ┌│            └─ package   ↓可扩展 ┤                      │└─ 拆分粒度：内部复杂度（可用开发人数衡量）、外部复杂度（可用业务流程涉及对象数量衡量，内外平衡、先粗后细）       │            ┌─ 拆分 ┘       ├ 应用可扩展 ┤                 └ 代码可扩展 ┤          ┌─ 预测变化：2年原则（只预测2年内的变化）                     └─ 封装 ─┤                                 │                                          ┌─ 规则引擎                                 └─ 封装变化：3次原则（一写、二抄、三封装）┼─ 微内核                                                                             ├─ 抽象层                                                                             └─ 设计模式

b.高性能（叠加法则）

1.高性能架构

                                 ┌─ 进程模型（多进程、多线程）               ┌─ 计算高性能 ─┼─ 网络模型（PPC/TPC、Reactor）               │                └─ 缓存模型（本地缓存、独立缓存）       ┌ 单机 ┤       │      └─ 存储高性能 ─── 存储核心模型（B+Tree、LSM）       │高性能 ┤       │      ┌─ 计算高性能 ─┐       └ 集群 ┤                ├─ 任务分配               │                ├─ 任务分解               └─ 存储高性能 ─┘

2.计算高性能

（1）负载均衡

·负载均衡架构四级负载均衡架构：

• DNS（客户端）

• 负载：F5/LVS+keepalive（服务端）

• nginx（服务端）

• 微服务网关（服务端）

• HTTP-DNS

• GSLB

DNS（客户端）地理位置和机房级别的负载均衡，可以定制私有 HTTP-DNS·优点：标准协议·缺点：1）不够灵活 2）DNS 劫持 3）DNS 缓存

LVS（服务端）地理位置和机房级别的负载均衡·优点：标准协议·缺点：1）不够灵活 2）DNS 劫持 3）DNS 缓存

F5（服务端）处理器：英特尔四核 Xeon 处理器（8 超线程逻辑处理器内核）内存：32GB 硬盘：400GB SSD 价格：100w 性能：L7 请求数：1M/s，L4 连接数：400K/sL4HTTP 请求数：7M/s，最大 L4 并发连接数：24ML4 吞吐量：40Gbps，L7 吞吐量：16Gbps

处理器：单 CPU；内存：4GB 硬盘：500GB 端口：8 个千兆端口，4 个可选千兆光纤端口。价格：30w 性能：4Gbps

LVS（服务端）内核级别负载均衡，基本能跑满千兆网卡带宽，性能量级 10-100w 请求

·负载均衡算法（1）轮询（2）随机（3）加权轮询（4）轮询负载（5）hash 算法

（2）多级缓存架构

五级缓存：

• 本地

• CDN

• Web 容器（tomcat、nginx）

• 应用（进程、SSD 缓存）

• 分布式缓存

3.存储高性能

                                               ┌ 规划：根据成本、预算、目标等                                 ┌ 用户量预估 ┼ 推算：基于已有数据                                 │            └ 对比：跟已有标杆对比                                 │                                 │              ┌ 行为                 ┌ 估算性能需求 ┼ 用户行为建模 ┼ 数量                 │              │              └ 频率                 │              │                 │              │              ┌ 数据量：需要存储的数据总量                 │              └ 性能需求计算 ┼ 请求量：对数据的读写请求量（TPS/QPS）                 │                              └ 预留量：预留的增长空间                 │                 │                      ┌ 技术本质                 │              ┌ 方法 ┼ 技术储备                 │              │      └ 综合考虑如何设计存储架构 ┼ 选择存储系统 ┼      ┌ 单机是否能够存储                 │              │      ├ 单机是否能够支撑读性能                 │              └ 逻辑 ┼ 单机是否能够支撑写性能                 │                      ├ 是否要自动切换                 │                      └ 是否要分区部署                 │                 │              ┌ 设计数据结构                 └ 设计存储方案 ┼ 验证读写场景                                 └ 评估读写性能

（1）读写分离

方式：一主一从、一主多从优：提升读性能缺：复制延迟、读写路由应对策略：·复制延迟（1）读写绑定缺：业务侵入（2）二次读取：读从机失败后，再读一次主机缺：加大主机读操作压力（3）业务分级：关键业务全部指向主机，非关键业务采用读写分离缺：不同人随意性较强·读写路由代码封装：sharding-jdbc，实现简单，但要多套 sdk 中间件封装：sharding-proxy，跨语言，维护复杂

（2）分库分表

方式：分库、分表场景：（1）B+Tree 3 层大约是 2000 万条（2）数据量持续增长的表复杂度：·表关联困难（1）小表冗余（2）字段冗余（3）代码 join

·路由 sharding-jdbc

·事务问题分布式事务

·分布式 id

（3）分片架构

复杂度：·分页困难改为无限下拉瀑布流

（4）分区架构

c.高可用（冗余法则）

冗余或分解（横向、纵向），高可用并不是说要建立一个完美的方案，而是降低事故发生的概率或事故发生后的影响。

                     ┌─ 任务分配 ─┬ “任务分配器”，作为分配的节点可以是服务器，也可以是sdk                     │              ├ “任务分配器”，所有管理的所有服务器，可以通过配置文件、数据库、配置服务器       ┌ 计算高可用 ┤              ├ 分配策略：轮询、随机权重、哈希       │            └─ 任务分解 ─┴ 监控检测，故障切换       │       │                                        ┌─ 命令（数据量小、可能不一致）高可用 ┤                          ┌─ 复制格式 ┤       │            ┌─ 数据复制 ┤            └─ 数据（数据量大、数据一致）       │            │            │            ┌─ 同步       │            │            └─ 复制方式 ┼─ 异步       └ 存储高可用 ┤                          ├─ 半同步                     │                          └─ 多数同步                     │            ┌─ 独裁式（中心化、如redis sentinel、zookeeper、raft、keepalive）                     └─ 状态决策 ┼─ 协商式（主备，可能出现双主）                                   └─ 民主式（raft、paxos，可能出现脑裂）措施：quorum

1.异地多活架构

一般会对核心业务做异地多活，前提是业务须支持 BASE 理论。核心业务：用户量 营收 交易量 阅读量

（1）灾备架构·同机架 or 同机房：·同城双中心：应对“机房级别”灾难。能当同一逻辑机房相距 50km 以下机房间网络延时 < 2ms 多光纤通路：防止脑裂异地多活不做用户分区·跨城双（多）中心--邻近城市：应对“城市级别”灾难。能当同一逻辑机房相距 200km 左右机房间网络延时 < 10ms 异地多活不做用户分区·跨城双（多）中心--远端城市：应对“区域级别”灾难。机房间网络延时 > 30ms 不能当同一逻辑机房相距 1000km 以上异地多活用户分区·跨国多中心合规与监管区域用户分区不会做异地多活：1.时延较高；2.政策不同

远距离 2000km 以上

（2）同步方式

（3）原则只保证核心业务只能做到最终一致性只能保证绝大部分用户

业务分级───────→数据分类───────→数据同步───────→异常处理保证 top3 业务 保证 top3 的关键数据

     ┌ 访问量

业务分级 ┼ 核心场景└ 收入

     ┌ 同步数据量：只同步数据的修改     ├ 一致性：一致性要求，强一致性还是最终一致性

数据分类 ┼ 唯一性：幂等、可重复├ 可丢失性：不可丢失（余额）、可丢失（评论）└ 可恢复性：

     ┌ 消息队列     ├ 数据库同步

数据同步 ┼ 块同步├ 文件同步└

     ┌ 业务兼容

异常处理 ┼ 事后补偿└ 人工修正

2.存储高可用

（1）复制架构

           ┌ 可用   ┐ ┌─ 故障 ┤        ├ 复制架构 │        └ 可恢复 ┘

系统 ┤│ ┌─ 可用：多活架构└─ 灾难 ┤└─ 可恢复：备份

主备复制：数据可恢复主从复制：数据可恢复、高性能读取主备级联复制

主从跨机房复制：IDC1、IDC2 在同一城市，IDC1、IDC2 在不同城市双机切换：主从切换、主备切换集群选举

（2）集群架构

指多个服务器组成一个集群，每台服务器都会负责存储一部分数据；同时，为了提升硬件利用率，每台服务器又会备份一部分数据。

复杂度：·均衡性·容错性·可伸缩性

（3）数据分区

·集中式┌────┐ ┌────┐ ┌────┐│北京分区│ │上海分区│ │广州分区│└────┘ └────┘ └────┘│ │ │└───────┐│┌───────┘│││↓↓↓┌──────┐│西安备份中心│└──────┘

特点：

• 设计简单，各分区之间并无直接联系，可以做到互不影响。

• 扩展容易，如果要增加第四个分区（例如，武汉分区），只需要将武汉分区的数据复制到西安备份中心即可，其他分区不受影响。

• 成本较高，需要建设一个独立的备份中心。

·互备式┌───────┐ ┌───────┐│ ↓ │ ↓┌────┐ ┌────┐ ┌────┐│北京分区│ │上海分区│ │广州分区│└────┘ └────┘ └────┘↑ │└─────────────────┘

特点：

• 设计比较复杂，各个分区除了要承担业务数据存储，还需要承担备份功能，相互之间互相关联和影响。

• 扩展麻烦

• 成本低，直接利用已有的设备。

·独立式┌────┐ ┌────┐ ┌────┐│北京分区│ │上海分区│ │广州分区│└────┘ └────┘ └────┘│ │ ││ │ ││ │ │↓ ↓ ↓┌────┐ ┌────┐ ┌────┐│天津备份│ │杭州备份│ │汕头备份│└────┘ └────┘ └────┘

特点：

• 设计简单，各分区互不影响。

• 扩展容易，新增加的分区只需要搭建自己的备份中心即可。

• 成本高，每个分区需要独立的备份中心，备份中心的场地成本是主要成本，因此独立式比集中式成本要高很多。

3.计算高可用

（1）接口高可用

             ┌ 限流：请求端、接入端、微服务限流 ┌ 请求过多 ┤ │          └ 排除

接口 ┤│ ┌ 熔断└ 接口故障 ┤└ 降级

（2）限流

固定窗口（临界点问题）/滑动窗口漏桶令牌桶（速率控制）

d.高并发？？？？？？？？

e.架构设计质量

                                   ┌─ 成本                                   ├─ 安全

需求 ─ 复杂度 ─ 备选架构 ─ 总体架构 ┼─ 可测试性 ─ 架构方案├─ 可维护性└─ 可观测性

1.成本

▲低成本复杂度本质┌─ 缓存├─ 虚拟化（容器）┌ 优化 ┼─ 性能调优│ ├─ 开源方案│ └─ 采用高性能硬件（加机器是综合成本最低的方式，服务器、开发、运维、测试成本）低成本复杂度 ┤│ ┌─ NoSQL│ ├─ k8s└ 创新 ┼─ 倒排索引└─ 云计算

2.安全性

▲安全性复杂度本质┌─ 网络隔离┌ 架构安全 ┼─ 流量清洗│ └─ 机房切换安全性复杂度 ┤│ ┌─ 业务漏洞（保底限制）└ 业务安全 ┼─ 安全漏洞（安全框架）└─ 内鬼破坏（权限管控，编码、管理角度）

3.可测试性

▲可测试性：软件系统在测试环境下能否方便的支持测试各种场景的能力┌─ 全链路压测┌ 架构可测试 ┤│ └─ 行为可手动触发（主备切换、触发选举）可测试性 ┤│ ┌─ 变量可修改└ 应用可测试 ┼─ 状态可见└─ 行为可手动触发（停用队列）

4.可维护性

▲可维护性：软件系统支持定位问题、修复问题的能力┌─ 全链路压测┌ 架构可维护 ┤ ┌─ 降级│ └─ 维护操作 ┼─ 下线可维护性 ┤ └─ 切换│ ┌─ 变量可修改└ 应用可维护 ┼─ 状态可见└─ 行为可手动触发（停用队列）

5.可观测性

▲可观测性：软件系统对外展现内部状态的能力┌─ 日志┌ 信息输出 ┼─ API│ └─ 命令行可观测性 ┤│ ┌─ 运维平台└ 信息展现 ┤└─ 管理平台

6.平稳性

▲平稳性：避免剧烈波动，如 mq 消峰、限流、预分配（分布式 id）

c.QPS 估算

1.估算单机最大 QPS 假设系统处理一个请求的响应时间是 100ms，则 1s 可以处理 10 个请求，即单核 QPS 为 10。如果 CPU 是 24 核，所以 QPS = 10*24 = 240。这个评估方法正确吗？如果是一个纯粹的 CPU 密集型应用，只读写内存，无任何磁盘 I/O，网络 I/O（RPC 调用、数据库访问、缓存读写），则这个评估方法基本是正确的。但实际上，对于大部分的 Web 应用来说，虽然请求处理时间是 100ms，但不代表 CPU 就运行了 100ms。那怎么知道，这 100ms，哪些是耗在了 CPU 计算，哪些是耗在了数据库访问，哪些是耗在了磁盘读写呢？一个办法是对代码做 profiling，对代码打点，统计这 100ms 的耗时分布。

假设，最终发现：100ms = 10ms（CPU 计算）+ 70ms（数据库访问）+ 20ms（缓存读写）那意味着 CPU 只运行了 10ms，另外 90ms 都是空闲的，在等待 I/O。假设让 CPU 跑满，1s 钟则应该可以处理 100 个请求，则估算的最大 QPS = 100 * 24 = 2400。（这里是假设 CPU 是整个系统的资源瓶颈，不是内存、带宽）

当然，要达到 2400/s，得让 CPU 充分利用，不等待 I/O，那技术上如何实现呢?（1）开多线程线程个数 = CPU 核数 * (线程等待时间 + 线程 CPU 时间）/ 线程 CPU 时间在这个例子中，就是 24 * 100/10 = 240 个线程。当然，线程多了，线程切换也需要耗费一定的 CPU 时间，所以实际效果可能是比 2400qps 略小。（2）使用异步 I/O 不等待 I/O，每个 CPU 只需要一个线程，线程数 = CPU 数。最典型的例子就是 Redis 和 Nginx，前者是单线程程序，后者是单进程程序，跑一个 CPU。有多少个 CPU，就部署多少个实例。

知道了单机的最大 QPS，紧接着就是下 1 个问题：我怎么知道这个最大 QPS 已经是上限了，还有多大提升空间？？？？？？？？？？？？

F.微服务

a.微服务

                 ┌─ 微服务关系复杂                 ├─ 团队效率下降     ┌ 粒度太细 ┼─ 问题定位困难     │          └─ 系统性能下降

微服务 ┤踩坑 │ ┌─ 无法快速交付└ 基础设施缺乏 ┤└─ 服务管理混乱

                 ┌─ 分布式事务 ┐     ┌ 数据分布 ┤              ├ 最终一致性     │          └─ 全局幂等   ┘

微服务 ┤挑战 │ ┌─ 接口兼容├ 服务分布 ┤│ └─ 服务管理混乱│ ┌└ 复杂度 ┤└ 系统集成难度增加

                                                 ┌ 业务专家                                 ┌ 业务边界划分 ┼ 粗分演进                                 │              └ 参考已有实现                                 │                 ┌─ 按业务拆分 ┤                 │              │          ┌ 三个火枪手                 │              │          ├ 领域-服务：1对1     ┌ 拆分方式 ┤              └ 服务拆分 ┼ 领域-服务：n对1     │          │                          └ 领域-服务：1对n     │          │              ┌ 按性能     │          │              ├ 按业务重要程度     │          └─ 按质量拆分 ┼ 按可用性     │                          └ 按稳定性     │

微服务 ┤拆分 │ ┌─ 构建核心的基础设施├ 基础设施要求 ┤│ └─ 构建完善的基础设施││ ┌ 一步到位└ 落地方式 ┤└ 逐步迭代

b.技术中台

1.业务中台

企业内部业务相关能力的共享，是跨业务的，相似的业务构建在同一个中台上。将可复用的公共能力从各个单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。

2.数据中台

企业内部所有业务数据能力的共享，目的是数据打通，不同业务间数据可以共享。数据中台的主要目标是打通数据孤岛，实现业务“融合”和“创新”。

c.机房

1.单机房数据隔离

2.单机房服务数据双隔离

3.双机房数据隔离

G.重构

1.代码重构

（1）目的 1.增加可读性 2.增加可维护性 3.增加可扩展性

（2）关键点不影响输出不修正错误不增加新功能

2.架构重构

（1）目的修复质量问题，如性能、可用性、可扩展、职责混乱

（2）时机业务线性增长

（3）关键点不影响输出不修正错误不增加新功能

3.架构演进

参考：当企业发展较好的情况下，用户日活量大体如下：1 年：60 万用户日活 5 年：1000 万用户日活

H.

I.云原生

a.概念

1.什么是云原生？

2.云原生的特点

• 按需分配

• 弹性扩缩容

云原生：服务化、容器化、服务网格、云产品 soa、微服务容器+容器管理服务风格：接口级别

所有的基础平台都是 cloud native

┌──────┐ ┌────┐ ┌──────┐│ request │ │ 函数 │ │ response ││ │────→│ │────→│ ││ data │ │ 算法 │ │ data │└──────┘ └────┘ └──────┘↑│┌──────┐│ 中间件 │└──────┘

b.微服务

1.介绍

·什么是 SOA？SOA 的全称是，面向服务架构(Service Oriented Architecture)，它属于一种组件架构模型。实际上 SOA 只是一种架构设计模式，而 SOAP、REST、RPC 就是根据这种设计模式构建出来的规范，其中 SOAP 通俗理解就是 http+xml 的形式，REST 就是 http+json 的形式，RPC 是基于 socket 的形式。CXF 就是典型的 SOAP/REST 框架，dubbo 就是典型的 RPC 框架，而 SpringCloud 就是遵守 REST 规范的生态系统。

·什么是微服务？

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. (MartineFowler 原文)微服务架构和 SOA 架构非常类似,微服务只是的 SOA 升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。 组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。若我们把 PC 中的各个组件以服务的方式构 建，那么这台 PC 只需要维护主板（可以理解为 ESB）和一些必要的外部设备就可以。CPU、内存、硬盘等都是以组件方式提供服务，例如 PC 需要调用 CPU 做计算处理，只需知道 CPU 这个组件的地址就可以了。

微服务就是一系列协同工作的，小而自治的服务群。一般会遵循以下原则：

• AKF 拆分原则

• 前后端分离

• 无状态服务

• restful 通信风格

·AKF 拆分原则

• X 轴：基于水平扩展复制（A+A+A+A）《可扩展艺术》一书提出了一个系统可扩展模型--AKF 可扩展立方（Scalability Cube）。为了解决单节点、单实例、单机带来的单点故障、资源限制（容量、连接）问题。

• Y 轴：基于纵向业务、功能切分（A+B+C+D）某些功能被频繁访问，涉及到数据频繁读写，其他数据基本不怎么访问，这时候可以将这部分数据独立出来，也就是根据功能、业务继续拆分服务器，这种拆解就是 AFK 中的 Y 轴拆分

• Z 轴：基于特定场景隔离（Area1+Area2+Area3+Area4）Z 轴扩展通常是指基于请求和用户独特的需求，进行系统划分，并使得划分出来的子系统相互隔离，但又是完整的。如：（1）单元结构化移动端、PC 端；（2）数据分区北京区域、上海区域、青岛区域、成都区域；数据类型（如：业务类型）数据范围（如：时间段，用户 id）数据热度（如：用户活跃度，商品热度）读写分离（如：商品描述，商品库存）

2.微服务基础设施

服务网关 服务流控 服务降级 服务安全

服务注册 服务发现 服务路由 服务容错（断路器、重试）

接口框架 分布式事务 自动化测试 容器编排自动化部署 灰度发布 服务监控（包括链路追踪） 链路追踪

配置中心 日志中心 分布式锁 消息队列 健康检查 分布式任务

（1）分布式（锁、缓存、数据库）（2）微服务网关（3）配置中心（4）服务治理：服务注册、服务发现（5）服务监控 APM（6）健康检查（7）流量管理：断路器、流量切换（8）重试机制（9）服务降级（10）链路追踪（11）服务描述

（12）服务粒度（13）rpc（14）容器（15）无状态（16）一致性（17）版本控制（18）restful（19）请求缓存（20）请求合并

（21）日志中心（22）分布式任务调度

3.微服务网关

所有的业务接口通过 API 网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过 API 网关。采用网关方式有如下优势：·有能力为微服务接口提供网关层次的抽象。比如：微服务的接口可以各种各样，在网关层，可以对外暴露统一的规范接口。·轻量的消息路由、格式转换。·统一控制安全、监控、限流等非业务功能。·每个微服务会变得更加轻量，非业务功能个都在网关层统一处理，微服务只需要关注业务逻辑目前，API 网关方式应该是微服务架构中应用最广泛的设计模式。

api gateway：安全 限流 缓存 日志 监控 认证 aggr api gateway：超时 缓存 熔断 重试 聚合

route: 核心思想是，通过用户特定标识（ parameter 、header、body、ip、id），根据路由策略，将请求引流到不同版本的服务上

4.熔断

Service D 挂了电话，响应很慢。Service G 和 Service F ，都依赖 Service D，也会受到牵连，对外响应也会变慢。影响层层向上传递，Service A 和 Service B 也会被拖垮，最后，引发雪崩效应，系统的故障影响面会越来越大。

c.Kubernetes

k8s并不是因为微服务而生而是因为docker而生只是天时地利人和正好赶上了微服务流行的时代，docker的特性正好特别适用于微服务，而k8s进一步对docker方便的编排。从基础设施方向来讲k8s可以比作是IDC机房和机房工作人员，对物理服务器（docker）的存放与管理，上机架、装系统、接网络等等。从微服务的角度来讲，k8s通过基础设施的方式通过逻辑抽象出service等概念提供了对微服务的另一种实现，就好比用N台电脑联网提供了FTP服务。优点：1、在基础层提供了抽象，对代码无侵入缺点：1、对微服务治理比较弱，如熔断限流等，当然这也不应该是k8s做的。

d.Istio（网格化）

Istio的理论概念是Service Mesh（服务网络），我们不必纠结于概念实际也是微服务的一种落地形式有点类似上面的SideCar模式，它的主要思想是关注点分离，即不像SpringCloud一样交给研发来做，也不集成到k8s中产生职责混乱，Istio是通过为服务配 Agent代理来提供服务发现、负截均衡、限流、链路跟踪、鉴权等微服务治理手段。Istio开始就是与k8s结合设计的，Istio结合k8s可以牛逼的落地微服务架构。优点：1、关注点分离，对代码无侵入2、服务治理相关较全面缺点：

e.Serverless（无服务化）

那么，当人们谈论无服务器 Serverless 架构的时候，到底是指什么呢？其实，无服务器架构并不是说不使用服务器了。恰恰相反，客户端-服务端模式仍然在其中发挥着重要的作用。

无服务器架构实际上指的是能够让开发者在不需要关心服务器上架、为操作系统打补丁、创建容器镜像这些工作的情况下，就能够完成编码、部署和创建应用这一整套流程的架构。