这是我参与「第五届青训营 」笔记创作活动的第10天
本篇文章将主要从微服务架构的基础知识方面进行介绍，由于本人对微服务架构的基础知识了解不多，因此，主要从概念、原理等方面进行记录，方便日后回顾。
1.微服务架构背景知识
系统架构的演变有5种形式，分别为单体架构、垂直应用架构、分布式架构、SOA架构和微服务架构。
单体架构：all in one process
-
优势：性能最高、冗余小
-
劣势：debug困难、模块相互影响、模块分工、开发流程
垂直应用架构：按照业务线垂直划分
-
优势：业务独立开发维护
-
劣势：不同业务存在冗余、每个业务还是单体
分布式架构：抽出业务无关的公共模块
-
优势：业务无关的独立服务
-
劣势：服务模块bug可导致全站瘫痪、调用关系复杂、不同服务冗余
SOA架构：面向服务
-
优势：服务注册
-
劣势：整个系统设计是中心化的、需要从上至下设计、重构困难
微服务架构：彻底的服务化
-
优势：开发效率、业务独立设计、自上而下、故障隔离
-
劣势：治理、运维难度、观测挑战、安全性、分布式系统
微服务架构核心要素
-
服务治理：服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理...
-
可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪...
-
安全：身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击...
2.微服务架构原理及特征
-
基本概念
-
服务：一组具有相同逻辑的运行实体
-
实例：一个服务中，每个运行实体即为一个实例
-
实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程（反之不常见）
-
集群：通常指服务内部的逻辑划分，包含多个实例
-
常见的实例承载形式：进程、VM、k8s pod...
-
有状态/无状态服务：服务的实例是否存储了可持久化的数据（例如磁盘文件）
-
服务间通信：对于单体服务，不同模块通信只是简单的函数调用。对于微服务，服务间通信意味着网络传输。
-
-
流量特征
-
统一网关入口
-
内网通信多数采用RPC
-
网状调用链路
-
3.核心服务治理功能
服务发布，即指让一个服务升级运行新的代码的过程。
服务发布的难点主要有三个：服务不可用、服务抖动、服务回滚
蓝绿部署优势：简单，稳定；劣势：但需要两倍资源
流量治理：在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
负载均衡负责分配请求在每个下游实例上的分布。
常见的LB策略：
-
Round Robin
-
Random
-
Ring Hash
-
Least Request
......
微服务架构中典型的稳定性治理功能主要有四个：限流、熔断、过载保护、降级
4.服务治理实践
在写代码过程中，一般会进行重试。这边将列举出重试在本地函数调用和远程函数调用中分别可能出现的异常。
-
本地函数调用：
-
参数非法
-
OOM（Out Of Memory）
-
NPE（Null Pointer Exception）
-
边界 case
-
系统崩溃
-
死循环
-
程序异常退出
-
-
远程函数调用
-
网络抖动
-
下游负载高导致超时
-
下游机器宕机
-
本地机器负载高，调度超时
-
下游熔断、限流
......
-
重试的意义：
-
降低错误率：假设单次请求错误概率0.01，那么连续两次错误概率则为0.0001
-
降低长尾延时：对于偶尔耗时较长的请求，重试请求有机会提前返回
-
容忍暂时性错误：某些时候系统会有暂时性异常（例如网络抖动），重试可以尽量规避
-
避开下游故障实例：一个服务中可能会有少量实例故障（例如机器故障），重试其他实例可以成功
重试的难点：幂等性、重试风暴、超时设置
重试策略：
-
限制重试比例：设定一个重试比例阈值（例如1%），重试次数占所有请求比例不超过该阈值
-
防止链路重试：链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明“请求失败，但别重试”。
-
Hedged requests:对于可能超时（或延时高）的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的相应。
5.总结
本篇文章主要从四个方面进行总结和介绍了微服务架构的相关内容。
6.引用
本篇文章的主要内容主要来自于字节内部课程。
