《餐飲圈APP后端容器化實踐》要點：
本文介紹了餐飲圈APP后端容器化實踐，希望對您有用。如果有疑問，可以聯系我們。

項目介紹

簡單介紹一下餐飲圈項目規模,以及團隊配置,用以作為技術選型和實踐的參考條件.

餐飲圈介紹

餐飲圈是專注于餐飲行業社交,招聘的APP. 后端采用微服務的設計思想,將不同的業務放在不同服務中. 隨著業務的發展,目前后端服務有20多個.

容器化之前,采用的是傳統的負載均衡(阿里云負載均衡)、多臺服務器(阿里云ECS)、數據庫(阿里云RDS)模式.

團隊規模介紹

研發團隊3～5人,同時負責前端APP和后端的研發和運維.日常的開發流程采用敏捷開發的Scrum方法.

一個簡單的目標——不斷提升生產力

不斷提升生產力是促使團隊嘗試容器化后端的主要動力.

隨著后端服務的增多,在服務管理方面投入的時間增多, 團隊注意到用于發布,調試和監控服務的時間越來越多. 因為之前采用的是單一Tomcat運行所有服務,導致每一個服務的變更都需要重啟整個Tomcat. Tomcat也占用了大量的服務器內存.

于是,列出了希望提升的幾個點：

• 更簡化的發布部署方法
• 更靈活管理服務對資源的使用
• 更高效的管理服務器資源,實現快速彈性伸縮

基于以上三點,團隊開始考慮容器化后端,使用容器編排平臺來管理服務.

注意：容器化后端,并不是解決上面問題的唯一選擇.后來的實踐中也漸漸體會到,容器化后端是很重大的決定,改變的是整個后端的基礎架構.之所以沒有過多猶豫就選擇容器化方案,是因為團隊內有人熟悉容器,而且現有后端基礎架構相對簡單.

第一張架構總覽

項目后端在阿里云上,持久化存儲用的全部是阿里云的服務. 數據庫使用RDS, 圖片等靜態文件使用OSS, Redis使用云數據庫Redis,所以容器化過程不存在應用服務器有持久化數據的問題, 只需要保證容器平臺可以順利鏈接阿里云服務器即可.

注：應用服務器無狀態化是容器化之前很關鍵的點,如果應用服務器上存有數據,例如圖片、緩存等,需要先將這些數據轉移到云平臺的存儲服務中, 可以參考12 Factor App(https://12factor.net/zh_cn/)這篇文章.

下面是第一張架構總覽,簡單的從邏輯層面描述了容器化后的后端架構.

可以看到容器編排平臺是架構的核心,所以選擇一個適合的容器編排平臺是容器化后端的關鍵.

容器編排平臺的選擇

我們選擇了三個容器編排平臺作為備選方案：

• Docker Swarm
• Kubernetes
• Rancher

Docker Swarm作為Docker自家出品的容器編排服務,和Docker無縫連接,實施簡單,學習曲線平滑,了解Docker使用的程序員可以很容掌握.而且,阿里云容器服務也采用了Docker Swarm作為基礎.

Kubernetes,很多大廠用它實現了PaaS服務, 在企業級解決方案中Kubernetes也經常被采用作為PaaS平臺的基礎,可以側面體現出Kubernetes的可靠性,穩定性等優勢.作為Google自家集群管理工具的開源版本,Kubernetes有很高的呼聲.

Rancher相對于前兩個選擇,有著開箱即用的特性,提供了完整的UI控制臺.在集群管理方面有多種選擇,可以選擇Kubernetes,Docker Swarm來做容器編排. 但是因為國內相關實踐例子不多,很快就被從選項中去掉.

嘗試阿里云容器服務——Docker Swarm

第一個POC是在阿里云容器服務上做的,因為阿里云容器服務采用Docker Swarm基礎, 而且提供了一套完成的UI控制界面. 借助官方提供的文檔,一天內完成了三臺服務器節點的測試集群搭建,并發布了幾個測試服務.一切進行的很順利.第二天,陸續將全部服務都部署上去,并開始性能和壓力測試.

阿里云容器服務架構如下(來自官方文檔)：

第一個問題

在測試過程中,遇到了第一個問題,響應時間不穩定. 有些服務第一次請求響應時間在幾千毫秒到幾百毫秒波動, 并不穩定.

翻閱了路由部分的文檔,找到了請求如何在平臺內路由的示意圖如下：

可以看到Routing容器起到了服務發現和路由轉發的作用, 負載之后所有請求都會經過Routing容器. 容器內是HAProxy做請求轉發.

因為請求經過負載,又經過Routing容器,然后由虛擬網絡層在集群內轉發到提供服務的容器. 此過程,在請求到達服務容器之前都沒有日志可以跟蹤,始終無法知道延遲出現在哪一步.

再后來的實施中這個問題隨著增加服務容器實例的個數得到緩解,但是始終沒有找問題的根本原因(并不能排除應用層本身有的問題的可能).

雪崩

壓力測試過程中,集群出現了第一次雪崩,三個節點全部掉線,并且無法SSH登錄.

調查雪崩原因有兩個：

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

結論

優勢

 

• 阿里云容器服務,提供了類似Rancher的開箱即用的特性,只需要將云服務器配置到集群中就可以自動完成集群的部署. 并且可以通過控制臺界面,快速完成阿里云日志服務,云監控等功能的集成. 對于沒有專門運維人員的小團隊,能節省很多維護時間.
• Docker Swarm作為基礎架構,開發團隊學習曲線平滑,只需要掌握docker基本知識就可以上手使用.

有待解決的問題

 

• 集群使用的etcd作為一個外部服務獨立提供,對于用戶不可見,也不可控.
• 請求鏈路不完全透明,鏈路跟蹤有難度.
• 技術支持需要在群里喊. 當然群里管理員很負責,阿里云工程師都很專業,問題基本可以很快解決.但感覺技術支持的流程還不是太規范.

嘗試Kubernetes集群

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

對于剛剛接觸Kubernetes的人來說,這很有挑戰.

依然從三節點的測試集群開始,但馬上遇到了虛擬網絡層的問題, 在經典網絡模式下始終無法在集群內聯通虛擬網絡. 幾次嘗試未果后,轉移到VPC網絡,成功建立了集群,并打通了虛擬網絡.

集群成功運行——只是個開始

經過兩天的折騰,Kubernetes集群搭建完成. 但是還有很多東西需要完善, 控制臺UI界面、服務發現、日志、監控. 很顯然這些都不在Kubernetes的核心中. 所有都需要借助其他開源項目來搭建,需要投入更多的人力和時間去完善. 對于小團隊來說,希望將Kubernetes用于微服務架構的生產環境,挑戰很大.咨詢過一些前輩后,了解到在Kubernetes上部署Spring Cloud是一個用于微服務的選擇,但是并沒有繼續嘗試.

結論

優勢

Kubernetes優勢很多,比如大廠都在用, 社區很活躍. 但我們最終并沒有完整實踐Kubernetes,所以沒有辦法談對這些優勢的體會.

對于小團隊來說的挑戰

• 阿里云上部署需要了解很多Kubernetes的基礎組件,其中『虛擬網絡層』搭建挑戰很大.
• 如果希望用于生產環境,需要自行搭建高可用架構,并且搭建控制臺,服務發現, 日志等應用. (可以參考《在阿里云上部署生產級別Kubernetes集群》<https://yq.aliyun.com/articles/71037>了解部署高可用集群的方法,但文章中也沒有提到微服務相關的工具如何搭建)
• 微服務平臺相關組件都需要自行部署和配置.

選擇——阿里云容器服務

經過對兩個平臺的POC,我們最后選擇了提供了更多工具的阿里云容器服務作為容器化后端的方案.

對于小團隊來說,容器化是為了提高生產力,開始選擇容器編排平臺時,我們忽略了微服務平臺這個概念,將容器編排平臺等同于了微服務平臺. 在POC階段,逐漸認識到了兩者的不同,微服務平臺可以構建在容器編排平臺之上,也可以直接在云服務器上部署.

選擇阿里云容器服務,其實是選擇了一套微服務平臺,并不單單是Docker Swarm.

堅持容器化后端,也是因為基于Docker的DevOps可以不局限于某種后端技術,更靈活的隔離應用運行環境,和控制應用對資源的使用.

第二張 Architecture Overview

目前實施的架構總覽：

 

 

 

后記

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

最初我們希望通過容器化后端架構來實現提高生產力這一目標. 在技術選型的開始階段,“選擇一個適合的容器編排平臺”被定義為關鍵技術問題. 但隨著POC的深入,只選擇容器編排平臺并不能解決提高生產力的目標,甚至容器編排平臺本身并不能直接提高生產力,對于小團隊來說反而需要投入更多的人力去維護. 我們認識到, 對于一個3～5人的小團隊來說,我們更需要的是一套微服務治理平臺,這個平臺是建立在IT基礎架構之上的應用平臺.而容器編排平臺更像是IT基礎架構針對容器的一層抽象,并不能直接滿足小團隊提高生產力的目標. 下圖大概說明了,應用、微服務平臺、容器編排平臺、IT基礎架構的關系.

所以,在容器化后端技術選型的后半程,我們更多的考量的是如何選擇一個適合的微服務平臺.最后基于阿里云容器服務,實現了我們的后端容器化的第一階段. 因為Docker Swarm和Docker的無縫連接, 開發團隊并沒有花費太多精力去學習新的概念,快速的將發布運維一系列工具遷移到了容器上. 在一個月之內,保證日常業務變更的前提下,完成了后端容器化,實現了提高生產力的目標.

還沒做的事情

• 繼續調研微服務平臺
• 測試彈性伸縮

文章來自微信公眾號：Docker

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4117.html