資源調度框架MESOS

　　應用編排平臺Marathon

　　nginx動(dòng)態(tài)修改upstream dyups

　　nginx動(dòng)態(tài)修改upstream upsync

　　使用Mesos進(jìn)行機器資源管理

　　首先，是機器資源的管理。在微服務(wù)的架構中，原有的單體服務(wù)被拆分成了一個(gè)個(gè)獨立單元的應用程序，這些服務(wù)體量較小，可以獨立運行在配置較小的機器上。為了故障隔離，我們會(huì )盡可能的把這些服務(wù)部署在不同的虛擬機上，這樣機器的數量會(huì )成倍增加。對于運維來(lái)說(shuō)，每個(gè)新服務(wù)部署時(shí)，需要先查看現有機器的剩余資源是否滿(mǎn)足新服務(wù)的需求，有時(shí)可能因為評估不準確造成來(lái)回擴容、遷移，或者資源浪費。

　　開(kāi)始時(shí)，我們的架構可能時(shí)這樣的

　　為了解決上面的問(wèn)題，可以使用MESOS（布式資源管理框架），它可以讓我們像用一臺電腦（一個(gè)資源池）一樣使用整個(gè)數據中心。

　　mesos部署時(shí)分為master和agent兩個(gè)角色，當然，你可以在同一臺機器啟動(dòng)它們。

　　安裝Mesos前需要安裝zookeeper，mesos使用zk實(shí)現高可用和選舉，包括一個(gè)masterleader和幾個(gè)備份master避免宕機。

　　Mesos master負責管理各個(gè)Framework和Slave，并將Slave上的資源非配給各個(gè)Framework。

　　Mesos agent負責管理本節點(diǎn)上的各個(gè)MesosTask，為各個(gè)Executor分配資源(低版本為mesos-slave)。

 

　　當mesos服務(wù)啟動(dòng)后，agent會(huì )向master節點(diǎn)匯報機器資源，包括CPU、內存、磁盤(pán)等。當我們要發(fā)布一個(gè)服務(wù)時(shí)，只需要設置這個(gè)服務(wù)的CPU、內存、磁盤(pán)參數，mesosmaster會(huì )自動(dòng)幫我們選擇有足夠資源的機器去運行，如下圖

　　我們將微服務(wù)的啟動(dòng)都交給Mesos管理，這樣我們只需要關(guān)注整體資源即可。MESOS提供了UI界面，可以直接訪(fǎng)問(wèn)mesosmaster的5050端口，查看集群資源使用情況。總體使用情況及Agent節點(diǎn)使用情況

　　完成以上后，我們的架構變成了這樣

　　使用Marathon進(jìn)行微服務(wù)管理

　　Marathon是建立在Mesos上的私有PaaS平臺。它能自動(dòng)處理硬件或者軟件故障，并確保每個(gè)應用程序都“永遠在線(xiàn)”。我們使用Marathon管理微服務(wù)有以下優(yōu)勢

　　支持容器和非容器，不受限于服務(wù)啟動(dòng)類(lèi)型，操作系統版本等

　　漂亮而強大的用戶(hù)界面，可以在UI上進(jìn)行快捷方便的應用程序配置

　　支持約束條件，例如允許一個(gè)mesos agent節點(diǎn)只運行一個(gè)應用程序

　　支持健康檢查。可以配置http、https、tcp、command類(lèi)型的監控檢查

　　完整的RESTAPI，易于集成和編寫(xiě)腳本。這個(gè)對于后期集成來(lái)說(shuō)至關(guān)重要

1. # Add the repository
2. $ sudo rpm -Uvh http://repos.mesosphere.com/el/7/noarch/RPMS/mesosphere-el-repo-7-2.noarch.rpm
3.  
4. # Install packages
5. $ sudo yum -y install mesos marathon
6.  
7. # marathon  and mesos zk path
8. $ cat /etc/default/marathon 
9. MARATHON_MESOS_USER="root"
10. MARATHON_MASTER="zk://192.168.100.9:2181,192.168.100.110:2181,192.168.100.234:2181/mesos"
11. MARATHON_ZK="zk://192.168.200.9:1181,192.168.100.110:2181,192.168.100.234:2181/marathon"
12.  
13. systemctl start marathon

　　啟動(dòng)后，直接訪(fǎng)問(wèn)marathon的8080端口，就能看到一個(gè)漂亮強大的UI界面。

 

　　我們以springboot應用為例，在marathon上創(chuàng )建一個(gè)應用程序

　　當我們更新應用程序時(shí)，marathon會(huì )新建相同實(shí)例數量的應用程序，待healthcheck通過(guò)之后替換老節點(diǎn)，所以不需要擔心新的服務(wù)沒(méi)有啟動(dòng)期間老的服務(wù)停掉造成線(xiàn)上事故。到這里為止，我們已經(jīng)可以在marathon上方便快捷的進(jìn)行日常應用的創(chuàng )建、升級、擴容、縮容。當服務(wù)健康檢查失敗或者機器宕機后，marathon會(huì )自動(dòng)在其它節點(diǎn)上啟動(dòng)掛掉的應用程序，大大提升了高可用性。

　　當我們的微服務(wù)可以隨機分配在不同機器上時(shí)，便產(chǎn)生了一個(gè)新的令人頭疼的問(wèn)題。nginx并不知道后端節點(diǎn)的變更，也不可能每次都去手動(dòng)修改upstream節點(diǎn)，reloadnginx，這樣成本就太高了。我們的解決思路是和微服務(wù)的注冊中心打通，當服務(wù)注冊、注銷(xiāo)時(shí)，都會(huì )對注冊中心進(jìn)行更新，利用nginx upsync/dyups模塊可以動(dòng)態(tài)修改upstream節點(diǎn)的能力進(jìn)行同步，做到平滑變更。如果使用的注冊中心為consul，建議使用upsync模塊，這樣無(wú)需開(kāi)發(fā)，只需要簡(jiǎn)單的nginx配置，就可以實(shí)現我們想要的效果，支持consulkv，consul_services，consul_health，同時(shí)upsync也支持etcd。建議使用consul_health接口。upsync模塊不是nginx內置模塊，使用時(shí)需要重新編譯添加此模塊。

1. wget 'http://nginx.org/download/nginx-1.8.0.tar.gz'
2. tar -xzvf nginx-1.8.0.tar.gz
3. cd nginx-1.8.0/
4.  
5.  
6. ./configure --add-module=/path/to/nginx-upsync-module
7. make
8. make install

1. http {
2.     upstream test {
3.         upsync 127.0.0.1:8500/v1/health/service/test upsync_timeout=6m upsync_interval=500ms upsync_type=consul_health strong_dependency=off;
4.         upsync_dump_path /usr/local/nginx/conf/servers/servers_test.conf;
5.  
6.         include /usr/local/nginx/conf/servers/servers_test.conf;
7.     }
8.  
9.     upstream bar {
10.         server 127.0.0.1:8090 weight=1 fail_timeout=10 max_fails=3;
11.     }
12.  
13.     server {
14.         listen 8080;
15.  
16.         location = /proxy_test {
17.             proxy_pass http://test;
18.         }
19.  
20.         location = /bar {
21.             proxy_pass http://bar;
22.         }
23.  
24.         location = /upstream_show {
25.             upstream_show;
26.         }
27.  
28.     }
29. }

　　當upsync無(wú)法滿(mǎn)足我們的需求或者注冊中心不是consul、etcd時(shí)，我們可以考慮使用nginxdyups模塊。dyups僅對外提供upstream的增刪查改接口，和注冊中心對比、修改的工作需要我們通過(guò)腳本的方式完成。雖然這種方式麻煩一些，但是可定制化程度高，支持http，C，luaAPI，基本上可以滿(mǎn)足大部分的場(chǎng)景需求。

　　dyups模塊也需要nginx編譯時(shí)添加

1. $ git clone git://github.com/yzprofile/ngx_http_dyups_module.git
2.  
3.  
4. # to compile as a static module
5. $ ./configure --add-module=./ngx_http_dyups_module
6.  
7.  
8. # to compile as a dynamic module
9. $ ./configure --add-dynamic-module=./ngx_http_dyups_module

1. http {
2.  
3.     include conf/upstream.conf;
4.  
5.     server {
6.         listen   8080;
7.  
8.         location / {
9.             # The upstream here must be a nginx variable
10.             proxy_pass http://$dyups_host;
11.         }
12.     }
13.  
14.     server {
15.         listen 8088;
16.         location / {
17.             return 200 "8088";
18.         }
19.     }
20.  
21.     server {
22.         listen 8089;
23.         location / {
24.             return 200 "8089";
25.         }
26.     }
27.  
28.     server {
29.         listen 8081;
30.         location / {
31.             dyups_interface;
32.         }
33.     }
34. }

　　特別注意，使用dyups時(shí)，proxy_pass時(shí)的upstream必須是nginx變量，否則不生效，切記。

　　經(jīng)過(guò)以上調整，我們得到了以下優(yōu)化

　　服務(wù)器資源自動(dòng)分配，合理利用

　　提升微服務(wù)的高可用性

　　減低OPS人工成本，更加便于管理和維護