微服务架构——不变的基建 ｜ 青训营笔记

aKun
91 阅读4分钟

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

微服务架构——不变的基建

微服务架构是当前大多数互联网公司的标准架构。

本次将介绍

  • 微服务架构的由来及原理
  • 服务治理功能如何工作的。

01.微服务架构介绍

为什么系统架构需要严谨？

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

1.1系统架构演变历史

image.png

单体架构

image.png

垂直应用架构 image.png

分布式架构

image.png

SOA架构（Service Oriented Architecture）

image.png

微服务架构

image.png

1.2微服务架构概览

image.png

1.3微服务架构核心要素

image.png

1.4总结

  • 系统架构的演变历史
  • 微服务架构的整体概览
  • 微服务架构中的核心要素

02微服务架构原理及特征

服务(service)

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

image.png

2.1基本概念

如何把 HDFS 看作一组微服务

image.png

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

image.png

2.1服务注册及发现

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

image.png

image.png 回答：服务有多个实例，没法 hardcode (记住一个服务的所有实例都是运行同一份代码)服务实例ip port本身是动态变化的

image.png

解决

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png 了解了服务发现的基本机制，我们来看看如何基于服务发现来实现平滑无损的服务实例上下线流程 假设系统管理员需要下线service B的实例-3 不能直接下线，因为还有流量

2.3流量特征

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

2.4总结

  • 微服务架构中的基本组件及术语
  • 服务注册及发现
  • 无损的服务实例上下线流程
  • 微服务架构中的基本流量特征

03核心服务治理功能

3.1服务发布

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

服务发布的难点

image.png

蓝绿部署

image.png

image.png

image.png

image.png

image.png

灰度发布（金丝雀发布）

image.png

image.png

3.2流量治理

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

image.png

3.3负载均衡

负载均衡（Load Balance）负责分配请求在每个下游实例的分布

image.png

3.4稳定性治理

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

image.png

微服务架构中典型的稳定性治理功能

image.png

image.png

3.5总结

  • 服务发布：蓝绿部署、灰度发布
  • 基于地区、集群、实例、请求等维度的流量治理功能
  • 几种常见的负载均衡策略
  • 微服务架构中的稳定性治理功能

04.字节跳动服务治理实践

4.1重试的意义

本地函数调用

image.png

可能有哪些异常？

  • 参数非法
  • OOM（Out Of Memory）
  • NPE（Null Pointer Exception）
  • 边界 case
  • 系统崩溃
  • 死循环
  • 程序异常退出 本地函数调用基本没有重试的意义

远程函数调用 image.png

image.png

重试的意义

image.png

4.2重试的难点

既然重试这么多好处，为什么默认不用呢？

image.png

幂等性:多次请求可能会造成数据不一致 重试风暴:随着调用深度的增加，重试次数会指数级上涨（稍后分析) 超时设置:假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢?

image.png

重试风暴

image.png

4.3重试策略

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

image.png

防止链路重试

链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的 status 表明 "请求失败，但别重试"

image.png

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

image.png

4.4重试效果验证

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

image.png

4.5总结

  • 重试的意义及难点
  • 应对重试风暴的策略

课程总结

  • 微服务架构介绍
  • 微服务架构原理及特征
  • 核心服务治理功能
  • 字节跳动服务治理实践
avatar
文章
阅读
粉丝