《餐飲圈APP后端容器化實(shí)踐》要點(diǎn)：
本文介紹了餐飲圈APP后端容器化實(shí)踐，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

項(xiàng)目介紹

簡(jiǎn)單介紹一下餐飲圈項(xiàng)目規(guī)模,以及團(tuán)隊(duì)配置,用以作為技術(shù)選型和實(shí)踐的參考條件.

餐飲圈介紹

餐飲圈是專注于餐飲行業(yè)社交,招聘的APP. 后端采用微服務(wù)的設(shè)計(jì)思想,將不同的業(yè)務(wù)放在不同服務(wù)中. 隨著業(yè)務(wù)的發(fā)展,目前后端服務(wù)有20多個(gè).

容器化之前,采用的是傳統(tǒng)的負(fù)載均衡(阿里云負(fù)載均衡)、多臺(tái)服務(wù)器(阿里云ECS)、數(shù)據(jù)庫(kù)(阿里云RDS)模式.

團(tuán)隊(duì)規(guī)模介紹

研發(fā)團(tuán)隊(duì)3～5人,同時(shí)負(fù)責(zé)前端APP和后端的研發(fā)和運(yùn)維.日常的開(kāi)發(fā)流程采用敏捷開(kāi)發(fā)的Scrum方法.

一個(gè)簡(jiǎn)單的目標(biāo)——不斷提升生產(chǎn)力

不斷提升生產(chǎn)力是促使團(tuán)隊(duì)嘗試容器化后端的主要?jiǎng)恿?

隨著后端服務(wù)的增多,在服務(wù)管理方面投入的時(shí)間增多, 團(tuán)隊(duì)注意到用于發(fā)布,調(diào)試和監(jiān)控服務(wù)的時(shí)間越來(lái)越多. 因?yàn)橹安捎玫氖菃我籘omcat運(yùn)行所有服務(wù),導(dǎo)致每一個(gè)服務(wù)的變更都需要重啟整個(gè)Tomcat. Tomcat也占用了大量的服務(wù)器內(nèi)存.

于是,列出了希望提升的幾個(gè)點(diǎn)：

• 更簡(jiǎn)化的發(fā)布部署方法
• 更靈活管理服務(wù)對(duì)資源的使用
• 更高效的管理服務(wù)器資源,實(shí)現(xiàn)快速?gòu)椥陨炜s

基于以上三點(diǎn),團(tuán)隊(duì)開(kāi)始考慮容器化后端,使用容器編排平臺(tái)來(lái)管理服務(wù).

注意：容器化后端,并不是解決上面問(wèn)題的唯一選擇.后來(lái)的實(shí)踐中也漸漸體會(huì)到,容器化后端是很重大的決定,改變的是整個(gè)后端的基礎(chǔ)架構(gòu).之所以沒(méi)有過(guò)多猶豫就選擇容器化方案,是因?yàn)閳F(tuán)隊(duì)內(nèi)有人熟悉容器,而且現(xiàn)有后端基礎(chǔ)架構(gòu)相對(duì)簡(jiǎn)單.

第一張架構(gòu)總覽

項(xiàng)目后端在阿里云上,持久化存儲(chǔ)用的全部是阿里云的服務(wù). 數(shù)據(jù)庫(kù)使用RDS, 圖片等靜態(tài)文件使用OSS, Redis使用云數(shù)據(jù)庫(kù)Redis,所以容器化過(guò)程不存在應(yīng)用服務(wù)器有持久化數(shù)據(jù)的問(wèn)題, 只需要保證容器平臺(tái)可以順利鏈接阿里云服務(wù)器即可.

注：應(yīng)用服務(wù)器無(wú)狀態(tài)化是容器化之前很關(guān)鍵的點(diǎn),如果應(yīng)用服務(wù)器上存有數(shù)據(jù),例如圖片、緩存等,需要先將這些數(shù)據(jù)轉(zhuǎn)移到云平臺(tái)的存儲(chǔ)服務(wù)中, 可以參考12 Factor App(https://12factor.net/zh_cn/)這篇文章.

下面是第一張架構(gòu)總覽,簡(jiǎn)單的從邏輯層面描述了容器化后的后端架構(gòu).

可以看到容器編排平臺(tái)是架構(gòu)的核心,所以選擇一個(gè)適合的容器編排平臺(tái)是容器化后端的關(guān)鍵.

容器編排平臺(tái)的選擇

我們選擇了三個(gè)容器編排平臺(tái)作為備選方案：

• Docker Swarm
• Kubernetes
• Rancher

Docker Swarm作為Docker自家出品的容器編排服務(wù),和Docker無(wú)縫連接,實(shí)施簡(jiǎn)單,學(xué)習(xí)曲線平滑,了解Docker使用的程序員可以很容掌握.而且,阿里云容器服務(wù)也采用了Docker Swarm作為基礎(chǔ).

Kubernetes,很多大廠用它實(shí)現(xiàn)了PaaS服務(wù), 在企業(yè)級(jí)解決方案中Kubernetes也經(jīng)常被采用作為PaaS平臺(tái)的基礎(chǔ),可以側(cè)面體現(xiàn)出Kubernetes的可靠性,穩(wěn)定性等優(yōu)勢(shì).作為Google自家集群管理工具的開(kāi)源版本,Kubernetes有很高的呼聲.

Rancher相對(duì)于前兩個(gè)選擇,有著開(kāi)箱即用的特性,提供了完整的UI控制臺(tái).在集群管理方面有多種選擇,可以選擇Kubernetes,Docker Swarm來(lái)做容器編排. 但是因?yàn)閲?guó)內(nèi)相關(guān)實(shí)踐例子不多,很快就被從選項(xiàng)中去掉.

嘗試阿里云容器服務(wù)——Docker Swarm

第一個(gè)POC是在阿里云容器服務(wù)上做的,因?yàn)榘⒗镌迫萜鞣?wù)采用Docker Swarm基礎(chǔ), 而且提供了一套完成的UI控制界面. 借助官方提供的文檔,一天內(nèi)完成了三臺(tái)服務(wù)器節(jié)點(diǎn)的測(cè)試集群搭建,并發(fā)布了幾個(gè)測(cè)試服務(wù).一切進(jìn)行的很順利.第二天,陸續(xù)將全部服務(wù)都部署上去,并開(kāi)始性能和壓力測(cè)試.

阿里云容器服務(wù)架構(gòu)如下(來(lái)自官方文檔)：

第一個(gè)問(wèn)題

在測(cè)試過(guò)程中,遇到了第一個(gè)問(wèn)題,響應(yīng)時(shí)間不穩(wěn)定. 有些服務(wù)第一次請(qǐng)求響應(yīng)時(shí)間在幾千毫秒到幾百毫秒波動(dòng), 并不穩(wěn)定.

翻閱了路由部分的文檔,找到了請(qǐng)求如何在平臺(tái)內(nèi)路由的示意圖如下：

可以看到Routing容器起到了服務(wù)發(fā)現(xiàn)和路由轉(zhuǎn)發(fā)的作用, 負(fù)載之后所有請(qǐng)求都會(huì)經(jīng)過(guò)Routing容器. 容器內(nèi)是HAProxy做請(qǐng)求轉(zhuǎn)發(fā).

因?yàn)檎?qǐng)求經(jīng)過(guò)負(fù)載,又經(jīng)過(guò)Routing容器,然后由虛擬網(wǎng)絡(luò)層在集群內(nèi)轉(zhuǎn)發(fā)到提供服務(wù)的容器. 此過(guò)程,在請(qǐng)求到達(dá)服務(wù)容器之前都沒(méi)有日志可以跟蹤,始終無(wú)法知道延遲出現(xiàn)在哪一步.

再后來(lái)的實(shí)施中這個(gè)問(wèn)題隨著增加服務(wù)容器實(shí)例的個(gè)數(shù)得到緩解,但是始終沒(méi)有找問(wèn)題的根本原因(并不能排除應(yīng)用層本身有的問(wèn)題的可能).

雪崩

壓力測(cè)試過(guò)程中,集群出現(xiàn)了第一次雪崩,三個(gè)節(jié)點(diǎn)全部掉線,并且無(wú)法SSH登錄.

調(diào)查雪崩原因有兩個(gè)：

• 沒(méi)有限制容器使用資源,導(dǎo)致容器過(guò)載后瞬間吃掉系統(tǒng)內(nèi)存 (參考阿里云文檔解決,https://help.aliyun.com/document_detail/26017.html).
• Tomcat官方鏡像并不能很準(zhǔn)確的計(jì)算出JVM的最大使用內(nèi)存是多少,導(dǎo)致服務(wù)容器過(guò)載后不斷重啟(具體解決辦法可參考這篇文).

結(jié)論

優(yōu)勢(shì)

 

• 阿里云容器服務(wù),提供了類似Rancher的開(kāi)箱即用的特性,只需要將云服務(wù)器配置到集群中就可以自動(dòng)完成集群的部署. 并且可以通過(guò)控制臺(tái)界面,快速完成阿里云日志服務(wù),云監(jiān)控等功能的集成. 對(duì)于沒(méi)有專門(mén)運(yùn)維人員的小團(tuán)隊(duì),能節(jié)省很多維護(hù)時(shí)間.
• Docker Swarm作為基礎(chǔ)架構(gòu),開(kāi)發(fā)團(tuán)隊(duì)學(xué)習(xí)曲線平滑,只需要掌握docker基本知識(shí)就可以上手使用.

有待解決的問(wèn)題

 

• 集群使用的etcd作為一個(gè)外部服務(wù)獨(dú)立提供,對(duì)于用戶不可見(jiàn),也不可控.
• 請(qǐng)求鏈路不完全透明,鏈路跟蹤有難度.
• 技術(shù)支持需要在群里喊. 當(dāng)然群里管理員很負(fù)責(zé),阿里云工程師都很專業(yè),問(wèn)題基本可以很快解決.但感覺(jué)技術(shù)支持的流程還不是太規(guī)范.

嘗試Kubernetes集群

雖然Kubernetes提供了在AWS等云上的部署的驅(qū)動(dòng),但是對(duì)于阿里云,目前并沒(méi)有集成進(jìn)去. 所以,我們參考了阿里云初揚(yáng)的《當(dāng) Kubernetes 遇到阿里云 之 快速部署1.6.1版本》(https://yq.aliyun.com/articles/73922)做POC.

對(duì)于剛剛接觸Kubernetes的人來(lái)說(shuō),這很有挑戰(zhàn).

依然從三節(jié)點(diǎn)的測(cè)試集群開(kāi)始,但馬上遇到了虛擬網(wǎng)絡(luò)層的問(wèn)題, 在經(jīng)典網(wǎng)絡(luò)模式下始終無(wú)法在集群內(nèi)聯(lián)通虛擬網(wǎng)絡(luò). 幾次嘗試未果后,轉(zhuǎn)移到VPC網(wǎng)絡(luò),成功建立了集群,并打通了虛擬網(wǎng)絡(luò).

集群成功運(yùn)行——只是個(gè)開(kāi)始

經(jīng)過(guò)兩天的折騰,Kubernetes集群搭建完成. 但是還有很多東西需要完善, 控制臺(tái)UI界面、服務(wù)發(fā)現(xiàn)、日志、監(jiān)控. 很顯然這些都不在Kubernetes的核心中. 所有都需要借助其他開(kāi)源項(xiàng)目來(lái)搭建,需要投入更多的人力和時(shí)間去完善. 對(duì)于小團(tuán)隊(duì)來(lái)說(shuō),希望將Kubernetes用于微服務(wù)架構(gòu)的生產(chǎn)環(huán)境,挑戰(zhàn)很大.咨詢過(guò)一些前輩后,了解到在Kubernetes上部署Spring Cloud是一個(gè)用于微服務(wù)的選擇,但是并沒(méi)有繼續(xù)嘗試.

結(jié)論

優(yōu)勢(shì)

Kubernetes優(yōu)勢(shì)很多,比如大廠都在用, 社區(qū)很活躍. 但我們最終并沒(méi)有完整實(shí)踐Kubernetes,所以沒(méi)有辦法談對(duì)這些優(yōu)勢(shì)的體會(huì).

對(duì)于小團(tuán)隊(duì)來(lái)說(shuō)的挑戰(zhàn)

• 阿里云上部署需要了解很多Kubernetes的基礎(chǔ)組件,其中『虛擬網(wǎng)絡(luò)層』搭建挑戰(zhàn)很大.
• 如果希望用于生產(chǎn)環(huán)境,需要自行搭建高可用架構(gòu),并且搭建控制臺(tái),服務(wù)發(fā)現(xiàn), 日志等應(yīng)用. (可以參考《在阿里云上部署生產(chǎn)級(jí)別Kubernetes集群》<https://yq.aliyun.com/articles/71037>了解部署高可用集群的方法,但文章中也沒(méi)有提到微服務(wù)相關(guān)的工具如何搭建)
• 微服務(wù)平臺(tái)相關(guān)組件都需要自行部署和配置.

選擇——阿里云容器服務(wù)

經(jīng)過(guò)對(duì)兩個(gè)平臺(tái)的POC,我們最后選擇了提供了更多工具的阿里云容器服務(wù)作為容器化后端的方案.

對(duì)于小團(tuán)隊(duì)來(lái)說(shuō),容器化是為了提高生產(chǎn)力,開(kāi)始選擇容器編排平臺(tái)時(shí),我們忽略了微服務(wù)平臺(tái)這個(gè)概念,將容器編排平臺(tái)等同于了微服務(wù)平臺(tái). 在POC階段,逐漸認(rèn)識(shí)到了兩者的不同,微服務(wù)平臺(tái)可以構(gòu)建在容器編排平臺(tái)之上,也可以直接在云服務(wù)器上部署.

選擇阿里云容器服務(wù),其實(shí)是選擇了一套微服務(wù)平臺(tái),并不單單是Docker Swarm.

堅(jiān)持容器化后端,也是因?yàn)榛贒ocker的DevOps可以不局限于某種后端技術(shù),更靈活的隔離應(yīng)用運(yùn)行環(huán)境,和控制應(yīng)用對(duì)資源的使用.

第二張 Architecture Overview

目前實(shí)施的架構(gòu)總覽：

 

 

 

后記

在容器化后端過(guò)程中到我們底在選擇什么

最初我們希望通過(guò)容器化后端架構(gòu)來(lái)實(shí)現(xiàn)提高生產(chǎn)力這一目標(biāo). 在技術(shù)選型的開(kāi)始階段,“選擇一個(gè)適合的容器編排平臺(tái)”被定義為關(guān)鍵技術(shù)問(wèn)題. 但隨著POC的深入,只選擇容器編排平臺(tái)并不能解決提高生產(chǎn)力的目標(biāo),甚至容器編排平臺(tái)本身并不能直接提高生產(chǎn)力,對(duì)于小團(tuán)隊(duì)來(lái)說(shuō)反而需要投入更多的人力去維護(hù). 我們認(rèn)識(shí)到, 對(duì)于一個(gè)3～5人的小團(tuán)隊(duì)來(lái)說(shuō),我們更需要的是一套微服務(wù)治理平臺(tái),這個(gè)平臺(tái)是建立在IT基礎(chǔ)架構(gòu)之上的應(yīng)用平臺(tái).而容器編排平臺(tái)更像是IT基礎(chǔ)架構(gòu)針對(duì)容器的一層抽象,并不能直接滿足小團(tuán)隊(duì)提高生產(chǎn)力的目標(biāo). 下圖大概說(shuō)明了,應(yīng)用、微服務(wù)平臺(tái)、容器編排平臺(tái)、IT基礎(chǔ)架構(gòu)的關(guān)系.

所以,在容器化后端技術(shù)選型的后半程,我們更多的考量的是如何選擇一個(gè)適合的微服務(wù)平臺(tái).最后基于阿里云容器服務(wù),實(shí)現(xiàn)了我們的后端容器化的第一階段. 因?yàn)镈ocker Swarm和Docker的無(wú)縫連接, 開(kāi)發(fā)團(tuán)隊(duì)并沒(méi)有花費(fèi)太多精力去學(xué)習(xí)新的概念,快速的將發(fā)布運(yùn)維一系列工具遷移到了容器上. 在一個(gè)月之內(nèi),保證日常業(yè)務(wù)變更的前提下,完成了后端容器化,實(shí)現(xiàn)了提高生產(chǎn)力的目標(biāo).

還沒(méi)做的事情

• 繼續(xù)調(diào)研微服務(wù)平臺(tái)
• 測(cè)試彈性伸縮

文章來(lái)自微信公眾號(hào)：Docker

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