我们客服系统使用mesos/marathon来管理springboot微服务已经有一年半了，没出现过任何故障，运行十分稳定。在这期间, 基于mesos/marathon开发的DCOS又提供了很多新特性还有丰富的framework, e.g. Cassandra,ES,mr-redis,mq等framework，这些framework都实现了高可用，快速扩容缩容。其中mr-redis提供的高可用，主从自动切换，快速部署等特性允许我们重新定义redis的运维方式，可以减少很多工作量，所以我们在考虑把mesos/marathon迁移到DCOS。
在今年6月北京国家会议中心的MesosCon大会上，通过讲师们的深入讲解，让我对DCOS有了进一步了解，于是就想在我们的系统中尝试一下DCOS......
先说明一下我们客服系统是如何使用mesos/marathon的，还有使用过程中遇到的相关问题
-
使用方式github -> nexus-> marathon shell pull jar && run jar (`mesos container a.k.a unified container`) 1. 开发提交代码到github, build出的package自动传到nexus 最初我们也尝试过用docker来部署，当时在build出jar包的同时会build一个对应docker image,并传到私有的docker registry, 但是这个严重拖延了部署时间, 最后我们选择 直接部署jar包，即使用mesos container，这种方式提高了部署效率 2. marathon中的task会从nexus下载jar包，然后通过shell命令直接运行，整个运行环境 是受cgroups的isolator限制的 问题
1. mesos container 运行springboot程序的部署方式在dcos上是否可行？(之前我一直以为
dcos只支持docker)
2. 曾经服务升级过程中遇到的一个坑，新版本的服务部署过程中由于配置或者起他未知问题hang
住无法启动成功，于是我手动kill了hang住的task，但是之前运行正常的服务task也被kill
了, 因此 nginx 对应的接口报了502, 整个服务不可用。这种情况为什么会发生?
我也是带着这2个问题来参加MesosCon会议的，幸运的是会议上Mesosphere公司的工程师Jörg Schad， Vinod Kone & Gregory Mann在问答阶段解释了这2个问题:
第一个问题答案: Schad 回答说DCOS支持原生的mesos container, 同时也支持
universal container, 大家也称原生的container为unified container, 这么多
称呼很容易让人迷惑。听到这个答案后我就觉得mesos/marathon 迁移到dcos完全可行。
第二个问题答案：Vinod Kone & Gregory Mann在讲解Executor 生命周期的过程中提到
了Task group, task是如何工作的， 同一个Task group 里的task认为都是相同的，如
果新加的task 健康检查没有通过，整个Task group里的task都会被kill掉。 这个特性就
解释了我们在升级sprintboot服务Webapp从v1到v2版本过程中v2启动有问题，手动kill后，
所有的 webapp服务都被kill, nginx直接返回502. Vinod Kone & Gregory Mann 解
释说他们也从用户收到新的需求更改Task group管理task的这种方式，
但是这个pr还没有排期，所以我们只能通过比较tricky的方式来解决，e.g: 当发现Task
group A中的新版服务无法正常启动的时候，我们可以另外新建一个Task group B来部署旧
版服务，等这个Task group B 中的task通过健康检测可以提供服务的时候,再手动kill掉
Task group A的服务并分析原因，这样就会保证 Webapp 这个服务一直是可用的。
经过MesosCon会议中的学习，回到公司以后，我就简单阅读了一下DCOS文档并搭建了一套环境来做测试 , 也有了初步的结论，即迁移到DCOS有好处也有坏处，需要针对不同场景需求作出取舍。
阿里云ECS server节点配置
- 1个bootstrap节点 (2 core, 16G, SSD)
- 1个master节点 (4 core, 16G, SSD)
- 2个agent节点 (4 core, 16G, SSD)
部署试验
当dcos部署以后，我迁移了一个crm的sprintboot 程序到dcos, 部署过程中突然发现启动时间增加了很多，于是就分场景做了测试
ECS直接run crm.jar
marathon shell 部署crm.jar
dcos 使用mesos-container部署crm.jar
在使用marathon和dcos部署过程中对cpu的配额做了微调
下面是记录了jar的启动时间如下:
| Service | ECS bare runtime | Mesos/Marathon runtime | DC/OS |
|---|---|---|---|
| CRM (1 cpu, 756MB mem) | 35s | 38s | 100s |
| CRM (0.5 cpu, 756MB mem) | 35s | 40s | 200s |
试验总结:
- Marathon即使设置了isolator (cpu/cgroups,mem/cgroups)，在jar启动过程中(a.k.a container创建的过程), cgroups的limit 并没有生效， 所以0.5 cpu和 1个cpu对启动时间没有什么影响。
这个特性也保证了jar能很快的启动，即使比起在ecs直接起jar也慢不了太多。
- DCOS 启动这么慢和cpu的配额有一部分原因，从结果可以推断dcos在container创建中对资源做了限制。
这个特性严格限制了资源的使用率，对控制服务器的load有好处，但是dcos启动jar的时间还是很慢，这个时间差对SLA来讲却是至关重要的
我们可以用到的dcos特性
pod特性
pod把多个container可以看成一个服务，可以共享network, health check 等，如果一个container有问题，会全部重启，或者整体迁移到另外的节点重新部署, 对有依赖的服务来说这个特性很有帮助，这几个有依赖的服务可以直接通过localhost:port 来访问，提供了访问速度。dashboard
可以查看整个集群的资源使用情况，相比原生的监控，这个界面更友好，而且都整合到一个平台，方便运维人员查看。-
dcos cli
dcos让习惯通过terminal来管理系统的运维人员能更方便快捷的来管理整个集群。
最后总结
DCOS启动jar慢可能与dcos加了很多起他组件(security)有关，在没有完全搞清楚为什么启动慢之前，暂时我们先不会把mesos/marathon上的服务迁移到DCOS上，毕竟SLA更重要。
下一步计划
准备把mr-redis(https://github.com/mesos/mr-redis)这个framework porting到当前的mesos/marathon中，这样就解决了快速部署和高可用的需求，现在已经完成了一部分工作，等全部完成后会再分享出来
Note: 对于dcos启动jar慢的问题，欢迎大家提建议，一起讨论一起学习...
