这是我参与「第三届青训营 -后端场」笔记创作活动的的第14篇笔记， 本文主要介绍了微服务架构原理与治理实现。
微服务架构介绍
系统架构演变历史
单体架构
垂直应用架构
分布式架构
SOA架构(面向服务)
微服务架构
微服务架构概览
微服务架构核心要素
- 服务治理
- 可观测性
- 安全性
微服务架构原理和特征
基本概念
如果把HDFS看做一组微服务
服务间通信
- 单体服务：通信是简单的函数调用
- 微服务：通信意味着网络传输
服务注册和发现
在代码层面，如何调用一个目标服务的地址？
指定ip：port
这种方式的问题
- 一个服务里面可能有多个实例，这个方法只有一个实例会得到请求
- 不能固定ip，服务地址会变
指定域名
- 一个域名可以指定多个ip，上面的问题好像都解决了
- 新的问题：
-
- 本地DNS存在缓存,导致延时。
- 负载均衡问题。
- 不支持服务实例的探活检查。
- 域名无法配置端口。
新增一个服务注册中心
用于存储服务名和服务实例的映射
服务实例上线和下线过程
下线服务B的实例3：从注册中心中对应实例
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
\
核心服务治理功能
服务发布：
让一个服务升级运行新的代码的过程
发布的难点
蓝绿部署
把服务B的实例分成两个集群，发布分别进行，先把流量切换到蓝色集群，然后升级绿色集群，再切换到绿色集群
灰度发布（金丝雀发布）
加新的代码实例，看看能不能正常运行，然后去掉老的代码实例
缺点：
- 即使代码升级到99%，出现了bug，也需要把代码都倒退回去，对基础设施要求非常高
流量治理
在微服务架构下,我们可以基于地区、集群、实例、请求等维度,对端到端流量的路由路径
- 基于地区：北京，上海
- 服务A：少部分流量打入测试集群：10% test instance
- 服务B：新旧机器，流量设置不同，老机器流量少
- 服务C：内部用户的测试请求发送到测试集群实例
\
负载均衡
常见的策略：
- Round Robin
- Random
- Ring Hash
- ...
稳定性治理
线上服务总是会出问题的，和程序正确性无关
- 网络攻击
- 流量突增
- 机房断电
- ...
典型的稳定性治理功能
- 限流
- 熔断
- 过载保护（CPU）
- 降级
字节跳动服务治理实践
重试的意义
远程函数调用
重试可以避免偶发的错误
意义
重试的难点
默认是不用重试的，为什么呢？
- 幂等性
- 重试风暴（雪崩）
- 超时设置
重试风暴
微服务链路都很深的，如果无脑重试会导致下游服务爆炸式重试
重试策略
限制重试比例
设定一个重试比例的阈值，重试次数站所有请求比例不能超过该阈值
防止链路重试
最理想的情况只有最下一层要重试
可以返回特殊的status表名，“请求失败但别重试”
Hedged Request（对冲请求？）
对于延迟高的请求，重新向另一个下游实例发送一个相同的请求，等待先到达的响应
