我們是一家做生鮮電商的公司，從系統搭建初期，我們就採用微服務的架構，基於DEVOPS體系來不斷提高我們的交付的質量和效率， 
隨著業務和團隊規模的發展，服務逐漸進行拆分，服務之間的互動越來越複雜，目前整個微服務已經近幾十個應用模組， 
整體架構上包括負載均衡、API閘道器、基於dubbo的微服務模組、快取、佇列、資料庫等，目前整個叢集的資源利用率也沒有一個合理的規劃評估，虛擬機器上部署多個應用服務隔離性也存在問題，考慮到越來越多門店以及第三方流量的接入，需要考慮系統的快速的伸縮能力，而基於統一資源管理的Docker容器技術在這些方面有一些天然的優勢，並且和微服務架構、devops體系完美銜接。 
經過調研和對比，最終我們採用mesos作為底層資源的管理和排程，marathon作為docker執行的框架，配合zookeeper、consul、nginx作為服務註冊發現。目前已經有部分的核心業務已經平穩的執行在基於docker容器的mesos資源管理平臺上。

實現的主要功能特性

• 平滑與虛擬機器叢集共存，容器獨立IP，跨主機和遺留系統互通
• 實現無縫釋出(滾動釋出)，釋出過程不影響線上業務，平滑升級
• 應用健康檢查，快速擴容，升級，回退
• 服務自動註冊和發現，負載均衡

邏輯架構

部署架構

在釋出流程中，在釋出上線之前的環節是預釋出，預釋出環境驗證完成後進行打包，生成docker 映象和基於虛擬機器部署的應用部署包，push到各自對應的倉庫中，並打Tag。 
生產環境釋出過程中，同時釋出到Mesos 叢集和原有的虛擬機器叢集上，兩套叢集網路是打通的。

網路架構

在網路架構選型時，會考慮一下幾個原則 
1、一容器一IP 
2、多主機容器互聯，主機和容器互聯 
3、網路隔離、細粒度的ACL 
4、效能損耗低 
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
        }]

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

healthcheck.sh通過負載均衡呼叫HealthMonitor來獲取應用例項的監控狀態， 
HealthMonitor是我們的健康檢查中心，可以獲取應用例項的整個拓撲資訊。

容器監控、日誌

下圖是我們的整體平臺監控的體系架構 

監控平臺涵蓋了系統各個層面的指標體系，這塊後續單獨列章節詳細介紹。 
對於容器的監控，由於我們是採用mesos docker的容器資源管理的架構，因此採用mesos-exporter+Prometheus+grafana的監控方案，mesos-exporter的特點是可以採集 task 的監控資料，可以從task的角度來了解資源的使用情況，而不是一個一個沒有關聯關係的容器。mesos-exporter匯出mesos叢集的監控資料到prometheus，prometheus是一套監控報警、時序資料庫組合，提供了非常強大儲存和多維度的查詢，資料的展現統一採用grafana。

本文可自由轉載、引用，但需署名作者且註明文章出處。如轉載至微信公眾號，請在文末新增作者公眾號二維碼。

轉自:http://blog.csdn.net/yangbutao/article/details/68951933