我们所有的微服务，无论它们如何相互通信，都提供一种心跳接口，以便监视系统可以随时发现其状态。 例如总体健康状况和某些特定特征，例如，它们要处理的内部数据的校验和。 这与主要传输方式无关：在这里RabbitMQ和Redis很好。
有时，为导出相关数据提供最简单的（ HTTP ）接口是有意义的。 从长远来看，我也想这样做，从长远来看，我想完全摆脱Redis ，转而使用内部存储键值对的解决方案，就像我们两年前成功使用PubSub 。
因此，我决定创建一个插件库来解决这个复杂的问题，即使用零代码从任何应用程序提供任意数据（ config.exs三行除外），而不是使用每个新的微服务来重新发明自行车。 是简单的心跳 （ HTTP 200 OK ），还是一长串当前汇率。
解决方案基于Dave Thomas的推文 。
笔尖的JSON API服务器
Camarero是一个现成的解决方案，用于在现有应用程序中添加一些JSON API函数，甚至在不希望使用更复杂（阅读繁重）的解决方案时，甚至从头开始实现一个不太混乱的 JSON API。 下图显示了在典型情况下我们如何连接和使用它。
该库绝不是要替代诸如Phoenix之类的完善解决方案。 不行不行 当微服务仅需要公开几个HTTP API API时，这就是一个这样的插件。 在某些情况下， Camarero可能是替换Redis或其他任何关键值存储区（也在其权重组中）的理想选择。 与此类Web解决方案的主要区别在于该库确实非常快。
这是用于从具有一百万个键的哈希表中返回键值的HTTP响应时间。
是的，没有收获。 在最坏的情况下，通过具有100万个值的kv存储的请求的HTTP响应时间为数十微秒 。
实施细节
假定Camarero只需打开库和配置文件中的三行即可连接到正在运行的应用程序。 它处理配置的路由，将执行委派给指定的处理程序模块。 最简单的配置如下所示：
config :camarero, carta: [Camarero.Carta.Heartbeat], root: "api/v1"
就这么简单，很可能就很清楚了： /api/v1 -Web服务器的根，一条heartbeat路由（默认情况下，从模块内部配置-名称不带前缀）-带Camarero.Carta.Heartbeat处理程序。 还可以使用对Camarero.Catering.route!调用在运行时动态添加处理程序Camarero.Catering.route! 。
处理程序
处理程序是实现Camarero.Plato 行为的模块。 它由标准CRUD存储库操作方法组成。 要用作传入HTTP请求的处理程序，任何实现此行为的模块都是合适的。
还有一个更精细的调整： 行为 Camarero.Tapas ，它管理每个Camarero.Plato容器内的键/值对的CRUD 。 通常，在使用该库时，您无需深入研究。
默认实现使用%{} 映射作为容器，看起来非常紧凑：
defmodule Camarero.Carta.Heartbeat do use Camarero.Plato end
这是纯净的，未涂漆的Heartbeat模块，默认情况下包含在库中。 文档中描述了较少的琐碎用途。
微调
毫无例外，两种默认实现（ Camarero.Tapas和Camarero.Plato ）中的所有方法都可以轻松地重新定义。 例如，要对模块以及定制容器使用定制路由，可以执行以下操作：
defmodule Camarero.Carta.Heartbeat do use Camarero.Plato, container: %MyStructWithAccessBehaviour{} @impl true def plato_route(), do: "internal/heartbeat" end
Web服务器配置
Camarero需要Cowboy2服务器和CowboyPlug才能工作 。 这是config.exs的典型Cowboy2设置：
config :camarero, cowboy: [port: 4043, scheme: :https, options: []]
卡马雷罗没有什么要求
该库决不声称要与复杂的解决方案竞争。 它不在其中，并且几乎可以肯定，永远不会有授权或认证，也就是说，我们仅将其用于私有云内部的服务。
生成了所有处理模块，因此，除了接口过载之外，不可能进行其他调整 。 这也是故意进行的。
但这比所有基准测试中的任何类似产品都要快。
快速回复！