这是我参与「第三届青训营 -后端场」笔记创作活动的的第15篇笔记
一、 本堂课重点内容
1.1 微服务架构介绍
1.2 微服务架构原理及特征
1.3 核心服务治理功能
1.4 字节跳动服务治理实践
二、 详细知识点介绍
2.1 微服务架构介绍
为什么系统架构需要演进
互联网的爆炸性发展
硬件设施的快速发展
需求复杂性的多样化
开发人员的急剧增加
计算机理论及技术的发展
2.1.1 系统架构演变历史
2.1.1.1单体架构：
all in one process
优势：
1.性能最高
2.冗余小
劣势：
1.debug困难
2.模块相互影响
3模块分工、开发流程
2.1.1.2 垂直应用架构
按照业务线垂直划分
优势：
1.业务独立开发维护
劣势：
1.不同业务存在冗余
2.每个业务还是单体
2.1.1.3 分布式架构
抽出业务无关的公共模块
优势：
1.业务无关的独立服务
劣势：
1.服务模块bug可导致全站瘫痪
2.调用关系复杂
3.不同服务冗余
2.1.1.4 SOA架构(Service Oriented Architecture)
面向服务
优势：
1.服务注册
劣势：
1.整个系统设计是中心化的
2.需要从上至下设计
3.重构困难
2.1.1.5 微服务架构
彻底的服务化
优势：
1.开发效率
2.业务独立设计
3.自下而上
4故障隔离
劣势：
1.治理、运维难度
2.观测挑战
3.安全性
4.分布式系统
2.1.2 微服务架构概览
2.1.3 微服务架构核心要素
2.2 微服务架构原理及特征
2.2.1 基本概念
服务(service)：一组具有相同逻辑的运行实体。
实例(instance)：一个服务中，每个运行实体即为一个实例。
实例与进程的关系:
实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程（反之不常见)
集群(cluster)：通常指服务内部的逻辑划分，包含多个实例。
常见的实例承载形式：进程、VM、k8spod
有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)
服务间通信:
对于单体服务，不同模块通信只是简单的函数调用。
对于微服务，服务间通信意味着网络传输。
2.2.2 服务注册及实现
问题：在代码层面，如何指定调用一个目标服务的地址(ip:port)?
使用hardcode?
服务有多个实例，没法hardcode(记住一个服务的所有实例都是运行同一份代码)
服务实例ip port本身是动态变化的
使用DNS?
本地DNS存在缓存，导致延时。
负载均衡问题
不支持服务实例的探活检查。
域名无法配置端口。
解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。
服务实例上线及下线过程
2.2.3 流量特征
统一网关入口
内网通信多数采用RPC
网状调用链路
2.3 核心服务治理功能
2.3.1 服务发布，即指让一个服务升级运行新的代码的过程。
服务发布的难点
蓝绿部署
蓝绿部署中，一共有两套系统：一套是正在提供服务系统，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。
最初，没有任何系统，没有蓝绿之分。
然后，第一套系统开发完成，直接上线，这个过程只有一个系统，也没有蓝绿之分。
后来，开发了新版本，要用新版本替换线上的旧版本，在线上的系统之外，搭建了一个使用新版本代码的全新系统。 这时候，一共有两套系统在运行，正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
服务发布：
灰度发布（金丝雀发布）
金丝雀(canary)对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只金丝雀，以确保矿井中没有瓦斯。
2.3.2 流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
2.3.3 负载均衡
负载均衡(Load Balance)负责分配请求在每个下游实例上的分布。
常见的LB策略
Round Robin
Random
Ring Hash
Least Request
2.3.4 稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
网络攻击
流量突增
机房断电
光纤被挖
机器故障
网络故障
机房空调故障
微服务架构中典型的稳定性治理功能：限流、熔断、过载保护、降级
2.4 字节跳动服务治理实践
2.4.1重试的意义
本地函数调用可能的异常：
参数非法
OOM (Out Of Memory)
NPE (Null Pointer Exception)
边界case
系统崩溃
死循环
程序异常退出
重试的作用：
重试可以避免掉偶发的错误，提高SLA(Service-Level Agreement)
降低错误率：
假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001。
降低长尾延时：
对于偶尔耗时较长的请求，重试请求有机会提前返回。
容忍暂时性错误：
某些时候系统会有暂时性异常（例如网络抖动)，重试可以尽量规避。
避开下游故障实例：
一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功。
2.4.2 重试的难点
幂等性：多次请求可能会造成数据不一致
重试风暴：随着调用深度的增加，重试次数会指数级上涨（稍后分析）
超时设置：假设一个调用正常是1s的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢？
2.4.3 重试策略
限制重试比例
设定一个重试比例阈值（例如1%），重试次数占所有请求比例不超过该阈值。
防止链路重试
链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。
可以返回特殊的status表明“请求失败，但别重试。
Hedged requests
对于可能超时（或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
2.4.4 重试效果验证
实际验证经过上述重试策略后，在链路上发生的重试放大效应。
三、 课后个人总结
本堂课介绍了架构的演变过程，以及相应的处理问题的方式。对实际开发有很大作用
四、 引用参考
青训营官方课件
