这是我参与「第五届青训营 」伴学笔记创作活动的第 5 天

微服务架构

微服务架构原理及特征

基本组件

• 服务：一组具有相同逻辑的运行实体(一个服务实体间运行的代码一致)

• 实例：一个服务中的每个运行实体

• 实例与进程的关系：没有必然对应关系，一般一对一或者一对多

• 集群：服务内部逻辑的划分，包含多个实例

• 常见的实例承载形式：进程、VM、k8s pod......

• 有状态/无状态服务：服务实例是否存储了持久化数据

基本概念

如果把HDFS看作一组微服务，

• NameNode属于一个服务，且NameNode是一个单实例服务
• DataNode属于另一个服务

服务间通信

• 单体服务，不同模块通信就是简单的函数调用
• 微服务之间通过网络进行通信
• 常见的通信协议包括 HTTP、RPC

服务注册及发现

• **基本问题：**服务间调用中，如何指定下游服务实例的地址？

• 直接指定 ip:port

  • 没有任何动态能力
  • 有多个实例下游实例怎么办？

• 使用 DNS？

  • 本地 DNS 存在缓存，导致延迟，修改域名对应的ip无法立即得到更新
  • DNS 没有负载均衡：很多时候只选第一个
  • 不支持服务探活检查：ip配置错误，也会发送请求，导致请求错误
  • DNS 不能指定端口(因为域名无法配置端口)

• 服务注册发现

  • 新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系

  • 下线流程：从服务注册中心删除该实例，旧服务实例下线

  • 上线流程：新服务实例上线，在服务注册中心注册该实例

流量特征

• 统一网关入口
• 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）

服务治理功能

服务发布

• 何为服务发布：让一个服务升级运行新的代码的过程

• 服务发布难点

  • 服务不可用：升级的服务不可用
  • 服务抖动：实例在发布服务时会导致短暂的服务不可用
  • 服务回滚：新版本服务有bug，需要把服务回退到旧版本

• 蓝绿部署：将服务分成两个部分，分别先后发布(适合在流量请求低的时候进行部署)

  • 先把绿色集群的流量全部导入蓝色集群，对绿色集群进行服务升级
  • 再把蓝色集群的流量全部导入绿色集群，对蓝色集群进行服务升级
  • 恢复蓝色集群的正常处理
  • 简单、稳定
  • 但需要两倍资源

• 灰度发布（金丝雀发布）
  • 先发布少部分实例，如果正常之后逐步增加发布比例
  • 不需要增加资源
  • 回滚难度大，基础设施要求高

流量治理

• 流量控制：在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制

• 控制维度
  • 地区维度
  • 集群维度：比如设置少量流量走测试集群
  • 实例维度
  • 请求维度

负载均衡

负载均衡(Load Balance)负责分配请求在每个下游实例上的分布。

• Round Robin

• Random

• Ring Hash

• Least Request

稳定性治理

• 限流：限制服务处理的最大 QPS，拒绝过多请求

• 熔断：中断请求路径，增加冷却时间从而让故障实例尝试恢复(这段时间不会请求故障实例)

• 过载保护：在负载高的实例中，主动拒绝一部分请求，防止实例被打挂

• 降级：服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求