摘要：具體技術細節的補充中國人壽兩朵云的最底層的容器調度與管理都是使用了平臺。決定采納容器擁抱，對整個中國人壽而言都是一次重大的變革。對中國人壽這樣的傳統金融企業而言，上一個并不容易。

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