每年都有这么多新技术问世（比如Kubernetes或Habitation），我们很容易陷入对未来的兴奋之中，以至于我们忘记了对那些默默支持我们生产环境的工具的敬意。我们在Stripe使用了好几年的一个这样的工具就是concur。consur帮助我们发现服务（也就是说，它帮助我们在运行的数千台服务器上导航，这些服务器上运行着各种服务，并告诉我们哪些服务器已启动并可供使用）。这一有效而实用的架构选择并不华丽，也不完全新颖，但在我们继续为世界各地的用户提供可靠服务的使命中，我们尽职尽责。我们将讨论：什么是服务发现和执政官，我们如何管理部署关键软件的风险，我们一路上遇到的挑战，以及我们如何应对这些挑战。你不只是建立新的软件，并期望它神奇地工作，解决你所有的问题使用新软件是一个过程。这是我们在生产中使用新软件的过程的一个例子。什么是服务发现？好问题！假设您是Stripe的负载平衡器，并且请求创建一个费用。你想把它发送到API服务器。任何API服务器！我们运行着数千台服务器，上面运行着各种各样的服务。哪些是API服务器？API在哪个端口上运行？使用AWS的一个惊人之处在于，我们的实例可以随时关闭，因此我们需要做好准备：随时失去API服务器，如果我们需要额外的容量，可以增加额外的服务器。跟踪可用框周围的更改的问题称为服务发现。我们使用HashiCorp的consur工具来进行服务发现。事实上，我们的实例可以在任何时候关闭，这实际上非常有助于我们的基础设施定期进行实例丢失和自动处理的实践，因此当发生这种情况时，一切照常进行。当失败经常发生时，更容易优雅地处理失败。领事介绍consur是一个服务发现工具：它允许服务注册自己并发现其他服务。它将哪些服务存储在数据库中，有将信息放入数据库的客户端软件，以及从该数据库读取信息的其他客户端软件。有很多东西可以让你的脑袋被包裹起来！consur最重要的组成部分是数据库。此数据库包含类似"api服务在IP 10.99.99.99上运行，端口12345。是的。"个别的盒子向领事发布信息说"嗨！我正在12345端口上运行api服务！我起床了！"。然后，如果你想和API服务交谈，你可以问consur"哪个API服务启动了？"。它会给你一个IP地址和端口列表，你可以与之对话。consur本身就是一个分布式系统（记住：我们可以随时丢失任何盒子，这意味着我们可以失去领事服务器本身！）所以它使用了一种叫做Raft的一致性算法来保持数据库的同步。如果你对执政官的共识感兴趣，请阅读这里。条纹执政官的开始我们一开始只写信给consur，让机器报告它们是否在consur服务器上，但没有使用这些信息来进行服务发现。我们编写了一些傀儡配置来设置它，这并不难！这样我们就可以发现运行Consul客户机的潜在问题，并获得在数千台机器上操作它的经验。起初，领事没有发现任何服务。会出什么问题？解决内存泄漏如果你在你的基础设施中的每一个盒子里添加一个新的软件，那么这个软件肯定会出问题！早些时候，我们在concur的stats库中遇到内存泄漏：我们注意到一个盒子占用了超过100MB的内存并在不断攀升。这是执政官的一个错误，已经修复了。100MB的内存并不是一个大的漏洞，但漏洞增长很快。内存泄漏通常是令人担忧的，因为它们是一个进程在一个box上完全毁掉其他进程的最简单方法之一。幸好我们决定不使用领事来发现服务开始！让它在一堆生产机器上运行并监视内存使用情况，可以让我们快速发现潜在的严重问题，而不会产生负面影响。开始发现领事的服务一旦我们对在我们的基础设施中运行consur更有信心，我们就开始添加一些客户与consur交谈！我们从两个方面降低了风险：只在少数地方使用执政官，保持一个备用系统，这样我们就可以在停电时正常工作。以下是我们遇到的一些问题。我们列出这些并不是为了抱怨consur，而是为了强调在使用新技术时，一定要缓慢推出并保持谨慎。一吨木筏故障。还记得执政官用的是协商一致的协议吗？这会将consur集群中一台服务器上的所有数据复制到该集群中的其他服务器上。主服务器在磁盘I/O方面有很多问题—磁盘的速度不够快，无法执行CONSUR想要执行的读取操作，整个主服务器都会挂起。然后Raft会说"哦，初选结束了！"选举一个新的初选，这个循环就会重复。当consur正忙于选举一个新的primary时，它不允许任何人从它的数据库中写任何东西或读取任何东西（因为一致读取是默认的）。0.3版完全破坏了SSL。我们使用consur的SSL特性（技术上是TLS）让consur节点安全地通信。一次领事释放就把它弄坏了。我们修补了它。我们在早期就意识到这是一个很难检测到的软件问题（或者说，这是一个很难检测到的软件版本），但这并不可怕。Goroutine泄漏。我们开始用执政官的领袖选举。还有一个goroutine泄漏，导致执政官很快吃掉了盒子上的所有内存。Consul团队在调试这方面非常有帮助，我们修复了一系列内存泄漏（与以前不同的内存泄漏）。一旦所有这些都修好了，我们就有了一个更好的地方。从"我们的第一个顾问客户"到"我们已经解决了生产中的所有这些问题"，只花了不到一年的后台工作周期。扩展Consul以发现哪些服务正在升级所以，我们在执政官那里了解到了一堆错误，并进行了修复，一切都变得更好了。不过，还记得我们一开始说的那一步吗？当你问领事"嘿，api服务有哪些箱子？"我们遇到了一些间歇性的问题，Consul服务器响应缓慢或者根本没有响应。这主要发生在救生筏故障或不稳定的时候；因为concur使用了一个强一致性的存储，所以它的可用性总是比不一致的存储要弱，尤其是在早期的时候。我们仍然有退路，但是执政官的中断对我们来说是相当痛苦的。当concur倒下的时候，我们会回到一组硬编码的DNS名称（比如"apibox1"）。当我们第一次推出concur时，这个方法还可以工作，但是随着我们扩展和使用consur越来越广泛，它变得越来越不可行。救援领事模板询问consur哪些服务已经启动（通过其httpapi）是不可靠的。但我们对此很满意！我们想从consur那里得到关于哪些服务在不使用其API的情况下启动的信息。怎么用？好吧，concur会取一个名字（比如monkey srv）并将其转换成一个或多个IP地址（"monkey srv就住在这里"）。知道名字和输出IP地址还有什么吗？DNS服务器！所以我们用DNS服务器代替了CONSUR。方法如下：consur模板是一个Go程序，它从conver数据库生成静态配置文件。我们开始使用consur模板为consur服务生成DNS记录。因此，如果monkey srv在IP 10.99.99.99上运行，我们将生成一个DNS记录：猴子-服务顾问在10.99.99.99下面是代码中的内容。您也可以找到我们真正的conver模板配置，它有点复杂。{{范围服务$服务名称}}{{$服务名称}}.服务。领事. 在{.Address}}中{{end}}如果你在想"等等，DNS记录只有一个IP地址，你还需要知道服务器在哪个端口上运行"，你是对的！dnsa记录（你通常看到的那种）只有一个IP地址。然而，dnsrv记录中可以有端口，我们还使用consur模板来生成SRV记录。我们每60秒在cron作业中运行consur模板。consur模板还有一个"监视"模式（默认），当数据库更新时，它会不断更新配置文件。当我们尝试手表模式时，它关闭了我们的领事服务器，所以我们停止使用它。所以如果我们的consur服务器坏了，我们的内部DNS服务器仍然有所有的记录！他们可能有点老了，但没关系。我们的DNS服务器令人敬畏的地方在于它不是一个奇特的分布式系统，这意味着它是一个简单得多的软件，而且不太可能自发地崩溃。这就意味着我可以查猴子了-服务顾问获取一个IP，并使用它与我的服务对话！因为DNS是一个没有共享的最终一致的系统，我们可以复制和缓存它一堆（我们有5个规范的DNS服务器，每个服务器都有一个本地DNS缓存，并且知道如何与5个规范服务器中的任何一个进行通信），所以它基本上比consur更具弹性。添加负载平衡器以实现更快的运行状况检查我们刚刚说我们每60秒更新一次领事的DNS记录。那么，如果一个API服务器爆炸了会发生什么呢？在DNS服务器更新之前，我们是否还要继续向该IP发送45秒的请求？我们没有！还有一个故事：哈普罗西。HAProxy是一个负载平衡器。如果你对它发送请求的服务进行健康检查，