Skip to content

微服务

微服务是一种用于构建应用的架构方案。微服务架构有别于传统的单体式方案，可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

1. 实施微服务好处

  • 针对特定服务发布，影响小，风险小，成本低
  • 频繁发布版本，快速交付需求
  • 低成本扩容，弹性伸缩，适应云环境

2. 带来的问题

  • 分布式系统的复杂性
  • 部署，测试和监控的成本问题
  • 分布式事务和 CAP 的相关问题

3. Spring Cloud 组件

  • 注册中心 Eureka，其他的还有 Zookeeper、Consul 和 Nacos。用于服务发现；
  • 配置中心 Spring Cloud Config
  • 网关 Spring Gateway 或 Zuul
  • 客户端负载均衡 Ribbon，默认策略是轮询
  • 断路器 Hystix
  • RPC 客户端 Feign

4. 限流方法（流量控制、熔断降级、系统负载保护）

  • Hystrix 熔断策略基于异常比率，限流基于 QPS。支持基于调用关系的限流。
  • Sentinel 熔断策略基于响应时间、异常比率、异常数，限流支持有限（并发线程数或信号量大小）
  • Redis + Lua 脚本。 判断 key 是否存在，若不存在设置 key 过期时间和对应 value 为1；
    若存在判断在过期时间内 key 对应的 value 值是否大于限制数量，大于返回 false，小于则自增加并返回 true。

5. 限流算法

  • 计数器（固定窗口）
    固定窗口计数，规定单位时间内处理的请求数量，超过拒绝。等时间到了之后计数归零重新开始计数。

  • 滑动窗口（Sentinel）
    滑动窗口计数可以看做是固定窗口计数的优化版，它把时间段以一定比例分片，比如一分钟限制请求60次，分成60个窗口，那么每秒只能处理不大于 60(请求数)/60（窗口数）的请求，并且若当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。

  • 漏桶（Java 线程池）
    桶接受请求，速率任意，漏桶以固定速率漏水，处理请求，当桶满了请求就会被丢弃。因桶容量不变，保证了整体处理请求的速率。

  • 令牌桶（Guava RateLimiter）
    按一定速率往桶里添加令牌。请求在处理之前需要到桶中拿一个令牌，请求处理完毕删除令牌，如果桶里令牌被抢空了，拿不到令牌的请求就会被丢弃。

6. 负载均衡方法

  • 轮询
    将收到的请求循环分配到服务器集群中的每台机器，不关心服务器实际的连接数和负载。

  • 随机
    通过随机算法，从服务器列表选择一台访问，按照随机算法的特性，客户端请求越多，访问各台服务器的次数趋向相等，最终实际效果跟轮询基本一样了。

  • 加权轮询
    不同服务器的配置可能不一样，所承受的负载也会不一样，所以我们给配置高、负载低的机器配置更高的权重处理更多的请求，给配置低、负载高的机器配置较低的权重以降低负载。

  • 加权随机
    与加权轮询相似，根据服务器配置调整访问概率。

  • 最小连接数
    积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务器的利用效率，将负责合理地分流到每一台服务器。

  • 源地址哈希法
    对客户端 IP 地址通过哈希函数计算，然后结果对服务器列表取模，得到要访问的服务器序号。服务器列表不变情况下，同一 IP 地址的客户端每次都会请求到同一台服务器上。

7. 分布式锁

  • 数据库级别：读频繁用乐观锁，写频繁用悲观锁

    • 乐观锁：基于版本号实现
    • 悲观锁：基于数据库级别的 for update

  • 基于 Redis 原子性操作，使用 setnx 和 expire 实现

  • 基于 Redisson 框架实现

  • 基于 Zookeeper，使用 InterprocessMutex 实现

8. CAP 原则

CAP 原则指在一个分布式系统中，Consistency（一致性）、Availability（可用性）和 Partition tolerance（分区容错性）三者不可兼得。

  • Consistency 一致性

    在分布式系统中的所有数据备份，在同一时刻是否是同样的值（等同于所有节点访问同一份最新的数据副本）。

  • Availability 可用性

    在集群的一部分节点故障之后，集群整体是否还能响应客户端的读写请求（对数据更新具备高可用性）。即正常响应时间，服务需要一直可用。只要收到用户请求，服务器就必须做出响应。

  • Partition tolerance 分区容错性

    区之间通讯可能失败，容忍某些区奔溃。当部分节点出现问题的时候，系统依然能正常堆外提供服务。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。

9. BASE 理论

BASE 理论核心思想是即便无法做到强一致性，也应该采用合适的方式保证最终一致性。BASE 理论是对 CAP 原则延伸，是对 CAP 中 AP 方案的一个补充。

  • Basically Available（基本可用）

    分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

  • Soft state（软状态）

    允许系统存在中间状态，而中间状态不会影响系统整体可用性。

  • Eventually consistent（最终一致性）

    系统中的所有数据副本经过一段时间后，最终达到一致的状态。

10. 分布式事务解决方案

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。常用的解决方案有：

  • 基于 XA 协议的 2PC （两阶段提交）和 3PC

  • 基于业务层的 TCC 方案。Try Confirm Cancel 三阶段，代码实现复杂度相对较高

  • 使用应用消息队列 + 本地消息表实现的最终一致性方案。跨行转账可通过该方案实现。目前市面上支持该方案的 mq 只有阿里的 rocketmq，单消息队列可用于：

    • 用户注册成功后发送邮件
    • 电商系统给用户发送优惠券

  • 最大努力通知。例如支付回调和其他一些回调通知

11. 分布式事务框架

  • Seata：提供 AT、TCC、SAGA 和 XA 事务模式
  • TX-LCN：提供LCN（2pc）、TCC、TXC 三种事务模式
  • Raincat

12. Seata 4种事务模式

（AT、TCC、Saga、XA）模式分析 四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景。 - AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。 - TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。 - Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。 - XA模式是分布式强一致性的解决方案，但性能低而使用较少。

13. 分布式链路跟踪

  • Spring Cloud Sleuth
  • ZipKin

14. 分布式 id 生成方式

  • UUID
  • 数据库自增 ID
  • 号段模式
  • Redis
  • 雪花算法