这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天，今天学习了，偏高层的设计微服务框架 - 不变的基建，还需要在实践里慢慢理解。
微服务框架：
架构演变历史：
单体架构——垂直应用架构——分布式架构——SOA架构——微服务架构
单体架构：all in one process
优势：性能最高，冗余最小
劣势：debug困难，模块相互影响，模块分工、开发流程复杂难
垂直应用架构：按照业务线垂直划分
优势：业务是独立开发维护的
劣势：不同业务存在冗余，每个业务还都是单体
微服务架构：彻底的服务化
优势：开发效率高，业务独立设计能力强，自上而下，故障是可以被隔离的
劣势：治理、运维难度大，观测挑战，安全性不高，分布式系统
微服务架构核心要素：服务治理，可观测性，安全
微服务基本概念：
服务（service)
一组具有相同逻辑的运行实体。
实例(instance)
一个服务中，每个运行实体即为一个实例。
实例与进程的关系：
实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程(反之不常见)。集群 （cluster)
通常指服务内部的逻辑划分,包含多个实例。
常见的实例承载形式：
进程、VM、k8s pod……
有状态/无状态服务：
服务的实例是否存储了可持久化的数据(例如磁盘文件)。
服务器发布：
服务器发布难点：服务不可用，服务抖动，服务回滚
蓝绿部署：简单稳定，但需要两倍资源
灰度发布（金丝雀发布）
稳定性治理：限流，短融，过载保护，降级
4.1重试的意义
降低错误率：
假设单次请求的错误概率为0.01，那么连续两次错误概率则为0.0001,
降低长尾延时：
对于偶尔耗时较长的请求,重试请求有机会提前返回。
容忍暂时性错误：
某些时候系统会有暂时性异常(例如网络抖动),重试可以尽量规避。
避开下游故障实例：
一个服务中可能会有少量实例故障（例如机器故障),重试其他实例可以成功。
