这是我参与「第三届青训营 -后端场」笔记创作活动的的第4篇笔记。
微服务架构原理与治理实践 | 青训营笔记
微服务架构介绍
为什么要学习微服务架构？ 微服务架构是当前大多数互联网公司的架构标准
可以学到什么？
- 微服务架构的由来和原理
- 服务治理功能是如何进行的
架构演进历史
单体架构 -> 垂直应用架构 -> 分布式架构 -> SOA架构 ->微服务架构
单体架构
优势：
- 性能最高
- 冗余小 劣势
- debug困难：一块有bug整个系统都会陷入瘫痪，难以定位bug
- 模块相互影响
- 模块分工和开发流程难度较大,几乎无法分工
垂直应用架构
按照业务线垂直划分
优势：
- 业务独立开发维护 劣势
- 不同业务线之间存在冗余，无法实现复用
分布式架构
抽出业务无关的公共模块
优势：
- 业务无关的独立服务 劣势
- 服务模块Bug可导致全站瘫痪
- 调用关系错综复杂
- 不同服务之间依然存在冗余
SOA架构
面向服务。开始引入服务、服务注册 的概念
优势：
- 引入了服务和服务注册的概念 劣势：
- 整个系统的设计依然是中心化的
- 需要从上至下设计
- 重构困难
微服务架构
微服务架构的核心要素
服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
可观测性
- 日志采集
- 日志分析
- 监控大点
- 监控大盘
- 异常报警
- 链路追踪
安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
微服务架构原理及特征
基本概念
- 服务：一组具有相同逻辑的运行实体。通俗来说就是一段相同的代码
- 实例：一个服务中，每个运行实体即为一个实例
- 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程。但一个进程一般不会对应多个实例
- 集群：通常指服务内部的逻辑划分，包括多个实例
- 常见的实例承载形式：进程、vm、k8s pod...
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)
如果把HDFS看做一组微服务：
概念：Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统（Distributed File System）
服务间通信：
对于单体服务，不同模块通信只是简单的模块调用 对于微服务，服务间通信意味着网络传输
在代码层面如何指定调用一个目标服务地址？
上述图例中的这种为什么不行？
解释：
一个服务中会有多个实例，Ip+端口没有办法指定是具体哪一个实例
服务实例ip+端口本身是动态变化的
如何解决？使用dns？ 存在的问题：
- 本地dns存在缓存导致延时
- 负载均衡问题
- 不支持服务实例的探活检查
- 域名无法配置端口
解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射 服务注册中心，简单来说就是一个哈希表或者说一个map
服务下线的过程： 注册中心中删去 -> 服务中该instance不再调用 -> 再先加一个实例到服务B -> 服务注册中心注册 -> A去调用该实例
流量特征：
内网通信多数采用rpc )
核心服务治理功能
服务发布
服务发布，即指让一个服务升级运行新的代码的过程
所以，服务发布的难点在哪？
服务抖动：实例暂时消失，响应的发往这个实例的流量也会消失
服务回滚：新的代码有问题，先倒回上一个没问题的
发布的方式有：
-
蓝绿部署
-
灰度发布（金丝雀发布）
流量治理
微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端的路由路径进行精确控制
负载均衡
负载均衡负责分配请求在每个下游实例上的分布
稳定性治理
线上服务总是会出问题的，与程序的正确性无关。常见问题： 网络攻击、流量突增、机房端点、光纤被挖断、机器故障、网络故障等 稳定性治理功能：
降级：重要的服务保留，不重要的服务先拒绝
字节跳动服务治理实践
重试的意义：
本地函数可能存在死循环等各种问题 远程函数调用可能出现网络抖动等问题 重试的意义：
- 避免掉偶发的错误，提高sla
- 降低长尾耗时
- 容忍暂时性错误
- 避开下游故障实例
重试的难点：
- 幂等性：多次请求可能会造成数据不一致
- 重试风暴： 随着调用深度的增加，重试次数会指数级上涨
- 超时限制
