正文
对Consul来说最重要的模块就是数据库。数据库里的记录是像这样的：“API服务运行在IP 10.99.99.99的12345端口上。它现在正在运行。”
每台服务器都会向Consul发布信息，内容类似这样：“嗨！我这里的12345端口运行着API服务！现在的状态是运行中！”
然后如果你需要和API服务进行交互，你就可以直接问Consul：“哪里有API服务可用？”它就会给你返回一系列的IP地址和端口，然后你就可以访问了。
Consul本身是一套分布式系统（记住：我们有可能在任意时刻宕掉某台服务器，这就意味着我们的Consul服务器自身也可能会宕掉），所以它用了名为Raft的一致性算法来保证数据库中的数据是同步的。
如果你对Consul内部的一致性问题感兴趣，可以点击以下链接继续阅读：
https://www.consul.io/docs/internals/consensus.html
在Stripe初期，我们只是在服务器正常启动后将数据写入Consul，并没有做服务发现（配置了一些简单的Puppet脚本）。
这样我们就可以通过运行Consul客户端来发现潜在的问题。但是一开始，我们用Consul压根发现不了服务。
是哪里出问题了呢？
如果你往你的基础设施中的每一台服务器上都增加一个新软件，那么那个软件肯定会出问题！最早的时候我们就发现了Consul的统计库里的内存泄露问题：我们发现有一台服务器用了超过100MB的内存，并且数字还在不断变大。那是Consul的一个漏洞，后来被修复了。
100MB的内存泄露得并不算多，但是泄露的量却增长得很快。内存泄露问题通常都是令人担忧的，因为这是让一个进程把一台服务器的运行环境完全破坏掉的最容易的办法，这样别的进程就都无法运行了。
好在最开始的时候我们没有用Consul来做服务发现。我们只把它部署在了一部分生产服务器上，并且在监控着内存使用量，所以我们可以很快地发现潜在的严重问题，没有产生什么负面影响。
当我们很有信心Consul运行在我们的基础设施中可以工作得很好的时候，我们就开始让一些客户端与Consul交互了！为了降低风险，我们做了这两方面的努力：
