微信号:infoqchina

介绍:有内容的技术社区媒体

Autodesk基于Mesos的可扩展事件系统

2015-09-02 08:16 韩陆 译

几个月前,我接到一个任务,要拿出一个集中式的事件系统,可以让我们的各种后端组件相互通信。我们讨论了后端活动流、渲染、数据转换、建筑信息模型(BIM)、个性身份(identity)、日志报表、分析等等。找寻其中是否有真正通用的可变负载、使用模式和扩展性配置。或许是其他的某样东西,能使我们的开发团队轻松接口。当然,系统的每个部分都应该具备自我扩展的能力。


由于我没有时间写太多的代码,所以我选择了Kafka作为我们的存储核心,因为它稳定且被广泛使用,而且表现良好(请注意,我没有说非得用它不可,可以用其他东西替代)。当然,现在我还不能直接将Kafka暴露出去,得在前端用一些API去实现这些。没想太多,我就放弃了在我的后端管理偏移量的想法,因为这在为实例处理失败时,会给人带来太多的约束。


所以我的结论就是,将系统分为独立的两层:第一层是API层,负责处理请求流(incoming traffic);第二层是后端层,负责处理长期的、有状态的、与Kafka交互的流处理进程(比如,实现生产者和消费者)。这两层都可以独立扩展,只要求它们之间保持一致的路由,以保证客户端可以与相同的后端流处理进程,保持通信。


两层代码均100%使用Scala实现,并使用Play!框架。同时,它们重度依赖Akka actor系统(每个节点通常跑数百个actor)。后端层实现了一组自定义的Kafka生产者和消费者,并使用一组专用的actor来管理预读与写缓冲区。一切都被实现为嵌套的有限状态机(我超爱这个概念)。分析数据存储到Splunk,同时,度量数据存储到Librato(collectd是在容器中运行的)。


在此,哥文艺地展示下系统发布后的模样。


如何实现两层之间的路由呢?只需使用RabbitMQ即可,它有很好的持久性和弹性,甚至没什么趣味可言。AMQP队列是实现这一简单的“电话交换机”模式的伟大方法。通过使用一些逻辑分片技术(比如对一些存在于每个事务中的cookie值进行散列或者类似的技术)将一组固定的后端节点关联到某个RabbitMQ broker,就能够让路由支持扩展,这简直是小事一桩。


为什么我没有对RabbitMQ的broker做集群?哇哦,我能说我懒吗,关键是我真心觉得没啥必要。在每个broker之间分流实际上是为了高效,而在我看来,更重要的是以更轻松的方式去控制。为此付出的额外工作相比收成毫无意义。


所以,总之,给定容器拓扑,我们的请求会保持一条特定路径,这条路径依赖于后端节点所处理的流会话。我们所需的每一层可独立扩展远比整体可扩展重要。唯一的实际限制将是虚拟网络适配器和带宽。

虚线表示给定的会话将保持的特定路径


现在,我们开始有意思的部分吧:如何确保可靠的通信,避免拜占庭式的失败呢?我要说,这非常简单,只需使用简单的两阶段提交协议,在客户端和后端同时建立状态机镜像模型(例如,他们总是同步的)。读写操作需要显式的确认请求。当你尝试读取并且失败的时候,你只需重新尝试,直到获得确认,然后这个确认将改变后端的状态(比如,向前移动Kafka的偏移量或者下发定时任务将事件发布)。所以我的客户端和后端之间的传输流实际上是这样的:“allocate session”、“read”、“ack”、“read”、“ack”......“dispose”。


这一系统的巨大优势是有效地实现了操作幂等,而且没有任何烦人的声明语句,就可以编码状态机中的所有逻辑(我告诫自己:我要提供一个纯粹的功能实现,没别的,只为了炫技)。应对任何网络故障,当然是优雅地重新尝试。通过这种方式,还可以得到自由的控制流和背压技术。


这个系统的API会暴露为Apache Thrift(当前通过HTTPS协议使用压缩技术工作,计划在某个时间点迁移到普通的TCP层)。我提供了Python、Scala、.NET和Ruby语言的客户端 SDK,以应对我们在Autodesk所使用的、花样百出的技术)。请注意,Kafka偏移量是由客户端管理的(虽然这样不透明),这使得后端控制更简单。


稍等,我听见你说,如何处理后端节点宕掉的情况?哇哦,因为我们有两阶段协议,所以我们在读取数据的时候并不会真的获取:如果客户端不断地失败,将使用当前的偏移量,重新分配一个新的流会话。当向 Kafka写入数据时,麻烦来了,因为这个过程是异步并且潜在地受下行流背压(比如你的节点失败了并且Kafka broker也出现问题了)。我会将后端节点配置为正常关机,在等待任何写挂起时,传入的任何请求都会快速失败。最后一招,我们甚至可以将任何待处理的数据刷新到磁盘上(之后,重新将数据注入)。


稍等,我听见你又说,如果基础设施的一部分挂掉会怎样?同样的。与流会话处理的实际后端节点之间的通信中断,当然会慢下来,但不会再有什么讨厌的影响,这又要归功于两阶段协议喽。


哦,我忘了说,在将数据写入Kafka日志前是自动加密的(使用AES 256)。Kafka的生产者和消费者使用同一套密钥共享。在涉密的主题上,我可以让流会话通过OAUTH2来验证,对每个请求验证MD5-HMAC,走TLS到后端集群。


现在你又问,那么,我们如何完整地部署这个时尚最时尚的系统呢?嗯,我们将整套系统100%地运行在一个普通的Mesos/Marathon集群上(现在用的不是DCOS哦,但我们可以切过去,因为这样可以用上他们超赞的仪表盘)。集群托管在AWS EC2上,我们基本上整体复用了一些 c3.2xlarge实例(在给定的区域内,10到20个小型部署足够了)。请注意,我们可以在Kubernetes上(无论是EC2还是GCE)做同样的事情。

小秀一下我们技术栈的结构


每处部署都使用了我们的开源技术Ochopod(自集群容器)。操作被降低到绝对最小值。例如,我们要做一次优雅的构建推送,就拿API层来说,无非是分配一些新的容器,等待他们启动好,然后逐步替换旧部署,这样就可以了。所有这一切都是通过集群中的一个专用的Jenkins slave(它本身也是一个Ochopod容器)完成的!

实际上,我开发了一个叫Ochothon的迷你PaaS系统,只是为了能够快速开发/运维所有的容器。


Ochothon CLI显示了我的一个预发布集群的情况

为了能让你感受Ocho-*平台是多么好用,我这样说吧,一个人(比如我)就能够管理跨2个区域的5个部署系统,包括所有的基础设施副本……此外,还能有时间写写博客、码码程序!


所以,总体来说,此间的设计和编码,整件事情都充满乐趣,再加上它现在已经在生产运行,是我们云基础架构任务的关键部分(这是一个还不错的打赏)。如果你想对这个奇葩的流系统有更多的了解,告诉我们哦!

CNUTCon全球容器技术大会相关PPT

点击“阅读原文”进行下载


今日文章推荐


干货 | 腾讯游戏如何使用Docker?

给Objective-C的『悼词』

Java9新功能:HTTP2 & REPL篇

全栈Web开发|Neo4j实战案例解码

投稿请联系:

邮箱:editors@cn.infoq.com QQ:1073600161

版权归属InfoQ,禁止私自抄袭转载。

回复关键词React | 架构师 | 运维 | 云 | 开源 | 物联网 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员



 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 像Sublime Text一样使用Chrome DevTools 自学Android资料大放送 【学习】Mac OS X 应用程序开发笔记 Android 极简反射教程 EntityFramework的多种记录日志方式,记录错误并分析执行时间过长原因