这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
本次编程学习的基本环境配置如下
OS: macOS 13.1
IDE: Goland 2022.3
Go Version: 1.18
Python Version: 3.6
主要内容
了解微服务架构. 微服务架构是当前大多数互联网公司的标准架构. 通过本节课, 可以学到微服务架构的由来和原理, 了解服务治理功能是如何工作的.
- 微服务架构介绍
- 微服务架构原理及特征
- 核心服务治理功能
- 字节调到服务治理实践
详细介绍
微服务架构介绍
系统架构演进的推动力
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
系统架构的发展路线
单体架构 => 垂直应用架构 => 分布式架构 => SOA架构 => 微服务架构
单体架构
优点: 性能高, 冗余小 缺点: 调试困难, 耦合度高
垂直应用架构: 按照业务垂直划分
优点: 业务独立开发维护 缺点: 不同业务存在冗余, 每种业务还是单体
分布式架构: 抽出业务无关的公共模块
优点: 业务无关的独立服务 缺点: 服务之间相对调用, 服务故障可能引发全站瘫痪; 调用关系复杂, 冗余较大
SOA: Service Oriented Arch
优点: 服务注册 缺点: 中心化, 自上而下设计, 重构困难
微服务: 彻底的服务化
优点: 开发效率高, 业务独立设计, 自下而上, 故障隔离 缺点: 治理和运维难度大, 观测挑战, 安全性问题
微服务架构概览
核心要素
- 服务治理:服务注册、发现; 负载均衡, 动态扩容; 流量治理和稳定性治理
- 可观测性(服务质量审计): 日志采集、分析; 监控打点和统计; 异常报警和链路追踪
- 安全(安全策略和审计): 鉴权和访问令牌、安全审计、传输层安全、黑灰产攻击
微服务架构原理及特征
基本概念
- 服务(service): 一组具有相同逻辑的运行实体。
- 实例(instance): 特定服务下，每个运行实体即为一个实例。
- 实例与进程的关系: 实例与进程之间没有必然对应关系，一个实例可以对应一个或多个进程（反之不常见)
- 集群(cluster):通常指服务内部的逻辑划分，包含多个实例。
- 常见的实例承载形式: 进程、VM、k8spod
- 有状态/无状态服务服务: 实例是否存储了可持久化的数据(例如磁盘文件)
- 服务间通信: 意味着网络传输(HTTP或RPC)
服务注册及发现
如何制定调用一个目标服务的地址
- 硬编码: 行不通, 服务一多, 改起来太麻烦了.而且也不一定只有一个实例, 扩容的时候也难以及时知晓. 需要统一的管理机制
- DNS: 在单机时代, 主机的名称确实有代表其运行服务的机制: 如一个域下运行Web的服务器通常叫www, 运行文件传输服务的服务器通常叫ftp. 但在分布式和微服务大行其道的今天, 显然行不通. 此外, DNS还有以下问题: 延迟过大, 负载均衡问题, 探活, 端口配置等(事实上, DNS及其扩展可以用来解决这些问题, 但意义不大, 解决旧的问题往往会引入新的问题. DNS的历史包袱太重了
- 新增一个统一的服务注册中心, 用于存储服务名到服务实例的映射
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布
让一个服务升级运行新的代码的过程
蓝绿部署
简单稳定, 但需要两倍资源
灰度发布
看图吧, 一看就懂, 一说就错, 代码不会写, 开摆
流量治理
在微服务架构下, 我们可以基于地区、集群、实例、请求等维度, 对端到端流量的路由路径进行精确控制
负载均衡(Load Balance)
负责分配请求在每个下游实例上的分布
策略
- Round Rabin
- Random
- Ring Hash
- Least Request
负载均衡、服务注册、服务发现和流量审计 这些本身也是服务, 或许可以叫 元服务
稳定性治理
线上肯定是要出问题的, 网络攻击, 流量激增、机器故障、物理环境不可抗力等
策略
- 限流
- 熔断
- 过载保护
- 降级(回滚?)
字节跳动服务治理实践
重试的意义
- 降低错误率
- 降低长尾延迟
- 容忍暂时性错误
- 避开下游故障实例
重试的难点在于 幂等性、重试风暴和超市设置
重试策略
- 限制重试比例阈值: 设定一个重试比例阈值, 重试次数占所有请求比例不超过该阈值
- 防止链路重试
- Hedged requests: 对于可能超时的请求, 重新想另一个下游实例发送一个相同的请求, 并等待先到达的响应
引用
字节内部课-后端入门
