这是我参与「第三届青训营 -后端场」笔记创作活动的第 4 篇笔记
微服务架构介绍
-
系统架构的演进历史
- 单体架构
- 垂直应用架构
- 分布式架构
- SOA架构
- 微服务架构
-
微服务架构的三大要素
- 服务治理
- 可观测性
- 安全
-
服务
- 一组具有相同逻辑的运行实体
-
实例
- 一个服务中的每个运行实体
-
实例与进程的关系
- 没有必然对应关系，一般一对一或者一对多
-
常见的实例承载形式
- 进程、VM、k8s pod......
-
服务间通信
- 微服务之间通过网络进行通信
- 常见的通信协议包括 HTTP、RPC
1、系统架构的演进历史
1.1、单体架构
all in one process
优势：
性能最高
冗余小
劣势：
- debug 困难
字节有上万研发，试想全部开发成一个程序，debug 会是什么体验？
- 模块相互影响
非核心功能可能导致程序崩溃
- 单个仓库的模块分工，依赖管理，开发流程
几乎无法分工（除了 google）
1.2、垂直应用架构
按照业务线垂直划分
优势：
业务独立开发维护
劣势： 不同业务存在冗余 每个业务还是单体
1.3、分布式架构
抽出业务无关的公共模块
优势：
抽出与业务线无关的公共模块，分布式独立部署运行
劣势：
- 一个模块服务有问题，可以导致整个系统崩溃
- 调用关系错综复杂
- 不同服务依然存在冗余
1.4、SOA架构
面向服务
优势：引入 “服务” “服务注册” 的概念，解决分布式架构调用关系错综复杂的问题
劣势：
- 整个系统从设计上依然是中心化的
- 需要从上至下 去设计划分
- 重构困难
1.5、微服务架构
彻底的服务化，从下而上设计
从组件的维度去看看微服务架构的整体视角
优势：
- 高效的开发效率
- 业务独立设计
- 自下而上设计
- 故障隔离可控
劣势：
- 治理、运维难度
- 观测挑战
- 安全性问题
- 分布式系统本身的复杂性
2、微服务架构的三大要素
-
服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
-
可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
-
安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
3、服务治理
服务发布
-
何为服务发布
- 让一个服务升级运行新的代码的过程
-
服务发布难点
- 服务不可用
- 服务抖动
- 服务回滚
-
蓝绿部署
- 将服务分成两个部分，分别先后发布
- 简单、稳定
- 但需要两倍资源
-
灰度发布（金丝雀发布）
- 先发布少部分实例，接着逐步增加发布比例
- 不需要增加资源
- 回滚难度大，基础设施要求高
流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
-
流量控制
- 在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制
-
控制维度
- 地区维度
- 集群维度
- 实例维度
- 请求维度
负载均衡
负载均衡（Load Balance）负责分配请求在每个下游实例上的分布。
常见LB策略：
- Round Robin
- Random
- Ring Hash
- Least Request
稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
-
限流
- 限制服务处理的最大 QPS，拒绝过多请求
- 限制服务处理的最大 QPS，拒绝过多请求
-
熔断
- 中断请求路径，增加冷却时间从而让故障实例尝试恢复
- 中断请求路径，增加冷却时间从而让故障实例尝试恢复
-
过载保护
- 在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
- 在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
-
降级
- 服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
- 服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
