这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
微服务架构
介绍
系统架构的演技
-
单体架构：all in one
- 优势：性能最高、冗余小
- 缺点：debug困难、模块相互影响、模块分工
-
垂直应用架构：按业务线垂直划分
- 优势：业务独立开发维护
- 缺点：不同业务存在冗余、每个业务还是单体
-
分布式架构：抽出业务无关的公共服务模块
- 优势：业务无关的独立服务
- 缺点：服务模块bug可导致全站瘫痪、调用关系复杂、不同服务冗余
-
SOA架构：面向服务
- 优势：服务注册
- 缺点：整个系统设计是中心化的、需要从上到下设计、重构困难
-
微服务架构：彻底的服务化
- 优势：开发效率、业务独立设计、自上而下、故障隔离
- 缺点：治理、运维难度、安全性
微服务架构核心要素：
-
服务治理
- 服务注册与发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
-
可观测性
- 日志采集与分析
- 监控打点
- 监控大盘
- 异常警报
-
安全
- 身份验证
- 认证授权
- 访问令牌
- 传输加密
- 黑产攻击
原理及特征
- 服务：一组具有相同逻辑（同一块代码）的运行实体
- 实例：一个服务中，每个运行实体就是一个实例
- 实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程
- 集群（cluster）：通常指服务内部的逻辑划分，包含多个实例
- 常见的实例承载形式：进程、VM、k8s pod
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据（磁盘文件）
服务间通信
- 对于单体服务，不同的模块通信只是简单的函数调用
- 对于微服务，服务间通信意味着网络传输（HTTP、gRPC）
服务注册与发现
在代码层面指定调用一个目标服务的地址（ip:port）
- 如果使用DNS，缺点：本地DNS存在缓存导致延时，负载均衡问题
- 服务注册与发现：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
服务实例的上线及下线过程：
- 下线服务实例，在服务注册中心去掉服务的地址
- 上线：先将服务提起来并进行健康检查（能否处理请求），再注册到服务注册中心
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理
服务发布
让一个服务升级运行新的代码的过程
难点：
- 服务不可用：服务升级导致不可用
- 服务抖动：某个服务升级导致流量断
- 服务回滚：升级的服务代码有问题
蓝绿部署
对需要升级的服务先断流量，升级完成后再回来
缺点：需要两倍资源
灰度发布
对新上的服务一个一个上，不一次性全部上线
流量治理
在微服务架构下，基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行控制
负载均衡
将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）
常见的LB策略：
- round robin
- random
- ring hash
- least request
负载均衡简单分类：
-
集中式LB
- 服务的消费方和提供方之间使用独立的LB设施，如Nginx，由该设施把访问请求转发给服务的提供方
-
进程式LB
- 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，如何增加再从这些地址中选出一个合适的服务器
- ribbon就属于进程内LB，它是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。
稳定性治理
线上服务总是会出现问题与程序的正确性无关
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
限流：速率限制
熔断
完成情况好的请求流如下：
当一个依赖的节点坏掉时，将阻塞整个的用户请求：
流量高峰时，一个单节点的宕机或延迟，会迅速导致所有服务负载达到饱和。应用中任何一个可能通过网络访问其他服务的节点，都有可能成为造成潜在故障的来源。更严重的是，还可能导致服务之间的延迟增加，占用队列、线程等系统资源，从而导致多系统之间的级联故障。
所有上述表现出来的故障或延迟，都需要一套管理机制，将节点变得相对独立，这样任何一个单节点故障，都至少不会拖垮整个系统的可用性。
降级
服务熔断：代码写在提供方，相当于处理、返回异常
- 某个服务超时或者异常，引起熔断
服务降级：代码写在消费方，提供方关闭服务后，提示、返回异常信息
- 从整体网站请求负载考虑，某个服务熔断或者关闭，服务不再被调用
- 在客户端准备一个fallbackFactory，返回一个默认值，整体的服务水平下降
