中國人壽如何基於容器搭建金融PaaS雲平臺

6月28日，Rancher Labs在北京舉辦了Container Day 2018容器技術大會。在大會上，Rancher Labs CEO及聯合創始人樑勝博士、中國人壽研發中心開發五部副總經理王川、技術處高階經理鄭曉勇、開發五部雲端計算架構師張青南、ZStack CEO及創始人張鑫進行了一場圓桌討論。

本文整理摘取自圓桌討論環節的內容，由中國人壽的嘉賓分享了中國人壽使用容器技術、搭建金融PaaS雲平臺的心路歷程，以及儲存、網路、CI/CD、微服務、資料庫拆分等具體技術細節和經驗。

中國人壽容器使用情況如何？

中國人壽從2016年底開始做技術調研，於2017年正式開始利用容器技術搭建金融PaaS雲平臺，用了半年多的時間完成了兩朵雲環境的搭建，一朵是開發測試的雲環境，一朵是生產的雲環境。中國人壽在開發測試雲環境裡做了持續整合，兩朵雲之間通過持續交付進行打通。最後又用了半年多時間在內部進行推廣。

中國人壽的容器使用已經比較深入了。開發團隊Java類的應用基本全部在開發測試雲上進行了容器化，這佔中國人壽總應用數量的一半以上。在生產雲環境上，從2017年底開始，我們先將內部應用往生產雲環境上搬；2018年6月一些對外的業務應用也陸續完成往生產雲的遷移，目前有兩個對外業務應用已經跑在生產雲環境上。

在雲規模上，目前中國人壽整個的雲規模有伺服器160多臺，雲化的、容器化的應用有94個，執行託管的容器有1700多個。

具體技術細節的補充？

中國人壽兩朵雲的最底層的容器排程與管理都是使用了Rancher平臺。Docker用的是17.03的版本。主機環境之前也嘗試過使用紅帽，最終遷到了Ubuntu上，使用的是Ubuntu 16.04。

重點說一下網路和儲存，中國人壽在網路和儲存方面的選擇，在不同雲環境上有不同的考量，開發測試雲和生產雲是不同的。

在網路方面，中國人壽在開發測試環境上，使用的是IPsec管理的Overlay網路。選擇Overlay網路是因為，雖然它可能架構比較複雜，但最終使用時管理起來會比較容易，我們不用額外去給它準備IP資源。在生產環境上，我們使用的是扁平網路，扁平網路的一個好處在於，它的IP跟整個大網裡的IP是互通的。存在的問題是我們要提前規劃網路，規劃IP資源的使用。

在儲存方面，中國人壽在開發測試環境上用的是Sun儲存，這樣的選擇和我們的實際情況有關，因為我們在開發測試環境上沒有足夠的NAS裝置。但是中國人壽在生產環境上使用的就是NAS儲存了。

中國人壽最初為何決定採納容器、搭建PaaS？

我想來參加Rancher Container Day大會的在座各位肯定都是容器、PaaS的專家，大家也許會覺得，這個問題的答案不是顯然的嗎？容器、PaaS能帶來這麼大好處，當然需要去建一個金融的PaaS平臺，不是嗎？但對中國人壽這樣一個傳統的金融國企而言，使用容器搭建PaaS平臺，其間也是有一些心路歷程值得分享的。

相信在不少組織中，研發程式員和運維人員的關係都很微妙，中國人壽也是這樣，我們曾面臨下面這兩個問題。

第一，程式設計師天性崇尚自由，但原先他寫的程式都是侷限在一個虛擬機器上，程式設計師經常需要向運維小夥伴要求多加一臺機器，他們常覺得不方便、被限制。

第二，是釋出新版本的問題。中國人壽很多年前就希望能有快速的版本更新，比如看能不能每月都發一個版本，但後來並沒有成功。到了網際網路時代，我們對發版的頻度要求更高了，而中國人壽這樣一個傳統企業怎麼去發版？到凌晨12點，然後停機。運維小夥伴負責去升級，程式設計師也得在一旁候著。這麼一個長期的工作環境和形式，我們的程式設計師他們都心情很鬱悶。

雖然我不是什麼心理輔導師，但是我覺得我們應該致力於給程式設計師創造一個良好的研發生態環境，實際上這也確實是很重要的。

當時中國人壽也正好想要做X86的改造。我們以前很多應用是跑在小型機上的，包括一些非常重的應用。決定採納容器、擁抱PaaS，對整個中國人壽而言都是一次重大的變革。我們集結的PaaS實施團隊在PaaS、容器這些方面都非常專業且很有興趣。對中國人壽這樣的傳統金融企業而言，上一個PaaS並不容易。Rancher產品功能很全面，幫我們快速解決了很多底層的基礎的問題，不過我們仍要做很多傳統應用的適用性改造。不過最後事實也證明這樣一個變革、這樣一種投入是值得的。容器輕量、快速、標準，在資源調配與節約、應用快速釋出等等方面都解決了我們原先的痛點與困境。

有哪些挑戰、哪些經驗可以分享？

我們剛剛提到了【變革】這兩個字，的確，在中國人壽PaaS雲平臺的搭建過程中，我們遇到過一些挑戰，其中有兩方面我想在此分享。第一個是使用者心理層面的問題，第二個是中國人壽自身能力提升方面的問題。

首先，新技術的使用和推廣，在使用者心理層面存在什麼問題？那就是，拍手叫好的多，但真正推廣、上線、遷移的時候，大家的實際心理接受程度又不一樣。我們怎麼有效地解決這個問題？中國人壽的PaaS雲平臺，所面向的大部分使用者都是人壽內部團隊。於是我們選擇一些熱愛並擁抱這個這個系統和平臺的人來從頭到尾參與這個系統，讓接受度高的團隊先做出一個樣板工程，以最終的優秀成果為標杆進行更大範圍的推廣，讓其他團隊的領導和成員看到實際的各項指標，如效能、效率、成本等各方面的成果，以資料和指標說話，最終達到了中國人壽內部大部分團隊的應用的容器化改造與遷移。

另外，還有自身能力的提升的問題。畢竟中國人壽是一個傳統企業，對新技術的上手和落地可能不如網際網路公司那麼快。所以我們一方面是加強自身團隊的打造，一定要建立自己的容器技術團隊；另一方面則要選擇借力一些已有的產品和解決方案，不新造輪子，比如選擇跟Rancher這樣的合作伙伴深入合作，這樣就能整體把這個事情給解決。

容器和PaaS給中國人壽帶去了哪些實際益處？

中國人壽使用容器技術、搭建PaaS平臺之後，兩大最顯著的益處，一個是資源和成本的節約，一個是研發效率的提升。

首先是資源和成本的極大節約。中國人壽正在做新一代整體架構的改造，其中有很多新一代的核心繫統。舉一個實際的例子，原先，有個團隊去做一個新的架構模式的開發，申請了80臺虛機，然後發現這遠不夠他做新一代建設，80臺虛機甚至搭不起一個開發環境。當時我們正好啟動PaaS專案，就按照這80臺虛機的資源，把這80臺虛機託管到雲上，在雲環境下進行新一代核心系統的開發。原先，80臺虛機連一套開發環境也託不起來；實際上在雲環境下，我們托起了三套環境，資源才使用了2/3。這是一個資源的巨大節省。

我們後來也分析了一下，為什麼搬到雲上能節省到這麼多資源？因為在虛機環境下：第一，團隊通常會超配申請資源，超額申請但最後並沒有使用到，從而導致了資源浪費；第二，很多時候我們實際使用的系統很多，執行的技術環境不同，有的執行在紅帽上，有的執行在Ubuntu上，有的中介軟體是Tomcat，有的是WebLogic……很多系統不能部署在同一臺機器上，必須分開部署，需要的機器資源自然更多。

而使用容器之後，情況則不同了。針對第一個問題，他只有在真正使用時才會佔用資源，不用到的時候資源並沒被預先佔用。針對第二個問題，因為容器進行了一層又一層隔離，並且容器是一種標準化打包，所以在環境上也可以更加靈活，就不存在虛機那種強制要求分開部署的情況。這就是容器給我們帶來的資源上的巨大節省。

另外一個就是研發效率的極大提升。就以申請環境這麼一個過程為具體例子吧。因為中國人壽有研發中心和資料中心，通常是研發中心向我們架構團隊提出要求，架構團隊內部討論稽核這個資源要求合不合理；如果合理就給到資料中心的架構團隊，資料中心架構團隊再內部溝通稽核；如果資料中心架構團隊覺得要求不合理，那雙方再開會來達成共識吧；之後再把這個達成共識的需求給到資料中心的運維團隊，運維團隊去製作虛機，然後安裝軟體，然後再交還給我們研發團隊。這個流程相當的複雜，一般我們申請一些機器、一些裝置，需要大概一週左右的時間才能到位。但也沒有辦法，規模大、結構複雜的企業團隊就是常面臨這種問題。

而上了PaaS之後，我們用到了PaaS裡面的應用商店，把一些基礎的應用打包成映象上架到應用商店。後續使用時基本上是秒用，需要一個環境的話，基本上一點用商店就能立馬拉起來。這是一個上百倍的環境準備效率的提升。

持續整合

另外還有一點值得分享，中國人壽在做PaaS的過程中，不只是用了容器技術，另一個很重要的是自動化技術。

並不是中國人壽的所有開發人員都清楚什麼是Docker，什麼是PaaS。他不太瞭解也不需要了解，他可能只是關注一套業務程式碼的開發。所以我們在幫助應用團隊將應用遷到PaaS的過程中，先給應用團隊的應用進行持續整合。這個開發團隊只要提交程式碼，剩下的由我們通過持續整合為他們進行程式碼編譯、映象打包、做PaaS平臺的托起，整個過程是不用專案組參與的，而是通過持續整合、通過自動化去完成的。如此一來，有效降低了他們技術上的使用門檻。

同時，完成了自動化的持續整合這個過程之後，也能大量地、快速地提升他們的研發效率，起碼在整合效率上的提高非常大。拍個腦袋說個數，原來的整合可能需要30分鐘，從程式碼編譯、到檢查、到部署；而通過持續整合去做的話，我們最終能在5分鐘之內完成整個流水線的工作，大概是這麼一個提升。

微服務的拆分或改造經驗

我們覺得做微服務，最簡單的方法是從頭到尾來做，在最初新建系統的規劃階段就按微服務架構去做。我們基於微服務架構新建系統時，使用的是Spring全家桶，即SpringBoot、SpringCloud這些。

以今年6月我們剛上線的對外業務系統為例，它原先面臨著非常大的運維問題。為了高可用、非停機升級、灰度釋出，我們將這個上線的微服務拆成了兩個獨立的、相同的棧。最後一共是有70多個微服務，執行著128個應用容器。如果是用傳統方法、在非雲的模式下，我們資料中心甚至不會同意去接這個專案，因為它的運維難度、甚至光上線難度就非常大。但是PaaS雲平臺讓我們得以解決這一難題，我們在雲上用到了應用商店、Rancher的應用釋出，只用10分鐘就完成了整個系統的上線和128個容器的部署。我們的經驗是，如果條件可行的話，微服務架構這種的還是從頭新建可能更好一點，碰到的坑可能會少一點。

另一個一定要提的建議就是，一定要跟雲相結合。中國人壽的整個過程都是做的持續整合、持續交付，都是用的自動化技術去對接。跟雲結合，這個技術是很好的。這是我們這邊的一點體驗。

資料庫拆分

中國人壽沒有做額外的資料庫拆分，因為目前這個雲對資料庫拆分起不到太大的幫助。若是新建系統，我們進行原生設計時就會考慮好資料結構。原有的老系統，目前我們碰到的正在拆的系統都還沒有從資料層面去下手。

我們的Oracle、MySQL都在容器上實現容器化，都能在雲環境上執行。在開發環境上，如果說如果專案組急切需要一個數據庫，我們會直接用映象在雲上給他托起Oracle、MySQL或MangoDB這些，直接給到專案組。生產環境上，我們沒有把資料庫執行在生產雲上。

因為就中國人壽的情況來看，我們的開發測試雲和生產雲的定位和目標都是不同，因而策略不同。在開發上是為了方便專案組快速去用，所以提供這個服務。不過我們也知道有不少公司會把所有的資料庫（MySQL）都搬到雲上。只能說，各公司有各自的情況和需求。中國人壽拆分資料庫的需求不那麼強烈，我們根據自己情況評估認為，將資料庫拆分或者部署在生產雲上所花費的成本可能得不償失。一切決策都是跟不同公司資料量的大小、系統的具體情況有關的。