Redis 如何契合微服务架构

这篇博文改编自我们由 Kyle Davis 和 Loris Cro 合著的新电子书“傻瓜式学习 Redis 微服务”。本文节选最初于 2019 年 12 月 20 日发布在 The New Stack 上。在此下载完整的电子书。

当今许多广泛使用的数据库系统都是在一个公司在整个企业中采用单一数据库的时代开发的。这个单一数据库系统将企业的所有功能存储和运行在一个地方。你可能可以想象它：一个房间里摆满了冰箱大小的机器，其中许多还带着超大的盘式磁带机。

但 Redis 的演变方式与许多其他流行数据库系统不同。Redis 构建于 NoSQL 时代，是一个灵活且多功能的数据库，专门设计用于不存储大量大部分时间处于空闲状态的数据。微服务架构也有相关的目标：每个服务都设计用于特定的用途，而不是运行业务中的所有事情。

Redis 设计用于存储频繁变化和移动的活动数据，其结构不定，没有关系的概念。Redis 数据库占用空间小，即使资源最少也能提供海量吞吐量。类似地，微服务架构中的单个服务只关心输入和输出以及该服务私有的数据，这意味着 Redis 数据库可以支持各种不同的微服务，每个微服务都有自己的独立数据存储。这很重要，因为拥有许多服务的本质意味着每个服务必须尽可能快地执行，以弥补服务间通信引入的连接和延迟开销。

描述基于 Redis 的微服务架构

微服务架构的一个关键特征是每个独立的服都务各自独立——服务不与其他服务紧密耦合。这意味着微服务必须维护自己的状态，而要维护状态就需要数据库。

微服务架构可以包含数百甚至数千个服务，而开销是规模化的敌人。仅仅为了运行而消耗大量资源的 IT 基础设施会冲淡微服务架构的好处。

理想情况下，服务数据应与其他数据层完全隔离，以便实现非耦合的伸缩和避免服务间对慢速资源的争用。由于服务专门设计用于承担单一角色（就业务流程而言），因此它们存储的状态本质上是非关系型的，非常适合 NoSQL 数据模型。Redis 可能不是微服务架构中所有数据存储的万能解决方案，但它肯定非常适合许多需求。

构建好服务后，它需要与其他服务通信。在传统的微服务环境中，这通过使用 REST 或类似约定的私有 HTTP 端点进行。一旦收到请求，服务便开始处理该请求。

虽然 HTTP 方法有效且被广泛使用，但还有一种备用的通信方法，即服务向日志状结构写入和从中读取。在这种情况下，这就是Redis Streams，它允许完全异步模式，其中每个服务在其自己的流上发布事件，并且只监听其感兴趣的服务所属的流。此时，双向通信通过两个服务观察彼此的流来实现。

然而，即使在不使用 Redis 进行存储或通信的服务中，Redis 仍然可以发挥至关重要的作用。为了提供低延迟的最终响应，每个独立服务必须尽可能快地响应自己的请求，这通常超出了传统数据库的性能阈值。在这种情况下，Redis 扮演着缓存的角色，服务开发人员决定哪些数据不总是需要直接从主数据库检索，而是可以更快地从 Redis 中拉取。

同样，需要通过 API 访问的外部数据服务也可能太慢，此时可以使用 Redis 来防止不必要且耗时的调用影响系统的整体性能。

要了解 Redis 如何助力您的微服务架构的更多详细信息，请下载“傻瓜式学习 Redis 微服务”电子书，并收听作者 Kyle Davis 和 Loris Cro 在 The New Stack Context 播客中讨论该书的内容。