在线支付公司Stripe的服务发现架构设计过程分享

16-11-01 banq
本文介绍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.在少数一些地方使用Consul

2.保持一个后备系统,防止功能中断。

在这个过程中,遭遇了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}}
<p>

但是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.首先请求来到一个公用的负载平衡器,其运行HAProxy

2.Consul Template已经倒入一堆服务器列表在/etc/haproxy.conf配置文件

3.HAProxy 每60秒刷新配置文件

4.HAProxy 发送你的请求到stripe.com一个服务器,确保其运行正常。

当我们开启或关闭服务器,Consul负责从HAProxy自动轮换中删除它们。没有手工工作要做。

Stripe并不需要处理如同Twitter 或 Facebook一样多流量请求, 但我们很关心每笔交易的极端可靠性,部署一个稳定的,优秀的解决方案才是取胜关键,不一定是新技术。

Service discovery at Stripe

              

4
猜你喜欢