这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
微服务框架 - 不变的基建
服务架构演变
- 单体架构
项目的模块（商品管理，订单管理，用户管理，广告管理）都在一个结构里。
优势：性能最高，冗余小。
劣势：debug困难，模块相互影响，模块分工、开发流程。 - 垂直应用架构
按照业务分类（电商系统，后台系统，广告系统）。 - 分布式架构
抽出业务无关的公共模块。 - SOA架构(Service Oriented Architecture)：面向服务的架构
- 微服务架构：彻底的服务化
优势：开发效率高，业务独立设计，自下而上，故障隔离。
劣势：治理、运维难度，观测挑战，安全性，分布式系统。
微服务架构基本概念
- 服务service：一组具有相同逻辑的运行实体
- 实例instance：一个服务中，每个运行实体即为一个实例。
- 实例与进程的关系：一个实例可以对应一个或多个进程 。
- 集群cluster：通常指服务内部的逻辑划分，包含多个实例。
- 常见的实例承载形式：进程、VM、k8s pod。
- 有状态 / 无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)。
- 服务间通信：
对于单体服务，不同模块通信只是简单的函数调用。
对于微服务，服务间通信意味着网络传输。 - 流量特征：统一网关入口，内网通信多数采用RPC，网状调用链路。
服务发布
- 服务发布 (deployment)，即指让一个服务升级运行新的代码的过程。
解决方案：蓝绿部署，灰度发布（金丝雀发布）， - 流量分布
- 负载均衡
负载均衡(Load Balance)负责分配请求在每个下游实例上的分布 - 稳定性治理
线上服务总是会出问题的，这与程序的正确性无关
例如：网络攻击，流量突增，机房断电，光纤被挖，机器故障，网络故障，机房空调故障。
措施：限流，熔断，过载保护，降级。
重试的意义与措施
- 重试的意义
重试可以避免掉偶发的错误，提高 SLA (Service-Level Agreement)。 - 限制重试比例
设定一个重试比例闯值 (例如 1%) ，重试次数占所有请求比例不超过该闯值 - 防止链路重试
链路层面的防重试风暴的核心是限制每层都发生重试，理想情况下只有最下一层发生重试，可以返回特殊的 status 表明“请求失败，但别重试”。 - Hedged requests
对于可能超时(或延时高)的请求，重新向另一个下游实例发送一个相同的请求，并等待先到达的响应。
