Redis 如何与微服务架构协同

这篇博文改编自我们新的电子书“Redis 微服务傻瓜指南”，作者 Kyle Davis 与 Loris Cro 合著。摘录于 2019 年 12 月 20 日最初发布在 The New Stack 上。 在此下载完整电子书。

如今许多广泛使用的数据库系统是在企业采用单个数据库的时代开发的。这个单个数据库系统会在一个地方存储和运行企业的所有功能。你可能可以想象：一个房间里满是冰箱大小的机器，许多机器都配备了超大型卷盘磁带驱动器。

但是 Redis 的发展与许多其他流行的数据库系统不同。Redis 在 NoSQL 时代构建，是一个灵活而通用的数据库，专门设计为不存储大量的基本上处于闲置状态的数据。微服务架构有类似的目标：每个服务都设计为适应特定的用途，而不是运行业务中的所有内容。

Redis 旨在存储经常更改和移动的活动数据，具有无限的结构，没有关系的概念。Redis 数据库占用的空间很小，即使在资源很少的情况下也能提供巨大的吞吐量。类似地，微服务架构中的单个服务只关注输入和输出以及该服务的私有数据，这意味着 Redis 数据库可以支持各种不同的微服务，每个服务都有自己的独立数据存储。这一点很重要，因为拥有许多服务的本质意味着每个服务必须尽可能快地执行，以弥补服务间通信带来的连接和延迟开销。

描述 Redis 支持的微服务架构

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

微服务架构可能包含数百甚至数千个服务，而开销是扩展的敌人。消耗大量资源来运行的基础设施会削弱微服务架构的优势。

理想情况下，服务数据应与其他数据层完全隔离，从而实现解耦扩展和跨服务争用缓慢的资源。由于服务专门设计为填充单一角色（在业务流程方面），因此它们存储的状态本质上是非关系型的，非常适合 NoSQL 数据模型。Redis 可能不是微服务架构中所有数据存储的通用解决方案，但它无疑非常适合许多要求。

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

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

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

类似地，需要通过 API 访问的外部数据服务也可能过于缓慢，Redis 可用于在此处防止不必要的长时间调用影响系统的整体性能。

有关 Redis 如何帮助为您的微服务架构提供动力的更多详细信息，请 下载您自己的“Redis 微服务傻瓜指南”电子书，并 收听作者 Kyle Davis 和 Loris Cro 在 The New Stack Context 播客中讨论这本书。