域名預(yù)訂/競(jìng)價(jià)，好“米”不錯(cuò)過(guò)

隨著近幾年微服務(wù)與云計(jì)算的飛速發(fā)展，機(jī)器由物理機(jī)逐步變?yōu)榱颂摂M機(jī)，應(yīng)用服務(wù)由龐大的單體應(yīng)用逐漸變?yōu)榱巳舾蓚€(gè)微服務(wù)聯(lián)合組成的應(yīng)用集群，更新迭代的速度成倍上漲，傳統(tǒng)的部署模式已無(wú)法滿(mǎn)足開(kāi)發(fā)日常更新需求，需要一套適合微服務(wù)的管理架構(gòu)。

技術(shù)棧及文檔

資源調(diào)度框架 MESOS

應(yīng)用編排平臺(tái)Marathon

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

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

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

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

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

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

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

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

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

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

$cat>/tmp/bintray-mesos-el.repo<

#bintray-mesos-el-packagesbymesosfromBintray

[bintray-mesos-el]

name=bintray-mesos-el

baseurl=https://dl.bintray.com/apache/mesos/el7/x86_64

gpgcheck=0

repo_gpgcheck=0

enabled=1

EOF

$sudomv/tmp/bintray-mesos-el.repo/etc/yum.repos.d/bintray-mesos-el.repo

$sudoyumupdate

$sudoyuminstallmesos

$tree/etc/mesos-master

/etc/mesos-master/

|--hostname

|--ip

|--log_dir

|--quorum#quorum>(numberofmasters)/2

`--work_dir

$tree/etc/mesos-agent

/etc/mesos-agent/

|--containerizers#容器類(lèi)型，默認(rèn)mesos，可以添加docker，如:mesos,docker

|--hostname

|--ip

|--log_dir

|--master#master地址，格式為host:port或

zk://host1:port1,host2:port2,.../path或file:///path/to/file

|--resources#設(shè)置總資源大小，可以設(shè)置小些來(lái)預(yù)留更多機(jī)器資源

`--work_dir

$cat/etc/mesos/zk#設(shè)置mesos在zk中的存儲(chǔ)目錄

zk://192.168.100.9:2181,192.168.100.110:2181,192.168.100.234:2181/mesos

$systemctlstartmesos-master

$systemctlstartmesos-slave

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

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

完成以上后，我們的架構(gòu)變成了這樣

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

Marathon 是建立在 Mesos 上的私有 PaaS平臺(tái)。它能自動(dòng)處理硬件或者軟件故障，并確保每個(gè)應(yīng)用程序都"永遠(yuǎn)在線(xiàn)"。我們使用 Marathon 管理微服務(wù)有以下優(yōu)勢(shì)1. 支持容器和非容器，不受限于服務(wù)啟動(dòng)類(lèi)型，操作系統(tǒng)版本等。2. 漂亮而強(qiáng)大的用戶(hù)界面，可以在UI 上進(jìn)行快捷方便的應(yīng)用程序配置3. 支持約束條件，例如允許一個(gè)mesos agent 節(jié)點(diǎn)只運(yùn)行一個(gè)應(yīng)用程序。4. 支持健康檢查?？梢耘渲?http、https、tcp、command 類(lèi)型的監(jiān)控檢查。5. 完整的REST API，易于集成和編寫(xiě)腳本。這個(gè)對(duì)于后期集成來(lái)說(shuō)至關(guān)重要。

#Addtherepository

$sudorpm-Uvhhttp://repos.mesosphere.com/el/7/noarch/RPMS/mesosphere-el-repo-7-2.noarch.rpm

#Installpackages

$sudoyum-yinstallmesosmarathon

#marathonandmesoszkpath

$cat/etc/default/marathon

MARATHON_MESOS_USER="root"

MARATHON_MASTER="zk://192.168.100.9:2181,192.168.100.110:2181,192.168.100.234:2181/mesos"

MARATHON_ZK="zk://192.168.200.9:1181,192.168.100.110:2181,192.168.100.234:2181/marathon"

systemctlstartmarathon

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

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

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

使用 nginx upsync/dyups 模塊進(jìn)行平滑變更

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

wget'http://nginx.org/download/nginx-1.8.0.tar.gz'

tar-xzvfnginx-1.8.0.tar.gz

cdnginx-1.8.0/

./configure--add-module=/path/to/nginx-upsync-module

make

makeinstall

配置文件示例

http{

upstreamtest{

upsync127.0.0.1:8500/v1/health/service/testupsync_timeout=6mupsync_interval=500msupsync_type=consul_healthstrong_dependency=off;

upsync_dump_path/usr/local/nginx/conf/servers/servers_test.conf;

include/usr/local/nginx/conf/servers/servers_test.conf;

}

upstreambar{

server127.0.0.1:8090weight=1fail_timeout=10max_fails=3;

}

server{

listen8080;

location=/proxy_test{

proxy_passhttp://test;

}

location=/bar{

proxy_passhttp://bar;

}

location=/upstream_show{

upstream_show;

}

}

}

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

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

$gitclonegit://github.com/yzprofile/ngx_http_dyups_module.git

#tocompileasastaticmodule

$./configure--add-module=./ngx_http_dyups_module

#tocompileasadynamicmodule

$./configure--add-dynamic-module=./ngx_http_dyups_module

示例配置

http{

includeconf/upstream.conf;

server{

listen8080;

location/{

#Theupstreamheremustbeanginxvariable

proxy_passhttp://$dyups_host;

}

}

server{

listen8088;

location/{

return200"8088";

}

}

server{

listen8089;

location/{

return200"8089";

}

}

server{

listen8081;

location/{

dyups_interface;

}

}

}

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

整體回顧

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

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

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

3.減低OPS人工成本，更加便于管理和維護(hù)

申請(qǐng)創(chuàng)業(yè)報(bào)道，分享創(chuàng)業(yè)好點(diǎn)子。點(diǎn)擊此處，共同探討創(chuàng)業(yè)新機(jī)遇！