本文介绍Consul如何在Stripe公司扮演服务发现功能的。主要谈论三个方面：
1.什么是服务发现和Consul是什么。
2.Stripe是如何管理关键软件的部署风险。
3.遭遇的挑战和应对措施。
Stripe是一家类似支付宝、Paypal的网上支付平台，Stripe不仅需要处理交易，还需要考虑退款，小费，额外收费，货币汇兑等一系列问题。什么是服务发现？负载平衡器将请求分发到任何一个不同的API服务器，在Stripe在成千上万的服务器上运行各种服务。哪一个是API服务器？API运行在哪个端口？关于使用AWS一个令人惊奇的地方是：我们Stripe服务器实例可以在任何时候当机。因此对下面情况有所准备：1.任何时候API服务器会丢失2.如果我们需要增加容量，只需要增加额外服务器.跟踪哪一个盒子（服务器）是否可用，这就是服务发现。我们使用Consul实现服务发现。其实我们的服务器任何时候都会死机，这还是有好处的，这是对我们基础设施进行定期检验，它们会自动化处理这些问题，当业务真正发生问题，它也很容易处理故障
。Consul介绍它是个服务发现工具，服务会注册其中以便需要调用时能够发现服务，他是将运行的服务保存在数据库，他有一个客户端软件，专门将信息放入数据库，其他客户端软件则是从数据库中读取。Consul重要的组件是数据库，数据库包含信息诸如：api-service运行在IP为10.99.99.99的端口12345，目前可用。独立的盒子（服务器）将信息发送给Consul说: 我运行在api-service的端口12345，我是处于运行状态。如果你要和api服务交互，你首先向Consul请求1：哪个api-service运行正常？它会给你一串IP地址列表和端口。Consul是一个分布式系统，使用共识算法Raft进行数据库同步。Consul在Stripe初期起初我们只是在服务器启动正常后将数据写入Consul，并没有使用服务发现，编写了一些 Puppet配置设置，不是很难。这种方式，有助于我们发现数千台带有Consul客户端的服务器运行中潜在的问题，他没有使用它进行服务发现。这个过程中发现什么问题？我们发现了Consul存在内存泄漏，现在这个问题已经fix。很庆幸我们没有开始使用它用于服务发现。一旦我们对Consul运行在我们的基础设施变得更加有信心，开始增加新客户端，用这两种方式降低风险：1.在少数一些地方使用Consul2.保持一个后备系统，防止功能中断。在这个过程中，遭遇了Consul很多坑，当然并不是抱怨，而是强调在使用新技术的时候，重要的是要慢慢的谨慎的推进。解决了这么多问题以后，开始实现服务发现，但是Consul服务器会响应慢或者没有响应。大部分是raft故障转移或不稳定时发生这些情况，Consul有强一致性存储，所以它的可用性弱一些。Consul起初这种当机情况可以使用DNS硬编码修改克服，但是随着应用广泛，就不怎么可行了。询问Consul哪个服务是可用的这个过程是不可靠的，如果不使用Consul的API而需要从其得到哪个服务是否正常，可以吗？Consul会将名称如monkey-srv翻译成一个或多个IP地址，它是从哪里将名称翻译成IP地址呢？DNS服务器，这样我们使用DNS服务器替代Consul， Consul Template 是一个从Consul数据库中产生静态配置文件的Go程序。我们开始使用Consul Template为Consul服务产生DNS记录，如果monkey-srv运行在IP 10.99.99.99，产生DNS记录：monkey-srv.service.consul IN A 10.99.99.99模版配置有点复杂：{{range service $service.Name}}{{$service.Name}}.service.consul. IN A {{.Address}}{{end}}

但是DNS记录只能提供一个ip地址，你还需要知道服务运行的服务器的端口？DNS SRV 记录则提供服务器端口，使用Consul Template也可产生SRV记录。如果我们的Consul服务器宕机，我们内部的DNS服务器仍然有其记录！记录可能有点老了，但那可用。关键是我们的dns服务器不是一个花俏的分布式系统，意味着它是一个非常简单的软件，根本不可能自身分裂变得不稳定。这意味着，我可以查询monkey-srv.service.consul获得一个IP地址，并用它来与我的服务交谈！由于DNS是一个共享的最终一致性的系统，我们可以复制和缓存它，我们有5个DNS服务器，每个服务器都有一个本地DNS缓存和知道如何跟任何5个服务器交谈。因此，它的基本上比Consul更具弹性。DNS记录更新是每60秒读取一次Consul，但是如果API服务器当机了，我们还是要将请求发到这个IP直到DNS服务器记录更新？使用HAProxy。HAproxy是一个负载平衡器，对每个服务是发送请求检查健康，它可以确保你的后端正常运行！我们所有的API请求实际上经过HAProxy。这里的它是如何工作：1. 每60秒，Consul模版会写一个HAProxy配置文件。2.这意味着HAProxy基本与后端情况精确一致。3.如果一台机器当机，HAProxy会很快意识到出错1（因为它每2秒进行一次健康检查）我们是每隔60秒重启一次HAProxy，当我们重启HAProxy时是丢掉它的连接吗？不，使用的是HAProxy的优雅重启特性，虽然可能丢失一些，但是大部分能够保留。几乎每个服务器都有/healthcheck这个端点用于检查健康，如果正常返回200，有一个标准很重要，因为它意味着我们可以很容易地配置HAProxy检查服务健康。当Consul当机，HAProxy只会有一个陈旧的配置文件，这将保持继续工作。开始我们的系统是一个高一致性的数据库，最终我们引人了DNS服务器，数据可能有几分钟的滞后，我们放弃高一致性要求，获得了更高的可用性，Consul当机基本对我们服务发现没有影响、从中获得一个重要的教训是，高一致性从来不是免费！你必须愿意支付可用性的成本，因此，如果你要使用一个强一致的系统，重要的是要确保这是你真正需要的东西。总结一下Stripe流程：当你访问 https://stripe.com/, 请求经过以下步骤：1.首先请求来到一个公用的负载平衡器，其运行HAProxy2.Consul Template已经倒入一堆服务器列表在/etc/haproxy.conf配置文件3.HAProxy 每60秒刷新配置文件4.HAProxy 发送你的请求到stripe.com一个服务器，确保其运行正常。当我们开启或关闭服务器，Consul负责从HAProxy自动轮换中删除它们。没有手工工作要做。Stripe并不需要处理如同Twitter 或 Facebook一样多流量请求, 但我们很关心每笔交易的极端可靠性，部署一个稳定的，优秀的解决方案才是取胜关键，不一定是新技术。Service discovery at Stripe