发表于 更新于 分类于 本文字数： 4k 阅读时长 ≈ 15 分钟

微服务

参考来源：字节跳动青训营（后端）

IDL：接口描述（定义）语言，用于描述接口

规则引擎：由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

优点：

  • 分离商业决策逻辑与开发者的技术决策
  • 提高实现复杂逻辑的代码的可维护性

架构，又称软件架构：

  • 是有关软件整体结构与组件的抽象描述
  • 用于指导软件系统各个方面的设计

软件架构：

  • 单机（单一进程，单一机器）

    优点：

    • 简单

    缺点：

    • 运维需要停服，用户体验较差
    • 承载能力有限。了解下 c10k 问题（服务器如何支持10k个并发连接）

  • 单体（单一进程，多个机器）

    优点：

    • 具备水平扩容能力
    • 运维不需要停服

    缺点：

    • 后端进程职责太多，越来越臃肿
    • 爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃

  • 垂直应用（多个进程，多个机器）

    优点：

    • 一定程度上减少了后端进程职责
    • 一定程度上缩小爆炸半径

    缺点：

    • 没有根本解决单体架构的问题

  • SOA (Service Oriented Architecture)

    SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。

    优点：

    • 各服务的职责更清晰
    • 运维粒度减小到服务，爆炸半径可控

    缺点：

    • ESB (企业服务总线) 往往需要一整套解决方案

  • 微服务 (Microservice)

    在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务。

    优点：

    • 兼具 SOA 解决的问题
    • 服务间的通信更敏捷、灵活

    缺点：

    • 运维成本

架构演进的初衷：满足软件迭代诉求，提高迭代效率

架构演进的思路：垂直切分——分布式，水平切分——分层/模块化

云计算

云计算基础：

  • 虚拟化技术
    • 硬件层面（VM 虚拟机）- KVM/Xen/VMware
    • 操作系统层面（Container 容器）- LCX/Docker/Kata Container
    • 网络层面 - Linux Bridge/Open v Switch
  • 编排方案
    • VM - OpenStack/VMWare Workstation
    • Container - Kubernetes/Docker Swarm

云计算架构：

  • 云服务
    • IaaS（基础设施即服务） - 云基础设施，对底层硬件资源池的抽象
    • PaaS（平台即服务） - 基于资源池抽象，对上层提供的弹性资源平台
    • SaaS（软件即服务） - 基于弹性资源平台构建的云服务
    • FaaS（函数即服务） - 更轻量级的函数服务。好比 LeetCode 等 OJ，刷题时只需要实现函数，不需要关注输入输出流
  • 云部署模式
    • 私有云 - 企业自用
    • 公有云 - AWS/Azure/Google Cloud/Huawei
    • 混合云

云原生

云原生，实际是云原生（计算）的简称，它是云计算发展到现在的一种形态。

云原生技术为组织（公司）在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。 它的代表技术：

  • 弹性资源
  • 微服务架构
  • DevOps
  • 服务网格

弹性资源

基于虚拟化技术，提供的可以快速扩缩容的能力。可以分为弹性计算资源和弹性存储资源两个方面。

弹性计算资源：

  • 计算资源调度
    • 在线计算 - 互联网后端服务
    • 离线计算 - 大数据分析（Map-Reduce/Spark/Flink）
  • 消息队列
    • 在线队列 - 削峰、解耦
    • 离线队列 - 结合数据分析的一整套方案，如 ELK

弹性存储资源：

  • 经典存储
    • 对象存储 - 视频、图片等。结合 CDN 等技术，可以为应用提供丰富的多媒体能力
    • 大数据存储 - 应用日志、用户数据等。结合数据挖掘、机器学习等技术，提高应用的体验
  • 关系型数据库
  • 元数据
    • 服务发现
  • NoSQL
    • KV 存储 - Redis
    • 文档存储 - Mongo

在云原生的大背景下，不论是计算资源还是存储资源，他们都像是服务一样供用户使用。

微服务架构

微服务架构下，服务之间的通讯标准是基于协议而不是 ESB 的。

  • HTTP - H1/H2
  • RPC - Apache Thrift/gRPC

如何在 HTTP 和 RPC 之间选择？

  • 性能 - RPC 协议往往具备较好的压缩率，性能较高。如 Thrift, Protocol Buffers
  • 服务治理 - RPC 中间件往往集成了丰富的服务治理能力。如 熔断、降级、超时等
  • 可解释性 - HTTP 通信的协议往往首选 JSON，可解释性、可调试性更好

服务网格

什么是服务网格？

  • 微服务之间通讯的中间层
  • 一个高性能的 4 层网络代理
  • 将流量层面的逻辑与业务进程解耦

没有什么是加一层代理解决不了的问题，服务网格相比较于 RPC/HTTP 框架：

  • 实现了异构系统治理体验的统一化
  • 服务网格的数据平面代理与业务进程采取进程间通信的模式，使得流量相关的逻辑（包含治理）与业务进程解耦，生命周期也更容易管理

分布式理论

什么是分布式？

  • 分布式系统定义：跨多个节点的计算机程序的集合
  • 使用分布式系统的五大优势：去中心化、低成本、弹性、资源共享、可靠性高
  • 分布式系统的挑战：故障、网络、环境、安全

常见的分布式系统：

  • 分布式存储：GFS、Ceph、HDFS、Zookeeper
  • 分布式数据库：Spanner、TiDB、HBase、MangoDB
  • 分布式计算：Hadoop、YARN、Spark

系统模型

故障模型

六种故障模型，从处理的难易程度分类

  • Byzantine failure：节点可以任意篡改发送给其他节点的数据，是最难处理的故障
  • Authentication detectable byzantine failure (ADB)：节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission failure：节点收到数据的时间无限晚，即收不到数据
  • Crash failure：节点停止响应，持续性的故障
  • Fail-stop failure：错误可检测，是最容易处理的故障

拜占庭将军问题

两将军问题

  • 定义：
    • 两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识
  • 结论：
    • 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识
  • TCP是两将军问题的一个工程解

三将军问题：

  • 两个“忠将”A和B，一个“叛徒”C，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。
  • 由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致

四将军问题：

  • 将军D作为消息分发中枢，约定如果没收到消息则执行撤退
  • 步骤：
    • 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
    • D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。
  • 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致

共识和一致性

  • 不同客户端A和B看到客户端C写入，因为时机的不同，产生数据读取的偏差。引导出最终一致性的详细说明
  • 要保证所有客户端看到相同的值，需要多节点进行“协商”，达成共识，来保证线性一致性
  • 一致性和可用性是对矛盾

理论基础

CAP理论

CAP的定义，分别代表一致性、可用性、分区容错性。三者无法同时达到

CAP诞生了三类系统：

  • CA系统：传统数据库的代表
  • AP系统：放弃强一致性，保证高可用，不少nosql存储系统采用
  • CP系统：放弃可用性，保证数据一致性

举例说明两个分布式进程之间同步数据，当出现故障的时候，如何选择不同的CAP系统，以及带来的影响：

  • CP系统：故障发生时，为了避免读到不一致的数据，可能拒绝访问
  • AP系统：故障发生时，为了保证可用性，允许不同进程读到不同的数据

针对故障场景，可以通过故障转移的方式，做一个相对较优的解决方式：

  • 允许一个进程作为Master，其他进程作为Backup，当故障时将请求转移给Backup进行处理

ACID理论

  • ACID理论是针对CA系统而言的，通常在数据库中具有广泛意义

  • 事务是数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行

  • 数据库事务拥有四个特性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）

BASE理论

BASE理论是针对AP系统而言的，其来源于对大型互联网分布式实践的总结

  • Basically Available(基本可用)：假设系统，出现了不可预知的故障，但还是能用
  • Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性
  • Eventually consistent（最终一致性）：数据最终一定能够达到一致的状态

分布式事务

二阶段提交

定义：

  • 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设：

  • 协调者和参与者进行通信
  • 预写式日志被保持在可靠的存储设备上
  • 所有节点不会永久性损坏，即使损坏后仍然可以恢复

正常流程：Prepare阶段和Commit阶段

异常流程：Prepare阶段失败 -> 回滚；协调者宕机 -> 重新启用新的协调者；双故障重启 -> 数据库管理员介入

两阶段提交需解决的问题：

  • 性能问题：需要多次网络通信，资源需要等待并锁定
  • 新协调者：如何确定状态选出新协调者
  • Commit阶段网络分区带来的数据不一致：非所有节点都收到Commit请求

三阶段提交

  • 针对两阶段提交的补充，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制
  • CanCommit阶段：询问是否可以执行；PreCommit阶段：重新确认是否可以执行
  • DoCommit阶段：向所有人提交事务

MVCC

MVCC：多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。

悲观锁和乐观锁

  • 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据
  • 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作

版本的选取：使用物理时钟或逻辑时钟

  • 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms。
  • 逻辑时钟：中心化授时的方式–时间戳预言机（TSO），好处是无需硬件的支持

微服务框架

架构概览：

  • 网关
  • 服务配置和治理
  • 链路追踪和监控

三大要素：

  • 服务治理
    • 服务注册
    • 服务发现
    • 负载均衡
    • 扩缩容
    • 流量治理
    • 稳定性治理
  • 可观测性
    • 日志采集
    • 日志分析
    • 监控打点
    • 监控大盘
    • 异常报警
    • 链路追踪
  • 安全
    • 身份验证
    • 认证授权
    • 访问令牌
    • 审计
    • 传输加密
    • 黑产攻击

架构原理及特征

服务注册及服务发现

  • 基本问题

    • 服务间调用中，如何指定下游服务实例的地址？

  • 简单方案

    • 直接指定 ip:port？
      • 没有任何动态能力
      • 有多个实例下游实例怎么办？
    • 使用 DNS？
      • 本地 DNS 存在缓存，导致延迟
      • DNS 没有负载均衡
      • 不支持服务探活检查
      • DNS 不能指定端口

  • 服务注册发现

    • 新增一个统一的服务注册中心，用于存储服务名到服务实例之间的映射关系
    • 旧服务实例下线前，从服务注册中心删除该实例，下线流量
    • 新服务实例上线后，在服务注册中心注册该实例，上线流量

  • 微服务流量特征

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

核心服务治理功能

服务发布

  • 何为服务发布

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

  • 服务发布难点

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

  • 蓝绿部署

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

  • 灰度发布（金丝雀发布）

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

流量治理

  • 流量控制

    • 在微服务架构中，可以从各个维度对端到端的流量在链路上进行精确控制

  • 控制维度

    • 地区维度
    • 集群维度
    • 实例维度
    • 请求维度

负载均衡

  • Round Robin

  • Random

  • Ring Hash

  • Least Request

稳定性治理

  • 限流

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

  • 熔断

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

  • 过载保护

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

  • 降级

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

分布式定时任务

发展历史：

  • Linux命令-CronJob

  • 单机定时任务-Timer、Ticker

  • 单机定时任务-ScheduledExecutorService

  • 任务调度- Quartz

  • 分布式定时任务

业内流行框架：

  • 美团点评Xxl-job
  • 阿里巴巴SchedulerX
  • 腾讯TCT

两种方案：

  • 触发器（腾讯、字节）
  • 时间轮（Quartz）

业务应用：

  • 业务应用
    • 所有需要定时、延时、周期性执行任务的业务场景，都可以考虑使用分布式定时任务
  • 知识面扩充
    • 分布式定时任务
    • 单机定时任务
    • 延时消息
    • 离线计算引擎Hive
    • 实时计算引擎Flink