博尔网是荷兰和比利时最大的在线零售商，截至5月，为540万客户提供930万种产品的目录。推动网上购物体验是一个集合超过130个不同的应用程序和服务，所有这些都需要协同工作。这个博尔网团队一直在寻找改进的方法；这个任务将我们从几个软件整体集合到面向服务的体系结构。最近，我们决定开始使用HashiCorp的conver来进行动态服务发现。在我们之前的设置中，配置更新需要15到20分钟，然后更改才会传播到整个系统。使用consur，这些软件现在几乎是实时的，这使我们能够更快地开发出更具弹性的软件系统。这篇文章最初是由博尔网在他们的官方博客上。我们将在HashiCorp博客上重新发布它，以便将来的读者能够很容易地找到关于我们的工具在现实环境中的使用的帖子。»问题-静态服务发现不能大规模地解决它去年，我们建立了一个基础设施管理系统并上线运行，在这个系统中，所有服务在每个环境中都有逻辑名称，开发人员将其服务配置为相互通信。然而，整个系统是完全静止的。所有的东西都来自一个单一的真相来源（CMDB），工程师必须手工编辑。编辑非常简单，基于Puppet的自动化处理了其余的工作，但是随着软件环境的发展，它不是动态的这一事实成为了一个瓶颈。要将服务X的另一个实例添加到负载平衡器？启动CMDB应用程序。要更改特定服务的主机名吗？好吧，这意味着从头开始重新配置一堆虚拟机，并在测试、验收、登台和生产环境中更改所有引用旧主机名的属性。静态服务注册起到了作用，但是博尔网需要一个动态的解决方案。只是动力不够。我们真正想要的是，无论服务运行在什么主机上，服务都能够在动态中找到彼此。简而言之，我们需要服务发现。如果您的服务支持它，那么不必确切知道服务在哪个主机上运行意味着您可以在发生故障时扩展和移动实例。用VM实现这种可移植性是可行的（正如Netflix使用Aminator等工具在AWS上证明的那样），但是我们选择了基于容器的解决方案。Docker最近的崛起让我们怀疑是否真的需要一个完整的虚拟机来隔离工作负载。将运行单个进程的容器作为我们的部署单元，而不是具有整个操作系统堆栈（以及所有必要工具）的VM非常吸引人。它使我们的部署过程更加轻量级，允许开发人员在他们的笔记本电脑上轻松运行应用程序的生产版本，减少部署时间，并可以显著提高生产服务器的利用率。此外，分层Docker图像格式和注册表为容器图像提供了一个非常高效和简单的分发机制。»执政官是必要的协调码头集装箱规模然而，容器本身并不能提供上述所有的好处。我们需要某种编排软件来决定哪些容器将在何时何地运行。作为我们新平台的基础，我们最初考虑使用Kubernetes或Fleet，但最终选择了在Mesos之上进行马拉松赛跑。我们之所以喜欢Mesos，是因为它是一款久经考验、久经考验的集群管理器，它真正实现了将数据中心转变为一台大型计算机的承诺。我们选择Marathon作为顶级Mesos上的任务运行器，因为它有一个可靠的API，我们的内部工具可以与之对话。既然我们的服务可以在集群上运行，我们需要服务发现。我们首先考虑在etcd或Zookeeper上运行我们自己的，然后才发现concur很容易运行，它提供了一个简单的restapi，可以说人类可读的JSON，支持acl，而且，作为一个令人愉快的额外功能，它实际上有一个很好的GUI。此外，基于DNS的发现功能似乎是让遗留应用程序与新系统集成的好方法。concur的分布式键值存储和健康检查也是我们设想使用的功能。最后，concur似乎得到了广泛的认可，并得到了迅速发展的社区的支持。我们确信这不是一个很快就会变成弃件的工具。»执政官到底是怎么用的bol.com？我们目前正在Mayfly中使用consur进行服务发现，Mayfly是我们基于用户故事的开发平台。由于该平台正在大力开发中，并且明确要求使用新兴技术，因此Mayfly是我们组织内尝试consult等产品的理想场所。构成蜉蝣的6项服务是第一个"执政官支持"的服务。目前我们只使用concur的两个特性：服务发现和简单的健康检查。我们已经为我们的内部web服务框架Backspin构建了一个扩展，它允许服务向consur注册，然后以完全动态的方式找到彼此。博尔网服务使用内部反向旋转服务框架进行通信。我们为Backspin构建了一个consur适配器，它允许服务在服务注册中心注册自己，发现其他服务并从KV存储中提取值。适配器还定期轮询conver，以检查它发现的任何服务实例是否仍在运行，如果没有，则使用其他实例重新初始化连接池。要发现一个服务，唯一需要的就是它的不可变的三个字母的标识符（我们在构思服务时将其分配给它）和所需的版本。当前的实现很简单，允许我们丢弃无数行配置。现在consur已经在Mayfly平台上证明了自己，我们正在研究如何在整个平台上推广它博尔网服务环境。我们面临的一个挑战是如何将老式的、傀儡配置的服务公开给支持领事的服务。我们需要在这两个独立的配置领域之间建立一个双向的信息流。例如，我们可以使用consur Hiera Puppet模块使Hiera值可用于启用consur的服务，并且可以使用consur Template这样的工具向尚不知道如何与服务发现对话的服务提供常规配置文件。这样的设置允许我们逐步将服务转移到consur，从而避免任何类型的大爆炸式迁移。»突出的挑战我们在领养领事的过程中遇到了两个主要问题。首先，也是最烦人的一点是，API有时会有点不稳定和不一致。API中似乎还有几个问题需要解决。我们意识到consur目前只有0.5.2，但是要绕过它们还是很烦人的。例如，一些不同的调用可以以不同的方式给同一个逻辑对象。如果调用{host}/v1/health/service/{service}，它将返回："节点"：{"节点"：""，"地址"：""},"服务"：{"ID"：""，"服务"：""，"端口"：31015},而服务目录为同一对象返回以下信息：{"节点"：""，"地址"：""，"服务ID"：""，"，"服务名称，"服务端口"：}不仅有两种不同的结构来表示同一个对象，一些属性名也不同。除了这些类型的问题，还有一些小的不便之处，比如不能查询所有通过健康检查的服务的目录。第二个问题是键值存储。虽然它作为一个KV存储可以正常工作，但是它缺少一些我们需要的特性，这促使我们编写自己的KV存储（当我们有时间时，它将是开源的）供内部使用。在博尔网服务具有版本控制的属性集。我们需要一个系统，在这个系统中，每个属性键对于不同的版本可以有不同的值，而不同的版本可以包含不同的键。我们需要的最好描述为一种用于KV集的联合文件系统，例如，特定密钥集的版本3可能包含版本1中key1的值和版本2中key2的值。没有一个好的方法把这个模型塞进一个像执政官提供的一个平坦的KV商店，所以我们决定推出我们自己的。我在阿姆斯特丹的一次会议上和米切尔·桥本刚明（Mitchell Hashimoto）提出了这个问题，他也认为目前在领事KV商店没有好的方法来制作这个模型（尽管这是他想要支持的东西）。至于我们希望看到的其他特性，我们希望能够将自定义信息添加到服务发现记录中。如果到特定web服务的连接需要代理，那么在服务发现记录中就没有办法定义它。当然，您可以将这些信息存储在KV存储库中并单独查找，但这不仅意味着另一个向consol提出的请求，还会迫使您在服务消失时对过时的KV条目进行维护。让consur为您处理这个问题并在服务发现响应中为您提供代理信息（或DB连接密码信息或服务API版本号等）会更容易。我们还希望在consur中有一个"环境"抽象，以及DC抽象。这将允许我们在逻辑上将Mayfly用户故事环境彼此分离，而不必为每个环境或名称空间（不仅是服务名称，还包括整个KV存储）运行单独的conver实例。»摘要如果没有consur，我们现在在Mayfly项目中使用的动态服务编排是不可能的。在我们之前的设置中，对CMDB的更新将启动Puppet，我们必须等待15到20分钟，然后才能进行更改。这些变化现在可以近乎实时地进行，这使我们能够开发