微服务架构介绍
系统架构演变历史：单体架构👉垂直应用架构👉分布式架构👉SOA架构👉微服务架构
单体架构
- 特点：all in one process
- 优势：性能最高、冗余少
- 劣势：debug困难、模块相互影响、模块分工和开发流程
垂直应用架构
- 特点：按照业务线垂直划分
- 优势：业务独立开发维护
- 劣势：不同业务存在冗余、每个业务还是单体
分布式架构
- 特点：抽出业务无关的公共模块
- 优势：业务无关的独立服务
- 劣势：服务模块bug可导致全站瘫痪、调用关系复杂、不同服务冗余
SOA（Service Oriented Architecture）架构
- 特点：面向服务（有一个服务注册中心）
- 优势：服务注册
- 劣势：整个系统设计是中心化的、需要从上至下设计、重构困难
微服务架构
- 特点：彻底的服务化
- 优势：开发效率、业务独立设计、自下而上、故障隔离
- 劣势：治理和运维难度、观测挑战、安全性、分布式系统
微服务架构概览
服务配置和治理 ⏸ 用户终端👉网关👉服务组件 ⏸ 链路追踪和监控
微服务架构核心要素
- 服务治理：服务注册、服务发现、负载均衡等
- 可观测性：日志采集、日志分析、链路跟踪等
- 安全：身份验证、认证授权、访问令牌等
微服务架构原理及特征
基本概念
- 服务(Service)：一组具有相同逻辑的运行实体
- 实例(Instance)：一个服务中，每个运行实体即为一个实例
- 实例与进程的关系：实例与进程之间没有必然对应关系，一个实例可以对应一个或多个进程（反之不常见）
- 集群(cluster)：通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式：进程、VM、k8s pod等
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据（例如磁盘文件）
- 服务间通信：对于单体服务，不同模块通信只是简单的函数调用；对于微服务，服务间通信意味着网络传输
服务注册与发现
- 服务A寻找服务B：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
- 服务实例上线及下线过程：在注册中心把下线服务的域名增加/删除
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布
- 特点：指让一个服务升级运行新的代码的过程
- 难点：服务不可用、服务抖动、服务回滚
- 蓝绿部署：把服务的实例分成蓝色的集群和绿色的集群，依次执行蓝色集群和绿色集群（简单、稳定、但需要两倍资源、适合流量低的情况）
- 灰度发布(金丝雀发布)：依次把新的代码放入已测试完备的代码里面测试
（金丝雀对瓦斯极其敏感，可测试井下有无瓦斯。）
流量治理
- 特点：在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端对端流量的路由路径过滤
负载均衡
- 特点：负责分配请求在每个下游实例上的分布
- 常见的负载均衡(LB)策略：Round Robin、Random、Ring Hash、Least Request
稳定性治理
- 特点：线上服务总是会出问题的，这与程序的正确性无关
- 问题类型：网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障、机房空调故障等
- 微服务架构中典型的稳定性治理功能：限流(增加rate limit等)、熔断(服务负载过大或者网络连接时间过长等)、过载保护(服务CPU压力太大等)、降级(服务高负载时，只与重要服务通信，拒绝一般服务等)
字节服务治理实践
重试的意义
- 本地函数调用可能出现的异常：参数非法、OOM、NPE、边界case、系统崩溃、死循环、程序异常退出
- 远程函数调用可能出现的异常：网络抖动、下游负载高导致超时、下游机器宕机、本地机器负载高和调度超时、下游熔断和限流
- 重试可以避免掉偶发的错误，提供SLA(Service-Level Agreement)
- 重试具体意义：降低错误率、降低长尾延时（对于偶尔耗时较长的请求，重试请求有机会提前返回）、容忍暂时性错误、避开下游故障实例
重试的难点
- 幂等性
- 重试风暴
- 超时设置
应对重试风暴的策略
- 限制重试比例：设定一个重试比例阈值（例如 1 %），重试次数占所有请求比例不超过该阈值
- 防止链路重试：链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败，但别重试”。
- Hedged requests（对冲的请求）：对于可能延时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
