这是我参与「第五届青训营」伴学笔记创作活动的第 8 天
微服务框架：
系统架构演变历史
单体架构————>垂直应用架构————>分布式架构————>SOA架构————>微服务架构
单体架构：
优势：性能最高（程序之间的调用），冗余小
劣势：
- debug 困难 字节有上万研发，试想全部开发成一个程序，debug 会是什么体验 ？
- 模块相互影响 非核心功能可能导致程序崩溃
- 单个仓库的模块分工 ， 依赖管理 ， 开发流程几乎无法分工 （ 除了 google)
垂直应用架构：
按照业务垂直划分
优势： 业务独立开发维护
劣势： 不同业务存在冗余，每个业务还是单体
分布式架构：
抽出业务无关的公共模块
优势：业务无关的独立服务
劣势：
- 服务模块 bug 可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构：
面向服务
优势： 服务注册
劣势：
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
微服务架构：
彻底的服务化
优势：
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势：
- 治理 、 运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务的核心要素：
服务治理：
服务注册 服务发现 负载均衡 扩缩容 流量治理 稳定性治理
可观测性：
日志采集 日志分析 监控打点 监控大盘 异常报警 链路追踪
安全：
身份验证 认证授权 访问令牌 审计 传输加密 黑产攻击
使用微服务
微服务在解决了单体架构带来的问题的同时，也出现了部署复杂，需要增加中间件联络各服务的问题。所以，不是所有的场景都推荐使用微服务架构，具体如下:
适用场景:
①:大型复杂的项目…(来自单体架构200W行代码的恐惧)
②:快速迭代的项目…(来自一天一版的恐惧)
③:并发高的项目…(考虑弹性伸缩扩容的恐惧)
不适场景:
①：业务稳定，就是修修bug ，改改数据
②：迭代周期长 发版频率 一二个月一次
核心服务治理能力
服务发布：
即指让一个服务升级运行新的代码的过程
难点：
发布的方式：
- 蓝绿部署（简单，但是需要双倍资源,因为再更新时要承受2倍请求）： 先部署一部分集群，将更新的请求转发给另一部分集群，再部署一部分集群
灰度发布（回滚难度大 ， 基础设施要求高）：
派一个实例，试试看行不行，行的话，删除一个旧的，增加新的，重复以上操作；
流量治理：
负载均衡：
稳定性治理：
限流，熔断，降级，过载保护
字节跳动服务治理实践————重试
意义：重试可以避免掉偶发的错误 ， 提高 SLA (Service-LeveI Agreement)
- 降低错误率。
- 降低长尾延时：对于偶尔耗时较长的请求 ， 重试请求有机会提前返回 。
- 容忍暂时性错误
- 避开下游故障实例
难点：
重试风暴： 假如每个请求在失败的时候重试3次，那么随着服务的增加，后边的服务接受的请求就愈多，可能出现服务雪崩的问题
