这是我参与「第三届青训营-后端场」笔记创作活动的第4篇笔记
微服务的概念和基本原理
-
微服务架构中的基本概念及组件
-
服务：一组具有相同逻辑的运行实体
-
实例：一个服务中的每个运行实体
-
实例与进程的关系：没有必然对应关系，一般一对一或者一对多
-
常见的实例承载形式：进程、VM、k8s pod......
-
-
-
服务注册及服务发现
-
直接指定 ip:port
问题：
- 没有任何动态能力
- 有多个实例下游实例怎么办？
-
使用 DNS
问题：
- 本地 DNS 存在缓存，导致延迟
- DNS 没有负载均衡
- 不支持服务探活检查
- DNS 不能指定端口
-
服务注册发现
新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
- 旧服务实例下线前，从服务注册中心删除该实例，下线流量
- 新服务实例上线后，在服务注册中心注册该实例，上线流量
-
-
微服务流量特征
- 统一网关入口
- 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
核心服务治理功能
-
服务发布
-
概念：让一个服务升级运行新的代码的过程
-
难点：
- 服务不可用
- 服务抖动
- 服务回滚
-
蛮力发布：简单粗暴，直接用新版本覆盖老版本。
-
蓝绿部署
概念：将服务分成两个部分，分别先后发布
优势：简单、稳定
劣势：但需要两倍资源
-
灰度发布（金丝雀发布）
概念：先发布少部分实例，接着逐步增加发布比例
优势：不需要增加资源
劣势：回滚难度大，基础设施要求高
-
滚动发布：每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑
-
红黑发布：与蓝绿发布类似，但是日常只有一个集群工作，发布时扩容一个集群升级新版本，切换流量后下掉老版本的集群。
-
-
流量治理
在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制
控制维度：地区维度、集群维度、实例维度、请求维度
-
负载均衡
-
四层负载均衡（传输层）
根据IP地址和端口号，将请求报文转发给某个后端服务器。
概念：
- VIP：虚拟IP，一般作为四层反向代理的入口，client看起来一直在与VIP交互
- RS：Real Server，VIP后实际承受client请求的服务，可能是物理机/虚拟机/容器POD。RS可以通过TCP的可选字段获得client的地址。
- DPDK：Data Plane Development Kit，主要用户4层负载均衡，用于转发的网络加速领域比较多；以极大提高网卡报文的处理性能和吞吐量，提高数据平面应用程序的工作效率
转发模式：
- DR模式：修改MAC地址转发
- DNAT模式：修改目的IP地址转发
- TUNNEL模式：使用应用服务器TUNNEL功能转发
- FULLNAT模式：修改目的IP地址和源IP地址转发
调度算法：
- RR轮询：将请求平均分配给每个RS
- 加权RR轮询：将请求按照RS的负载均衡权重分配给RS
- 最小连接：将请求分配给当前连接数最少的RS
- 五元组hash：根据 (sip, dip, sport, dport, proto) 的hash值分配给RS (缺点：当后端的一个服务器出现故障时，需要重哈希)
- 一致性哈希
-
七层负载均衡（应用层）
根据应用层报文进行转发。常用nginx。
与四层负载均衡相比，灵活性更强，但效率更低。
-
-
稳定性治理
-
限流：限制服务处理的最大 QPS，拒绝过多请求
-
熔断：中断请求路径，增加冷却时间从而让故障实例尝试恢复
-
过载保护：在负载高的实例中，主动拒绝一部分请求，防止实例被打挂
-
降级：服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求
-
