Autodesk基于Mesos和Kafka的通用事件系统架构

本文讲的是Autodesk基于Mesos和Kafka的通用事件系统架构,【编者的话】我非常喜欢这篇博客,因为它揭示了许多简单架构模块—例如:Mesos、Kafka、RabbitMQ、Akka、Splunk、Librato和EC2可以整合起来来解决实际问题。而且一个小团队就可以获得非常令人惊讶的成就。

几个月前我被分配一个新任务,要求拿出一个集中事件系统的解决方案,这个系统可以允许各种后端彼此通讯。这些后端包括动态消息、渲染、数据转换、BIM、身份验证、日志报告、分析等等后端应用。这应该是一个可以适配多种应用、使用场景与可扩展配置文件的通用系统。当然,这个系统还应该有易用的接口,以及动态扩展性。

显然我不可能有时间写很多代码。因为Kafka可以动态扩展,在业内被广泛应用,所以选择它作为核心存储方案(请注意不一定非要使用Kafka)。现在我当然不能直接把它发布,而是通过一些API对前端提供服务。如果不深思熟虑,我也拒绝让后端处理偏移量(offsets),因为这会对如何应对实例失效造成太多限制。

那我该怎么办呢?两个独立的分层:第一是处理访问流量的API层,然后是保持长期链接和有状态消息流进程的后台层,后台层和Kafka通信(也就是说,完成生产者和消费者的角色)。每一层都各自独立扩展,只需要一致性路由来保证客户端持续跟同一个后台消息流进程沟通。

这两层都是100%使用Scala语言开发的Play!框架,而且严重依赖Akka Actor系统(每个节点都运行几百个Actor)。后台层部署了一系列客制化的Kafka消息生产者和消费者,用一系列指定的actors来处理预读和写缓冲,所有服务都以内置的有限状态机(我喜欢这个概念)方式部署,数据搜集由Librato完成(实际上是运行在容器内的collectd),而分析由Splunk完成。

手绘图:发布流程图

那么,这两层直接如何路由呢?可以使用RabbitMQ来实现就好了,它可以提供足够的容错性和一致性。AMQP队列可以很好地实现“电话交换机”模式,纵向扩展就不用说了,同时可以使用某些逻辑分区(例如通过hash分配到代表每个交易的cookie上或者类似的特征上),是的一部分固定的后端节点与一个RabbitMQ代理联系起来。

为什么我不对RabbitMQ代理采用集群模式呢?嗯,主要是因为我比较懒而且这也不是必须的。在我看来,每个代理之间的分区流量既有效又容易控制,跟好处比起来额外工作量可以认为忽略不计。

因此简要来说,考虑到不同后台节点运行不同消息流, 因此我们需要的容器技术会继续使用特定的路径。扩展整个架构就跟互不影响扩展每一层任务一样微不足道,唯一实际限制来自于虚拟网卡和带宽。

虚线代表某一个特定session持续使用的通道

接下来就是比较有趣的部分:我们如何确保可信交易以及避免错综复杂的失效。要我来说,这个更加容易,只需要一个简单的双向握手(2-phase commit-esque protocol and mode) 协议和模式,这样你的客户端和背景作为镜像状态机处于完全同步状态。可以通过给读写操作请求返回一个明确的请求响应方式来实现。当需要读取的时候,如果失败就一直重试知道得到一个响应,然后转变为后台服务响应(例如,转发kafka offset,或者预约发布事件)。这样客户端和后台之间的交互流量就真的像“分配一个session”,“读”,“应答响应”,“读”,“应答响应”........“部署”。

通过这些处理,系统的巨大优势在于可以有效地呈现操作幂等,同时还可以在状态机上编译所有逻辑,无需使用烦人的说明语句。此外,任何网络失效当然会重试,也顺便会从中获得免费的控制流和背压路由(back-pressure routing)。

这样所有的服务对外就表现为一个Apache Thrift的API(现在通过带压缩HTTPS加密隧道,将在未来某个时间计划改为明码TCP)。我有使用Python、Scala、.Net和Ruby的SDK客户端来使用这些令人目眩的新技术。请注意尽管Kafka偏移被客户端管理(尽管这样不透明),但是这样可以使得后端变的更加简单且容易控制。

等一下,当后端节点失效怎么来处置呢?因为有了双向握手协议,因此当读数据时,这并不会成为问题:当后端节点失效时,客户端持续得到失败返回,接下里就会使用现在的偏移量重新申请一个链接。如果向Kafka写入数据时,因为这是异步过程,而且可能会出现双向失效(例如客户端和Kafka代理节点同时有问题),因此有可能会出现问题。为了解决写问题,当有等待任何等待写操作完成时,后台节点会对任何其它访问请求返回失败,或者在最近的可恢复点将任何挂起数据刷新入磁盘(之后在重新读入)。

那么当部分架构出现问题怎么处理呢?同样的解决办法。任何客户端和后台节点之间的中断链接会影响到链接的响应速度,但是因为有双向握手协议,并不会有任何严重的问题。

哦,我忘了提到数据写入Kafka日志之前数据都会自动(AES256)加密,而在Kafka消息生产者和消费者之间共享秘钥是不可能的。从安全角度来看,流链接是通过OAUTH2认证的,每个连接使用单独的MD5-HMAC认证,并通过TLS在后端集群之间传输。

那么,你现在会问到底是怎么部署这套酷毙的系统呢?我们100%部署这套系统是通过标准的Mesos、Marathon集群来部署的(现在还不是DCOS,但是我们很有可能会转向它,并从炫酷的仪表盘受益)。集群目前都是运行在AWS的EC2上,我们一般会在多个c3.2xlarge实例上被复用(在给定区域中执行一个小型部署,10到20算不少了)。请注意,在Kubernetes(不管是EC2还是GCE)也可以使用同样的方法。

我们集群运行的一个简单架构示意图

我们使用Ochopod技术完成部署(自集群容器),它同样是开源的,可以将交互操作减到最少。比如将一次构建推入API层时,此系统只负责分配一些新的容器,等分配好之后再逐步清理旧的。所有这些操作都通过一个专门的、在集群中运行的Jenkins从节点来处理(其本身也是一个Ochopod容器)。

事实上,我也开发了Ochothon mini-PaaS,只是为了快速开发运维(devops)所有的容器。

Ochothon 命令行展示我们一套预配置的集群

这些Ocho-*平台到底能起到多大作用呢?可以说一个人(比如我)可以管理管理跨越两个区域管理五套这样的系统部署,包括备份架构。而且同时我还有时间来记录下这些博客和代码。

总体上来说,设计和编码实现这样的系统有很多乐趣,而且它现在作为云基础架构的关键部分支撑着我们的生产环境。如果想了解关于这套迷人系统更多的内容,可以联系我们。

相关文章

原文链接:How Autodesk Implemented Scalable Eventing Over Mesos(翻译:叶振安 审校:杨峰)

原文发布时间为:2015-08-22

本文作者:giam 

本文来自合作伙伴DockerOne,了解相关信息可以关注DockerOne。

原文标题:Autodesk基于Mesos和Kafka的通用事件系统架构

时间: 2024-10-28 22:13:09

Autodesk基于Mesos和Kafka的通用事件系统架构的相关文章

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

几个月前,我接到一个任务,要拿出一个集中式的事件系统,可以让我们的各种后端组件相互通信.我们讨论了后端活动流.渲染.数据转换.建筑信息模型(BIM).个性身份(identity).日志报表.分析等等.找寻其中是否有真正通用的可变负载.使用模式和扩展性配置.或许是其他的某样东西,能使我们的开发团队轻松接口.当然,系统的每个部分都应该具备自我扩展的能力. 由于我没有时间写太多的代码,所以我选择了Kafka作为我们的存储核心,因为它稳定且被广泛使用,而且表现良好(请注意,我没有说非得用它不可,可以用其

去哪儿网基于Mesos和Docker构建私有云服务的实践

本文讲的是去哪儿网基于Mesos和Docker构建私有云服务的实践[编者的话]本文深入介绍了去哪儿网利用Mesos和Docker构建私有云服务的全过程,分享了从无状态应用向有状态应用逐步过度的经验与心得. 平台概览 2014年下半年左右,去哪儿完成了有关构建私有云服务的技术调研,并最终拍定了Docker/Mesos这一方案.下图1展示了去哪儿数据平台的整体架构: 图1:去哪儿数据平台的整体架构 该平台目前已实现了如下多项功能: 每天处理约340亿/25TB的数据: 90%的数据在100ms内完成

基于Mesos的当当作业云Elastic Job Cloud

作业在互联网电商行业中是很常见的技术手段.当当具有成千上万的作业规模,大致分为业务类,归档类,监控类和大数据类. 当当原有的作业解决方案是Elastic Job,以下称为Elastic Job 1.X.主要关注以下4个方面: 高可用.这里高可用指主从热备.主节点提供服务的同时从节点处于等待状态.一旦主节点失效,其中一个从节点通过选举成为主节点继续提供服务,原来的主节点再次生效后,作为从节点继续等待选举机会.线性扩展.可理解为高可用的高阶功能.既然多节点参与服务提供,若从节点只负责热备,难免造成资

中国电信基于Mesos+Docker的运维自动化在CDN中的实践

本文讲的是中国电信基于Mesos+Docker的运维自动化在CDN中的实践[编者的话]本次分享将讲解容器技术在CDN系统中的应用,包括应用的容器化,使用Mesos.Marathon.ZooKeeper对线上业务的快速部署.升级.回滚以及Docker在研发测试环境中的实践.在引入Docker技术之后,CDN不同角色的服务部署在一个物理服务器,资源利用率明显提高,另外应用都可以一键部署,运维工作量明显减少. 大家好,我是中国电信云公司CDN运营中心的张其栋,今天跟大家分享的题目是<中国电信基于Mes

基于JavaScript语言的快速物联网开发架构

随 JavaScript 语言的流行,及物联网领域的崛起,我们能看到它们结合的可能性,同时也发现它特别适合于物联网开发.因此,在这篇文章里,笔者将主要从以下三个方面进行介绍: 典型的物联网架构,及多种语言带来的问题: 只使用 JavaScript 语言的物联网架构: 详解基于 JavaScript 语言的物联网不同层级结构. 那么,先让我们看看典型的物联网架构是怎样的吧. 典型的物联网架构 我们甚至还可以认为,物联网只是对互联网的扩展.与传统的 C/S 架构相比,它多了一个"数据采集层"

暴走漫画基于阿里云的全面容器化架构实践

标题有所修改. 很高兴能和大家分享一些暴走漫画基于公有云的容器化架构的实践经验. 基于之前在暴漫的经验,我到了扇贝以后,大概用了一个月的时间,就将扇贝的产品成功迁移到了容器环境中,并做了很多改进,也有了更多的思考. 暴走漫画(以下简称"暴漫")相信大家都不陌生,它应该算一个互联网应用.先简单介绍一下背景:暴漫主要做App和网站,后端主要是Ruby,也有一些Python.Scala的异构化系统.整体架构是标准的互联网应用架构.包括负载均衡.Nginx.应用服务器.数据库(MySQL),等

阿里沈询:阿里技术架构演变,及基于EDAS的敏捷服务开发与架构实践

8月30-31日20:00-21:30,一场别开生面的技术大会-- "蚂蚁金服&阿里云在线金融技术峰会"将在线举办.本次将聚焦数据库.应用架构.移动开发.机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践. 蚂蚁金服&阿里云在线金融技术峰会专题:https://yq.aliyun.com/activity/109 峰会统一报名链接:http://yq.aliyun.com/webinar/join/38 来自阿里巴巴的资深专家王晶昱(花名:沈

部署基于国际版Azure的SharePoint三层架构服务器场

前言 微软Azure国际版已经很普及了,这里没有用国内版(世纪互联),用的是国际版,当然是由于公司性质的缘故.这里一步步图文的方式,分享给大家创建Azure国际版的SharePoint三层架构的过程,并带给大家一些使用感受. 自己在使用的过程中,也发现一些问题,搜了很久也没有搞定,最后在MS case的帮助下,才真正解决了问题.同时也分享给大家,对于已经深入了解Azure的朋友,可以忽略本文,烦请勿见笑. 1.申请Azure账号,这部分略过了,我这里已经有创建好的Azure账号,在管理页面上点击

基于分布式存储的数字图书馆云存储安全架构研究

基于分布式存储的数字图书馆云存储安全架构研究 马晓亭,陈臣 在分析基于云存储OSI 安全模型的基础上,对云存储技术可能引发的安全问题进行了描述.针对云存储系统及其在应用过程中数据安全问题,提出了一种基于云计算环境下图书馆新的安全存储策略. 关键词:数字图书馆:云存储:安全:架构 [下载地址]:http://bbs.chinacloud.cn/showtopic-13392.aspx