Autodesk基于Mesos的通用事件系统架构
程序员文章站
2022-03-05 12:59:29
...
【编者按】本文由Autodesk Cloud软件架构师Olivier Paugam撰写，解释了如何集合Mesos、Kafka、RabbitMQ、Akka、Splunk、Librato、EC2等基础设施解决实际问题。此外，以如此小规模的团队解决问题确实令人赞叹。
以下为分享原文：
数月前分到了一项新的任务：做一个集中事件系统（central eventing system），允许各个后端彼此通讯——包括动态流式（activity streaming）后端、渲染、数据转换、BIM、日志报告、分析等等。最终确定，这应该是一个可以匹配多种负载、使用场景与可扩展配置文件的通用系统。此外，这个系统还需要具备简单易用的接口。最后，这个系统的每部分都应当能够自动扩展。
然而，笔者根本没有那么多的时间去深入开发，再选用稳定通用、性能良好的Kafka作为存储核心（当然这里Kafka并不是唯一选择）。同时需要注意的是，这里还需要通过一些API将之以前端的方式提供。而在一些思考后，使用后端管理offset同样被否决，因为这样做在处理实例错误时需要建立大量约束。
基于这些需求，这里设置了两个独立的层：一个API层，处理接收的信息；还有一个后端层，托管常驻、有状态的Kafka做通信的流处理服务（比如执行生产者和消费者）。这两个独立的层分别具备良好的扩展性，只需要一致的路径以确保客户端与同一个后端流处理服务通讯不会中断。
这两个独立的层完全用Scala实现，并使用了Play！框架。同时，这两个层都非常依赖Akka的actor系统（每个节点通常运行着几百个actor）。后端层执行了定制的Kafka producer与consumer，并使用了独立的actor设置来管理预读与写入缓存。在整套系统中，“ Everything is implemented as nested finite-state machines ”被一直执行。使用Librato收集度量数据，随后转到Splunk处理。
如上所述，这里实现了两个独立的层，那么它们之间的路由机制该如何完成？非常简单，这里使用的是用RabbitMQ——可靠且兼具弹性！对于实现这个“phone-switch”，AMQP队列是良医妙药。同时，使用逻辑分片对其扩展也十分简单（比如对每个事务中出现的cookie使用哈希），它将会把一组固定的后端节点与一个RabbitMQ broker连接起来。
那么，这里为什么不聚合RabbitMQ broker？其主要原因在于这么做并不会带来显著地提升，同时也非常耗时。实际上，各独立broker之间的分区流量更高效易控。跟收益比起来，附加的工作量微不足道。
简而言之，在一些容器拓扑中执行针对路径路径，其取决于不同后端节点主导的是什么样的streaming session。扩展整体与分层拓展一样简单，取决于具体的需求。实际中唯一的限制来自虚拟网络适配器与其带宽。
现在有趣的部分来了：流量的稳定该如何确保，同时还需要避免byzantine 故障？其实这里并不存在太多的挑战，只需使用一个简单的二阶段提交协议，将客户端与后端作为镜像的状态机（比如始终同步），这可以通过让读写操作需求明确的确认请求来实现。尝试读取的做法在失败后进行重试，直到获得确认，接下来会对后端更新（比如将Kafka offset转发，或者编排一系列事件发布）。这样，客户端与后端之间的传输就类似于“分配session”、“读取”、“确认”、“读取”、“确认”……“处理”。
通过这些处理，系统的巨大优势在于可以有效地呈现操作幂等，同时还可以在状态机上编译所有逻辑，无需使用烦人的说明语句（PS，请原谅我追求酷炫的思想）。此外，任何网络故障都可以通过重试解决，从而可以*地实现control-flow和back-pressure。
这样一来，所有功能都通过Apache ThriftAPI提供（汇聚了压缩和HTTS，并准备实现某些情况下场景的TCP切换）。当下，平台客户端已经使用了Python、Scala、NET和Ruby等多个语言，并使用了大量炫酷的技术。值得一提的是，Kafka offset是由客户端控制的，使得控制后台更为简单。
到了这里，你肯定想问，后端节点挂掉的话该如何处理？这里需要感谢的是二阶段提交协议让读取数据变得简单——客户端复制失败后会使用现有的offset重新分配一个新的streaming session。因此这里的问题存在于向Kafka写入数据，因为它是异步的，因此可能会面临受到下游back-pressure的情况（在节点失败后，Kafka broker也会出现问题，这一点必须注意）。因此这里需要为后端系统实现一个优雅的关闭功能，从而在等待写入时关闭阻止新的请求进入。再不济，也可以将任何等待数据刷新到磁盘中，等待稍后处理。
这里你肯定想问，基础设施问题该如何解决？这里的原理是相同的，任何与处理streaming session的实际后端节点传输中断必然会导致速度变慢，但是由于二阶段提交，这里不会产生令人不快的影响。
此外，在落入Kafka log之前数据会被自动加密（AES 256），当然你一定要在Kafka producers和consumers之间共享秘钥那么只能祝你好运了。关于安全，streaming session通过OAUTH2认证，每个请求单独用MD5-HMAC，并通过TLS向后端集群传输。
那么，这个炫酷的系统是如何部署的？这里使用是Mesos/Marathon集群来运行（现在还不是DCOS，不过在未来会转换过去，并享受其强大的控制面板）。当下，集群托管在AWS EC2 上，在多个c3.2xlarge实例上被复用（在给定区域中执行一个小型部署，10到20算不少了）。请注意，在Kubernetes（不管是EC2还是GCE）也可以使用同样的方法。
使用Ochopod技术完成部署（自集群容器），它同样是开源的。将操作减到最少。比如推进build时，API层只负责分配一些新的容器，等分配好之后再逐步清理旧的。所有这些操作都通过一个专门的、在集群中运行的Jenkins从节点来处理（其本身也是一个Ochopod容器）。
事实上，笔者也开发了Ochothon mini-PaaS，只是为了快速开发运维（devops）所有的容器。
下面让你体会Ocho-* 平台的强大：1个人（笔者）可以管理跨越2个regions上的5个系统部署，包括所有备份基础设施……而且还有时间写写博客和代码。
所以，总体来讲，对它设计与编码是件很有意思的事情，再加上它现在作为Autodesk Cloud基础设施的关键部分在生产环境运行（相当不错）。也欢迎各位提交问题。
相关阅读：
原文链接：How Autodesk Implemented Scalable Eventing Over Mesos（译者/孙薇 审校/朱正贵 责编/仲浩）
以下为分享原文：
数月前分到了一项新的任务：做一个集中事件系统（central eventing system），允许各个后端彼此通讯——包括动态流式（activity streaming）后端、渲染、数据转换、BIM、日志报告、分析等等。最终确定，这应该是一个可以匹配多种负载、使用场景与可扩展配置文件的通用系统。此外，这个系统还需要具备简单易用的接口。最后，这个系统的每部分都应当能够自动扩展。
然而，笔者根本没有那么多的时间去深入开发，再选用稳定通用、性能良好的Kafka作为存储核心（当然这里Kafka并不是唯一选择）。同时需要注意的是，这里还需要通过一些API将之以前端的方式提供。而在一些思考后，使用后端管理offset同样被否决，因为这样做在处理实例错误时需要建立大量约束。
基于这些需求，这里设置了两个独立的层：一个API层，处理接收的信息；还有一个后端层，托管常驻、有状态的Kafka做通信的流处理服务（比如执行生产者和消费者）。这两个独立的层分别具备良好的扩展性，只需要一致的路径以确保客户端与同一个后端流处理服务通讯不会中断。
这两个独立的层完全用Scala实现，并使用了Play！框架。同时，这两个层都非常依赖Akka的actor系统（每个节点通常运行着几百个actor）。后端层执行了定制的Kafka producer与consumer，并使用了独立的actor设置来管理预读与写入缓存。在整套系统中，“ Everything is implemented as nested finite-state machines ”被一直执行。使用Librato收集度量数据，随后转到Splunk处理。
如上所述，这里实现了两个独立的层，那么它们之间的路由机制该如何完成？非常简单，这里使用的是用RabbitMQ——可靠且兼具弹性！对于实现这个“phone-switch”，AMQP队列是良医妙药。同时，使用逻辑分片对其扩展也十分简单（比如对每个事务中出现的cookie使用哈希），它将会把一组固定的后端节点与一个RabbitMQ broker连接起来。
那么，这里为什么不聚合RabbitMQ broker？其主要原因在于这么做并不会带来显著地提升，同时也非常耗时。实际上，各独立broker之间的分区流量更高效易控。跟收益比起来，附加的工作量微不足道。
简而言之，在一些容器拓扑中执行针对路径路径，其取决于不同后端节点主导的是什么样的streaming session。扩展整体与分层拓展一样简单，取决于具体的需求。实际中唯一的限制来自虚拟网络适配器与其带宽。
现在有趣的部分来了：流量的稳定该如何确保，同时还需要避免byzantine 故障？其实这里并不存在太多的挑战，只需使用一个简单的二阶段提交协议，将客户端与后端作为镜像的状态机（比如始终同步），这可以通过让读写操作需求明确的确认请求来实现。尝试读取的做法在失败后进行重试，直到获得确认，接下来会对后端更新（比如将Kafka offset转发，或者编排一系列事件发布）。这样，客户端与后端之间的传输就类似于“分配session”、“读取”、“确认”、“读取”、“确认”……“处理”。
通过这些处理，系统的巨大优势在于可以有效地呈现操作幂等，同时还可以在状态机上编译所有逻辑，无需使用烦人的说明语句（PS，请原谅我追求酷炫的思想）。此外，任何网络故障都可以通过重试解决，从而可以*地实现control-flow和back-pressure。
这样一来，所有功能都通过Apache ThriftAPI提供（汇聚了压缩和HTTS，并准备实现某些情况下场景的TCP切换）。当下，平台客户端已经使用了Python、Scala、NET和Ruby等多个语言，并使用了大量炫酷的技术。值得一提的是，Kafka offset是由客户端控制的，使得控制后台更为简单。
到了这里，你肯定想问，后端节点挂掉的话该如何处理？这里需要感谢的是二阶段提交协议让读取数据变得简单——客户端复制失败后会使用现有的offset重新分配一个新的streaming session。因此这里的问题存在于向Kafka写入数据，因为它是异步的，因此可能会面临受到下游back-pressure的情况（在节点失败后，Kafka broker也会出现问题，这一点必须注意）。因此这里需要为后端系统实现一个优雅的关闭功能，从而在等待写入时关闭阻止新的请求进入。再不济，也可以将任何等待数据刷新到磁盘中，等待稍后处理。
这里你肯定想问，基础设施问题该如何解决？这里的原理是相同的，任何与处理streaming session的实际后端节点传输中断必然会导致速度变慢，但是由于二阶段提交，这里不会产生令人不快的影响。
此外，在落入Kafka log之前数据会被自动加密（AES 256），当然你一定要在Kafka producers和consumers之间共享秘钥那么只能祝你好运了。关于安全，streaming session通过OAUTH2认证，每个请求单独用MD5-HMAC，并通过TLS向后端集群传输。
那么，这个炫酷的系统是如何部署的？这里使用是Mesos/Marathon集群来运行（现在还不是DCOS，不过在未来会转换过去，并享受其强大的控制面板）。当下，集群托管在AWS EC2 上，在多个c3.2xlarge实例上被复用（在给定区域中执行一个小型部署，10到20算不少了）。请注意，在Kubernetes（不管是EC2还是GCE）也可以使用同样的方法。
使用Ochopod技术完成部署（自集群容器），它同样是开源的。将操作减到最少。比如推进build时，API层只负责分配一些新的容器，等分配好之后再逐步清理旧的。所有这些操作都通过一个专门的、在集群中运行的Jenkins从节点来处理（其本身也是一个Ochopod容器）。
事实上，笔者也开发了Ochothon mini-PaaS，只是为了快速开发运维（devops）所有的容器。
下面让你体会Ocho-* 平台的强大：1个人（笔者）可以管理跨越2个regions上的5个系统部署，包括所有备份基础设施……而且还有时间写写博客和代码。
所以，总体来讲，对它设计与编码是件很有意思的事情，再加上它现在作为Autodesk Cloud基础设施的关键部分在生产环境运行（相当不错）。也欢迎各位提交问题。
相关阅读：
- Deploying our eventing infrastructure over Mesos/Marathon & Ochothon !
- Ochopod + Kubernetes = Ochonetes
- Return of the finite state machine!
原文链接：How Autodesk Implemented Scalable Eventing Over Mesos（译者/孙薇 审校/朱正贵 责编/仲浩）
上一篇： mongodb与关系型数据库相比的优缺点
下一篇： Java操作MongoDB