微服务框架 - 不变的基建 | 青训营笔记

writiger
58 阅读5分钟

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

重点内容

  1. 微服务架构介绍
  2. 微服务架构原理及特征
  3. 核心服务治理功能
  4. 字节跳动服务治理实践

知识点介绍

微服务架构介绍

为什么系统架构需要演进

  • 互联网的爆炸性发展
  • 硬件设施的快速发展
  • 需求复杂性的多样化
  • 开发人员的急剧增加
  • 计算机理论及技术的发展

演变历史

  • 单体架构

    • 优点

      • 性能最高
      • 冗余小

    • 缺点

      • debug困难
      • 模块相互影响
      • 模块分工、开分流程

  • 垂直应用架构

    • 优点

      • 业务独立开发维护

    • 缺点

      • 不同业务存在冗余
      • 每个业务还是单体

  • 分布式架构

    • 优点

      • 业务无关的独立服务

    • 劣势

      • 服务模块bug可导致全站瘫痪
      • 调用关系复杂
      • 不同服务冗余

  • SOA架构

    • 优点

      • 服务注册

    • 缺点

      • 整个系统设计是中心化的
      • 需要从上至下设计
      • 重构困难

  • 微服务架构

    • 优点

      • 开发效率
      • 业务独立设计
      • 自下而上
      • 故障隔离

    • 缺点

      • 治理、运维难度
      • 观测挑战
      • 安全性
      • 分布式系统

微服务架构核心要素

  • 服务治理

    • 服务注册
    • 服务发现
    • 负载均衡
    • 扩缩容
    • 流量治理
    • 稳定性治理

  • 可观测性

    • 日志采集
    • 日志分析
    • 监控打点
    • 监控大盘
    • 异常报警
    • 链路追踪

  • 安全

    • 身份验证
    • 认证授权
    • 访问令牌
    • 审计
    • 传输加密
    • 黑产攻击

微服务架构原理及特征

基本概念

  • 服务（service）一组具有相同逻辑的运行实体
  • 实例（instance）一个服务中，每个运行实体即为一个实例
  • 实力与进程的关系：实力与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程
  • 集群（cluster）通常指服务内部的逻辑划分，包含多个实例
  • 常见的实例承载形式：进程、VM、k8s pod
  • 有状态/无状态服务：服务的实例是否存储了可持久化的数据

流量特征

  • 统一网关入口
  • 内网通信多数采用rpc
  • 网状调用链路

核心服务治理功能

服务发布

服务发布，即指让一个服务升级运行新的代码的过程

服务发布的难点

  • 服务不可用
  • 服务抖动
  • 服务回滚

解决方案

  • 蓝绿部署：简单、稳定，但需要两倍资源
  • 灰度发布（金丝雀发布）：一个一个实例发布，需要精细流量控制，流量回滚复杂

流量治理

在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行治理

稳定性治理

线上服务总是会出现问题，这与程序的正确性无关

  • 网络攻击
  • 流量突增
  • 机房断电
  • 光纤被挖
  • 机器故障
  • 网络故障
  • 机房空调故障

稳定性治理功能

  • 限流
  • 熔断
  • 过载保护
  • 降级

字节跳动服务治理实践

重试的意义

一般本地函数没有重试的必要

fucn LocalFunc(x int) int {
    res := calculate
}

远程调用

func RemoteFunc(ctx context.Context, x int) (int, error) {
    ctx2, defer_func := context.WithTimeout(ctx, time.Second)
    defer defer_func()
    
    res, err := grpc_client.Calculate(ctx2, x * 2)
    return res, err
}

重试的意义

降低错误率

假设每次请求的错误率为0.01，那么连续两次错误概率则为0.0001

降低长尾延时

对于偶尔耗时较长的请求，重试请求有机会提前返回

容忍暂时性错误

某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避

避开下游故障实例

一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功

重试的难点

  • 幂等性
  • 重试风暴
  • 超时设置

重试策略

限制重试比例

设定一个重试比例阈值（例如%1），重试次数占所有请求比例不超过该阈值

防止链路重试

链路层面的放重试风暴的核心是限制每层都发生重试，理想状态下只有最下层发生重试，可以返回特殊的状态码

Hedged request

对于可能超时（或延迟高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应

课后

  1. 结合 CAP 等原理，思考微服务架构有哪些缺陷？

    数据一致性需要单独维护；微服务中一个请求可能会需要调用多个服务，某些服务的故障可能导致整个链路故障。

  2. 微服务是否拆分得越“微”越好？为什么？

    不是。拆分服务会提高网络延迟，导致进程之间通信的可用性降低，服务之间维护数据一致性复杂，一些类所需的数据不适合拆分。

  3. Service Mesh 这一架构是为了解决微服务架构的什么问题？

    Service Mesh的目标是要将微服务治理体系下沉为与业务无关的基础设施

  4. 有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务？

    我认为和CAP模型一样，微服务和单体的优缺点同样相互冲突，单体服务的运行效率高但对硬件、部署的压力较大，且需要理解大量代码；而微服务开发时只需要注重自己的模块，可以利用负载均衡分配流量降低硬件压力，链路追踪等技术进行运维。两者的优缺点互补，无法相互融合。

avatar
文章
阅读
粉丝