这是我参与「第五届青训营 」伴学笔记创作活动的第 18 天
1. 系统架构演变历史
1.1 单体架构
优势：
- 性能最高
- 冗余小
劣势：
- debug困难
- 模块相互影响
- 几乎无法模块分工，依赖管理，开发流程
1.2 垂直应用架构
优势：
- 业务独立开发维护
劣势：
- 不同业务存在冗余
- 每个业务还是单体
1.3 分布式架构
抽出业务无关的服务模块
优势：
- 业务无关的独立服务
劣势：
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
1.4 SOA架构
面向服务
优势：
- 服务注册
劣势：
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
1.5 微服务架构
彻底的服务化
优势：
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势：
- 治理，运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务架构概览
核心要素
2. 微服务架构原理及特征
2.1 基本概念
- 服务（service）
- 一组具有相同逻辑（代码）的运行实体（实例）
- 实例（instance）
- 一个服务中，每个运行实体即为一个实例
- 实例与进程的关系
- 没有必然的对应关系，一个实例可以对应一个或多个进程（反之不然）
- 集群（cluster）
- 通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式
- 进程、VM、k8s pod...
- 有状态/无状态服务
- 服务的实例是否存储了可持久化的数据（例如磁盘文件）
服务间通信
对于单体服务，不同模块通信只是简单的函数调用。
对于微服务，服务间通信意味着网络传输。
2.2 服务注册与发现
注册
如何指定调用一个目标服务的地址(ip:port)?
解决思路：
新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。
服务实例上线和下线过程
下线：先在Service Register删除addr，再对相应的实例删除
上线：先对相应的实例添加，再在Service Register添加addr
2.3 流量特征
- 统一网关入口
- 内网通信多采用RPC
- 网状调用链路
3. 服务核心治理功能
3.1 服务发布
即，指让一个服务升级运行新的代码的过程
蓝绿部署
灰度部署（金丝雀发布）
3.2 流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路径进行精确控制。
3.3 负载均衡
负责分配请求在每个下游实例上的分布。
3.4 稳定性治理
线上服务总是会出问题的，这与代码的正确性无关
微服务架构中典型的稳定性治理功能
