开源中国

我们不支持 IE 10 及以下版本浏览器

It appears you’re using an unsupported browser

为了获得更好的浏览体验,我们强烈建议您使用较新版本的 Chrome、 Firefox、 Safari 等,或者升级到最新版本的IE浏览器。 如果您使用的是 IE 11 或以上版本,请关闭“兼容性视图”。
SmartStack 介绍 —— 云端的服务发现 - 技术翻译 - 开源中国社区

SmartStack 介绍 —— 云端的服务发现 【已翻译100%】

oschina 推荐于 4年前 (共 22 段, 翻译完成于 10-28) 评论 0
收藏  
14
推荐标签: Synapse 待读

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

SmartStack的组件——NerveSynapse——在GitHub上可以获取!继续阅读获得更多内容。

Garfielt
 翻译得不错哦!

SOA中的服务问题

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

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

Garfielt
 翻译得不错哦!

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

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

lwei
 翻译得不错哦!

理想解决方案的特征

解决服务问题的答案是自动化-让计算机完成后端池的维护清理工作。然而实现这样的自动化有许多方法。首先让我们总结一下理想实现的特征:
  • 能够处理特定服务请求的后端可以自动地接收这样的请求
  • 负载将智能地分布到所有的后端上,因此没有任何一个后端服务器比其余的后端做更多的工作,这样请求就会自动的路由到最不忙碌的后端
  • 遇到问题的后端将自动地停止接受请求
  • 同一系统下,应当可能在不影响其他后端的情况下从一个后端卸下负载。这样才可能进行调试。
  • 应当具有非常完美的内省功能,这样你通常可以知道哪些后端可用,它们接收哪种类型的负载以及这些负载来自于哪些客户。
  • 对后端列表的更改应该对客户的影响最小;理想情况下,这样的更改对客户应该是透明的。
  • 不应当存在单点故障-系统里的任何地方的任一机器出现故障都不会有任何影响。
我们可以使用这些标准去评估可能的解决方案。例如,手动更改哪些直接写在客户端的后端列表,然后再部署客户端,这立刻引起许多标准在很大程度上失效。其他方法结果会怎样呢?

几点人
 翻译得不错哦!

不奏效的解决方案

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

DNS

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

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

Garfielt
 翻译得不错哦!

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

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

lwei
 翻译得不错哦!

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

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

Garfielt
 翻译得不错哦!

集中式负载均衡

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

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

几点人
 翻译得不错哦!

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

lwei
 翻译得不错哦!

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

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

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

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

几点人
 翻译得不错哦!
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们
评论(0)
Ctrl/CMD+Enter

暂无网友评论
顶部