客服系统mesos/marathon迁移到DC/OS的探索(1)

我们客服系统使用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慢的问题，欢迎大家提建议，一起讨论一起学习...