Go 微服务架构 | 青训笔记

用户6214681127813
74 阅读5分钟

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

Go 微服务架构

微服务架构介绍

系统架构演变历史为

  • 什么系统架构需要演进?
    • 互联网的爆炸性发展
    • 硬件设施的快速发展
    • 需求复杂性的多样化
    • 开发人员的急剧增加
    • 计算机理论及技术的发展 单体架构->垂直应用架构->分布式架构->SOA架构->微服务架构

单体架构

all in one process

  • 优势
    • 性能最高
    • 冗余小
  • 劣势
    • debug困难
    • 模块相互影响
    • 模块分工、开发流程

垂直应用架构

按照业务线垂直划分

  • 优势
    • 业务独立开发维护
  • 劣势
    • 不同业务存在冗余
    • 每个业务还是单体

分布式架构

抽出业务无关的公共模块

  • 优势
    • 业务无关 的独立服务
  • 劣势
    • 服务模块bug可导致全站瘫痪
    • 调用关系复杂
    • 不同服务冗余

SOA架构(Service Oriented Architecture)

面向服务

  • 优势
    • 服务注册
  • 劣势
    • 整个系统设计是中心化的
    • 需要从上至下设计
    • 重构困难

微服务架构

彻底的服务化

  • 优势
    • 开发效率
    • 业务独立设计
    • 自下而上故障隔离
  • 劣势
    • 治理、运维难度
    • 观测挑战
    • 安全性
    • 分布式系统

微服务架构核心要素

  • 服务治理
    • 服务注册
    • 服务发现
    • 负载均衡
    • 扩缩容
    • 流量治理
    • 稳定性治理
  • 可观测性
    • 日志采集
    • 日志分析
    • 监控打点
    • 监控大盘
    • 异常报警
    • 链路追踪
  • 安全
    • 身份验证
    • 认证授权
    • 访问令牌
    • 审计
    • 传输加密
    • 黑产攻击

微服务架构原理及特征

基本概念

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

服务间通信

  • 对于单体服务器，不同模块通信只是简单的函数调用
  • 对于微服务，服务间通信意味着网络传输

服务注册及发现

问题 在代码层面，如何制定调用一个目标服务器的地址（ip:port）

client:=grpc.NewClient("10.23.45.67:8080")
  • 本地DNS存在缓存，导致延时
  • 负载均衡问题。
  • 不支持服务实例的探活检查
  • 域名无法配置端口。 解决思路:新增一个统-的服务注册中心，用于存储服务名到服务实例的映射。

流量特征

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

核心服务治理功能

服务发布

服务发布（deployment）,即指让一个服务升级运行新的代码的过程

  • 服务发布的难点
    • 服务不可用
    • 服务抖动
    • 服务回滚

蓝绿部署

  • 简单，稳定
  • 但需要两倍资源

灰度发布（金丝雀发布）

金丝雀（canary）对于瓦斯及其敏感，17世纪时，英国矿工在下井前会放入一只金丝雀，确保矿井中没有瓦斯

流量治理

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

负载均衡

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

  • Round Robin
  • Random
  • Ring Hash
  • Least Request

稳定性治理

  • 线上服务总是会出问题的，这与程序的正确性无关。
    • 网络攻击
    • 流量突增
    • 机房断电
    • 光纤被挖
    • 机器故障
    • 网络故障
    • 机房空调故障
  • 微服务架构中典型的稳定性治理功能
    • 限流
    • 图片.png
    • 熔断
    • 图片.png
    • 过载保护
    • 图片.png
    • 降级
    • 图片.png

字节跳动服务治理实践

重试的意义

本地函数调用

func LocalFunc(x int) int {
    res:=calculate(x*2)
    return res
}
  • 可能有哪些异常?
    • 参数非法
    • OOM (Out Of Memory)
    • NPE (Null Pointer Exception)
    • 边界case
    • 系统崩溃
    • 死循环
    • 程序异常退出 远程函数调用
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
}
  • 可能有哪些异常?
    • 网络抖动
    • 下游负载高导致超时
    • 下游机器宕机
    • 本地机器负载高，调度超时
    • 下游熔断、限流 重试可以避免掉偶发的错误，提高SLA(Service-Level Agreement)
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
}

func RemoteFuncRetry(ctx context.Context,x int)(res int,err error){
    for i:=0;i<3;i++{
        if res,err=RemoteFunc(ctx,x);err==nil{
            return
        }
    }
    return
}
  • 降低错误率
    • 假设单次请求的错误概率为0.01,那么连续两次错误概率则为0.0001。
  • 降低长尾延时
    • 对于偶尔耗时较长的请求重试请求有机会 提前返回。
  • 容忍暂时性错误
    • 某些时候系统会有暂时性异常(例如网络抖动)重试可 以尽量规避。
  • 避开下游故障实例
    • 一个服务中可能会有少量实例故障(例如机器故障)，重试其他实例可 以成功。

重试的难点

重试风暴 图片.png

重试策略

限制重试比例 设定一个比例阈值（如1%）重试次数占所有请求比例不超过该阈值 图片.png 防止链路重试

  • 链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试
  • 可以返回特殊的status表明“请求失败，但别重试” 图片.png Hedged requests
  • 对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应

图片.png

重试效果验证

实际经过上述重试策略后，在链路上发生的重试放大效应

图片.png

avatar
文章
阅读
粉丝