微服务架构介绍
架构概览
- 优势：
- 开发效率高、2. 业务独立设计、3. 自下而上、4. 故障隔离
- 劣势：
- 治理、运维难度高、2. 观测挑战、3. 安全性、4. 分布式系统的问题
核心要素
- 服务治理：
- 服务注册、2. 服务发现、3. 负载均衡、4. 扩缩容、5. 流量治理、6. 稳定性治理
- 可观测性：
- 日志采集、2. 日志分析、3. 监控打点、4. 监控大盘、5. 异常报警、6. 链路追踪
- 安全：
- 身份验证、2. 认证授权、3. 访问令牌、4. 审计、5. 传输加密、6. 黑客攻击
微服务架构原理及特征
服务间通信
对于单体服务，不同模块通信只是简单的函数调用，对于微服务，服务间通信意味着网络传输。
服务注册及发现
在代码层面，如何指定调用一个目标服务的地址（ip:port）？
解决思路：新增一个统一的注册中心，用于存储服务名到服务实例的映射。
服务的上下线流程（上面是下线流程、下面是上线流程）
流量特征
统一网关入口、内网通信多数采用RPC、网状调用链路。
核心服务治理功能
服务发布
蓝绿发布：简单、但需要两倍资源（可以根据流量的错峰特性使用蓝绿发布）
金丝雀发布：过度平滑，但是在部署时进度在1%～99%时都有可能出现问题，需要回滚版本，这种维护能力需要平台级的设施提供支持。
流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由进行精确控制。
负载均衡
负载均衡负责分配请求在每个下游实例上的分布。
常见的LB策略：轮询、随机、一致性hash等。
稳定性治理
线上服务总是会出现故障：网络攻击、流量突增、机房断电、光纤问题、机器问题、网络问题......
下面给出了微服务治理中的四个经典功能：
字节跳动服务治理实践
针对于微服务架构中的请求重试机制字节给出了如下实践：
重试的意义
本地函数重试基本上是没有意义的，而远程函数重试则有意义，因为其发生请求错误的原因可能不是下游程序编写出错，而是因为：网络抖动、下游负载高导致超时、下游机器宕机、本地机器负载高、调度超时、下游熔断、限流等。
因此远程调用的重试可以：
- 降低错误率：单次错误概率为0.01，连续错误两次概率为0.0001
- 降低长尾延迟：对于偶尔耗时较长的请求，重试请求有机会提前返回
- 规避暂时性错误：网络抖动
- 避开下游故障实例：一个服务可能会有少量故障实例（如机器故障），重试可以将请求打到其他机器
重试的难点
重试本身并不默认开启，因为有一些难点需要克服：
- 幂等性：一些请求发起一次和多次结果会造成数据不一致情况（转账）
- 超时设置：不同项目需要结合自己的业务设置超时重试时间和频率
- 重试风暴：下游的重试次数会因为调用层数的深入而不断放大
重试策略
- 限制重试比例：设定一个重试比例阈值（例如1%），重试此处占所有请求比例不超过该阈值。
- 防止链路重试：链路层面防止重试风暴的核心是限制每层都发生重试，理想情况下只有最下层发生重试。可以返回特殊的status表明“请求失败、但别重试”。
- Hedgedrequests：对于可能超时或者高延时的请求，重新向下游另一个实例发送相同请求，并且等待先到达的响应。
- 重试效果验证：
