Uber如何使用Mesos的？答曰：和Cassandra一块儿用

过完程序员节吃完蛋糕，让咱们动力十足地开始新一轮的学习吧！
今天小数为你们带来的是一篇Uber海外工程师的演讲视频解读，让咱们一边听着纯正的英语（大雾）一边看着PPT一边来了解Uber的容器技术世界吧：）

若是你是Uber公司，你须要存储司机和乘客APP每30秒发出的位置信息，有大量的实时数据须要实时使用，你该如何作呢？

Uber的解决方案是综合性的。他们创建了一套系统，将Cassandra跑在 Mesos上面。在一个演讲中Uber的软件工程师很是好的解释了这个系统（https://www.youtube.com/watch... ，小数表示是很是纯正的印度英语）。

现在的开发们老是有太多艰难的决定要作。咱们应该所有都投入到云吗？哪个云？贵不贵？会不会厂商锁定？咱们是否应该两条路一块儿来尝试而后作个混合架构？由于担忧平台毛利达不到50%，咱们是否应该所有自研？

Uber决定打造他们本身的系统，或者说他们打算把当下两个十分能干的开源组件结合在一块儿。让Cassandra和Mesos一块儿工做，就是Uber选择的方式。

Uber作出这个决定并不困难。他们资金充足，有着顶级的人才和资源去开发、维持以及升级这个复杂的系统。

自从Uber的目标肯定为让每一个人、每一个地方的运输实现99.99%的可用，在扩大规模的同时想要控制开销就变得很是有意义。

用金钱来换时间一般是一笔好交易。用金钱来买技能也经常是颇有必要的。考虑到Uber可靠性的目标，10000个请求只有一个容许失败，他们须要运做多个数据中心。Cassandra被证实能够处理数据中心大量的负载和工做，因而数据中心就帮Uber作了这个决定。

若是你想让运输系统可靠到达每一个人每一个地方，那么就须要高效地利用你的资源。这是使用数据中心操做系统例如Mesos背后的想法。经过统计相同机器上的复用服务，就能够减掉30%的机器，节省了一笔不小的费用。Mesos之因此被选中，是由于在那时它是惟一辈子产环境里被证明能够管理数万集群的工具，这正是Uber须要的，Uber要作的系统规模确实很大。

还有哪些更有趣的发现呢？

• 你能够在容器里运行有状态的服务。Uber发现几乎没有任何差异，对比在裸机上跑Cassandra和在一个由Mesos管理的容器里跑Cassandra，大概仅有5-10%的差异。

• 性能很优秀：读延迟均值：13ms；写延迟：25ms；P99s看起来也不错。

• 他们能支持的最大集群每秒有超过一百万次的写和十万左右的读。

• 敏捷比性能更重要。在这种架构下Uber获得的是敏捷：很轻松地就能够在集群上建立和运行工做负载。

最初

• 静态分区机器横跨不一样的服务

• 50台机器用于API，50台用于存储，而且它们绝不重叠。

如今

• 一切都运行在Mesos上面，包括有状态的服务如Cassandra和Kafka。

• Mesos是数据中心操做系统，可以让你的数据中心变成一个单个的资源池。

• 在当时Mesos是惟一能够管理数万台机器的工具，如今或许也有了其余的选择。

• Uber 在MySQL上创建了他们本身的Sharded数据库，命名为Schenmaless。Cassandra和Schenmaless将会成为Uber的两个数据存储选择。而现有的Riak设备将会移到Cassandra上。

• 一个单独的机器能够跑不一样类型的服务。

• 在同一机器的静态复用服务能够带来减小30%机器使用。这是一个来自Google Borg系统的实验发现。

• 举例，一个使用了不少CPU的服务和一个使用了不少存储或者内存的服务能够很好地匹配，这两个服务能够很效率地跑在同一服务器上，机器利用率获得了提高。

• Uber如今有20个Cassandra机器，计划未来增长到100个。

• 敏捷性比性能更重要。你须要有能力管理这些集群而且在它们上面以一种平滑的方式进行不一样的操做。

• 为何在一个容器里运行Cassandra而不是在整个机器上？

• 你想要存储数据数千个千兆字节，可是你但愿它能在多个机器上复制甚至跨数据中心。

• 你一样但愿在不一样的集群实现资源隔离、性能隔离。

• 很难在一个共享集群作到上述这些。举例，若是你建立了一个1000节点的Cassandra集群，它要么不能大规模，要么就会在不一样集群之间有性能干扰。

生产环境

• 在两个数据中心间（东海岸和西海岸）有大约20个的集群复制。

• 最初有四个集群，包括中国。可是和滴滴合并后，这些集群就关闭了。

• 在两个数据中心有大约300台机器。

• 最大的两个集群：每秒超过一百万次读和十万次写。

• 其中的一个集群用来存储每30秒来自司机和乘客app的位置信息。

• 平均读延迟：13ms；平均写延迟：25ms

• 大多数使用LOCAL_QUORUM的一致性级别（即强一致性）。

Mesos

• Mesos从机器中抽象了CPU、内存和存储。

• 你看到的再也不是单独的机器，编程的对象是一整个资源池。

• 线性扩展。能够跑成千上万台机器。

• 高可用。Zookeeper被用来在可配置数量的复制中进行leader选举。

• 容器上可使用Docker containers或Mesos containers。

• 可插拔的资源隔离。好比Linux可用Cgroups memory和CPU isolator。有一个Posix isolator。对于不一样系统有着不一样的隔离机制。

• 二级调度。来自Mesos agent的资源被提供给不一样的framework。Framework在这之上调度他们的任务。

Apache Cassandra

• Cassandra很是适合Uber的用例。

• 水平扩展。读和写规模随着节点增长线性扩展

• 高度可用。容错率有着可调的一致性水平。

• 低延迟。在同一数据中心维持毫秒级的延迟。

• 操做简单。它是一种同构集群。没有master。集群中没有特殊节点。

• 丰富多样的数据模型。它有column、compositekey、 counter、 secondary index等多种模型。

• 和其余开源软件有很好的集成。Cassandra和Hadoop、Spark、Hive都有链接。

Dcos-Cassandra-Service

• Uber和Mesosphere合做搭建了mesosphere/dcos-cassandra-service——一个自动化的服务能够轻松部署和管理。

• 在最上面的是WebInterface或者ControlPlane API。你只要说明须要多少节点，须要多少CPU，指定Cassandra配置，而后提交到Control Plane API。

• 在Uber使用部署系统，始于用来跑无状态服务的Aurora的上面，能够自启dcos-cassandra-service framework。

• 在示例中dcos-cassandra-serviceframework有两个集群和Mesos master对话。Uber在他们的系统中使用了5个Mesos master。Zookeeper用来leader选举。

• Zookeeper也用来存储框架元数据：哪个任务在跑，Cassandra配置，集群健康等。

• 在集群中Mesos agent跑在每一台机器上。Agent为Mesos master提供资源，master将它们离散地分发出去。分发能够被framework接受也能够被拒绝。多Cassandra节点也能够跑在同一机器上。

• 使用的Mesos Container，而不是Docker。

• 在配置中override 5个端口（storage_port,ssl_storage_port, native_transport_port, rpcs_port, jmx_port），因此多个容器能够跑在同一机器上。

• 使用了persistent volume，因此数据被存放在沙箱目录以外。若是Cassandra挂掉，数据仍然在persistent volume，挂掉重启以后还能够提供给同一任务。

• 动态预留被用来确保挂掉的任务重启后资源可用。

• Cassandra服务操做

• Cassandra有一个seed node的理念，当新节点加入集群时自启gossip process。建立一个定制的seed provider用来启动Cassandra节点，让Cassandra节点在Mesos集群能够自动地roll out。

• Cassandra集群的节点数量可使用一个REST请求来增长。它会启动附加节点，给它seed nodes，以及自启附加的Cassandra daemons。

• 全部Cassandra的配置参数均可以改变。

• 使用API，一个挂掉的节点能够被替换掉。

• 在复制之间同步数据是须要修复的。修复的大体范围是在一个一个节点的基础上进行。它并不会影响性能。

• 并不须要清理移走数据。若是节点被加进来，数据会移到新的节点，这时清理被用来删除被移过来的数据。

• 多数据中心复制经过framework来配置。

• 多数据中心支持

• 在每一个数据中心设置Mesos独立安装。

• 在每一个数据中心设置Framework的单个实例。

• Framework互相对话，而且按期交换seed。

• 这些都是Cassandra须要的。经过自启其余数据中心的seed，节点能够gossip拓扑结构，指出这些节点是什么。

• 数据中心之间ping延迟是77.8ms。

• P50的异步复制延迟：44.69ms；P95: 46.38ms； P99: 47.44 ms。

• 调度执行

• 调度执行被抽象成计划（plan）、阶段（phase）和区块（block）。一个调度计划有不一样的阶段，一个阶段又有多个区块。

• 第一阶段，一个调度在进行中出现reconciliation时，它会前往Mesos而后指出哪些在运行。

• 有一个部署阶段会检查若是配置中节点的数量已经存在于集群中，有必要的话就会部署它们。

• 一个block就至关于一个Cassandra节点规格。

• 还有其余的阶段：备份，恢复，清除和修复，根据REST端点触及的是哪个。

• 集群能够每分钟一个新节点的速度来启动。

• 每一个节点启动时间但愿能降到30秒。

• 在Cassandra不可以多节点同时启动。

• 一般给每一个Mesos节点2TB的硬盘空间和128GB的内存。给每一个容器分配100GB，32GB给每一个Cassandra进程（数据并不彻底准确）。

• G1garbage collector被用来替代CMS，没有任何调优的状况下它有更好的延迟和性能表现。

文章来源：High Scalability 版权归原做者全部
http://highscalability.com/bl...