这是我参与「第五届青训营 」笔记创作活动的第9天。
一、前言
《三国演义》开篇便讲道: "话说天下大势，分久必合，合久必分...."。其实经历的大部分事物都有这样的规律， 在软件系统设计中，也会经历这样的迭代演进。在两年多的微服务架构设计与实战中，笔者经历了从庞大的单体应用系统架构拆分成不同的众多的微服务应用，再将不同的微服务应用重组成有能力复用的中台，但总目的都是为了更好地支撑业务发展，提升软件开发的效率与质量。本篇主要想梳理微服务架构的一些基础知识，让大家对微服务架构有个全面系统的了解。
摘自 微服务架构的一知半解
课程背景
为什么有课程？微服务架构是当前大多数互联网公司的标准架构
学到什么？微服务架构的由来及原理，服务治理功能是如何工作的。
二、微服务架构介绍
为什么系统架构需要演进?
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
系统架构演变历史
- 单体结构
- 垂直应用架构
- 分布式架构
- SOA架构(Service Oriented Architecture)
- 微服务架构：彻底的服务化
微服务架构核心要素
- 服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
- 可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
- 安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
三、微服务架构原理及特征
基本概念
- 服务（service)：一组具有相同逻辑的运行实体。
- 实例(instance)一个服务中，每个运行实体即为一个实例
- 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程 (反之不常见)
- 集群 (cluster)：通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式：进程、VM、k8s pod
- 有状态 / 无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)。
- 服务间通信: 对于单体服务，不同模块通信只是简单的函数调用对于微服务，服务间通信意味着网络传输。
服务注册与发现
调用服务时传统方式和问题
- 硬编码，当动态变化时无法处理，而且一个服务可能会有多个实例，不能处理多IP问题
- DNS: 解决了动态变化和多IP问题，但是本地 DNS 存在缓存，导致延时；负载均衡问题；不支持服务实例的探活检查；域名无法配置端口。
解决思路: 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
服务实例上线及下线过程
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
四、核心服务治理功能
服务发布 (deployment)，即指让一个服务升级运行新的代码的过程
服务发布的难点与问题
- 服务不可用
- 服务抖动
- 服务回滚
服务发布的方式
- 蓝绿部署：多上线一个集群，将流量导向新的集群后才对旧的集群里的服务进行停止修改，修改确认无误后将流量导回旧的集群。
- 优势：简单，稳定
- 劣势：但需要两倍资源，但可以在流量低的时候进行修改，降低两倍的基数值
- 灰度发布(金丝雀发布)：对服务集群中的实例逐渐修改，一个一个修改，直到所有修改完成
- 优势：
- 劣势：以实例为维度进行流量切换，切换工作量大。回滚难度也一样大，基础设施要求高
(金丝雀发布)：金丝雀(canary) 对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只金丝雀，以确保矿井中没有瓦斯。
流量治理
- 流量治理：在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
- 不同地区的流量打向部署在不同地区的机器实例上
- 小部分流量打向测试的集群实例，作为测试
- 对于不同性能的机器实例处理不同比例的流量请求
- 通过在请求中添加标识后让该请求流量打向测试的集群，可以走常规路线，不需要搭建全部服务的环境
负载均衡
负载均衡(Load Balance) 负责分配请求在每个下游实例上的分布
常见的LB策略
- Round Robin
- Random
- Ring Hash
- Least Request
稳定性治理
线上服务总是会出问题的，这与程序的正确性无关
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障 ......
典型的稳定性治理功能
- 限流
- 熔断：当下游服务宕机时，检测到下游服务失效时能够直接解决服务请求
- 过载保护：如CPU的使用率超过80%会尝试拒绝部分请求、
- 降级：对重要等级程度低的服务（内部测试）请求进行降级，进行部分拒绝，保证高等级服务的正常运行
五、字节跳动服务治理实践
异常的情况
- 对于一个本地函数的调用，如果出现一些异常问题，有无重试必要？如：没有重试必要
- 参数非法
- OOM (Out Of Memory)
- NPE (Null Pointer Exception)
- 边界 case
- 系统崩溃
- 死循环
- 程序异常退出
- 远程函数调用出现的一些异常，对于某次失败，某些情况还是可能重试成功的
- 网络抖动
- 下游负载高导致超时
- 下游机器宕机
- 本地机器负载高，调度超时
- 下游熔断、限流
- 重试可以避免掉偶发的错误，提高 SLA(Service-Level Agreement)
重试的意义
- 降低错误率：假设单次请求的错误概率为 0.01，那么连续两次错误概率则为 0.0001。
- 降低长尾延时：对于偶尔耗时较长的请求，重试请求有机会提前返回
- 容忍暂时性错误：某些时候系统会有暂时性异常 (例如网络抖动)重试可以尽量规避
- 避开下游故障实例：一个服务中可能会有少量实例故障 (例如机器故障)，重试其他实例可以成功。
重试的难点
幂等性
重试风暴
- 调用的服务链路可能会很深，所有重试的次数都是指数型的增长的，如下图所示，只要三层放大的话，就会放到到27次
超时设置
重试策略
- 限制重试比例：设定一个重试比例闻值(例如 1%)，重试次数占所有请求比例不超过该闻值。只有在大部分请求成功才会尝试
- 防止链路重试：链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的 status 表明“请求失败，但别重试”
- Hedged requests(对冲请求)：对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
重试效果验证
实际验证经过上述重试策略后，在链路上发生的重试放大效应
