大家好！先做一個(gè)自我介紹，我來(lái)自新浪微博，付穩(wěn)，屬于微博平臺(tái)研發(fā)中心，本次分享的主題是新浪微博DCP基于Docker的混合云架構(gòu)與應(yīng)用實(shí)踐。今天的主題是Swarm、Mesos、Kubernetes的三國(guó)演義，但是我可能更多講的是大型互聯(lián)網(wǎng)公司在調(diào)度框架選型或者它依賴的中間設(shè)施，如何把它應(yīng)用到上千臺(tái)服務(wù)器的一個(gè)規(guī)模，新浪微博遇到了哪些問(wèn)題，并且如何來(lái)解決它們。

背景，挑戰(zhàn)與實(shí)現(xiàn)

?

?

介紹一下本次項(xiàng)目微博混合云的背景，大家知道微博的體量是比較大的，線上規(guī)模大概幾千臺(tái)服務(wù)器，所以每一次架構(gòu)改造對(duì)我們來(lái)說(shuō)都是非常大的挑戰(zhàn)，要考慮的因素會(huì)更多。

?

?

微博的峰值流量特點(diǎn)類似前一段時(shí)間的王寶強(qiáng)事件、奧運(yùn)事件、喬任梁事件，在10分鐘之內(nèi)，微博的流量會(huì)漲到兩到三倍。線上有三千臺(tái)服務(wù)器，如果十分鐘內(nèi)流量來(lái)了三倍，以前是沒(méi)辦法的，申請(qǐng)機(jī)器、上架、初始化、服務(wù)部署，這一個(gè)流程大概需要一兩個(gè)月，所以就要求平臺(tái)研發(fā)中心具備在十分鐘之內(nèi)完成一千個(gè)節(jié)點(diǎn)的擴(kuò)張能力。考慮幾個(gè)方面：極端峰值、擴(kuò)展性、成本和業(yè)務(wù)迭代。業(yè)界基本就是依靠混合云這種趨勢(shì)，包括阿里云、AWS等公有云平臺(tái)的成熟是一方面，國(guó)內(nèi)的12306利用阿里云來(lái)解決它的余票查詢業(yè)務(wù)，包括Docker、Mesos等容器新技術(shù)使大規(guī)模動(dòng)態(tài)調(diào)度成為可能性，京東等也在這上面有一些實(shí)踐，所以我們也提出了自己混合云的解決方案。

?

?

說(shuō)一個(gè)大家能比較切身感受的例子，12306。這是12306的一個(gè)本地機(jī)房。它70%的業(yè)務(wù)來(lái)自于余票查詢，即壓力70%在余票查詢上，它把這一部分放在公有云上，內(nèi)部的IDC每五分鐘之內(nèi)緩存同步，同步到阿里云機(jī)房。用戶來(lái)訪問(wèn)12306的時(shí)候，如果是其它業(yè)務(wù)、結(jié)算類業(yè)務(wù)就走本地IDC，如果余票查詢就走阿里云的IDC。這給我們很好的一個(gè)啟發(fā)，可以利用公有云節(jié)省成本，快速擴(kuò)容，但是它的數(shù)據(jù)是分鐘級(jí)同步的、流量可預(yù)期，而新浪微博整個(gè)峰值就是十分鐘，比如王寶強(qiáng)發(fā)酵事件，要十分鐘之內(nèi)要擴(kuò)容完成，完成服務(wù)發(fā)現(xiàn)流量引入；大家刷一條微博也不可能要求別人五分鐘之后才能看到，所以對(duì)技術(shù)的要求很高。

混合云去年DCP的實(shí)戰(zhàn)，具備了十分鐘混合云擴(kuò)容一千節(jié)點(diǎn)的技術(shù)能力，春晚兩天之內(nèi)完成了1000+臺(tái)阿里云ECS，基本上就是16核16G或者16核64G高配的這種配置，當(dāng)然容器數(shù)量肯定是成倍的增加。實(shí)現(xiàn)了無(wú)降級(jí)的平滑過(guò)渡，同時(shí)支持了微博50%的主體流量，利用Docker技術(shù)動(dòng)態(tài)調(diào)度技術(shù)、基礎(chǔ)設(shè)施跨云，包括微博Feed流、紅包飛、手機(jī)微博不同業(yè)務(wù)方都使用。現(xiàn)在每天晚上也是利用這種動(dòng)態(tài)調(diào)度標(biāo)準(zhǔn)體系的晚高峰擴(kuò)容300+節(jié)點(diǎn)，熱點(diǎn)事件也會(huì)進(jìn)行彈性擴(kuò)容。

基于混合云的微博項(xiàng)目總結(jié)兩點(diǎn)，第一是基于Docker的彈性調(diào)度，第二是基礎(chǔ)設(shè)施的跨云。當(dāng)然服務(wù)編排是不可分割的一個(gè)部分，但是如果想讓混合云體系運(yùn)轉(zhuǎn)起來(lái)可能還需要基礎(chǔ)設(shè)施的跨云。接下來(lái)，我會(huì)對(duì)這幾個(gè)問(wèn)題分別講解。

?

?

?

整個(gè)微博的容器技術(shù)發(fā)展體系， 2014年我們做了Docker化、容器化，2015年到現(xiàn)在我們做了私有云+混合云，還有動(dòng)態(tài)調(diào)度。技術(shù)也是在不斷積累中的，這是目前成型的一個(gè)技術(shù)體系。大家可以看主機(jī)層，主機(jī)層其實(shí)是內(nèi)部和私有云打通，外部和公有云打通，它進(jìn)行主機(jī)的創(chuàng)建。主機(jī)的創(chuàng)建之后，進(jìn)行成本的結(jié)算。它還要承擔(dān)一個(gè)最重要的任務(wù)就是初試化，比如Docker環(huán)境，Mesos、Swarm的環(huán)境，還有運(yùn)維基礎(chǔ)環(huán)境的初始化。服務(wù)編排下發(fā)編排任務(wù)，編排向調(diào)度層進(jìn)行下發(fā)，下發(fā)根據(jù)調(diào)度策略選擇進(jìn)行資源調(diào)度。當(dāng)你有資源的時(shí)候，它可以進(jìn)行資源調(diào)度。如果沒(méi)有物理資源，它向主機(jī)層進(jìn)行申請(qǐng)。主機(jī)層申請(qǐng)之后，這里面創(chuàng)建機(jī)器，其實(shí)初始化做了很重要部分就是把它創(chuàng)建機(jī)器成為一個(gè)可運(yùn)行的Docker編排環(huán)境。在調(diào)度層去年我們主體跑的Swarm大概有兩千+節(jié)點(diǎn)，然后部分的業(yè)務(wù)線在Mesos上跑，今年主要在自研的容器調(diào)度平臺(tái)。DCP的編排+調(diào)度+主機(jī)體系，和Docker三駕馬車有類似，之后也會(huì)重點(diǎn)介紹。當(dāng)集群是一、兩千節(jié)點(diǎn)，并發(fā)量百億級(jí)時(shí)候，服務(wù)發(fā)現(xiàn)、鏡像中心、監(jiān)控中心包括容量評(píng)估等周邊體系建設(shè)等都是要考慮的。

?

?

新浪微博的技術(shù)棧基本上是內(nèi)網(wǎng)私有云的裸主機(jī)，公有云上VM，CentOs全是7.0的，Docker1.6.2。為什么1.6.2？因?yàn)檫@是目前跑的最穩(wěn)定的一個(gè)版本，近期也在考慮升級(jí)，去年調(diào)研的時(shí)候，因?yàn)槲覀冇肧warm比較早，所以從0.1快到0.4，后來(lái)出了1.0，穩(wěn)定版本一直在用。其實(shí)Docker1.6.2目前來(lái)說(shuō)是最能和Swarm兼容的版本，因?yàn)镾warm是基于DockerAPI的，低版本的API是不支持的，這就要求我們Docker版本至少為Docker1.6.2。網(wǎng)絡(luò)模式是Host的模式，因?yàn)槲覀兊牟l(fā)量比較大，我們調(diào)整過(guò)其它網(wǎng)絡(luò)模式，但是網(wǎng)絡(luò)性能損耗是非常大的，這方面不能忍受，所以是Host的模式。DockerRegistry是自建的鏡像倉(cāng)庫(kù)V1、V2。

?

?

整個(gè)混合云的DCP流程，首先是內(nèi)網(wǎng)主機(jī)申請(qǐng)，內(nèi)網(wǎng)向私有云申請(qǐng)，公網(wǎng)向云端進(jìn)行申請(qǐng)，申請(qǐng)之后進(jìn)行初始化，初始化有兩步，系統(tǒng)環(huán)境、運(yùn)維環(huán)境(DNSmasq、Cron等)初始化。還有一些Docker環(huán)境， Docker Swarm、 Mesos進(jìn)行安裝和啟動(dòng)，安裝和啟動(dòng)之后就代表一個(gè)可調(diào)度的Docker環(huán)境，然后根據(jù)你的調(diào)度策略和算法進(jìn)行動(dòng)態(tài)調(diào)度。之后容器鏡像啟動(dòng)、服務(wù)發(fā)現(xiàn)全自動(dòng)流程。關(guān)于服務(wù)發(fā)現(xiàn)是微博自己開(kāi)源的平滑reload的服務(wù)發(fā)現(xiàn)版本nginx-upsync-module。

基礎(chǔ)設(shè)施

新浪微博的基礎(chǔ)設(shè)施很多功能現(xiàn)在都要用阿里云去改進(jìn)或者是去定制，所以在公有云上做了很多經(jīng)驗(yàn)。整個(gè)DCP的思路就是內(nèi)網(wǎng)私有云，因?yàn)槲⒉┯兄@樣的特點(diǎn)，就是大家刷微博的時(shí)候，刷PC端一般是中午，刷手機(jī)端微博是晚上，它屬于兩個(gè)不同的業(yè)務(wù)方，當(dāng)然從屬于一個(gè)大的技術(shù)平臺(tái)。當(dāng)中午流量刷的時(shí)候，手機(jī)端微博的用戶其實(shí)少了，可以把機(jī)器共享出來(lái)放入我們的私有云或者放到共享池。不管是私有云還是公有云的機(jī)器，通過(guò)資源調(diào)度的方式，當(dāng)機(jī)器閑置的時(shí)候，把它放入一個(gè)共享池整合來(lái)利用，提高資源的利用率。

?

?

公有云方面，我們做了一些改造是封裝阿里云的接口。大家封裝阿里云可能是一臺(tái)或者是幾臺(tái)的，但我們?nèi)绻趲追昼娭畠?nèi)要?jiǎng)?chuàng)建一百臺(tái)或者一千臺(tái)，肯定要對(duì)它的接口進(jìn)行封裝，包括它的一些BUG也提出要求，一些VPC或者是一些控制臺(tái)的性能我們也做了封裝和改進(jìn)。假如有了上面的API，就可以創(chuàng)建機(jī)器了。創(chuàng)建機(jī)器的時(shí)候，首先建議大家定制一個(gè)自己的VM，這個(gè)VM鏡像不是Docker鏡像，是操作系統(tǒng)的鏡像。我們的Docker基礎(chǔ)鏡像版本是這樣每個(gè)層級(jí)來(lái)分的，比如說(shuō)CentOS，然后所有的Mesos，Java，PHP，整個(gè)鏡像大概是700M。如果一個(gè)鏡像700M，當(dāng)整個(gè)一千臺(tái)集群開(kāi)始拉這個(gè)鏡像的時(shí)候，它是相當(dāng)大的帶寬，多機(jī)房鏡像倉(cāng)庫(kù)是扛不住的。主要Docker鏡像放置操作系統(tǒng)VM鏡像，使只有代碼部分或者你的配置變更部分，在拉取鏡像時(shí)變更。利用的就是Docker鏡像分層機(jī)制。

?

?

回到上面，我們創(chuàng)建一臺(tái)VM的時(shí)候，配置所需要的環(huán)境和軟件，構(gòu)建快照，這些快照基本上把所需要的鏡像先預(yù)放到操作系統(tǒng)里面，然后設(shè)置你的磁盤(pán)分區(qū)、機(jī)器權(quán)限及自定義的啟動(dòng)腳本，進(jìn)行預(yù)設(shè)。下邊一步是初始化，一般是在內(nèi)網(wǎng)Puppet，阿里云上用的Ansible。然后用這些內(nèi)網(wǎng)工具做初始化，我希望通過(guò)初始化把這個(gè)版本、把Swarm、Mesos這些組件進(jìn)行啟動(dòng)。初始化完成以后，代表你是一個(gè)可運(yùn)行的調(diào)度資源調(diào)度環(huán)境。關(guān)于Ansible大家知道有很多坑，包括性能非常差。一臺(tái)Ansible配完能達(dá)到30、40臺(tái)的規(guī)模，我們把它源碼做了一些改造，包括一些初始化的穩(wěn)定性和速度優(yōu)化。

?

?

綜上說(shuō)，我們通過(guò)了一個(gè)VM的鏡像加初始化，利用Docker鏡像體系打造了一個(gè)標(biāo)準(zhǔn)化的運(yùn)行平臺(tái)，不同語(yǔ)言或者不同的跨云、跨業(yè)務(wù)都可以在這個(gè)Docker環(huán)境中進(jìn)行動(dòng)態(tài)調(diào)度。

?

?

我們的內(nèi)網(wǎng)有自己的鏡像倉(cāng)庫(kù)，版本是V1到V2，存儲(chǔ)是Ceph。在內(nèi)網(wǎng)所有的業(yè)務(wù)端上傳鏡像之后會(huì)自動(dòng)同步到公有云或者同步到不同的機(jī)房，這樣避免跨IDC之間的帶寬傳送太大。阿里云上為鏡像Mirror的緩存，隨時(shí)進(jìn)行同步，節(jié)省了拉鏡像的時(shí)間。其實(shí)整個(gè)容器啟動(dòng)是非常快的，但是遇到大鏡像存在一兩分鐘無(wú)法拉去現(xiàn)象。鏡像倉(cāng)庫(kù)最大的瓶頸其實(shí)是帶寬，千兆網(wǎng)卡如果沒(méi)達(dá)到瓶頸，你會(huì)看到它很正常；如果達(dá)到瓶頸，它會(huì)達(dá)到一個(gè)峰值惡化，性能急劇下滑。同時(shí)我們做了一些優(yōu)化，包括鏡像倉(cāng)庫(kù)根據(jù)擴(kuò)容臺(tái)數(shù)，比如擴(kuò)一千臺(tái)可能按比例自動(dòng)擴(kuò)容鏡像倉(cāng)庫(kù)，支持動(dòng)態(tài)擴(kuò)展。

?

?

最后簡(jiǎn)單說(shuō)一下公有云上有一個(gè)網(wǎng)絡(luò)，就是微博內(nèi)網(wǎng)聯(lián)通電信兩大機(jī)房之后，通過(guò)兩根端線，比如阿里云的A區(qū)和C區(qū)進(jìn)行打通、專線互聯(lián)打通，同時(shí)構(gòu)建了一個(gè)VPN網(wǎng)絡(luò)，這個(gè)VPN網(wǎng)絡(luò)是走公網(wǎng)的，性能要求不高可以走VPN網(wǎng)絡(luò)，當(dāng)然兩個(gè)專線之間是互備的，比如這根斷了之后，它會(huì)自動(dòng)進(jìn)行路由切換，走這條線路，保證網(wǎng)絡(luò)的高可用。

彈性調(diào)度

?

?

接下來(lái)介紹拿到一個(gè)物理主機(jī)之后怎么樣建成一個(gè)可動(dòng)態(tài)調(diào)度的Docker環(huán)境，首先說(shuō)一下彈性調(diào)度。其實(shí)彈性調(diào)度基本上離不開(kāi)今天提的三個(gè)主題，Swarm、Mesos和K8S。我們?cè)谟玫臅r(shí)候也做了很多調(diào)研，也糾結(jié)于選型，最后選擇了Swarm，我們又自研了一些容器編排的工具。我們的需求其實(shí)很復(fù)雜，包括跨池調(diào)度、指定歸還、單機(jī)業(yè)務(wù)的灰度、多實(shí)例的部署、故障的自動(dòng)恢復(fù)、還有一些定制的調(diào)度算法、容器的監(jiān)控、評(píng)估，跨IP調(diào)度等等。其實(shí)我們要實(shí)現(xiàn)的需求就是快速迭代，實(shí)現(xiàn)內(nèi)網(wǎng)計(jì)算資源的統(tǒng)一管理，公有云上獲取計(jì)算資源，快速進(jìn)行部署。結(jié)果發(fā)現(xiàn)上面任何一個(gè)調(diào)度框架拿來(lái)直接用的都是不好用的，所以我們?cè)谏厦孀隽烁脑?#xff0c;就是對(duì)調(diào)度框架進(jìn)行了一個(gè)封裝。它接受編排層的一個(gè)任務(wù)調(diào)度體系，告訴你不同的IDC、不同的服務(wù)，然后你的調(diào)度策略是怎么樣的，根據(jù)你所要的資源、你所要的數(shù)量來(lái)下發(fā)。分幾種模式，現(xiàn)在主要線上跑的有直接DockerDaemon的管理，以及Swarm、Mesos。Mesos將來(lái)預(yù)期管理離線存儲(chǔ)業(yè)務(wù)，其實(shí)就是把它整個(gè)生態(tài)體系進(jìn)行封裝。我們做了自定義調(diào)度框架，還有資源的管理，特別是資源的編排和管理、容量的評(píng)估、監(jiān)控報(bào)警基本上都在這一層來(lái)完成。

?

?

因?yàn)楣δ芏?#xff0c;所以生產(chǎn)池的環(huán)境中有很多坑的問(wèn)題。Swarm的架構(gòu)基本上是業(yè)界很通用的CS的模式，Client節(jié)點(diǎn)向Master進(jìn)行匯報(bào)，這里面有一個(gè)資源注冊(cè)中心，我們用的是Consul，向Consul進(jìn)行注冊(cè)，Master通過(guò)Consul拿到節(jié)點(diǎn)信息后通過(guò)Http請(qǐng)求與client通信管理。之前早期的版本，Swarm性能非常差，因?yàn)樗掳l(fā)命令之后，任何命令會(huì)有一個(gè)全局鎖，現(xiàn)在已改為分步式鎖，性能比較高。整體來(lái)說(shuō)，它的性能還是比較好的。單個(gè)集群節(jié)點(diǎn)，單個(gè)IDC，其實(shí)管最大的一千+節(jié)點(diǎn)是沒(méi)有問(wèn)題的。現(xiàn)在Swarm應(yīng)該有了一個(gè)高可用的版本，當(dāng)時(shí)我們做了基于Consul的一個(gè)多IDC的高可用、可擴(kuò)展的機(jī)制。

?

?

為什么微博當(dāng)時(shí)選擇Swarm？因?yàn)樗?jiǎn)單，是Docker原生，滿足微博跨服務(wù)池一些編排或者一些抽象多租戶的需求。因?yàn)楫?dāng)時(shí)K8S只能管理容器化，微博后期還有一些離線的業(yè)務(wù)想去做，所以就沒(méi)有選K8S。Mesos，現(xiàn)在也是簡(jiǎn)單管理一些非容器。

?

?

Swarm的調(diào)度策略基本上分為兩個(gè)部分，第一個(gè)部分是主機(jī)、容器的過(guò)濾加上策略的選擇。拿到一定資源之后，過(guò)濾基本上就是健康性的過(guò)濾，容器這個(gè)節(jié)點(diǎn)是死還是活，還有約束條件，就是DockerDeamon打標(biāo)簽。給這些容器打這個(gè)標(biāo)簽，它就只能這個(gè)范圍之內(nèi)進(jìn)行容器管理，比如不同的服務(wù)池，手機(jī)微博的服務(wù)池、PC端的服務(wù)池啊、不同業(yè)務(wù)的服務(wù)池進(jìn)行隔離，隔離之后，比如只要找手機(jī)微博的服務(wù)池進(jìn)行容器管理。同時(shí)還有一些親和性的管理、依賴性的管理，還有端口的管理。通過(guò)這些約束性條件之后，會(huì)根據(jù)各個(gè)節(jié)點(diǎn)的CPU或內(nèi)存運(yùn)行狀況包括它的過(guò)濾策略選出來(lái)、剔除掉資源不足的主機(jī)，然后進(jìn)行打分，比如對(duì)一千個(gè)節(jié)點(diǎn)進(jìn)行打分。打分之后，然后進(jìn)行策略選擇。其實(shí)就是在同等條件下，是選擇資源使用最多的節(jié)點(diǎn)，還是選擇容器用得多的節(jié)點(diǎn)，還是容器用得少的節(jié)點(diǎn)，還是隨機(jī)進(jìn)行選擇，其實(shí)整個(gè)Swarm調(diào)度策略就這么簡(jiǎn)單。然后調(diào)度的粒度基本上就是內(nèi)存和CPU。

?

?

其實(shí)調(diào)度代碼最核心的不像Mesos那種選舉策略或者其他，它的策略比較簡(jiǎn)單，你可以看使用的資源，占的比例，進(jìn)行打分。當(dāng)所有有CPU資源和內(nèi)存資源都同時(shí)滿足的時(shí)候，那就證明資源是可以用的。它的策略很簡(jiǎn)單，就是把兩個(gè)分加起來(lái)，這就是它的調(diào)度算法。如果大家有更復(fù)雜的一些資源調(diào)度框架，我不建議用Swarm，它支持得不太好，當(dāng)然對(duì)內(nèi)存和CPU這種限制，是可以滿足我們需求的。還有一個(gè)坑就是它的資源創(chuàng)建只與容器create時(shí)的配置有關(guān)，與運(yùn)行時(shí)實(shí)際使用的資源情況無(wú)關(guān)。比如第一次啟動(dòng)的時(shí)候用Swarm配置了8G，但其實(shí)只使用了2G，最后的算法是永遠(yuǎn)認(rèn)為它用了8G，它在Cgroup文件里面進(jìn)行了限制，與實(shí)際使用時(shí)無(wú)關(guān)，只有容器啟動(dòng)的時(shí)候與它分到的資源數(shù)有關(guān)系。

動(dòng)態(tài)調(diào)度那一塊，微博整合了Mesos、Swarm包括DockerDeamon直接下發(fā)，，現(xiàn)在服務(wù)器單機(jī)或者是按批次來(lái)上線的時(shí)候，我們會(huì)有Docker deamon下發(fā)的策略。對(duì)分布式調(diào)度框架進(jìn)行封裝，包括SwarmMaster高可用、多機(jī)房的自動(dòng)適配、容器資源評(píng)估、容器資源監(jiān)控，這都是我們的動(dòng)態(tài)調(diào)度需要做的東西。

編排與實(shí)現(xiàn)

?

簡(jiǎn)單說(shuō)一下服務(wù)編排，剛才三駕馬車底層和主機(jī)層講完之后，然后進(jìn)入資源調(diào)度，上面就是服務(wù)的編排。服務(wù)之間的依賴、容器之間的依賴很多都在服務(wù)編排層去做，當(dāng)然我們沒(méi)用Compose或者其它一些組件來(lái)用，因?yàn)閳?chǎng)景更復(fù)雜無(wú)法滿足。我們?cè)诰幣艑幼约憾x進(jìn)行解決，用編排層的工具進(jìn)行解決。內(nèi)網(wǎng)的共享池加上公有云組成一個(gè)共享池，大家從共享池來(lái)拿資源。當(dāng)然，也會(huì)按照不同的服務(wù)池進(jìn)行切分。整個(gè)流程的發(fā)起是在編排層，它會(huì)向調(diào)度層發(fā)起，調(diào)度層如果有資源就進(jìn)行資源調(diào)度，如果沒(méi)有資源的進(jìn)行資源申請(qǐng)，然后初始化，服務(wù)上線。

拿一個(gè)現(xiàn)實(shí)的例子來(lái)說(shuō)，如何申請(qǐng)阿里云機(jī)器。這是阿里云的機(jī)房，三個(gè)機(jī)房，選擇哪個(gè)交換機(jī)，16核16G要一百臺(tái)，這是剛才定義的VM鏡像，就是操作系統(tǒng)鏡像。選擇16核16G內(nèi)存，創(chuàng)建100臺(tái)的機(jī)器，這樣就有了100臺(tái)物理機(jī)。當(dāng)然，你可以向內(nèi)網(wǎng)私有云進(jìn)行創(chuàng)建。如果沒(méi)有資源其實(shí)要資源申請(qǐng)，向共享池發(fā)起申請(qǐng)，申請(qǐng)之后會(huì)入到Buffer池，Buffer池進(jìn)行初始化。這個(gè)初始化要實(shí)時(shí)生成報(bào)告來(lái)告訴你失敗，然后實(shí)時(shí)重試。一切就是自動(dòng)的，有一個(gè)初始化報(bào)告。初始化完成之后，還有一個(gè)實(shí)用的經(jīng)驗(yàn)就是大家不要把自己的容器類型或者容器的資源類型切割的力度太散，微博基本上是定一個(gè)通用的標(biāo)準(zhǔn)，運(yùn)維的復(fù)雜度一下子降低了，比如dP01、dP02、dP03、dP04，基本上按照業(yè)務(wù)來(lái)分四到五種類型就可以了。容器的類型越復(fù)雜，資源管理就越復(fù)雜。我們也很簡(jiǎn)單，這是微博的RPC服務(wù)，這是Web服務(wù)，后面還有一個(gè)類型是緩存服務(wù)，按照不同的業(yè)務(wù)進(jìn)行容器的劃分。你的業(yè)務(wù)通過(guò)調(diào)度下發(fā)給我，我就知道要的是這種容器類型，我給你編排，盡量減少用戶自定義的數(shù)量，減少用戶使用復(fù)雜度。對(duì)每個(gè)任務(wù)來(lái)說(shuō)，我們會(huì)有一個(gè)整體的任務(wù)監(jiān)控，然后實(shí)施成功、失敗都可以提示，包括剛才說(shuō)的整個(gè)初始化、包括服務(wù)發(fā)現(xiàn)，都會(huì)有任務(wù)框管理。任務(wù)的耗時(shí)，也會(huì)進(jìn)行監(jiān)控。

?

?

這個(gè)圖是整個(gè)流程，一鍵擴(kuò)容，管理員向混合云平臺(tái)發(fā)起，第一步進(jìn)行資源的評(píng)估，然后根據(jù)你的配額，向公有云和內(nèi)網(wǎng)的私有云進(jìn)行拉資源。如果資源獲取到進(jìn)行初始化，初始化完畢發(fā)起容器調(diào)度，通過(guò)Swarm或者通過(guò)我們自己的調(diào)度框架進(jìn)行調(diào)度。調(diào)度完之后進(jìn)行容器的啟動(dòng)、服務(wù)的部署，服務(wù)的部署之后進(jìn)行服務(wù)發(fā)現(xiàn)。我們?cè)诿總€(gè)容器里面還有一個(gè)運(yùn)維，業(yè)務(wù)上分為兩個(gè)容器，一個(gè)是業(yè)務(wù)容器，一個(gè)是運(yùn)維容器，運(yùn)維容器的組件就是把監(jiān)控的組件進(jìn)行推送，推送到日志中心，生成一些監(jiān)控?cái)?shù)據(jù)。同時(shí)要機(jī)器進(jìn)行創(chuàng)建，你的業(yè)務(wù)監(jiān)控隨時(shí)可以馬上監(jiān)控到。

?

?

現(xiàn)在說(shuō)一下比較重要的服務(wù)發(fā)現(xiàn)，容器啟動(dòng)的流量怎么過(guò)的，就是容器編排。容器編排其實(shí)是一個(gè)大的概念，因?yàn)樵趺礃涌鏘DC、跨機(jī)房，不同的服務(wù)池你怎么樣更快更便捷的進(jìn)行服務(wù)發(fā)現(xiàn)。這是微博的，當(dāng)然微博是有內(nèi)網(wǎng)機(jī)房和阿里云的機(jī)房，有不同的服務(wù)，如何快速的服務(wù)發(fā)現(xiàn)。簡(jiǎn)單說(shuō)一點(diǎn)業(yè)界比較通用的就是NginxReload，當(dāng)然你在大機(jī)房情況下可以驗(yàn)證一下，它會(huì)有10%的性能損耗。大家可以看這個(gè)開(kāi)源地址https://github.com/weibocom/nginx-upsync-module，是基于Consul的自動(dòng)服務(wù)發(fā)現(xiàn)。因?yàn)槭褂萌萜?#xff0c;你的變更肯定會(huì)非常頻繁，降低它的性能損耗上，服務(wù)發(fā)現(xiàn)也是很重要的一個(gè)方面。還有一個(gè)特點(diǎn)是公有云上它會(huì)有20%的性能差，同樣內(nèi)網(wǎng)是16核16G或者你的容器資源是16核16G，但是如果你用阿里云或者你用公有云資源的話，它會(huì)有20%的性能差，盡量讓你在服務(wù)化進(jìn)行配置的時(shí)候把你的權(quán)重調(diào)低。比如公有云上整體權(quán)重為20，權(quán)重調(diào)為16，這樣才能達(dá)到你的性能和內(nèi)網(wǎng)是一致的，和你自己的宿主機(jī)是一致的權(quán)重。

RPC服務(wù)大家也知道了，這是Motan的RPC框架，它是支持跨IDC的服務(wù)發(fā)現(xiàn)，也支持按權(quán)重、按機(jī)房來(lái)自動(dòng)調(diào)配。

?

?

春晚要保證整個(gè)體系沒(méi)有問(wèn)題，還得從整體的運(yùn)維架構(gòu)上包括監(jiān)控體系、容量評(píng)估、干預(yù)手段，微博都有一個(gè)完整手段進(jìn)行解決。監(jiān)控基本上分為四類，一個(gè)是作戰(zhàn)類監(jiān)控，就是云上的服務(wù)器數(shù)，包括你的容器數(shù)量、專線帶寬、實(shí)時(shí)容量。實(shí)時(shí)報(bào)警類的是接口監(jiān)控，超過(guò)閾值就會(huì)報(bào)警。監(jiān)控類，我們會(huì)有QPS監(jiān)控、平均耗時(shí)、4XX和5XX。問(wèn)題節(jié)點(diǎn)監(jiān)控有單機(jī)的slow、資源slow、分布耗時(shí)，這些基本上都是可以認(rèn)為單機(jī)和單容器的一個(gè)slow，是對(duì)容器進(jìn)行單機(jī)和整體的監(jiān)控。整體的一個(gè)監(jiān)控體系，微博是把一些業(yè)務(wù)日志進(jìn)行掛載到硬盤(pán)，然后通過(guò)logtailer推到一個(gè)日志中心，日志中心進(jìn)行收斂計(jì)算之后通過(guò)Graphite的展示，沒(méi)有特別針對(duì)容器監(jiān)控組件，是把業(yè)務(wù)日志進(jìn)行落地，推動(dòng)監(jiān)控中心進(jìn)行監(jiān)控，生成監(jiān)控頁(yè)面。

很重要的幾點(diǎn)，大家一定要對(duì)單機(jī)容器或者是總體監(jiān)控，因?yàn)樵诠性频臅r(shí)候，它會(huì)有一些超買(mǎi)問(wèn)題，你不確定哪個(gè)容器會(huì)發(fā)生問(wèn)題的，所以你可能開(kāi)一百臺(tái)有二十臺(tái)容器莫名會(huì)有問(wèn)題，單機(jī)性能的惡化也會(huì)很嚴(yán)重的，大家一定要把監(jiān)控做到這種力度，這樣方便問(wèn)題排查。錯(cuò)誤響應(yīng)是多少，超過(guò)一個(gè)閾值，我們會(huì)把這個(gè)容器進(jìn)行自動(dòng)摘掉。容量評(píng)估系統(tǒng)，就是根據(jù)你單容器的平均系統(tǒng)指標(biāo)包括你的QPS業(yè)務(wù)指標(biāo)，這都可以自動(dòng)進(jìn)行設(shè)置進(jìn)行，看你的線上，比如說(shuō)你可縮容多少臺(tái)、可擴(kuò)容多少臺(tái)。我剛才提到的這些縮容和擴(kuò)容，如果縮容就進(jìn)入共享池，擴(kuò)容就從共享池里面進(jìn)行容器的彈性調(diào)度，會(huì)有一個(gè)容量評(píng)估的決策。整體的干預(yù)手段基本上也有重啟、回滾、緊急上線、服務(wù)降級(jí)、封殺，包括流量切換，流量切換有跨IDC、跨服務(wù)池的，還有限流的一些數(shù)據(jù)修復(fù)，等等這些干預(yù)手段。這些干預(yù)手段其實(shí)有一些是帶容器級(jí)別的操作。

?

?

春晚實(shí)戰(zhàn)&總結(jié)

這些做完之后，再看一下春晚的整個(gè)實(shí)戰(zhàn)，基本流程是三分鐘機(jī)器創(chuàng)建，然后Ansible進(jìn)行初始化，Registry進(jìn)行拉鏡像，然后是預(yù)熱鏡像，進(jìn)行容器調(diào)度，包括服務(wù)發(fā)現(xiàn)。整個(gè)完成之后，大概是十分鐘。

?

?

這是一個(gè)微博內(nèi)部阿里云多機(jī)房的架構(gòu)，可能大家可以了解一點(diǎn)，這是微博內(nèi)網(wǎng)標(biāo)準(zhǔn)的一個(gè)前端機(jī)、隊(duì)列機(jī)，然后消息隊(duì)列、緩存、數(shù)據(jù)庫(kù)，然后在阿里云上同步有一個(gè)類似的架構(gòu)。

?

?

微博常規(guī)部署會(huì)在阿里云上部署、緩存。在正常情況下阿里云上=只有十到二十臺(tái)機(jī)器，但是在峰值流量的情況下我們立馬擴(kuò)到一千到兩千+的容器。容器進(jìn)行擴(kuò)容，主要是web服務(wù)器或者是RPC服務(wù)，然后我通過(guò)服務(wù)發(fā)現(xiàn)把流量引入。

?

?

大家可以看一下這個(gè)作戰(zhàn)圖，剛才我提到一個(gè)監(jiān)控?cái)?shù)量，包括服務(wù)池水位，包括服務(wù)池容量承載倍數(shù)、專項(xiàng)帶寬、各業(yè)務(wù)方占用帶寬、各服務(wù)池用的容器數(shù)量都會(huì)有一個(gè)實(shí)時(shí)的監(jiān)控進(jìn)行監(jiān)控。

?

?

最后說(shuō)一下微博遇到的一些問(wèn)題，比如阿里云部署，在公有云上部署緩存服務(wù)器的時(shí)候，會(huì)發(fā)現(xiàn)它的PPS經(jīng)常被打滿。阿里云的北京A區(qū)7W，C區(qū)10W+，當(dāng)你的PPS打滿之后，你的緩存或者服務(wù)會(huì)急劇下降。我們通過(guò)擴(kuò)容緩存來(lái)解決。還有一些莫名的機(jī)器性能差，這就依賴大流量高并發(fā)服務(wù)的時(shí)候你的單機(jī)監(jiān)控，要隨時(shí)發(fā)現(xiàn)，自動(dòng)把性能差服務(wù)平滑摘掉。還有一個(gè)剛才提到的在公有云上使用阿里云SLB負(fù)載均衡的時(shí)候，當(dāng)大流量大概4、5G的時(shí)候，大流量下肯定會(huì)把SLB打垮。此外，就是專線帶寬的時(shí)候，跨機(jī)房的時(shí)候要注意這些專線帶寬。

剛才講了整個(gè)DCP擴(kuò)容的一個(gè)流程，自動(dòng)擴(kuò)容、云平臺(tái)服務(wù)管理，DCP平臺(tái)優(yōu)勢(shì)可能是高并發(fā)、大流量的場(chǎng)景實(shí)際場(chǎng)景應(yīng)用，微博也會(huì)把我剛才所有講到的東西進(jìn)行開(kāi)源，就是DCP開(kāi)源項(xiàng)目，12月份也會(huì)開(kāi)源，到時(shí)候大家也可以一塊把它建得更好。

原文：新浪微博基于Docker的混合云架構(gòu)與應(yīng)用實(shí)踐

總結(jié)

以上是生活随笔為你收集整理的新浪微博基于Docker的混合云架构与应用实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。