Hydra 是一个轻量级的 NodeJS 库，用于构建分布式计算应用程序，比如微服务。我们对轻量级的定义是：轻处理外部复杂性和基础设施依赖 —— 而不是有限的轻处理。 Hydra 声称对基础设施的依赖很轻，这是因为它唯一的外部依赖是 Redis。
Hydra 利用 Redis 丰富的数据结构来实现重要的微服务所需的功能。如 presence（在线状态）、service discovery （服务发现）、load balancing （负载平衡）、messaging（消息传递）、queuing（队列）等。
Hydra 到底是什么？
Hydra 是一个 NodeJS 模块，可以将其导入到 JavaScript Node 应用程序中，以使其具有微服务功能。Hydra 通过利用 Redis 做到这一点。
在这里，我们看到三个微服务 - 每个微服务都带有一个连接到 Redis 的 Hydra 模块。在这种模式下，大多数服务不会直接与 Redis 通信。而是底层的 Hydra 模块代理 Redis。
关于此图的另一点是，Hydra 只是另一个导入的模块 - 如绿色所示。Hydra 在底部仅以蓝色显示，以说明其存在和与 Redis 的关系。
Hydra 模块公开一个 JS 类接口，该接口共有36个成员函数。
该快照提供了简化抽象的感觉。成员函数（例如 findService 和 sendMessage）非常简单。
Hydra 如何利用 Redis
这张幻灯片显示了许多重要的微服务问题。每个都是 non-trivial（非平凡的） 微服务所必需的。我们将详细研究 Hydra 如何使用 Redis 来实现所有这些功能。
请记住，这里的目标是展示如何做到这一点 —— 而不是说每种方法都是您应该如何在自己的服务中实现该特性。一个恰当的例子是，虽然你可以在 Redis 中存储你的微服务配置数据，或者使用 Redis 作为一个 logger —— 但这并不意味着你应该这样做。至少，除非你确切地知道你在做什么，以及需要做哪些权衡。
另外，请记住，您也许不需要Hydra。这些功能都是由 Redis 实现的，您当然可以在自己的应用程序中做到这一点。（如：Golang 来一版）
我将向您展示的一个关键点是，其中一些特性只有在组合时才能实现。例如，请求（request）和消息路由（message routing）依赖于状态（presence）、运行状况（health）、服务发现（service discovery）和负载平衡（load balancing）。
如您所知，这些特性中的每一个都可以使用各种基础设施工具来解决。然而，Hydra 的一个关键目标是简化构建微服务，同时最小化外部基础设施需求。在构建可用于生产的服务时，您需要决定需要哪些 Hydra 特性，以及哪些特性将从其他工具获得。这不是一个非此即彼的命题，而是一个你想要达到的目标和你能多快开始的问题。
就是说，很有趣的是，仅使用 Redis 和您喜欢的编程语言就可以实现所有这些功能。
Key 空间组织
了解 Hydra 如何利用 Redis 的第一步是查看它如何组织对 Redis key 空间的使用。
Hydra 使用的键 —— 由 2 到 4 段标签组成，标签之间用冒号分隔。段标签被命名为：前缀（Prefix）、服务名称（Service name）、实例 ID（Instance ID）和类型（type）。
前缀段允许过滤 Hydra key 和非 Hydra key。因此，如果你大量使用 Redis，那么能够过滤特定的 key 是至关重要的。
服务名称段帮助过滤特定服务类型的 key。例如授权（authorization）、用户（user）或图像处理（image processing）服务类型。
实例ID（Instance ID）段允许过滤唯一服务实例的 key。运行微服务时，通常需要运行一个服务类型的多个实例。每个服务实例都分配有唯一的 ID，并且能够区分它们是有用的。
最后，还有“类型（Type）”部分，用于对 key 的用途进行分类。并非每个 key 中都存在所有段。例如，某些 key 中不需要服务名称（Service name）和实例ID（instance ID）。
这是用户服务（user service） key 的示例。我们看到前缀 hydra:service 后跟服务名称，在本例中为 “user-svcs”。接下来，我们看到唯一的实例ID（unique instance ID）。最后，我们看到此 key 的类型为 presence（presence）。因此，我们说 presence 信息存储（presence information）在此 key 地址中。
在前面的描述中，一个令人困惑的地方是，key 由名称组成，名称中有2到4个段标签，用冒号分隔。然而，在这里我们看到 hydra:service 也用冒号分隔。当时的想法是，可能还有另一种 hydra:other 类型，service 只是其中之一。关于消息传递还有另一个不一致的地方，稍后我们将对此进行讨论。
我们可以输入 redis-cli 和输入 Redis 命令来查看各种键。在接下来的演示中我们会看到一些例子。
一个关于我们将使用的 redis-cli 示例的快速说明：你将看到 keys 命令的使用 —— 这是为了方便 —— Hydra 内部使用 Redis scan 命令。
所以重述一下 —— Hydra 使用的 key 是按段组织的，这使它们更容易查询。此外，一致的组织使它们更容易扩展和维护。随着我们继续，我们将看到 key 在每个微服务特性的组织中所扮演的角色。让我们从检查 presence（examining presence）开始。
Presence（呈现 type）
在微服务领域中，发现服务、了解服务是否正常以及是否可以路由到该服务的能力至关重要。这些特性依赖于知道某个特定的服务实例确实存在并可供使用。对于服务发现（service discovery）、路由（routing）和负载平衡（load balancing）等特性，这也是必需的。
每隔一秒钟，Hydra 就会更新它的服务 key 的生存时间(TTL)。在三秒钟的时间内这样做失败将导致 key 过期，主机应用程序被视为不可用。
在这里我们可以看到使用的 Redis 命令是 “get” 和 “setex”，它们设置了一个 key 和一个到期时间。
我们可以使用带有模式匹配项的 “keys” 命令来查询 presence key。注意，存在三个 key。这告诉我们存在 “ asset-svcs” 运行的三个实例。
如果我们尝试检索其中一个 key 的内容，我们会看到它包含实例ID（instance ID）。
并对键使用 TTL 命令可以向我们显示，它还有 2 秒钟的剩余时间。
所以回顾一下。可以使用自动过期的 key 来管理微服务的存在。Hydra 代表主机服务自动更新密钥。这意味着这不是开发人员做的事情。在3秒内更新 key 失败将导致服务被视为不可用。这可能意味着服务不健康。
这将我们带入下一个主题…
Health（健康 type）
能够监视微服务的运行状况是另一个重要功能。Hydra 每 5 秒钟收集并写入一个健康信息快照。
您可以检查快照以快速查看单个服务实例的运行状况。并且，快照可以由监控工具（例如 HydraRouter 仪表板）使用。
这就是健康 key 的样子。请注意，唯一的新位是标识 key 为关于 health 的 “type” 段。
当我们查看密钥的内容时，我们看到它包含一个字符串化的 JSON 对象。在这种情况下，它用于 “project-svcs”。
将 JSON 解串可以更容易地查看存储的内容。它包含了很多有用的信息。
因此，可以按服务实例存储运行状况（health）信息。使用包含字符串化的JSON文本的字符串 key 进行管理。而且这些信息可以通过监视应用程序来使用。
