这是我参与「第三届青训营 -后端场」笔记创作活动的的第3篇笔记
1.微服务架构由来
1.1系统架构演变历史
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
微服务架构演变史
1.1.1单体架构
所有的逻辑放在一个项目里
优势：
- 性能最高
- 冗余小
劣势：
- debug困难，很多服务糅杂在一起
- 模块相互影响
- 模块分工困难，开发流程慢
1.1.2垂直应用架构
按照业务线垂直划分
优势：
- 业务独立开发维护 劣势：
- 不同业务存在冗余
- 每个业务还是单体架构的形式
1.1.3分布式架构
抽出业务无关的公共模块，降低多个业务存在的冗余
优势：
- 业务无关的独立服务 劣势：
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 服务间还是存在冗余
1.1.4SOA架构(Service Oriented Architecture)
面向服务的架构，利用服务注册中心进行服务注册与发现，实现与业务系统的解耦。
优势：
- 服务注册与发现 劣势：
- 整个系统设计是中心化的
- 需要从上到下设计
- 重构困难
1.1.5微服务架构
彻底的服务化
优势：
- 开发效率高
- 业务独立设计
- 自下而上
- 故障隔离 劣势：
- 治理/运维困难
- 观测挑战
- 安全性
- 分布式系统
1.2微服务架构概览
1.3微服务架构核心要素
微服务中各个模块的调用之间需要身份验证与认证授权。
2微服务架构原理及特征
2.1基本概念
- 服务：一组具有相同逻辑的运行实体
- 实例：一个服务中，每个运行实体即为一个实例
- 集群：通常指服务内部的逻辑划分，包含多个实例。 服务/实例/集群的关系
- 有状态/无状态服务： 服务的实例是否存储了可持久化的数据(例如磁盘文件)
- 服务间通信： 对于单体服务，不同模块通信只是简单的函数调用 对于微服务，服务之间意味着网络通信，涉及到通信协议的选择(http/gRPC/Thrift)
2.2服务注册与发现
使用DNS来实现域名的解析，但端口还是同一个
存在的问题：
- 本地DNS存在缓存，导致延时
- 负载均衡问题，需要制定相应的多个服务实例的访问策略
- 不支持服务实例的探活检查
- 域名无法配置端口 解决思路： 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
2.3流量特征
特征：
- 统一的网关入口
- 内网通信多数采用RPC
- 网状的调用链路
3核心服务治理功能
3.1服务发布
让一个服务升级运行新的代码的过程
3.1.1蓝绿部署
步骤：
- 1.关掉绿色的服务，将流量全部切到蓝色服务上
- 2.升级绿色服务
- 3.蓝色同上
特点：简单且稳定，但需要两倍的资源
可以在流量低的时候进行。
3.1.2灰度发布(金丝雀发布)
步骤： 不断添加新的代码示例，观察服务运行情况
存在的问题：
- 不断地切流量的精细化实现复杂
- 回滚难
- 但需要的资源少
3.2流量治理
在微服务架构下，可以基于地区/集群/实例/请求等维度，对端到端的路由路径进行精确控制
3.3负载均衡
常见的LB策略：
- Round Robin(轮询策略)
- Random
- Ring Hash
- Least Request
3.4稳定性治理
线上的服务总是会出问题的，这与程序的正确性无关
- 网络攻击
- 流量突增
- 机房断电
- 光线被挖
- 机器故障
- 网络故障
- 机房空调故障 解决方案：
- 限流
- 熔断
- 过载保护
- 降级
4.服务治理实践
4.1重试的意义
重试一般用在涉及网络调用的服务上
- 网络抖动
- 下游负载高导致超时
- 下游机器宕机
- 本地机器负载高/调度超时
- 下游熔断/限流
重试的意义：
- 可以避免偶发的错误，提高SLA(Service-Level Aggrement)
- 降低长尾延时 对于偶尔耗时较长的请求，重试请求有机会提前返回
- 容忍暂时性错误 某些时候系统会有暂时性异常(例如网络抖动),重试可以尽量规避
- 避开下游故障实例 一个服务中可能会有少量实例故障(例如机器故障),重试其他实例可以成功。
4.2重试难点
- 幂等性 服务需要不管重试几次，结果还是正确的
- 重试风暴
- 超时设置
4.3重试策略
- 限制重试比例 设定一个重试比例，重试次数占所有请求比例不超过该阈值
- 防止链路重试 限制每层都发生重试，理想情况下只有最下一层发生重试，可以返回特殊的status表明“请求失败，但别重试”
- 对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
