- 微服务架构
- 系统架构需要演进（由于各种原因）
- 单体架构
- 性能最高
- 冗余小
- debug困难
- 模块相互影响
- 模块分工，开发流程难
- 垂直应用架构
- 业务独立开发维护
- 每个业务还是单体
- 分布式架构
- 抽出与业务无关的公共模块
- 单个bug会导致全站瘫痪
- 调研关系复杂 不同服务冗余
- SOA架构
- 面向服务
- 服务注册中心
- 重构困难
- 从上而下
- 微服务架构
- 彻底的服务化
- 从下而上
- 开发效率好
- 业务独立
- 故障隔离
- 治理，运维难
- 观测挑战
- 安全性
- 分布式系统
- 单体架构
- 用户通过 网关 处理不同的服务
- 服务配置和治理
- 链路追踪和监控
- 服务治理
- 可观测性
- 以往是单个整体的服务去看日志
- 而微服务日志数量庞大
- 链式调用看传统调用栈不合适
- 安全
- 服务之间认证授权
- 系统架构需要演进（由于各种原因）
- 微服务架构原理
- 基本概念
- seveice（服务） instance（实例）
- 实例和进程的关系 一个实例可能会有多个进程
- 集群 cluster 服务内部的逻辑划分
- 实例承载进程 VM k8s pod
- 有状态/无状态 是否可持久化的数据
- HDFS看做一组微服务
- 微服务通信
- 单体服务 不同模块通信 通过函数调用
- 微服务 服务间通信意味着网络传输
- 网络传输协议
- HTTP
- gRPC
- Thrift
- 服务注册及发现
- hardcode 写死ip地址
- 存在多个实例
- 服务地址会变
- 指定域名 DNS解析成多个地址
- 本地DNS存在缓冲 导致延时
- 负载均衡问题（可能一直访问IP）
- 不支持探活检查
- 域名无法指定端口
- 新增统一的服务注册中心
- 一个哈希表
- 设置权重 每次调用random
- 上述是服务注册发现的基本的机制
- 无损的服务实例上下线
- 先删表 再下线
- 先上线 （健康检查） 再加表（注册）
- 流量特征
- 统一网关入口
- 内网通信多采用RPC（二进制协议 性能好）
- 网状调用链路
- hardcode 写死ip地址
- 基本概念
- 核心服务治理
- 服务发布 让一个服务升级运行新的代码
- 难点
- 服务不可用
- 服务抖动
- 服务回滚
- 解决
- 蓝绿发布
- 简单稳定
- 但需要两倍资源 在流量少的时段发布
- 灰度发布（金丝雀发布）
- 慢慢加新的代码实例
- 精细的部署 回滚很难
- 蓝绿发布
- 难点
- 流量治理（Traffic Control）
- 可以基于地区 集群 实例 请求等维度 对端到端流量的路由路径治理
- 负载均衡（Load Balance） 分配下游的流量
- Load Balance
- 轮询
- Random
- Ring Hash 一致性哈希
- Load Balance
- 稳定性治理
- 线上服务总会出问题 这与程序的正确性无关
- 网络攻击
- 流量突增
- 机房断电
- 解决办法
- 限流 （reject 一些流量）
- 熔断 （冷却 拒绝上游的流量）
- 过载保护 （CPU过高 拒绝一部分）
- 降级 （拒绝低等级）
- 线上服务总会出问题 这与程序的正确性无关
- 服务发布 让一个服务升级运行新的代码
- 字节的服务治理实践
- 本地函数调用 没有重试的必要
- 远程函数调用 有重试的意义（存在网络调用）
- 网路抖动
- 下游负载高导致超时
- 下游及其宕机
- 本地机器负载高
- 下游熔断 限流
- 重试可以避免偶发的错误 提高SLA (Service-Level-Agreement)
- 降低错误了
- 降低长尾延时
- 融入暂时性错误
- 避开下游故障实例
- 重试的难点
- 幂等性
- 重试风暴（调用链路太深 重试次数随服务层数会指数增加）
- 超时设置
- 解决方案
- 限制重试比例 每一个服务的
- 防止链路重试
- Hedeged requests
- 字节内部重试实践
