这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天，参与青训营的第 20 天。今天主要学习了微服务架构。
微服务架构
单体架构
优势：1、性能最高 2、冗余量小
劣势：1、debug困难 2、模块相互影响 3、模块分工、开发流程
垂直应用架构
按照业务线垂直划分
优势：1、业务独立开发维护
劣势：1、不同业务存在冗余 2、每个业务还是单体
分布式架构
抽出业务无关的公共模块
优势：1、业务无关的独立服务
劣势：1、服务模块bug可导致全站瘫痪 ；2、调用关系复杂 ； 3、不同服务冗余
SOA架构
面向服务
优势：1、服务注册
劣势：1、整个系统设计是中心化的 ；2、需要从上至下设计 ；3、重构困难
微服务架构
彻底的服务化
优势：1、开发效率 ；2、业务独立设计 ； 3、自下而上 ； 4、 故障隔离
劣势：1、治理、运维难度 ； 2、观测挑战 ； 3、安全性 4、分布式系统
核心要素：服务治理；可观测性； 安全 。
基本概念：
服务（service）：一组具有相同逻辑的运行实体。
实例（instance）：一个服务中，每个运行实体即为一个实例。
实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程（反之不常见）
集群（cluster）：通常指服务内部的逻辑划分，包含多个实例。
常见的实例承载形式：进程，VM，k8s pod...
有状态/无状态服务：服务的实例是否存储了可持久化的数据（磁盘文件）。
服务间通信：
对于单体服务，不同模块通信只是简单的函数调用。
对于微服务，服务间通信意味着网络传输。
服务注册及发现：
问题：在代码层面，如何指定调用一个目标服务的地址（ip:port) ?
固定地址、DNS 有问题
解决思路：新增一个统一的服务注册中心，用于存储服务明道服务实例的映射。
服务实例上线及下线过程
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布（deployment）
即指让一个服务升级运行新的代码的过程。
服务发布的难点：
- 服务不可用
- 服务抖动
- 服务回滚
蓝绿部署：简单稳定，需要两倍资源
灰度发布（金丝雀发布）：
流量治理
微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由途径进行精确控制。
负载均衡（Load Balance）
负责分配请求在每个下游实例上的分布
常见的LB策略：
- Round Robin
- Random
- Ring Hash
- Least Request
- ......
稳定性治理
- 限流
- 熔断
- 躲在保护
- 降级
字节跳动服务治理实践
重试的意义
重试可以避免掉偶发的错误，提高SLA(Service-Level Agreement)
降低错误率
降低长尾延时
容忍暂时性错误
避开下游故障实例
重试的难点
幂等性 ；重试风暴 ； 超时设置。
重试策略
限制重试比例：设定一个重试比例阈值（1%），重试次数占所有请求比例不超过该阈值。
防止链路重试：链路层面的防重试风暴是限制每层都发生重试，理想情况下只有最下一层发生重试。可以返回特殊的status表明 “请求失败，但别重试” 。
Hedged requests
重试效果验证
今日总结：
今天主要学习了微服务架构的基本组件、工作原理、流量特征，微服务架构中核心的服务治理功能，最后介绍了字节内部微服务架构在实际应用中的稳定性治理经验和对充实策略的探索。
