这是我参与「第五届青训营 」伴学笔记创作活动的第 8天
一、本节课重点内容
- 微服务架构介绍
- 微服务架构原理及特征
- 核心服务治理功能
- 字节跳动服务治理实践
二、本节课详细内容
认识系统架构
系统架构按照先后出现的顺序分为单体架构，垂直应用架构，分布式架构，SOA架构，微服务架构。
各架构优缺点
单体：优势：性能最高、冗余小 劣势：debug困难、模块相互影响、分工和开发困难
垂直应用：优势：业务独立开发维护 劣势：不同业务存在冗余、各业务都是单体
分布式：优势：业务无关的独立服务 劣势：服务模块BUG可导致全站瘫痪、调用关系复杂、不同服务冗余
SOA：优势：祝福注册 劣势：系统设计是中心化的、需要自上而下设计、重构困难
微服务：优势：开发效率、业务独立设计、自下而上、故障隔离 劣势：治理运维困难、观测挑战、安全性、分布式系统
微服务核心要素
服务治理、可观测性、安全性
微服务架构原理
- 服务：一组、相同逻辑、运行实体
- 实例：运行实体 包含一或多个进程
实例的形式：进程、VM等
服务间通信
单体：函数调用
微服务：网络传输
流量特征
统一网管入口、内网通信多数采用RPC（效率高，二进制）、网状调用链路
核心服务治理
服务发布 一个服务升级运行新代码的过程
存在的困难：服务不可用、服务抖动、服务回滚
蓝绿部署：无损升级，简单、稳定，但需要两倍资源
灰度发布（金丝雀发布）：一个一个替换实例（流量切换问题、回滚问题）
流量治理
可以基于地区、集群、实例、亲求等维度进行分流
负载均衡
Round Robin、Random、Ring Hash、 Least Request
稳定性治理
限流（rate limit 超过限制的访问拒绝一部分）、熔断（多次连接无应答，取消连接）、过载保护（过载了则拒绝）、降级（优先级低的服务拒绝掉）
字节跳动服务治理实践
请求重试的意义
- 降低错误率
- 降低长尾延时
- 容忍暂时性错误
- 避开下游故障实例
请求重试的难点
- 幂等性
- 重试风暴
- 超时设置
重试策略
-
限制重试比例
-
防止链路重试
-
Hedged Requests
重试效果验证
- 字节跳动重试组件能够极大限制重试发生的链路放大效应
三、课后
1. 结合 CAP 等原理，思考微服务架构有哪些缺陷？
单体应用通过数据库事务保证一致性，拆分为微服务后，会形成分布式处理的业务，进而就会产生分布式事务一致性问题。
2. 微服务是否拆分得越“微”越好？为什么？
服务的过度拆分会使架构的设计复杂度大大提升，同时也会大大提升运维和测试的复杂度等。
3. Service Mesh 这一架构是为了解决微服务架构的什么问题？
通过将微服务通信下沉到基础设施层，屏蔽了微服务处理各种通信问题的复杂度，形成微服务之间的抽象协议层。开发者无需关心通信层的具体实现，也无需关注 RPC 通信（包含服务发现、负载均衡、流量调度、流量降级、监控统计等）的一切细节，真正像本地调用一样使用微服务，通信相关的一起工作直接交给 Service Mesh。
4. 有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务？
未完待续
