微服务 ｜ 青训营笔记
这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天，主要记录相关的知识点。
本堂课重点内容
- 微服务架构简介
- 微服务架构原理及特征
- 微服务核心服务治理功能
微服务架构简介
微服务架构本身是 SOA 架构在服务层面更进一步的架构，相比较于 SOA ，微服务架构自身不需要依赖于服务注册中心，而是将业务与服务合为一体。
整体的微服务的框架如下：
作为分布式系统之一的微服务架构，服务是最重要的，为了管理好服务，就需要有服务配置与链路追踪的管理能力。
微服务架构包括三个基本要素：服务治理，可观测性和安全。
- 服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
- 可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
- 安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
微服务架构原理及特征
基本概念
服务(service)：一组具有相同逻辑的运行实体（一个服务运行的代码是一样的）
实例(instance)：一个服务中的每个运行实体（一个服务就是运行同一段代码的多个实例）
集群(cluster)：指服务内部的逻辑划分，包含多个实例
服务，集群与实例的关系如下图所示：
实例与进程的关系：没有必然对应关系，一般一对一或者一对多（一个实例对多个进程）
实例承载形式：进程、VM、k8s pod等
有状态/无状态服务：一个服务的实例是否存储了可持久化的数据（例如存储到磁盘）
服务间通信
对于普通的单体架构，服务通信只需要通过函数调用就可以了，因为都在本地，但是对于微服务，由于是分布式的，所欲通常会需要网络传输。
一个通信的示例图
服务注册与发现
由于服务之间需要通过网络通信，因此获取服务之间的实例的地址就成为了一个开发中要考虑的问题。
一种简单的的方案是直接指定ip地址与端口号，但是带来的问题也很明显：
- 没有任何动态能力（写死了ip和port）
- 有多个实例下游实例怎么办？
另外一种方式是使用DNS：
- 本地 DNS 存在缓存，导致延迟
- DNS 没有负载均衡
- 不支持服务探活检查
- DNS 不能指定端口
在微服务架构中，为了解决这个问题，提出了服务注册发现这个概念，其实际工作原理如下：
- 新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
- 旧服务实例下线前，从服务注册中心删除该实例，下线流量
- 新服务实例上线后，在服务注册中心注册该实例，上线流量
从微服务流量的角度来看，其具有如下特点：
- 统一网关入口
- 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
- 网状链路调用
微服务核心服务治理功能
服务发布
服务发布：让一个服务升级运行新的代码的过程（更新代码）
服务发布的问题：
- 服务不可用：对于一个服务下的一个实例，一旦服务更新，那么这个实例就会进入暂时的不可用状态。
- 服务抖动：流量消失，进入短暂的不可用状态。
- 服务回滚：新升级的代码出现问题，需要回滚版本。
解决服务发布问题的办法：
-
蓝绿部署
- 将服务分成两个部分（cluster），分别先后发布
- 优点是简单、稳定
- 缺点是需要使用两倍资源，并且在高流量的情况下可能会给服务器带来压力，因此适合在低流量场景下使用
-
灰度发布（金丝雀发布）
- 先发布少部分实例，接着逐步增加发布比例
- 优点是不需要像蓝绿部署那样增加资源
- 缺点是回滚难度大，基础设施要求高，并且流量等需要精细化控制
流量治理
流量控制：在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制
流量控制可以从以下几个角度考虑：
- 地区
- 集群
- 实例
- 请求
流量控制的实例：
负载均衡
负载均衡：负责分配请求在每个下游实例上的分布（即对于一个服务的多个实例，尽可能使得每个实例收到的请求个数较为均衡）。
常用的负载均衡策略如下：
-
Round Robin
-
Random
-
Ring Hash
-
Least Request
稳定性治理
一个重要思想：线上服务总是会出问题，不管服务是否正确。
即使程序没有 bug，在上线后面对复杂的环境，也可能会产生新的问题。
稳定性治理的方式：
-
限流：限制服务处理的最大
QPS，（请求接收方）拒绝过多请求 -
熔断：(请求发起方)中断请求路径，增加冷却时间从而让故障实例尝试恢复
-
过载保护：在负载高的实例中，（请求接收方）主动拒绝一部分请求，防止实例被打挂
-
降级：服务处理能力不足时，（请求接收方）拒绝低级别的请求，只响应线上高优请求
个人总结
本次课程主要学习了：
- 微服务架构简介
- 微服务架构原理及特征
- 微服务核心服务治理功能
