微服务架构原理｜青训营笔记

路有所思
88 阅读5分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 11 天

1. 概述

我将主要介绍如下知识点：

  1. 微服务架构介绍
  2. 微服务架构原理及特征
  3. 核心服务治理功能

2. 微服务架构介绍

2.1 系统架构演变历史

1675496571212.png

详见笔者之前的文章：架构初探｜青训营笔记 - 掘金 (juejin.cn)

2.2 微服务架构概览

微服务架构：彻底的服务化

  • 优点：
    • 高效的开发迭代效率
    • 业务独立设计
    • 自下而上
    • 故障可控
  • 缺点：
    • 治理、运维难度急剧增加
    • 观测挑战
    • 安全性
    • 分布式系统本身的复杂性

微服务架构概览：

  • 网关

  • 服务配置和治理

  • 链路追踪和监控

1675497073802.png

2.3 微服务架构的核心要素

  • 服务治理

    服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理、......

  • 可观测性

    日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪、......

  • 安全

    身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击、......

3. 微服务架构原理及特征

3.1 微服务架构中的基本概念

  • 服务(service)

    • 一组具有相同逻辑的运行实体

  • 实例(instance)

    • 一个服务中的每个运行实体即为一个实例

  • 集群(cluster)

    • 通常指服务内部的逻辑划分，包含多个实例

  • 实例与进程的关系

    • 没有必然对应关系，一般一个实例可以对应一个或多个进程(反之不常见)

  • 常见的实例承载形式

    • 进程、VM、k8s pod......

  • 有状态/无状态服务

    • 服务的实例是否存储了可持久化的数据(例如磁盘文件)

  • 服务间通信

    • 微服务之间通过网络进行通信

    对于单体服务，不同模块通信只是简单的函数调用

    而对于微服务，服务间通信意味着网络传输

    • 常见的通信协议包括 HTTP、RPC

3.2 服务注册及服务发现

提出问题：

  • 在代码层面，如何指定调用一个目标服务的地址(ip:port)？

    对于网络通信功能(不管 http 还是 rpc)，我们知道是需要指定远程的 ip port 的，既然服务之间存在通信关系，在实际代码层面，我们怎么写通信地址？

hardcode？

hardcode 的方式直接指定下游实例地址有什么问题？

  • 服务有多个实例时，没法 hardcode（因为一个服务的所有实例都是运行同一份代码）
  • 服务实例 ip port 本身是动态变化的，直接指定 ip:port 则没有任何动态能力

使用 DNS？

  • 本地 DNS 存在缓存，导致延迟
  • DNS 没有负载均衡
  • 不支持服务实例的探活检查
  • DNS 不能指定端口(域名无法配置端口)

解决思路：服务注册发现：

新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系

  • 服务实例上线及下线过程
    • 旧服务实例下线前，从服务注册中心删除该实例，下线流量
    • 新服务实例上线后，在服务注册中心注册该实例，上线流量

3.3 流量特征

刚刚我们已经了解了微服务的基本概念和服务发现的思想，我们再从流量的视角看看微服务架构的全貌

弱化连接的概念，强调“请求”

即同一个客户端长连接发出的请求，理论上可以到达服务中所有实例

API gateway 可以用作身份认证，进而将 token 附在请求上

  • 统一网关入口
  • 外网通信多数采用 HTTP，内网通信多数采用 RPC（Thrift, gRPC）
  • 网状调用链路

4. 核心服务治理功能

4.1 服务发布

何为服务发布：

  • 即指让一个服务升级运行新的代码的过程

服务发布难点：

  • 服务不可用
  • 服务抖动
  • 服务回滚

蓝绿部署：

  • 将服务分成两个部分，分别先后发布
  • 简单、稳定
  • 但需要两倍资源

灰度发布(金丝雀发布)：

  • 先发布少部分实例，接着逐步增加发布比例
  • 不需要增加资源
  • 但回滚难度大，基础设施要求高

4.2 流量治理

  • 在微服务架构中，我们可以基于地区、集群、实例、请求等维度，对端到端的流量在链路上进行精确控制

4.3 负载均衡

  • 负载均衡(Load Balance) 负责分配请求在每个下游实例上的分布
  • 常见的 LB 策略：
    • Round Robin
    • Ring Hash
    • Random
    • Least Request

4.4 稳定性治理

线上服务总是会出问题的，这与程序的正确性无关

微服务架构中典型的稳定性治理功能如下：

  • 限流

    • 限制服务处理的最大 QPS，拒绝过多请求

  • 熔断

    • 中断请求路径，增加冷却时间从而让故障实例尝试恢复

  • 过载保护

    • 在负载高的实例中，主动拒绝一部分请求，防止实例被打挂

  • 降级

    • 服务处理能力不足时，拒绝低级别的请求，只响应线上高优请求

5. 总结

微服务架构是当前大多数互联网公司的标准架构，与开源生态契合，是当前主流的系统架构。提前了解微服务概念，能方便之后更快适应工作。

参考：

  • 字节内部课：微服务架构原理与治理实践
avatar
文章
阅读
粉丝