Synapse 英文原文：Introducing SmartStack: Service Discovery in the Cloud

SmartStack是一个服务自动发现和注册的框架。它通过透明地处理你组织中运行代码的创建、删除、异常及维修工作使工程师的日常工作更便利。我们相信这是处理这类问题最好的方案之一：概念简单，易于操作，相比同类工具提供更多的可配置性。SmartStack过去一年中一直在Airbnb内部测试，并已在许多大大小小的组织中广泛地应用。

SmartStack的组件——Nerve和Synapse——在GitHub上可以获取！继续阅读获得更多内容。

SOA中的服务问题

类似Airbnb的公司往往创立初期是以一个独立应用的形式——像瑞士军刀一样能完成有组织内的所有功能。随着流量（以及产品开发工程师数量）的增长，这种比喻并没有随之变得更贴切。代码库变得越来越复杂，问题出在分离不彻底上，众多工程师所负责代码库的不同部分合在一起时发生了变化，性能是由应用中表现最差的部分决定的。

解决这个问题的办法是服务：独立的、具有更小代码代码的、运行在独立服务器上拥有独立迭代周期的，这种服务能更明确更具目标性的定位问题区域。这被称为面向服务的架构：SOA。

当你在你的架构中增加了一些服务时，你会注意到你现在维护着许多小型的服务池，而不是维护一个单一的通常意义上的应用服务池。这带来了几个问题。你如何把阻塞引导到池中的每一台机器？你如何增加新机器或者移除那些坏掉的或者退休的机器？单个机器的损坏对该应用的其它机器会产生什么影响?

跨越几个服务集合来处理这些问题，将需要很快投入多个全职的工程师，致力于这个费时费力的错误监测活动，而且充满着风险和宕机的可能。

理想解决方案的特征

解决服务问题的答案是自动化-让计算机完成后端池的维护清理工作。然而实现这样的自动化有许多方法。首先让我们总结一下理想实现的特征：

• 能够处理特定服务请求的后端可以自动地接收这样的请求
• 负载将智能地分布到所有的后端上，因此没有任何一个后端服务器比其余的后端做更多的工作，这样请求就会自动的路由到最不忙碌的后端
  

• 遇到问题的后端将自动地停止接受请求

• 同一系统下，应当可能在不影响其他后端的情况下从一个后端卸下负载。这样才可能进行调试。

• 应当具有非常完美的内省功能，这样你通常可以知道哪些后端可用，它们接收哪种类型的负载以及这些负载来自于哪些客户。

• 对后端列表的更改应该对客户的影响最小；理想情况下，这样的更改对客户应该是透明的。

• 不应当存在单点故障-系统里的任何地方的任一机器出现故障都不会有任何影响。

我们可以使用这些标准去评估可能的解决方案。例如，手动更改哪些直接写在客户端的后端列表，然后再部署客户端，这立刻引起许多标准在很大程度上失效。其他方法结果会怎样呢？

不奏效的解决方案

许多常用方案应用到服务发现上在实践中并没有很好地工作。要理解为什么SmartStack这么好，了解一下其他方案不好的地方会有帮于理解。

DNS

注册和发现的最简单的方案就是把所有的后端放在同一个DNS后。需要定位服务时请求DNS便会得到一个随机的后端。

这个注册组件相当容易理解。在你自己的基础设施中，你可以使用像BIND-DLZ这样的动态域名解析服务用来注册服务。在云端，像Route53这样DNS托管服务，简单的API调用就足够了。在AWS上，如果你使用循环CNAME你会得到免费的水平拓展，而且同样的记录在AWS内外都起作用。

不过，使用DNS来进行服务发现也很冒险。首先，消费者不得不下载变更 – 因为没有方法来进行状态推送。而且，DNS收到传播延时的困扰；即使你的监控器检测到一次失败并且向DNS发送了一个取消注册的命令之后，仍然需要等待至少几秒钟消费者才能得到消息。更糟的是，由于DNS设备存在着多级缓存，传播延时的准确时间通常是无法确定的。

如果使用最简单的方式，使用名称来标记你的服务，你也无法确定哪个节点陷入了拥堵。使用随机路由你也会面临同样的情况，某些后端设备上的负载会混乱的堆积如山，而另一些设备却静止不懂。

最糟糕的是，许多应用程序只在启动时缓存DNS解析一次。例如，Nginx将缓存初始名称的解析结果，除非你使用配置文件监听，HAProxy也是这样。应用程序脆弱性表现出来的代价是昂贵的，解决问题更难。

请注意，我们这里是指本地通过客户端库使用DNS。这里有一个使用DNS来做服务发现的聪明做法——我们在SmartStack上使用Zookeeper，我们也使用DNS但没有失去太多的功能。但是只是简单使用HTTP库发起到myservice.mydomain.com的HTTP请求并不会受到好的成效。

集中式负载均衡

如果你确信DNS是发现服务的所采取的错误的方法的话，那么你可能决定采用集中式服务路由。在这中方法力，如果服务a想要和服务b会话，那么它应当同可能路由这个请求的负载均衡器会话。所有的服务都要配置查找负载均衡器的方法，而且负载器是所有后端都必须了解的唯一的东西。

这种方法听起来很有希望，不过现实面前它却不会给你很多。首先，服务是如何发现负载均衡器的呢？通常答案是DNS,然而目前DNS方法给你带来了比你要解决的问题更多地问题-如果负载均衡器停止运行，那么你仍让要面对使用DNS实现服务发现的所有问题。另外，集中式路由层是最大的故障点。如果这个层停止运行，那么么其他的一切都会因为它而停止运行。重新对新的后台配置负载均衡会带来很大的危险-而这是例行操作。

接下来，你会选择什么负载均衡方案?在传统的数据中心上，也许你会尝试两台硬件设备的方式，就像F5。但在云端这并不适用。在AWS上，你也许会尝试适用ELB，但是ELB在内网负载均衡上表现很糟，因为他们只有公网IP。从你的一台服务器到另一台服务器的阻塞，将会不得不退出你的私有网络并且重新进入。除了引入延时之外，这种情况也对安全分组产生很大损害。如果你决定在EC2实例上运行你自己的负载均衡层，那么最终的结果只是把服务发现中的问题推向了上层。你的负载均衡器现在不再是一个特殊的、无法替代的设备；它只是另外一个实例，一个失败探测器，但是对你的操作来说它确实至关重要的。

应用内部实现服务注册/服务发现

由于DNS和集中式负载均衡都存在问题，因此你可能决定仅通过代码解决这个问题。为了在你的应用内不使用DNS发现依赖，为何不使用一些不同的、更加专业的机制呢？

这是很流行的做法，在许多软件堆栈中都可以发现。例如，Airbnb最初在Twitter commons服务里使用了这个模型。我们运行在Twitter commons上的java服务是使用zookeeper自动注册自身的，用配置信息集中点替代了DNS。想要与这些服务会话的应用向zookeeper请求可用后端的列表，并且通过zookeeper watches定期地刷新或者订阅以了解列表的变化。

然而，这种方法也会受到许多限制。首先，如果你在统一的软件栈上运行的话，这种方法工作的非常良好。在Twitter上，大多数服务都运行在JVM上，那么一切就很容易实现。然而，在Airbnd上，为了与ZK注册服务通信，我们不得不用ruby编写自己的在zookeeper。最终的实现非常不可靠，以至于在Zookeeper停止的时候服务就会中断。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务