平台概览
2014年下半年左右，去哪儿完成了有关构建私有云服务的技术调研，并最终拍定了Docker/Mesos这一方案。下图1展示了去哪儿数据平台的整体架构：
图1：去哪儿数据平台的整体架构
该平台目前已实现了如下多项功能：
1.每天处理约340亿/25TB的数据；
2.90%的数据在100ms内完成处理；
3.最长3h/24h的数据回放；
4.私有的Elasticsearch Cloud；
5.自动化监控与报警。
为什么选择Docker/Mesos
目前为止，这个数据平台可以说是公司整个流数据的主要出入口，包括私有的Elasticsearch Cloud和监控报警之类的数据。那么为什么选择Docker/Mesos？
选择Docker有两大原因。第一个是打包：对于运维来讲，业务打完包之后，每天面对的是用脚本分发到机器上时所出现的各种问题。业务包是一个比较上层的话题，这里不做深入的讨论，这里讲的“打包”指软件的Runtime层。如果用Docker的打包机制，把最容易出现问题的Runtime包装成镜像并放在registry里，需要的时候拿出来，那么整个平台最多只执行一个远程脚本就可以了，这是团队最看好的一个特性。第二个是运维：Docker取消了依赖限制，只要构建一个虚拟环境或一个Runtime的镜像，就可以直接拉取到服务器上并启动相应的程序。此外Docker在清理上也较为简单，不需要考虑环境卸载不干净等问题。
以常见的计算框架来说，它们本质上仍然属于运行在其上的Job的Runtime。综合上述情况，团队选择针对Runtime去打包。
选择Mesos是因为它足够简单和稳定，而且拥有较成熟的调度框架。Mesos的简单体现在，与Kubernetes相比其所有功能都处于劣势，甚至会发现它本身都是不支持服务的，用户需要进行二次开发来满足实际要求，包括网络层。不过，这也恰好是它的强项。Mesos本身提供了很多SDN接口，或者是有模块加载机制，可以做自定义修改，平台定制功能比较强。所以用Mesos的方案，需要考虑团队是否可以Hold住整个开发过程。
从框架层面来看，Marathon可以支撑一部分长期运行的服务，Chronos则侧重于定时任务/批处理。
以下图2是Mesos的一个简单结构图：
图2：Mesos结构
数据平台的最终目标架构如下图3所示：
图3：平台目标
组件容器化与部署
组件的容器化分为JVM容器化和Mesos容器化。JVM容器化需要注意以下几方面：
潜在创建文件的配置都要注意
1.java.io.tmpdir
2.-XX:HeapDumpPath
3.-Xloggc
-Xloggc会记录GC的信息到制定的文件中。现在很少有直接用XLoggc配置的了（已经用MXBean方式替代了）。如果有比较老的程序是通过-Xloggc打印GC日志的话，那么要额外挂载volume到容器内。
时区与编码
1.–env TZ=Asia/Shanghai
2.–volume /etc/localtime:/etc/localtime:ro
3.–env JAVA_TOOL_OPTIONS=”-Dfile.encoding=UTF-8 -Duser.timezone=PRC
时区是另一个注意点。上面所列的三种不同的方法都可以达到目的，其中第一/三个可以写在Dockerfile里，也可以在docker run时通过–env传入。第二种只在docker run时通过volume方式挂载。另外，第三种额外设置了字符集编码，推荐使用此方式。
主动设置heap
1.防止ergonomics乱算内存
这是Docker内部实现的问题。即使给Docker设置内存，容器内通过free命令看到的内存和宿主机的内存是一样的。而JVM为了使用方便，会默认设置一个人机功能会根据当前机器的内存计算一个堆大小，如果我们不主动设置JVM堆内存的话，很有可能计算出一个超过 Memory Cgroup限制的内存，启动就宕掉，所以需要注意在启动时就把内存设置好。
CMS收集器要调整并行度