【容器雲】傳統金融企業的 Docker 實踐

基於 Docker 的容器雲—Padis

目前市面上基於容器雲的產品有不少，對於平安而言，則是基於 Docker 的 Padis 平臺。所謂 Padis，全稱是 PingAn Distribution ——平安分佈式平臺。Padis 基於 Docker，實現了平安內部的一個分佈式平臺。它的實現採用了 Mesos+Marathon（下面簡稱MM） 框架，能夠完成應用程序的快速建立、運行、快速縮容擴容以及故障自愈的功能；平臺上實現了獨立 IP，能夠實現任何集羣與外部的或者傳統的 IP 的通信；平臺負載均衡的方式不少，能夠根據容器的動態變化（容器的增刪）作動態調整；平臺內還有獨立的域名解析，能夠作到 CMDB 和性能監控的動態更新。

Padis 的「成長」主要歷經如下幾個階段： 

1. 開發環境 Docker 單機版
2. 測試環境 Padis 上線
3. 生產環境 Padis 上線
4. Padis 承接平安金管家（原平安人壽App） 系統羣

下面是對每一個階段的詳細敘述。

開發環境 Docker 單機版

平安傳統的交付過程耗時很長。從需求發起，到資源申請，到中間件交互，這些過程往返不少，會耗費大量的人力和時間。而交付流程長，人力支配不足等緣由，會致使交付質量的降低。爲了解決交付所面臨的這一系列難題，Docker 就成爲了一種最初的嘗試方式。Docker 包含三方面內容（圖 1）：倉庫、鏡像、容器。倉庫這方面須要改進的很少，重點放在鏡像上面。 2014 年單機版的 Docker 上線，初版的 Padis 將 Docker 鏡像集成到 OS。

初版的 Padis 基於 Docker 和 Docker UI 。 當時的 Docker UI 改了不少的東西（圖 2），本來的 Docker UI 不帶倉庫管理，也沒有鏡像下載和鏡像提高的功能， 而更改後的 Docker UI，不只添加了 Commit 鏡像功能，還增長了倉庫管理功能，同時也支持定向搜索下拉或上傳。

圖 2

初版的 Padis 出來時，着手的重點就是定製化的鏡像。平安的業務系統很是多，中間件用的東西又比較標準化，因此定製化的主要方向就是標準的中間件怎麼去配，才能放到鏡像裏造成一個標準的東西，這個問題解決了，那麼當開發環境的鏡像可用時，該鏡像放入生產後依舊可用。此時，將應用包或中間件打包起來後就能夠快速啓動服務；若是要對這個環境進行復制，將原來環境進行拷貝就能夠。這樣一來，交付就能夠作到分鐘級別或者是秒級別。

可是，怎麼將中間件打到標準鏡像中，這又是一個問題。一個容器是有限制的，若是什麼東西都打進去，日誌會越寫越多，容器容量就會爆，容器默認大小隻有 10G。金融行業的日誌，它必需要落地、必需要存儲，有一些須要排查的問題若是沒有日誌就會很不方便，所以日誌必定要保留。而把應用都打到裏面去，開始時不會出現太大的問題，可是隨着第一個版本的發行，就出現一個讓人很不爽的問題：要對鏡像做調整，但是無需對應用的獨立鏡像進行更新。因此必需要將應用包和日誌所有挪走，只留下 OS 和 中間件固定配置和介質，纔可行。

由於須要根據一些用戶需求作調整，因此這個版本的 Padis 出來後在平安內部作了推廣並進行反饋收集。對所收集的信息進行整合，發現單機版的 Docker 存在不少缺陷：一是沒有集羣，不能解決跨 Host 之間的通信功能；二是沒有健康檢查機制，容器應用故障沒法自愈；三是沒有監控和統計信息，資源使用不可控；四是熟悉 Docker 命令的人很少，要去推廣使用很困難。公司中各類不一樣部門的人不少，每一個部門的關注重點不同，當一個部門裏的人根本不瞭解這是什麼的時候，是沒有辦法使用 Docker 的，所以必須作到界面化。因此後續又作了相應的調整，對於用戶必定要鏡像透明，並把 Docker 作成集羣模式。

對於集羣模式的選擇則作了兩個選項，下面先簡單介紹一下這兩種框架選項。

圖 3

其一是 k8S（圖 3 ），它基於 Go 語言開發，而且底層基於 CentOS。若是選用這個框架，首先在 Go 語言的學習成本上會耗費不少精力，再者，平安的底層基本是基於 Red Hat Linux ，因此要將 Red Hat Linux 和 CentOS 之間作轉換又是一個很複雜的問題。鑑於這兩個緣由，最後選用了 MM 框架，MM 框架解決了這兩個問題。

圖 4 

MM 框架（圖 4）結構簡單，而且是基於 Java 開發，開發人員佔比不少，選用 MM 框架，不只在上面能夠作不少的二次開發和接口，底層也能夠選用 Red Hat Linux。這些最基本的問題 MM 均可以解決。而服務器資源池化、容器應用關聯、故障自愈、資源隔離、事件驅動也是 MM 框架能夠解決的問題。

利用 Mesos 能夠實現資源池化，包括對後臺的資源進行配置、管理。容器應用關聯，能夠實現容器的動態伸縮。Marathon 框架自己會提供故障自愈這個功能，平安常常會作一個靜態的頁面，當使用 HTTP 協議訪問該頁面時，會返回一個設定好的字符串， 若是不是這個字符串，則會被認爲是訪問異常，此時就會將原有容器刪除，以後進行重啓。資源隔離是基於 Mesos 的資源管理所作的，在後臺物理機或者是虛擬機上打上標籤，當進行資源分配時，不一樣的資源天然就會落到其所對應的不一樣的服務器上。平安有不少保險公司，而監管的要求是必須進行物理隔離，所以要進行資源隔離。對於事件驅動而言，在 Marathon 作容器的任何起停時，都會同時在Marathon 有 event 生成，可將自身的 API sever 註冊到 Marathon 的 上 ，以後監聽全部的 event ，根據返回的全部 event 進行解析，並作一些相應的任務下發。
集羣模式的選擇肯定了，接下來就是如何解決跨 Host 之間的通信功能問題。平安存在一些歷史性的遺留問題，一是容器沒有獨立的 IP，沒法與容器集羣外面的服務器進行通信，當時採用的解決方案是作獨立 IP；二是因爲沒有 IP，因此也不存在 DNS ，這樣就沒法實現跨安全區域，平安的域名不少都是經過 DNS 作負載的，因此 DNS 不可或缺；其次是負載均衡和共享存儲的問題。下面是就獨立 IP 和 DNS 的解決方案詳述。

圖 5 

首先是關於獨立 IP 的幾個問題（圖5）：

EJB 邏輯，共享存儲，傳統的共享存儲使用的是 Nas，Nas 則基本上都須要用到獨立 IP 作二層進行對接 。
組播與 HA，不論兩個容器在不在同一個物理機上，都要保證它們之間的組播相通。
要與傳統環境對接，由於不能將全部系統都搬到平臺上面來。要與傳統環境進行對接，必須與平臺外的服務器應用作通訊，這就須要獨立 IP 。 
用戶操做習慣，用戶須要登陸主機查看日誌，配置等相關信息。所以不只要在物理機上登陸，也須要在容器上登陸，因此獨立 IP 也發揮了很大的做用。

圖 6.1

 

圖 6.2

圖 6.3

什麼是 EJB 邏輯？EJB 當中存在一個 Cluster 的概念（圖 6.1），假設 Cluster 中有三臺服務器，2.1 、2.2 、2.3 ，三臺服務器上都作了容器，當 Container 端對他們進行訪問時，首先都會經過 T3 地址來調用（這裏沒有域名，因此選用的是 IP，在三個 IP 裏隨機取一個，這裏取 192.168.2.1）。首先，會發出 EJB Create Request  請求（圖 6.1），以後 2.1 會返回一個集羣信息 Return Stub message （圖 6.2）給 Client，並告訴 Client 這個集羣中間有哪些服務器，以後 Client 這邊會再發出 EJB Channle Create 的請求（圖 6.3）， 此時無論集羣中有多少服務器，都會創建 EJB 長鏈接。

圖 7   

在 Padis 平臺的初始版本中，沒有獨立 IP，容器與外面通訊是基於端口 Mapping 的方式實現，這樣EJB 邏輯就會如上圖（圖 7）。這樣就出現了一個問題，假設容器裏的地址是私網 IP：172.17.0.2（外部不可見），而宿主主機的 IP 是 192.168.2.2，當請求發到這裏時，由於 172 的 IP 對外不可見，因此只可以鏈接到 192（物理機）的 IP ，再經過對物理機進行端口 Mapping 的方式來獲取 172 的 IP (這是在組播通的狀況下,會返回 172 的 IP )。但是，即使是獲取了 172 的 IP 地址，依舊是不能與外部創建鏈接的，由於 172 的 IP 對外是不可見的，因此致使容器也不能進行鏈接，所以要求它必須有獨立的 IP 。這裏有一點要強調，Docker 不支持 overlay。

圖 8

圖 8 是平安對 Padis  Network 的一個簡單描述。圖左側的 API Server（基於 Python） 主要包括 Message Center 和 Network，Message Center 會註冊到 MM 框架當中，接收 Marathon 框架的全部 event ，用來進行分析處理，右側從上到下依次是 MM 框架、計算節點（物理機中裝了 Openvswitch，在上面起容器）、本身設計的網關服務器（基於 Linux 服務器上和 Iptables 實現）。  整個過程如圖 8 所示，Message Center 收到 event 消息後，獲取容器建立，刪除，重啓等動做的 event，經過基於 Ansible 搭建的任務分發平臺把相應的動做下發到響應的服務器上。

圖 9

圖 9 是 Docker 宿主主機實現的簡單示意圖。首先全部的物理機/虛擬機（用 trunk 實現了物理機裏面跑全部 VLAN 的容器）的物理網卡都要經過 Openvswitch 加入到 ovs0 中，啓動容器後用Pipework 給容器指定一個 IP、網關、VLAN，這樣就能夠實現 WEB 通訊。宿主主機的 IP 是 10.30.1.11 （初版用的是雙網卡，其中 eth0 是管理網卡，eth1 是宿主主機的網卡，容器啓動後會和它進行 mapping），在這裏必須記住要給容器加路由，不然會因爲Marathon自身的故障自愈功能，致使不可訪問。固然，此時也可指定相關命令，自動下發的對容器裏的路由進行調整。

在這些裏面，IP 是一個很重要的概念，因此，接下來介紹一下 Padis 平臺的 IP 管理。

對於 Padis 的 IP 管理有如下幾點：

1. IP 地址池能夠在用戶建立資源池時，動態的生成網段信息。
2. 網段生成時，能夠自動在 Gateway 上配置網關和 VLAN 信息（生產環境取消了 Gateway ）
3. IP 狀態設置增長爲三種：預留、已分配和未分配。
4. 故障自愈是指，容器和 IP 原本是綁定在一塊兒的，可是，將容器刪除後該 IP 也會隨之刪除。
5. 一個容器一個 IP，共享存儲走三層路由。

圖 10 

剛剛上面講的是對 IP 的訴求，下面介紹平安關於 DNS 的需求。

平安的 DNS 安全區域架構主要分三種（圖 10）：WEB 層（作展現，WEB || 提供給內部員工使用，DMZ 給公網或者合做夥伴使用）、SF 層（應用邏輯層）  、DB 層。在三層架構時 ，DMZ 上要求作雙向的 NAT ，即在 DMZ 上所看到 SF 的 IP 地址不是真實的，在 SF 上看到 DMZ 的 IP 地址也不是真實的。 作分佈式協調的時候，也會存在這樣的問題，跨安全區域時，由於作了 NAT，你所看到的地址，並非真實，能夠進行訪問的地址。這樣一來，在對外提供服務時，你須要去給人家提供 IP 地址，才能讓人家進入，這樣會致使用戶體驗很是很差。  對於應用層，會常常出現跨域的問題，因此域名是必需要有，且必需要一致，還有就是平安內部會有一些應用需求，好比要作單點登陸（ SSO ） ，它是基於域名作的，因此也要求系統必須有域名。

對於 LB（ Load balancing ），根據收集到的需求和歷史經驗作如下分析：一是軟件負載均衡，對金融公司來講，負載均衡的要求是很是穩定的，不能出事，軟件負載均衡的可靠性和性能很差，因此不被承認；硬件負載均衡的性能確定是要高於軟件負載均衡的，但是也存在相應的問題，硬件負載均衡的成本相對很高，部分系統的用戶量沒有必要用硬件負載均衡。

針對 LB 的這 幾種狀況，平安提出了三套方案：

• 軟件負載均衡 HAProxy
  基於容器，在容器上面搭建一個 HAProxy。

優勢：能夠實現基本功能、新版的能夠作應用路由（能夠根據不一樣規則，向不一樣應用上分發路由）、動態更新配置（經過 API 更改配置文件而後進行 Reload）。

缺點：高併發能力比較弱、SSL 卸載能力差。

• 軟件負載均衡 Lvs＋Nginx LVS+Ospf 調度機自由伸縮，自由擴展（最大 8 臺，受限於網絡設備容許的等價路由數目）；一個 LVS 後端能夠搭建多個 Nginx。

優勢：併發能力比較高、能夠很輕易的完成動態配置更新、SSL 卸載能力好（ LVS 能夠搭建多個 Nginx，Nginx 多了，卸載能力天然有所提高）。

缺點：後端 Nginx 發生頻繁變化時（例如由 10 個變成 20 個），當進行等價路由算法時，此時便會發生路由抖動。  

• 硬件負載均衡 LTM
  作了自動化配置開發、作了動態接口配置。

缺點：自己擴展能力很差、成本高。

測試環境 Padis 上線

圖 11 

圖 11 是基於以上問題，搭建出來的一個測試環境框架。首先提供給用戶看的是 Portal（基於 JS 寫的），下面的 API 是基於 python 寫的。接下來是 MM 框架，Log 是日誌雲，Log 旁邊是認證模塊和硬件負載均衡 LTM 。 圖中紅色那塊就是倉庫，開發環境時所用的鏡像所有在倉庫裏面，鏡像中包括用戶認證配置、基礎環境的調優等等，倉庫下面是存儲，存儲主要用 Nas。如今的容器支持虛擬機和物理機的運維理念與開發不一樣，節點越少越好，這樣故障點也會越少，因此平臺的主要計算節點大部分是物理機。最後，在網絡模塊（ Network ）上設置了 Gateway 。

圖 12

圖 12 是一個邏輯示意圖。首先從 Potal 進入，調用 API 建立網段或者應用  ，API 分爲認證、DNS、Traffic（ LB ）、Network 、Cache 這幾個模塊，當時的想法是將數據庫也一同打包進來，可是因爲平安的庫太大（動輒幾個 T ），因此就放棄了這樣的想法。 Padis API 能夠進行用戶認證、DNS 的增刪改。從圖 12 可見，全部模塊彼此相互獨立，全部系統都是經過 Portal 進來，併發送請求到 API，API 根據不一樣的請求作相應的操做，全部的操做會直接發送給Marathon框架，Marathon 框架也會根據事件再給 API 相應的反饋，API 同時也會根據反饋結果再作相應的操做。

生產環境 Padis 上線

與測試環境相比，對生產環境的要求是很高的。對於生產環境，主要作了如下幾點改造：

1. 測試環境的性能達不到要求，穩定性有問題，因而取消 Gateway  Server ，生產環境中 所有改用網絡設備。 
2. CMDB,測試環境是本身獨立的，生產的要與傳統的 CMDB 對接，數據須要寫入傳統的 CMDB 裏面去，因此須要開發 CMDB 接口，進行數據導入。
3. 監控告警。須要搭建 Zabbix 監控平臺，對接傳統的監控平臺。
4. 性能數據收集。在作故障分析時，都是基於對性能數據的分析，而後得出結果，而且要根據性能數據， 對容量進行判斷，好比是否要作一些動態的擴容縮容（關於擴容縮容最初的想法是作成自動化的，但存在的問題是，若是作成自動化，當別人攻擊時，後臺資源則不必定能扛住）。
5. DNS 改造。對接生產網絡的 DNS，實現動態更新 DNS（在這個地方專門寫一個 DNS 模塊，跟平安的 DNS 對接，內部的 DNS 會作一個節點，在上面作單獨配置，全部的配置更新都在裏面作）。
6. 日誌存儲。測試環境用的是 Ceph，沒有用到本地磁盤，把全部空餘的物理磁盤作了一個Ceph，但測試時用的 Ceph 是不成熟的，因此改爲了 NAS，同時將日誌接入到日誌雲裏進行分析、處理和歸檔。

圖 13

通過以上幾點改造，生產環境框架就變成如圖 13 這樣（添加了 CMDB 模塊）。

Padis 承接平安金融管家系統羣

平安 Padis 在今年上半年的時候承接了平安金融管家（原平安人壽）系統羣，當時系統羣所運用的平臺，就是 Padis 平臺。

傳統環境的搭建，從 0 到上線最快 3 天，但是 Padis 卻完成了系統從 0 到上線只用 5 分鐘這個過程，當中還包括全部的調試環節。Padis 當時作了一個互聯網出口，還有一個 LVS + Ospf 的改造，而且同時由 50 路 Nginx 和多路 LVS 提供服務。由於當時全部的配置都是標準化的，只需將包上傳，以後立馬就能使用，因此耗時短。那也是 Padis 在生產環境的第一次亮相，通過這一次以後，總結出了一個經驗：隔離集團和其餘系統的相互影響，不能由於搞活動而影響系統的正常運行。

 

---

 

本文做者：

王耀武

2008 年首次參加工做，2010 年加入平安科技基礎架構，今後被打上了中間件烙印，4 年時間從不知道中間件是什麼，到成長爲中間件專家。經歷了平安的多個重大項目和改革。2014 年開始「遊手好閒」，作 Docker 在平臺的落地，組建團隊，搭建快速部署平臺 Padis。

更多容器雲實踐文章可移步七牛雲博客查看。