我們客服系統(tǒng)使用mesos/marathon來管理springboot微服務(wù)已經(jīng)有一年半了，沒出現(xiàn)過任何故障，運行十分穩(wěn)定涂召。在這期間, 基于mesos/marathon開發(fā)的DCOS又提供了很多新特性還有豐富的framework, e.g. Cassandra,ES,mr-redis,mq等framework麻捻，這些framework都實現(xiàn)了高可用，快速擴容縮容兼蕊。其中mr-redis提供的高可用初厚，主從自動切換，快速部署等特性允許我們重新定義redis的運維方式孙技，可以減少很多工作量产禾，所以我們在考慮把mesos/marathon遷移到DCOS。
在今年6月北京國家會議中心的MesosCon大會上牵啦，通過講師們的深入講解亚情，讓我對DCOS有了進一步了解，于是就想在我們的系統(tǒng)中嘗試一下DCOS......
先說明一下我們客服系統(tǒng)是如何使用mesos/marathon的哈雏，還有使用過程中遇到的相關(guān)問題
-
使用方式github -> nexus-> marathon shell pull jar && run jar (`mesos container a.k.a unified container`) 1. 開發(fā)提交代碼到github, build出的package自動傳到nexus 最初我們也嘗試過用docker來部署楞件，當時在build出jar包的同時會build一個對應(yīng)docker image,并傳到私有的docker registry, 但是這個嚴重拖延了部署時間, 最后我們選擇 直接部署jar包，即使用mesos container裳瘪，這種方式提高了部署效率 2. marathon中的task會從nexus下載jar包土浸，然后通過shell命令直接運行，整個運行環(huán)境 是受cgroups的isolator限制的 問題
1. mesos container 運行springboot程序的部署方式在dcos上是否可行彭羹？(之前我一直以為
dcos只支持docker)
2. 曾經(jīng)服務(wù)升級過程中遇到的一個坑黄伊，新版本的服務(wù)部署過程中由于配置或者起他未知問題hang
住無法啟動成功，于是我手動kill了hang住的task皆怕，但是之前運行正常的服務(wù)task也被kill
了, 因此 nginx 對應(yīng)的接口報了502, 整個服務(wù)不可用毅舆。這種情況為什么會發(fā)生?
我也是帶著這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服務(wù)Webapp從v1到v2版本過程中v2啟動有問題辜梳，手動kill后粱甫，
所有的 webapp服務(wù)都被kill, nginx直接返回502. Vinod Kone & Gregory Mann 解
釋說他們也從用戶收到新的需求更改Task group管理task的這種方式，
但是這個pr還沒有排期作瞄，所以我們只能通過比較tricky的方式來解決茶宵，e.g: 當發(fā)現(xiàn)Task
group A中的新版服務(wù)無法正常啟動的時候，我們可以另外新建一個Task group B來部署舊
版服務(wù)宗挥，等這個Task group B 中的task通過健康檢測可以提供服務(wù)的時候,再手動kill掉
Task group A的服務(wù)并分析原因乌庶，這樣就會保證 Webapp 這個服務(wù)一直是可用的。
經(jīng)過MesosCon會議中的學(xué)習契耿，回到公司以后瞒大，我就簡單閱讀了一下DCOS文檔并搭建了一套環(huán)境來做測試 , 也有了初步的結(jié)論，即遷移到DCOS有好處也有壞處搪桂，需要針對不同場景需求作出取舍透敌。
阿里云ECS server節(jié)點配置
- 1個bootstrap節(jié)點 (2 core, 16G, SSD)
- 1個master節(jié)點 (4 core, 16G, SSD)
- 2個agent節(jié)點 (4 core, 16G, SSD)
部署試驗
當dcos部署以后，我遷移了一個crm的sprintboot 程序到dcos, 部署過程中突然發(fā)現(xiàn)啟動時間增加了很多踢械，于是就分場景做了測試
ECS直接run crm.jar
marathon shell 部署crm.jar
dcos 使用mesos-container部署crm.jar
在使用marathon和dcos部署過程中對cpu的配額做了微調(diào)
下面是記錄了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 |
試驗總結(jié):
- Marathon即使設(shè)置了isolator (cpu/cgroups,mem/cgroups)酗电，在jar啟動過程中(a.k.a container創(chuàng)建的過程), cgroups的limit 并沒有生效， 所以0.5 cpu和 1個cpu對啟動時間沒有什么影響裸燎。
這個特性也保證了jar能很快的啟動顾瞻，即使比起在ecs直接起jar也慢不了太多。
- DCOS 啟動這么慢和cpu的配額有一部分原因德绿，從結(jié)果可以推斷dcos在container創(chuàng)建中對資源做了限制荷荤。
這個特性嚴格限制了資源的使用率，對控制服務(wù)器的load有好處移稳，但是dcos啟動jar的時間還是很慢蕴纳，這個時間差對SLA來講卻是至關(guān)重要的
我們可以用到的dcos特性
pod特性
pod把多個container可以看成一個服務(wù)，可以共享network, health check 等个粱，如果一個container有問題古毛，會全部重啟，或者整體遷移到另外的節(jié)點重新部署, 對有依賴的服務(wù)來說這個特性很有幫助都许，這幾個有依賴的服務(wù)可以直接通過localhost:port 來訪問稻薇，提供了訪問速度。dashboard
可以查看整個集群的資源使用情況胶征，相比原生的監(jiān)控塞椎，這個界面更友好，而且都整合到一個平臺睛低，方便運維人員查看案狠。-
dcos cli
dcos讓習慣通過terminal來管理系統(tǒng)的運維人員能更方便快捷的來管理整個集群服傍。
最后總結(jié)
DCOS啟動jar慢可能與dcos加了很多起他組件(security)有關(guān)，在沒有完全搞清楚為什么啟動慢之前骂铁，暫時我們先不會把mesos/marathon上的服務(wù)遷移到DCOS上吹零，畢竟SLA更重要。
下一步計劃
準備把mr-redis(https://github.com/mesos/mr-redis)這個framework porting到當前的mesos/marathon中拉庵，這樣就解決了快速部署和高可用的需求灿椅，現(xiàn)在已經(jīng)完成了一部分工作，等全部完成后會再分享出來
Note: 對于dcos啟動jar慢的問題钞支，歡迎大家提建議阱扬，一起討論一起學(xué)習...
