中國人壽從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存儲了。

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

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

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

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

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

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

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

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

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

中國人壽使用容器技術、搭建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 公眾號的最新推送~