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

中國人壽做爲著名的傳統金融企業，在採納容器、搭建PaaS平臺的過程當中遇到了許多挑戰，也積累了寶貴的經驗。中國人壽的技術負責人分享了他們的心路歷程和實踐心得，以及存儲、網絡、CI/CD、微服務、數據庫拆分等具體技術細節和經驗。

---

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）都搬到雲上。只能說，各公司有各自的狀況和需求。中國人壽拆分數據庫的需求不那麼強烈，咱們根據本身狀況評估認爲，將數據庫拆分或者部署在生產雲上所花費的成本可能得不償失。一切決策都是跟不一樣公司數據量的大小、系統的具體狀況有關的。

後續Rancher將會繼續爲你們帶來更多大會演講實錄，請保持關注Rancher 公衆號的最新推送~