Mailgun开源速率限制微服务Gubernator

电子邮件API服务供应商Mailgun开源了Gubernator，这是一个原生云端分散式速率限制微服务，官方提到，微服务架构可以在不影响服务独立性的情况下，提供通用速率限制服务。

当客户端或服务，向Gubernator发出速率限制请求的时候，请求会被赋予键值，并应用杂凑演算法，决定出速率限制请求的拥有节点（Owner）。官方提到，选择单一节点来处理速率限制较为快速，且能避免分散式计数带来的複杂性以及延迟。

而客户端的每个请求都会带有速率限制配置，速率限制的配置便会与现阶段速率限制状态，一起被存在速率限制拥有节点的本地记忆体中，这些配置具有时效性，当时限到期且没有再次收到速率限制配置，配置便会从快取中被删除。

Gubernator的架构被设计成，适合在同侪分散式丛集中运作，其利用记忆体快取所有当前阶段启用的速率限制，Gubernator无状态，没有资料会被同步至磁碟中，官方提到，多数网路速度限制持续的时间只有数秒中，因此当重新启动或是计画性停机，而使得记忆体内资料丢失，并不是大问题，对于Gubernator来说，也仅是几秒钟的时间，一小部分的流量可能发生过度请求的状况。

Gubernator可以均匀的分散速率限制请求到整个丛集，也就是说，用户只要为丛集增加一个节点，就能简单地扩展系统，Gubernator不依赖Memcache或是Redis等外部快取，也不会在磁碟上储存状态，其配置来自客户端传递请求，并且能支援极高吞吐量的应用。

之所以不使用Redis的原因，官方解释，Redis用在速率限制的最佳解决方案，是在Redis上储存一个速率限制脚本，每次速率限制请求都呼叫该脚本，大部分的工作都会由Redis完成，速率限制微服务只是作为存取Redis的代理。而以Redis实作速率限制功能，将会产生额外的流量，因为每次单一请求，都会产生至少一次往返Redis的存取，而速率限制微服务也需要至少存取Redis一次，因此会在服务中增加至少两次的存取往返。

Gubernator能够处理高吞吐量的请求，官方提到，在正式生产环境中，他们为请求API服务设下两个速率限制条件，一个是HTTP请求速率，另一个则是用于评估用户在特定时间内，用户发送电子邮件的收件人数量，单个Gubernator节点每秒可以处理超过2,000次请求，大多数都在1毫秒内回应。

Mailgun也提到，当用户使用Go语言，也能把Gubernator当作函式库使用，并在顶层使用自有特定模型的速率限制服务，这样不只能使用Gubernator的功能，还可以将商业逻辑分开，并整合专门领域问题到速率限制服务中。