这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天
微服务框架原理
微服务框架介绍
系统框架及演变历史
-
互联网的爆炸性发展
-
硬件设施的快速发展
-
需求复杂性的多样化
-
开发人员的急剧增加
-
计算机理论及技术的发展
-
演变历史
-
单体框架
-
优势
- 性能最高
- 冗余小
-
劣势
- debug 困难
- 模块相互影响
- 模块分工、开发流程
-
-
垂直应用框架
-
按照业务线垂直划分
-
优势
- 业务独立开发维护
-
劣势
- 不同业务存在冗余
- 每个业务还是单体
-
-
分布式框架
-
抽出业务无关的公共模块
-
优势
- 业务无关的独立服务
-
劣势
- 服务模块 bug 可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
-
-
SOA 架构
-
面向服务
-
优势
- 注册服务
-
劣势
- 整个系统该设计是中心化
- 需要从上至下设计
- 重构困难
-
-
微服务架构
-
彻底的服务化
-
优势
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
-
劣势
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
-
-
微服务框架核心要素
-
服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
-
可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
-
安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
微服务架构原理及特征
基本概念
-
服务 service
- 一组具有相同逻辑的运行实体
-
实例 instance
- 一个服务中，每个运行实体即为一个实例
-
实例与进程的关系
- 实例与进程之间没有必然的对应关系，可以一个实例可以一个或多个进程（反之不常见）
-
集群 cluster
- 通常指服务内部的逻辑划分，包含多个实例
-
常见的实例承载形式
- 进程、VM、k8s pod……
-
有状态 / 无状态 服务
- 服务的实例是否存储了可持久化的数据（例如磁盘文件）
-
服务间通信
- 对于单体服务，不同模块通信知识只是简单的函数调用
- 对于微服务，服务间通信意味着网络传输
流量特征
- 统一网关接口
- 内网通信多数采用 RPC
- 网状调用链路
核心服务治理功能
服务发布
-
然过一个服务升级运行新的代码的过程
-
服务发布的难点
- 服务不可用
- 服务抖动
- 服务回滚
-
蓝绿部署
- 简单、稳定，但是需要两倍资源
-
灰度发布
- 试探性
流量治理
- 在微服务架构下，可以基于地区、集群、实例、请求等维度对端到端流量的路由路径进行精确控制
负载均衡
-
负责分配在每个下游实例上的分布
-
常见的 LB 策略
- Round Robin
- Random
- Ring Hash
- Least Request
稳定性治理
-
线上服务总是会出现问题的，这与程序的正确性无关
- 网络攻击
- 流量徒增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
-
微服务架构中典型的稳定性治理功能
- 限流
- 熔断
- 过载保护
- 降级
服务治理
重试的意义
-
降低容错率
-
降低长尾延时
- 对于偶尔耗时较长的请求，重试请求有机会会提前返回
-
容忍暂时性错误
- 某些时候系统会暂时性异常（例如网络抖动），重试可以尽量规避
-
避开下游故障实例
- 一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功
重试的难点
- 幂等性
- 重试风暴
- 超时设置
重试策略
-
显示重试比例
- 设定一个重试比例阈值，重试次数占所有请求比例不超过该阈值
-
防止链路重试
- 链路层面的放重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试，可以返回特殊的 status 表明请求失败，但别重试
-
Hedged requests
- 对于可能超市（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待到达的响应
