《CaaS在微服務(wù)開發(fā)運(yùn)維中的最佳實(shí)踐》要點(diǎn)：
本文介紹了CaaS在微服務(wù)開發(fā)運(yùn)維中的最佳實(shí)踐，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

作者簡(jiǎn)介

李斌

阿里巴巴 高級(jí)技術(shù)專家

現(xiàn)在阿里云負(fù)責(zé)容器服務(wù)的開發(fā),在加入阿里之前在 IBM 工作多年,主要從事企業(yè)應(yīng)用以及云計(jì)算的研發(fā)和運(yùn)維.

前言

本文分享會(huì)有三個(gè)方面的內(nèi)容：

• 第一是單體應(yīng)用和微服務(wù),我們會(huì)討論在微服務(wù)當(dāng)中容器和容器技術(shù)提供什么的支持；
• 第二是容器即服務(wù)；
• 第三是容器即服務(wù)在微服務(wù)的開發(fā)運(yùn)維當(dāng)中起什么作用；

1、單體應(yīng)用和微服務(wù)

1.1 什么是單體應(yīng)用

談到微服務(wù),相對(duì)應(yīng)的就是單體應(yīng)用,單體應(yīng)用的抽象示例大家可以看這個(gè)照片.

單體應(yīng)用把所有的東西放在一起,內(nèi)部通過(guò)模塊調(diào)用完成所有的工作.好處就是上手非常快,上手快的好處就是變現(xiàn)也特別快,流量上的也非?？?

慢慢你發(fā)現(xiàn)單體應(yīng)用架構(gòu)上的問(wèn)題就出來(lái)了,這些問(wèn)題最大的情況就是自己內(nèi)部依賴特別強(qiáng)的情況下,升級(jí)維護(hù)都有很多的麻煩.這也是微服務(wù)需要解決的問(wèn)題,這背后的原因是什么,大家可能討論了很多.

大家也許聽說(shuō)過(guò)康維定律這個(gè)概念,系統(tǒng)的架構(gòu)上和組織架構(gòu)是一一映射的,你可以想象程序做得越好,公司發(fā)展越快,內(nèi)部組織架構(gòu)也會(huì)變化的很快,慢慢就會(huì)發(fā)生組織架構(gòu)和應(yīng)用架構(gòu)不匹配的情況.

這種情況會(huì)引起很多麻煩.康維定律并不是有好有壞,只是一個(gè)現(xiàn)實(shí),存在即合理,如果真的是想解決這個(gè)問(wèn)題,就是要專業(yè)人做專業(yè)的事情.

1.2 什么是微服務(wù)

有一篇文章討論微服務(wù)相關(guān)的概念,把一個(gè) Java 的應(yīng)用當(dāng)成像一個(gè) Unix 程序一樣,每個(gè)程序只做一件事情,做到最好.大的系統(tǒng)通過(guò)多個(gè)程序組合而成.這篇文章探討了一個(gè)在實(shí)際項(xiàng)目當(dāng)中怎樣把一個(gè) Java 應(yīng)用做到這一點(diǎn).

我的理解單體應(yīng)用就是把所有的雞蛋放在一個(gè)籃子里頭,這里一個(gè)籃子就是一個(gè)進(jìn)程.微服務(wù)就是把所有的雞蛋放在所有的籃子里頭,在這種情況下,微服務(wù)的好處直接解決了單體應(yīng)用的問(wèn)題,升級(jí)部署都會(huì)好很多.

但是問(wèn)題就馬上出來(lái)了,我們可以想像如果是你原來(lái)只有一個(gè)應(yīng)用要維護(hù),你的維護(hù)成本和你如果有一千個(gè)服務(wù),一萬(wàn)個(gè)服務(wù),維護(hù)的工作量差異會(huì)非常大,復(fù)雜性也非常大.

1.3 微服務(wù)神器Docker

Docker 能解決很多問(wèn)題,有應(yīng)用分發(fā)的一致性,保證應(yīng)用在中心各個(gè)環(huán)節(jié)里頭可是可以都使用的.

第二個(gè)解決了隔離性的問(wèn)題,如果你一個(gè)環(huán)節(jié)里頭很多個(gè)應(yīng)用,出現(xiàn)各種依賴的問(wèn)題以后很難解決,你維護(hù)的惡夢(mèng)就開始了,采用 Docker 技術(shù)后,一個(gè)節(jié)點(diǎn)可以跑多個(gè)容器,容器之間是隔離的.

容器鏡像作為一個(gè)標(biāo)準(zhǔn)打包格式,能夠分發(fā),作為一種服務(wù)部署和分發(fā)模式會(huì)非常好,我們可以用 Docker 做微服務(wù).

1.4 理想與現(xiàn)實(shí)

這張圖,我們想象的微服務(wù)像一個(gè)戰(zhàn)隊(duì)一樣,星戰(zhàn)重點(diǎn)描述的是駕駛員的勇氣,后面有一個(gè)支撐平臺(tái),如果沒(méi)有這個(gè)支撐平臺(tái),英雄就變成了無(wú)頭蒼蠅的一堆隕石飛來(lái)飛去.

我們?cè)谖⒎?wù)的實(shí)踐當(dāng)中碰到了非常多的問(wèn)題,怎么解決.我今天的題目就是用一個(gè)CaaS平臺(tái)解決微服務(wù)在做的過(guò)程當(dāng)中都有哪些事情.

1.5 微服務(wù)和Docker

有人問(wèn) Docker 到底做什么,本身 Docker 是一種打包的鏡像模式,并且是一種運(yùn)行的方式,能夠讓鏡像以一種標(biāo)準(zhǔn)方式在各個(gè)環(huán)節(jié)里跑,這是國(guó)外的調(diào)查,有很多公司把 Docker 作為自己云戰(zhàn)略的核心.

另外一個(gè)就是做微服務(wù), ?Docker 和微服務(wù)之間有一些千絲萬(wàn)縷的聯(lián)系,最后一個(gè)是 ?Devops,如果一旦有了容器了,把交付標(biāo)準(zhǔn)化了,就相當(dāng)于集裝箱標(biāo)準(zhǔn)化以后把物流標(biāo)準(zhǔn)化一樣,這就是如果咱們要用 Docker.

2、容器即服務(wù)CaaS

這是一個(gè) CaaS 圖,如果大家自己使用過(guò) Docker 的話,可能很多人覺(jué)得這個(gè)東西上手太容易了,我們用它來(lái)解決業(yè)務(wù)問(wèn)題就非常容易.

在自己的筆記本電腦上裝一個(gè) Docker 引擎,鏡像拉起來(lái)應(yīng)用就跑起來(lái)了,如果做一個(gè)簡(jiǎn)單的應(yīng)用鏡像,上手也非常容易.這會(huì)給大家造成一個(gè)很大的錯(cuò)覺(jué),就是 Docker 用在生產(chǎn)環(huán)境里頭是很容易的事情.

好多文章說(shuō) Docker ?遍地都是坑遍地都是雷,不是那么容易的事情.比如說(shuō)容器的調(diào)度、控制、監(jiān)控、服務(wù)發(fā)現(xiàn)、日志管理,甚至高可用,很多事情都要做,這實(shí)際上不是一個(gè)軟件分發(fā)的機(jī)制就能解決的了.

所以 CaaS 平臺(tái)出來(lái)的目標(biāo)就是,CaaS 平臺(tái)會(huì)讓用戶擺脫自己重新搭建這么一個(gè)平臺(tái)的難度,讓你專注于應(yīng)用本身,專注于應(yīng)用的發(fā)布和運(yùn)行.所以這張圖只是告訴大家如果一個(gè) CaaS 平臺(tái)大概會(huì)做什么事情,CaaS 平臺(tái)最好的解釋也是在網(wǎng)上大家可以看到的,就是構(gòu)建,然后發(fā)布和運(yùn)行.

2.1 實(shí)現(xiàn)Caas能提供哪些開發(fā)和運(yùn)維的支持

在微服務(wù)的實(shí)踐當(dāng)中,這個(gè) CaaS 到底能幫助做什么?

• 第一個(gè)是服務(wù)的發(fā)現(xiàn)和路由

原來(lái)的時(shí)候應(yīng)用之間互相調(diào)用的話可以用一個(gè)IP地址來(lái)互相鏈接,但是在云上,容器啟動(dòng)會(huì)非常快,也會(huì)消失遷移之類的,這是一個(gè)特性,不能假定IP地址永遠(yuǎn)在那,也不能假定這個(gè)服務(wù)的實(shí)例就某個(gè)特定的實(shí)例.

在這種情況下,最重要的就是服務(wù)發(fā)現(xiàn)機(jī)制,服務(wù)發(fā)現(xiàn)包括注冊(cè)的機(jī)制和服務(wù)的路由.一個(gè)請(qǐng)求,到底是讓哪個(gè)服務(wù)的實(shí)例來(lái)實(shí)現(xiàn),有兩類,一類是內(nèi)部的請(qǐng)求,一類是外面的請(qǐng)求進(jìn)來(lái)了,怎么路由到內(nèi)部的服務(wù).

• 第二是發(fā)布策略和彈性伸縮
  發(fā)布策略這件事情是上線最后一個(gè)環(huán)節(jié),我們知道現(xiàn)在已開發(fā)測(cè)試已經(jīng)自動(dòng)化了,真正上線的時(shí)候,可以很多發(fā)布策略可以選用.CaaS 平臺(tái)能不能提供這樣一些支持?用了容器以后大家看重的一個(gè)好處是能不能在業(yè)務(wù)量發(fā)生變化的時(shí)候進(jìn)行動(dòng)態(tài)的容器伸縮.
• 最后是服務(wù)管控和SLA

服務(wù)管控和SLA等下會(huì)介紹,這是不完全的列表,不是說(shuō)微服務(wù)當(dāng)中只有這些問(wèn)題,也不是說(shuō) CaaS 平臺(tái)只解決這些問(wèn)題,只不過(guò)拿這個(gè)平臺(tái)做一個(gè)例子,如果一個(gè) CaaS 平臺(tái)對(duì)微服務(wù)進(jìn)行支持,到底會(huì)支持成什么樣.

2.2 Routing Mesh

首先介紹服務(wù)發(fā)現(xiàn)服務(wù)路由以及相關(guān)的東西.在 Docker1.12,新出了一個(gè)很有意思的概念叫做 Routing ?Mesh,routing 就是路由,Mesh 就是人人為我我為人人的意思.

一個(gè)請(qǐng)求進(jìn)來(lái)以后會(huì)在每個(gè)節(jié)點(diǎn)上都會(huì)有一個(gè)類似路由器這樣一個(gè)東西,這個(gè)路由器的東西可以把請(qǐng)求分發(fā)到集群里面任何一個(gè)其他的節(jié)點(diǎn)上,這樣的好處就是不是一個(gè)集中式的東西,這有點(diǎn)像負(fù)載均衡,也有點(diǎn)像全員參與的負(fù)載平衡.如果 CaaS 平臺(tái)已經(jīng)用了 Docker1.12 天生就有這個(gè)能力了.

2.3 服務(wù)發(fā)現(xiàn)與負(fù)載均衡

如果有人說(shuō)現(xiàn)在還沒(méi)到 Docker1.12,那么可以通過(guò)一個(gè)內(nèi)部的負(fù)載均衡和服務(wù)發(fā)現(xiàn)結(jié)合起來(lái),完成兩件事情.一個(gè)是服務(wù)發(fā)現(xiàn)一個(gè)是負(fù)載均衡,外面的請(qǐng)求進(jìn)來(lái)以后,怎么定位后面的服務(wù)實(shí)例,請(qǐng)求是由誰(shuí)來(lái)完成的,這是發(fā)現(xiàn)服務(wù),可以理解為一個(gè)數(shù)據(jù)庫(kù).

后面所有的實(shí)例啟動(dòng)以后都會(huì)向發(fā)現(xiàn)服務(wù)報(bào)告一下我在這兒.我的IP地址等各種信息,路由器根據(jù)的負(fù)載把請(qǐng)求傳送到一個(gè)具體的服務(wù)實(shí)例上面,這本質(zhì)上講是負(fù)載均衡,實(shí)際上完成了服務(wù)發(fā)現(xiàn)的功能,這是一個(gè)比較容易理解的架構(gòu).

我們不喜歡用戶寫一段腳本自己編排運(yùn)維這些東西,所以我們說(shuō)在部署模板描述文件里能不能把這種東西描述出來(lái).

舉例,如果接觸過(guò) Docker 的會(huì)知道這是一個(gè) Docker 的部署模版,描述了一個(gè)服務(wù),這是鏡像,這些服務(wù)之間什么關(guān)系,如果沒(méi)有接觸過(guò) Docker,你就可以理解成這就是一個(gè)部署模板.

在部署模板中大家都知道是聲明式的,而不是編程式的,怎么樣用聲明式的方式描述剛才我說(shuō)的這些關(guān)系,這些關(guān)系就是說(shuō)現(xiàn)在已經(jīng)有了的這些基礎(chǔ)架構(gòu).

首先用戶寫的這個(gè)服務(wù),我對(duì)外的80端口被聲明成一個(gè)；其次就是自動(dòng)伸縮的能力,右邊兩個(gè)綠色的,我們真正用戶提交上來(lái)的服務(wù),啟動(dòng)的時(shí)候部署的時(shí)候直接起兩個(gè)實(shí)例.

還有就是 probe url,讓系統(tǒng)平臺(tái)怎么知道容器里的應(yīng)用是活著的,這里很簡(jiǎn)單直接訪問(wèn)80端口根目錄,只要是200我就是活著的,如果測(cè)試80端口沒(méi)反應(yīng),說(shuō)明應(yīng)用就死掉了,以后的流量就別往這兒來(lái)了.

我們不需要用戶自己寫一段腳本做配置,也不需要在服務(wù)上掛一個(gè)鉤子的東西,只需要一個(gè)聲明的方式表達(dá)我想要的結(jié)果.解決了在外面我服務(wù)發(fā)現(xiàn)的問(wèn)題,這個(gè)服務(wù)請(qǐng)求一旦進(jìn)來(lái)以后,我就到了后面就是一個(gè)負(fù)載均衡,從這個(gè)頁(yè)面可以看出一個(gè)很也意思的概念—架構(gòu)即代碼.

說(shuō)明：架構(gòu)即代碼—就是說(shuō)我描述的不是過(guò)程,我要描述的是最終結(jié)果,最終結(jié)果可以像代碼一樣被管理起來(lái),這里就反映出這樣的一些概念.

2.4 日志集中和分析

剛才是服務(wù)發(fā)現(xiàn)和服務(wù)路由的情況,如果用了 Docker 如果做了微服務(wù)以后,日志管理和監(jiān)控這件事情怎么做.原來(lái)如果有五臺(tái)十臺(tái)服務(wù)的時(shí)候,出了問(wèn)題自己上服務(wù)器上拉日志.自己也可以搭建一個(gè) ELK,主要解決的是集中的問(wèn)題.

作為容器服務(wù)平臺(tái),就要替用戶解決日志集中的問(wèn)題,把集中的的日志文件通過(guò)一個(gè)管道送給分析服務(wù),如果容器里應(yīng)用直接往標(biāo)準(zhǔn)輸出寫日志,系統(tǒng)會(huì)自動(dòng)把這些日志集中起來(lái).

如果應(yīng)用把日志寫到文件目錄里,這個(gè)能不能抓去呢?也可以,只要聲明一個(gè)日志目錄的一個(gè)標(biāo)簽,說(shuō)明日志在某某路徑之下,那么容器服務(wù)也會(huì)自動(dòng)把這些日志收集起來(lái).

日志收集好了,還要分析.日志的集中和分析方案非常多,假定用戶在應(yīng)用已經(jīng)有了自己的日志和監(jiān)控,是不是必須放棄掉原來(lái)的用系統(tǒng)的這個(gè)呢?不是, Docker 很重要的一點(diǎn)是生態(tài),有很多這樣的一些開源工具也可以完成這樣的任務(wù),都是可以和系統(tǒng)接起來(lái)的.

2.5 監(jiān)控與彈性伸縮

彈性伸縮這件事情實(shí)際上聽起來(lái)很高大上,但是實(shí)際上真正運(yùn)行起來(lái)有非常多的復(fù)雜性,這里展現(xiàn)的就是如何彈性伸縮,監(jiān)控系統(tǒng)會(huì)把所有的這些指標(biāo)都監(jiān)控起來(lái),包括容器的、虛擬機(jī)的、網(wǎng)絡(luò)的,還有其他的服務(wù)都監(jiān)控起來(lái).

定義一個(gè)策略,一旦某種情況發(fā)生以后需要做什么事情,也是用聲明的方式.上面第一句話的意思是平滑后的CPU利用率超過(guò)的70%后,可以按照按兩個(gè)容器的步長(zhǎng)增加的速度來(lái)擴(kuò)展.這里沒(méi)有指定下限,所以這個(gè)策略只漲不跌.

我們看這個(gè)圖,對(duì)請(qǐng)求處理上是分布在兩個(gè)不同的節(jié)點(diǎn)上的.云監(jiān)控發(fā)現(xiàn)CPU指標(biāo)達(dá)到了設(shè)定的閾值后會(huì)通知集群,集群的控制節(jié)點(diǎn)會(huì)起兩個(gè)容器.這兩個(gè)容器是平臺(tái)調(diào)度的,會(huì)選擇最合適的負(fù)載能力的節(jié)點(diǎn)去做,這個(gè)圖里面有兩個(gè)節(jié)點(diǎn),都有資源,所以這兩個(gè)新的容器就會(huì)被平均分配在這上面.

3、CaaS在微服務(wù)運(yùn)維開發(fā)中的作用

3.1 SLA保證

下面這塊對(duì)大家的影響平常顯示不出來(lái),如果出現(xiàn)問(wèn)題有巨大的作用,這就是 SLA 的保證. SLA 的意思就是作為一個(gè)服務(wù)提供商,怎么保證實(shí)現(xiàn)我說(shuō)的要做的一些業(yè)務(wù)指標(biāo)承諾,比如實(shí)現(xiàn)高可用.

• 自定義命令/HTTP等健康檢查
  再比如說(shuō)自定義的 HTTP 命令,定義負(fù)載均衡的時(shí)候,可以指定一個(gè)URL,表明容器里的服務(wù)是不是健康的.

  沒(méi)有這個(gè)功能的時(shí)候,系統(tǒng)只知道 Docker 這個(gè)容器是不是正常在跑,沒(méi)辦法判斷 Docker 里面的應(yīng)用是不是真的是活著的.自定義命令和 HTTP 這種方式是在 從Docker1.12 開始引入的.在這之前,阿里云的容器服務(wù)已經(jīng)實(shí)現(xiàn)了這個(gè)功能.

• 按照資源約束的調(diào)度和再平衡.
  資源約束的意思是這個(gè)應(yīng)用需要多少資源,根據(jù)資源約束來(lái)部署運(yùn)行容器.
• 節(jié)點(diǎn)故障自動(dòng)重調(diào)度

我們經(jīng)常碰到的一個(gè)問(wèn)題是容器是沒(méi)有狀態(tài)的,容器掛掉了,或者容器所在的節(jié)點(diǎn)掛掉了,另外一個(gè)容器起的時(shí)候要保證當(dāng)初掛的那些存儲(chǔ)要跟著遷移過(guò)去.

有的服務(wù)天生就喜歡和有的服務(wù)在一塊,比如說(shuō)一個(gè) Web 應(yīng)用就喜歡和數(shù)據(jù)庫(kù)服務(wù)待在一個(gè)節(jié)點(diǎn)上.有些服務(wù)天生不喜歡在一塊,假定做了一個(gè)數(shù)據(jù)庫(kù)主備別把它們放在一個(gè)節(jié)點(diǎn)上.

跨可用區(qū)調(diào)度意思是,假定我的應(yīng)用必須是高可用的,實(shí)例要分配在多個(gè)可用區(qū)中.這些要求也可以通過(guò)聲明的方式來(lái)描述,不用寫腳本.

3.2 微服務(wù)上線發(fā)布策略

最后一個(gè)是服務(wù)的發(fā)布策略,做 Devops,關(guān)注自動(dòng)化從頭到尾只是解決了第一步,第二步是部署,部署和上線發(fā)布的策略問(wèn)題.

我們知道新服務(wù)的第一次部署可能在公司創(chuàng)建的第一天就完成了,隨后每天都是在升級(jí)都是在發(fā)布,發(fā)布如果解決不好了,Devops 做的就是比較華而不實(shí)了.

現(xiàn)在業(yè)界有很多討論,我們到底有哪些發(fā)布策略,這是網(wǎng)上的一些圖：

• 有藍(lán)綠發(fā)布,老服務(wù)在這運(yùn)行著,部署新的服務(wù),我們稱之藍(lán)色服務(wù),服務(wù)起來(lái)了以后,不把流量切換到藍(lán)色服務(wù)上,驗(yàn)證藍(lán)色服務(wù),如果沒(méi)問(wèn)題了再切換過(guò)去,把綠色服務(wù)刪掉.

  在這個(gè)過(guò)程當(dāng)中只有短暫的一個(gè)流量切換的過(guò)程,這是藍(lán)綠發(fā)布,意思就是兩個(gè)集群的流量從零到百分之百,要么是零要么是百分之百.下面這個(gè)圖大家可能看不太清楚,跟這個(gè)很類似,這是老的這是新的服務(wù),這里面流量不是百分之百,應(yīng)該是5%或者是95%,意思是逐步切換,.

• 還有一種模式是金絲雀發(fā)布模式,正常老的服務(wù)都是粉色的,金絲雀是新版,叫金絲雀是因?yàn)樵诘V井里面,金絲雀對(duì)瓦斯特別敏感,稍微有點(diǎn)危險(xiǎn)信號(hào)就死掉了,我們先放一個(gè)金絲雀,如果代碼沒(méi)有問(wèn)題,就可以慢慢把所有的服務(wù)升級(jí)上去.
• 最后一個(gè)圖是AB測(cè)試,實(shí)際上是一種驗(yàn)證措施,假定新上線的頁(yè)面,我們需要檢驗(yàn)它的作用,可以把流量分成兩半,對(duì)于用戶來(lái)講看到的是同一個(gè)頁(yè)面,但是后面左右兩個(gè)不同的服務(wù),通過(guò)一段時(shí)間的觀察,看看同樣的流量情況下面,運(yùn)行的效果是不是都有變化.

所有的這些發(fā)布模式,在網(wǎng)上都有很多討論,也都有很多實(shí)踐,如果自己完全都是從頭搭也可以.但是如果里用了 CaaS 服務(wù),平臺(tái)應(yīng)該提供這些能力,你不用再自己搭了.所以說(shuō)在容器服務(wù)里面,Devops 最后環(huán)節(jié)里面最后這一公里給你解決了.

小結(jié)

這里我說(shuō)微服務(wù)是冰山一角,冰山下面實(shí)際是最大的一砣,分布式系統(tǒng)部署運(yùn)維,服務(wù)治理,還有一個(gè)我們剛才沒(méi)說(shuō)的應(yīng)用服務(wù)化改造.

這里總結(jié)一點(diǎn),我們看微服務(wù)冰山一角是非常亮的,但是底層的支持東西是非常重要也是非常大的,這是我們運(yùn)維人員要做的事情,也是一個(gè) CaaS 平臺(tái)想為運(yùn)維人員所能提供的一點(diǎn)幫助,這個(gè)幫助就是我剛才提到的六個(gè)方向.

文章來(lái)自微信公眾號(hào)：高效運(yùn)維

 

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4216.html