1. 微服务架构介绍
1.1 系统架构演变历史
1.1.1 单体架构：all in one process
优势：性能最高；冗余小
劣势：debug困难；模块相互影响；模块分工，开发流程
1.1.2 垂直应用架构：按照业务线垂直划分
优势：业务独立开发维护
劣势：不同业务存在冗余；每个业务还是单体
1.1.3 分布式架构：抽出业务无关的公共模块
优势：业务无关的独立服务
劣势：服务层模块出现问题会导致全站瘫痪；调用关系复杂；不同服务冗余
1.1.4 SOA架构：面向服务
优势：出现了服务注册与发现
劣势：整个系统设计是中心化的，需要从上至下设计，重构困难
1.1.5 微服务架构：彻底的服务化
优势：开发效率；业务独立设计；自下而上；故障隔离
劣势：治理、运维难度；观测挑战；安全性；分布式系统
1.2 微服务架构概览
从组件的维度看整体框架：网关、服务配置和治理、链路追踪和监控、一个个具体的服务
1.3 微服务架构核心要素
服务治理：服务注册/发现、负载均衡、扩缩容、流量治理、稳定性治理...
可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪...
安全：身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击...
2. 微服务架构原理与特征
2.1 基本概念
服务（service）：一组具有相同逻辑（同一份代码）的运行实体。
实例（instance）：一个服务中，每个运行实体即为一个实例。
实例与进程的关系：实例与进程没有必然对应关系，可以一个实例对应一个或多个进程（反之不常见）。
集群（cluster）：通常指==服务内部==的逻辑划分，包含多个实例。
常见的实例承载形式：进程、VM、k8s pod ...
有状态/无状态服务：服务的实例是否存储了可持久化的数据（例如磁盘文件）。
服务间通信：对于单体服务，不同模块通信只是简单的函数调用；对于微服务，服务间通信意味着网络传输。
2.2 服务注册与发现
在代码层面，如何指定调用一个目标服务的地址（ip:port）？
方案一：client := grpc.NewClient("10.23.45.67:8080")，不可行。
这种方式，ip和port固定，对于一个服务集群来说，会将所有的流量打到其中一台机器上，负载不均衡。
方案二：DNS，不可行。
- 本地 DNS 存在缓存，导致延时
- 负载均衡问题
- 不支持服务实例的探活检查
- 域名无法配置端口
方案三：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。可行。
优点：
- 探活检查，方便服务实例的上线和下线
- 负载均衡
2.3 流量特征
统一网关入口，内网通信多数采用RPC，网状调用链路。
弱化连接的概念，强调“请求“，即同一个客户端长连接发出的请求，理论上可以到达服务中所有实例。
网关可以用作身份认证，进而将 token 附在请求上。
3. 核心服务治理功能
3.1 服务发布（deployment）
服务发布即指一个服务升级运行新的代码的过程。
服务发布的难点：
- 服务不可用：代码出现bug
- 服务抖动：有的部署成功，有的部署失败
- 服务回滚：发布失败，只能回滚到上一个版本，不能原地修改bug
3.1.1 蓝绿部署
在蓝绿部署中，有两个相同的环境（或资源集）用于部署和测试新版本的软件。一个环境被认为是“蓝色”环境，另一个被认为是“绿色”环境。
当前版本的软件在蓝色环境中运行，新版本在绿色环境中进行部署和测试。一旦新版本在绿色环境中被认为稳定且功能齐全，流量可以从蓝色环境切换到绿色环境，使新版本成为当前版本。
优点：
- 停机时间最短：允许零停机更新，新版本应用程序可以在切换到蓝色环境之前就部署到绿色环境。
- 降低风险：新版本应用部署过程中出现任何问题都与绿色环境隔离，降低了大范围故障的风险。
- 简化回滚：如果部署过程中出现问题，很容易回滚到以前的版本，因为蓝色环境仍然运行以前的版本。
缺点：复杂性增加；增加资源使用；更长的部署时间；配置漂移的风险（两个相同的环境同时运行，如果更改一个环境而不更改另一个环境）
3.1.2 灰度发布（金丝雀发布）
金丝雀发布就像蓝绿部署，只是它风险更小，无需一步从蓝色切换到绿色，而是使用一种分阶段的方法。通过金丝雀分布，可以在生产基础设施的一小部分部署新的应用程序代码，一旦应用程序被签署发布，只有少数用户被路由到新版本，这样可以最大限度地减少任何影响。在没有错误报告的情况下，新版本可以逐步推广到基础架构的其余部分。
优点：降低风险；早期反馈；提高可靠性；受控推出
缺点：复杂性增加；增加资源使用；更长的部署时间；金丝雀超载的风险（金丝雀子集太小或不能代表更广泛的受众，它可能会因流量或使用而超载）
3.2 流量治理
在微服务架构下我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
3.3 负载均衡
负责分配请求在每个下游实例上的分布，常见的策略：
- Round Robin：轮询
- Random：随机
- Ring Hash：一致性哈希
- Least Request：最少请求
3.4 稳定性治理
线上服务总会出现问题（网络攻击、流量突增、机房断电、光纤被挖、机器故障），这与程序的正确性无关。
微服务架构中典型的稳定性治理功能：限流、熔断、过载保护、降级
限流：（服务B的组件，超出的QPS直接拒绝）
熔断：（服务A的组件，发现B连接不到，直接拒接发起连接）
过载保护：（服务B的组件，如果B的CPU超编，就会拒绝响应）
降级：（服务B的组件，如果B出现过载，此时允许高优先级别的服务访问，拒绝低优先级的服务访问）
总结：只有熔断是发生在请求方的，限流、过载保护、降级是发生在服务方的。·
4. 字节跳动服务治理实践
4.1 重试的意义
本地函数一般不需要重试，除非是一些非常特殊的情况。
远程调用函数需要重试，远程调用可能会出现一些异常包括但不限于：
- 网络抖动
- 下游负载高导致超时
- 下游机器宕机本地机器负载高，调度超时
- 下游熔断、限流
重试可以避免掉偶发的错误，提高 SLA (Service-Level Agreement)。
- 降低错误率：假设单次请求的错误概率为 0.01，那么连续两次错误概率则为 0.0001。
- 降低长尾延时：对于偶尔耗时较长的请求，重试请求有机会提前返回
- 容忍暂时性错误：某些时候系统会有暂时性异常 (例如网络抖动)，重试可以尽量规避
- 避开下游故障实例：一个服务中可能会有少量实例故障(例如机器故障)，重试其他实例可以成功。
4.2 重试的难点
幂等性：多次请求可能会造成数据不一致
重试风暴：随着调用深度的增加，重试次数会指数级上涨
超时设置：假设一个调用正常是 1s 的超时时间，如果允许一次重试，那么第一次请求经过多少时间时，才开始重试呢?
4.3 重试策略
限制重试比例： 设定一个重试比例阈值（如1%），重试次数占所有请求比例不超过该阈值。重试只有在大部分请求都成功，只有少量请求失败时，才有必要；如果大部分请求都失败，重试只会加剧问题严重性。因此，可以定义，比如重试次数不能超过正常成功请求次数的 1%。
防止链路重试： 链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试，可以返回特殊的status表明“请求失败，但别重试”。
Hedged requests： 对于可能超时或者延时高的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
