SmartStack 介绍 —— 云端的服务发现

理想解决方案的特征

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

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

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

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

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

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

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

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

不奏效的解决方案

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

DNS

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

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

集中式负载均衡

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

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

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

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

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

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

———————

更为糟糕的是，当我们在像Node.js这样的栈上开始开发更多服务的时候，我们预计到将迫使我们用各种各样的语言实现同样的注册和发现逻辑。有时，相关库的缺乏或者不成熟都会进一步阻止我们的努力。有时你希望运行那些不是你自己写的但仍然使用你基础架构的应用：Nginx，CI服务器，rsyslog或者其他软件。这种情况下，在应用内部实现服务发现是完全不可能的。

最终这种方法难于操作。在没有停止应用的前提下调试一个自身来注册服务的应用是不可能的-我们将不得不借助 iptables 来阻止我们正在研究的机器上的Zookeeper端口。必须采取特别的方式来对与特定的应用实例目前正在通信的后端列表和对。 另外再说明一下，智能负载均衡的实现也很复杂。

尽管一个健康检查很简单，就像“该应用可以通过TCP或HTTP访问吗”一样，但是正确的和Nerve整合还是意味着要针对你的应用实现并暴露一个健康检查接口。比如，在Airbnb上，每一个使用HTTP协议通信的应用都暴露了一个/health的服务点，它会在应用健康时返回一个200 OK的状态码，否则返回一个其它状态码。在我们的基础框架中，就是如此；比如，你可以在浏览器里尝试访问https://www.airbnb.com/health!

对于非HTTP应用来说，我们已经写了一些检查，使用特定的协议来发出询问。一个 redis 检查，举例来说，会尝试写入并读取一个简单的key。而一个rabbitmq检查，会尝试发布并消费一条消息。

Synapse

Synapse在Airbnb中的后端发现服务中十分有魔力。它和你的服务一起运行，并且能使服务所要依赖的程序能正常使用，它对你的应用来说是透明的。Synapse在Zookeeper中读出有关可用的后端程序信息，然后用这些信息来配置本地HAProxy进程.当一个客户端想要和服务通信，它只需要和本地HAProxy通信，本地HAProxy只关心匹配请求适当的路径。

本质上，这就是我上面提及的将分散的请求负载均衡的解决方案。这里没有引导错误的问题，因为没有必要发现负载均衡层-通常在localhost来显现。

真正的工作是由HAProxy完成的，它已被证明非常稳定并经过实战考验。Synapse进程本身就是一个中介——如果它宕掉了，你只会收不到变更通知但其他一切仍会良好地运行。使用HAProxy有一大堆的优点。我们能用到强大logging和introspection。我们能够使用先进的负载平衡算法、队列控制、重试及超时。HAProxy还有内置的健康检查，我们可以用它来防范网络隔离（我们能够从Nerve了解到有一个可用的后端但因为网络问题却不能和它连接）。事实上，谈论HAProxy以及如何配置它需要另开一篇博客了，有太多关于它的内容了。

尽管每次Synapse收到后端变更后都更改整个HAProxy的配置文件，但我们依旧尝试用HAProxy状态套接字来做变更。已经存在于HAProxy中的后端在宕掉时会通过状态套接字进入维护模式，当它们恢复后再回到正常模式。我们只有在要添加一个全新的后端时才重启HAProxy让它重新读取配置文件。

在ELB之后我们已经将Nginx放置在第一位了。这是因为我的网络流量已经被分为两个部分，其包括一些用户相关的应用-https://www.arebnb.com的服务器和另一个https://www.airbnb.com/help服务器。比如，在Charon里，从Akamai的一个请求先是直接到达一个Nginx服务器。每一个服务器都运行着Synapse，并且都启用了用户相关服务。当我们根据位置匹配了URI后，信息流发送，通过正确的HAPoxy来选择最佳的后端程序来处理请求。

事实上，Charon从我们用户到我们的用户相关服务选择路径就像是在后端程序之间选择一样。我们得到了所有的好处-健康检查，添加、删除实例，通过HAProxy来修正队列行为。