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

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

Uber的解决方案是综合性的。他们建立了一套系统，将Cassandra跑在Mesos上面。在一个演讲中Uber的软件工程师非常好的解释了这个系统（https://www.youtube.com/watch?v=4Ap-1VT2ChU&feature=youtu.be，小数表示是非常纯正的印度英语）。

如今的开发们总是有太多艰难的决定要做。我们应该全部都投入到云吗？哪一个云？贵不贵？会不会厂商锁定？我们是否应该两条路一起来尝试然后做个混合架构？因为担心平台毛利达不到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/blog/2016/9/28/how-uber-manages-a-million-writes-per-second-using-mesos-and.html