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

[dataman]

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

如果你是 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