这是我参与「第五届青训营」伴学笔记创作活动的第9天
1、微服务框架介绍
1.1、系统架构演变历史
为什么系统架构需要演进？
- 互联网的爆炸性发展
- 便使件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展 演变历史：单体架构 -> 垂直应用架构 -> 分布式架构 -> SOA 架构 -> 微服务架构 -> service mesh
1.1.1、单体架构(all in one process)：
- 优势:
- 性能最高
- 冗余小
- 劣势:
- debug困难
- 模块相互影响
- 模块分工、开发流程
1.1.2、垂直应用架构——按照业务线垂直划分
- 优势:
- 业务独立开发维护
- 劣势:
- 不同业务存在冗余
- 每个业务还是单体
1.1.3、分布式架构——抽出业务无关的公共模块
- 优势:
- 业务无关的独立服务
- 劣势:
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
1.1.4、SOA架构(Service Oriented Architecture)——面向服务
- 优势:
- 服务注册
- 劣势:
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
1.1.5、微服务架构——彻底的服务化
- 优势:
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
- 劣势:
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
1.2、微服务架构核心要素
2、微服务架构原理及特征
2.1、基本概念
- 服务(service)：一组具有相同逻辑的运行实体。
- 实例(instance)：一个服务中，每个运行实体即为一个实例。
- 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程(反之不常见)。
- 集群(cluster)：通常指服务内部的逻辑划分，包含多个实例。
- 常见的实例承载形式：进程、VM、k8s pod……
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)。
- 服务间通信：对于单体服务，不同模块通信只是简单的函数调用。对于微服务，服务间通信意味着网络传输。
3、核心服务治理功能
3.1、服务发布
服务发布(deployment)，即指让一个服务升级运行新的代码的过程。
3.2、流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
3.3、负载均衡
负载均衡(Load Balance)负责分配请求在每个下游实例上的分布。
3.4、稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
4、服务治理实践
4.1、重试的意义
重试可以避免掉偶发的错误，提高SLA (Service-Level Agreement)
4.1.1、本地函数调用：
可能有哪些异常？
- 参数非法
- OOM (Out Of Memory)
- NPE (Null Pointer Exception)
- 边界case
- 系统崩溃
- 死循环
- 程序异常退出
4.1.2、远程函数调用：
- 网络抖动
- 下游负载高导致超时
- 下游机器宕机
- 本地机器负载高，调度超时
- 下游熔断、限流
重试的作用:
- 降低错误率
- 假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001。
- 降低长尾延时
- 对于偶尔耗时较长的请求,重试请求有机会提前返回。
- 容忍暂时性错误
- 某些时候系统会有暂时性异常（例如网络抖动)，重试可以尽量规避。
- 避开下游故障实例
- 一个服务中可能会有少量实例故障（例如机器故障)，重试其他实例可以成功。
4.2、重试的难点
- 幂等性:多次请求可能会造成数据不一致
- 重试风暴:随着调用深度的增加，重试次数会指数级上涨
- 超时设置:假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢?
