微服务架构介绍
为什么系统架构需要演进？
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
项目架构演变历史
单体架构
优势：
- 性能最高
- 冗余小
劣势：
- debug 困难
- 模块相互影响
- 模块分工、开发流程
垂直架构
优势:
- 业务独立开发维护
劣势：
- 不同业务存在冗余
- 每个业务还是单体
分布式架构
优势：
- 业务无关的独立服务
劣势：
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构
优势：
- 服务注册
劣势：
-
整个系统设计是中心化的
-
需要从上至下
微服务架构
优势：
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势：
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务架构原理及特征
基本概念
服务 (service)
一组具有相同逻辑的运行实体。
实例 (instance)
一个服务中，每个运行实体即为一个实例。
实例与进程的关系
实例与进程之问没有必然对应关系，可以一个 实例可以对应一个或多个进程（反之不常见）。
集群 (cluster)
通常指服务内部的逻辑划分，包含多个实例。
常见的实例承载形式
进程、VM、k8s pod ..
有状态/无状态服务
服务的实例是否存储了可持久化的数据（例如磁盘文件）
服务注册与发现
在代码层面，不能只单单通过调用ip+port的形式来调用一个服务
DNS？
- 本地 DNS存在缓存，导致延时。
- 负载均衡问题。
- 不支持服务实例的探活检查。
- 域名无法配置端口。
解决方法：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。
流量特征
- 统一网关入口
- 内网通信多数采用RPC（相较于http效率高）
- 网状调用链路
服务发布
服务发布（deployment)，即指让一个服务升级运行新的代码的过程。
服务发布难点：
- 服务不可用
- 服务抖动
- 服务回滚
蓝绿部署
简单稳定，但需要两倍的资源
金丝雀发布
（不停添加新的代码实例，回滚困难）
流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行调节。
负载均衡
负载均衡 (Load Balance）负责分配请求在每个下游实例上的分布。
稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
主要措施：
- 限流
- 熔断
- 过载保护
- 降级
重试
重试的作用
降低错误率
- 假设单次请求的错误概率为 0.01，那么连续两次错误概率则为 0.0001。
降低长尾延时
- 对于偶尔耗时较长的请求，重试请求有机会提前返回。
容忍暂时性错误
- 某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避。
避开下游故障实例
- 一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功。
重试的难点
幂等性 重试风暴 超时设置
重试策略
重试阈值
防止链路重试
Hedged requests
对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
