Docker Mesos在生產環境的應用
我們是一家做生鮮電商的公司,從系統搭建初期,我們就採用微服務的架構,基於DevOps體系來不斷提高我們的交付的質量和效率, 隨著業務和團隊規模的發展,服務逐漸進行拆分,服務之間的交互越來越複雜,目前整個微服務已經近幾十個應用模塊, 整體架構上包括負載均衡、API網關、基於Dubbo的微服務模塊、緩存、隊列、資料庫等,目前整個集群的資源利用率也沒有一個合理的規劃評估,虛擬機上部署多個應用服務隔離性也存在問題,考慮到越來越多門店以及第三方流量的接入,需要考慮系統的快速的伸縮能力,而基於統一資源管理的Docker容器技術在這些方面有一些天然的優勢,並且和微服務架構、DevOps體系完美銜接。
經過調研和對比,最終我們採用Mesos作為底層資源的管理和調度,Marathon作為Docker執行的框架,配合ZooKeeper、Consul、Nginx作為服務註冊發現。目前已經有部分的核心業務已經平穩的運行在基於Docker容器的Mesos資源管理平台上。
實現的主要功能特性
平滑與虛擬機集群共存,容器獨立IP,跨主機和遺留系統互通
實現無縫發布(滾動發布),發布過程不影響在線業務,平滑升級
應用健康檢查,快速擴容,升級,回退
服務自動註冊和發現,負載均衡
邏輯架構
部署架構
在發布流程中,在發布上線之前的環節是預發布,預發布環境驗證完成後進行打包,生成Docker鏡像和基於虛擬機部署的應用部署包,push到各自對應的倉庫中,並打Tag。
生產環境發布過程中,同時發布到Mesos集群和原有的虛擬機集群上,兩套集群網路是打通的。
網路架構
在網路架構選型時,會考慮一下幾個原則:
一容器一IP
多主機容器互聯,主機和容器互聯
網路隔離、細粒度的ACL
性能損耗低
docker bridge使用默認的docker0網橋,容器有獨立的網路命名空間,跨主機的容器通信需要做埠NAT映射;Host的方式採用和宿主機一樣的網路命名空間,網路無法做隔離,等等這些方式有非常多的埠爭用限制,效率也較低。
Docker Overlay的方式,可以解決跨主機的通信,現有二層或三層網路之上再構建起來一個獨立的網路,這個網路通常會有自己獨立的IP地址空間、交換或者路由的實現。
Docker在1.9中libnetwork團隊提供了multi-host網路功能,能完成Overlay網路,主要有隧道和路由兩種方式, 隧道原理是對基礎的網路協議進行封包,代表是Flannel。
另外一種是在宿主機中實現路由配置實現跨宿主機的容器之間的通信,比如Calico。
Calico是基於大三層的BGP協議路由方案,沒有使用封包的隧道,沒有NAT,性能的損耗很小,支持安全隔離防護,支持很細緻的ACL控制,對混合雲親和度比較高。經過綜合對比考慮,我們採用calico來實現跨宿主機的網路通訊。
安裝好ETCD集群,通過負載均衡VIP方式(LVS+keepalived)來訪問ETCD集群。
ETCD_AUTHORITY=10.10.195.193:2379
export ETCD_AUTHORITY
構建Calico網路集群,增加當前節點到集群中,Calico 節點啟動後會查詢 Etcd,和其他 Calico 節點使用 BGP 協議建立連接。
./calicoctl node –libnetwork –ip=10.10.3.210
增加可用的地址池ip pool
./calicoctl pool add 10.4.10.0/24 –nat-outgoing
./calicoctl pool show
創建網路,通過Calico IPAM插件(Driver(包括IPAM)負責一個Network的管理,包括資源分配和回收),-d指定驅動類型為Calico,創建一個online_net的driver為Calico的網路:
docker network create -d calico –ipam-driver calico –subnet=10.4.10.0/24 online_net
啟動容器,網路指定剛才創建的online_net,容器啟動時,劫持相關 Docker API,進行網路初始化。 查詢 Etcd 自動分配一個可用 IP,創建一對veth介面用於容器和主機間通訊,設置好容器內的 IP 後,打開 IP 轉發,在主機路由表添加指向此介面的路由,宿主機10.10.3.210的路由表:
宿主機10.10.50.145的路由表:
容器包發送包的路由過程如上圖,宿主機10.10.3.210上的容器IP 10.4.10.64通過路由表發送數據包給另外一個宿主機10.10.50.145的容器10.4.10.55。
對於有狀態的資料庫,緩存等還是用物理機(虛擬機),來的應用集群用的是虛擬機,Docker容器集群需要和它們打通,做服務和數據的訪問交互。那麼只需要在物理機(虛擬機)上把當前節點加入容器網路集群即可:
ETCD_AUTHORITY=10.10.195.193:2379
export ETCD_AUTHORITY
./calicoctl node –ip=10.10.16.201
服務自註冊和發現
API網關提供統一的API訪問入口,分為兩層,第一層提供統一的路由、流控、安全鑒權、WAF、灰度功能發布等功能,第二層是Web應用層,通過調用Dubbo服務來實現服務的編排,對外提供網關的編排服務功能,屏蔽業務服務介面的變更;為了能夠快速無縫的實現web層快速接入和擴容,我們用Consul作為服務註冊中心實現Web服務的自動註冊和發現。
對於Web服務註冊,我們自己實現了Register,調用Consul的API進行註冊,並通過TTL機制,定期進行心跳彙報應用的健康狀態。
對於Web服務的發現,我們基於Netflix Zuul進行了擴展和改造,路由方面整合Consul的發現機制,並增加了基於域名進行路由的方式,對路由的配置功能進行了增強,實現配置的動態reload功能。API網關啟動定時任務,通過Consul API獲取Web服務實例的健康狀態,更新本地的路由緩存,實現動態路由功能。
平台的微服務框架是基於Dubbo RPC實現的,而Dubbo依賴ZooKeeper做服務的發現和註冊。
Consul在Mesos Docker集群的部署方案:
不建議把Consul Agent都和Container應用打包成一個鏡像,因此Consul Agent部署在每個Mesos Slave宿主機上,那麼Container如何獲取宿主機的IP地址來進行服務的註冊和註銷,容器啟動過程中,默認情況下,會把當前宿主機IP作為環境變數傳遞到Container中,這樣容器應用的Register模塊就可以獲取Consul代理的IP,調用Consul的API進行服務的註冊和卸載。
在日常應用發布中,需要保障發布過程對在線業務沒有影響,做到無縫滾動的發布,那麼在停止應用時應通知到路由,進行流量切換。
docker stop命令在執行的時候,會先向容器中PID為1的進程發送系統信號SIGTERM,然後等待容器中的應用程序終止執行,如果等待時間達到設定的超時時間,或者默認的10秒,會繼續發送SIGKILL的系統信號強行kill掉進程。這樣我們可以讓程序在接收到SIGTERM信號後,有一定的時間處理、保存程序執行現場,優雅的退出程序,我們在應用的啟動腳本中實現一段腳本來實現信號的接受和處理, 接收到信號後,找到應用的PID,做應用進程的平滑kill。見上面圖中的腳本。
應用的無縫滾動發布、宕機恢復
Marathon為運行中的應用提供了靈活的重啟策略。當應用只有一個實例在運行,這時候重啟的話,默認情況下Marathon會新起一個實例,在新實例重啟完成之後,才會停掉原有實例,從而實現平滑的重啟,滿足應用無縫滾動發布的要求。
當然,可以通過Marathon提供的參數來設置自己想要的重啟策略:
「upgradeStrategy」:{ 「minimumHealthCapacity」: N1, 「maximumOverCapacity」: N2 }
如何判斷新的實例是否啟動完成可以提供服務,或者當前容器的應用實例是否健康,是否實例已經不可用了需要恢復,Marathon提供了healthchecks健康監測模塊
"healthChecks": [{
"protocol": "COMMAND",
"command":{
"value":"sh /data/soft/healthcheck.sh app 10.10.195.193"
},
"gracePeriodSeconds": 90,
"intervalSeconds": 60,
"timeoutSeconds": 50,
"maxConsecutiveFailures": 3
}]
healthcheck.sh通過負載均衡調用HealthMonitor來獲取應用實例的監控狀態, HealthMonitor是我們的健康檢查中心,可以獲取應用實例的整個拓撲信息。
容器監控、日誌
下圖是我們的整體平台監控的體系架構。
監控平台涵蓋了系統各個層面的指標體系,這塊後續單獨列章節詳細介紹。
對於容器的監控,由於我們是採用Mesos Docker的容器資源管理的架構,因此採用mesos-exporter+Prometheus+Grafana的監控方案,mesos-exporter的特點是可以採集 task 的監控數據,可以從task的角度來了解資源的使用情況,而不是一個一個沒有關聯關係的容器。mesos-exporter導出Mesos集群的監控數據到Prometheus,Prometheus是一套監控報警、時序資料庫組合,提供了非常強大存儲和多維度的查詢,數據的展現統一採用Grafana。
TAG:程序源 |
※使用Kubespray部署生產可用的Kubernetes集群
※Tesla前生產總監跳槽同行對手Lucid Motors
※Elon Musk 已批准生產 Model Y 原型車
※魅族將與 Google 合作生產 Android Go 手機
※Louis Vuitton 將不會生產以 Michael Jackson 為靈感的 2019 秋冬系列單品
※iPad Pro對比Surface Pro 6,生產力如何
※【新鮮】碩果僅存的Wileyfox:我們會繼續生產銷售Windows Phone手機
※Chanel 投資綠色科技:液態蠶絲生產商 Evolved by Nature
※【蘋果】滿滿生產力的發布會 蘋果推出全新MacBook Air、iPad Pro及Mac Mini
※Urban Decay宣布不再生產Naked Palette眼影盤,還為它辦了個葬禮?
※如何在生產環境中部署Kubernetes集群?
※iPhone又要出新顏色,iPhone 6s Plus印度生產
※特斯拉 Model 3 加速生產,導致 Panasonic 電池短缺
※華燦持股Semicon Light成功生產出AR·VR用Micro LED面板
※iPhoneXR大規模延遲生產,富士康取締Pegatron
※別再笑iPad Pro沒生產力了,Adobe將為它推出完整版Photoshop
※推動環保纖維量產!H&M和宜家支持的 TreeToTextile與北歐紙張生產商 Stora Enso 達成合作
※詳解Github的.gitignore忽略文件+.gitignore不生效解決+生產配置
※adidas Originals 即將發售一個「從未生產」過的球鞋系列
※iPhoneXS/Max銷售滯後,蘋果恢復生產iPhoneX