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

6月28日，Rancher Labs在北京舉辦了Container Day 2018容器技術(shù)大會。在大會上，Rancher Labs CEO及聯(lián)合創(chuàng)始人梁勝博士、中國人壽研發(fā)中心開發(fā)五部副總經(jīng)理王川、技術(shù)處高級經(jīng)理鄭曉勇、開發(fā)五部云計算架構(gòu)師張青南、ZStack CEO及創(chuàng)始人張鑫進行了一場圓桌討論。

本文整理摘取自圓桌討論環(huán)節(jié)的內(nèi)容，由中國人壽的嘉賓分享了中國人壽使用容器技術(shù)、搭建金融PaaS云平臺的心路歷程，以及存儲、網(wǎng)絡、CI/CD、微服務、數(shù)據(jù)庫拆分等具體技術(shù)細節(jié)和經(jīng)驗。

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

中國人壽從2016年底開始做技術(shù)調(diào)研，于2017年正式開始利用容器技術(shù)搭建金融PaaS云平臺，用了半年多的時間完成了兩朵云環(huán)境的搭建，一朵是開發(fā)測試的云環(huán)境，一朵是生產(chǎn)的云環(huán)境。中國人壽在開發(fā)測試云環(huán)境里做了持續(xù)集成，兩朵云之間通過持續(xù)交付進行打通。最后又用了半年多時間在內(nèi)部進行推廣。

中國人壽的容器使用已經(jīng)比較深入了。開發(fā)團隊Java類的應用基本全部在開發(fā)測試云上進行了容器化，這占中國人壽總應用數(shù)量的一半以上。在生產(chǎn)云環(huán)境上，從2017年底開始，我們先將內(nèi)部應用往生產(chǎn)云環(huán)境上搬；2018年6月一些對外的業(yè)務應用也陸續(xù)完成往生產(chǎn)云的遷移，目前有兩個對外業(yè)務應用已經(jīng)跑在生產(chǎn)云環(huán)境上。

在云規(guī)模上，目前中國人壽整個的云規(guī)模有服務器160多臺，云化的、容器化的應用有94個，運行托管的容器有1700多個。

具體技術(shù)細節(jié)的補充？

中國人壽兩朵云的最底層的容器調(diào)度與管理都是使用了Rancher平臺。Docker用的是17.03的版本。主機環(huán)境之前也嘗試過使用紅帽，最終遷到了Ubuntu上，使用的是Ubuntu 16.04。

重點說一下網(wǎng)絡和存儲，中國人壽在網(wǎng)絡和存儲方面的選擇，在不同云環(huán)境上有不同的考量，開發(fā)測試云和生產(chǎn)云是不同的。

在網(wǎng)絡方面，中國人壽在開發(fā)測試環(huán)境上，使用的是IPsec管理的Overlay網(wǎng)絡。選擇Overlay網(wǎng)絡是因為，雖然它可能架構(gòu)比較復雜，但最終使用時管理起來會比較容易，我們不用額外去給它準備IP資源。在生產(chǎn)環(huán)境上，我們使用的是扁平網(wǎng)絡，扁平網(wǎng)絡的一個好處在于，它的IP跟整個大網(wǎng)里的IP是互通的。存在的問題是我們要提前規(guī)劃網(wǎng)絡，規(guī)劃IP資源的使用。

在存儲方面，中國人壽在開發(fā)測試環(huán)境上用的是Sun存儲，這樣的選擇和我們的實際情況有關(guān)，因為我們在開發(fā)測試環(huán)境上沒有足夠的NAS設備。但是中國人壽在生產(chǎn)環(huán)境上使用的就是NAS存儲了。

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

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

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

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

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

雖然我不是什么心理輔導師，但是我覺得我們應該致力于給程序員創(chuàng)造一個良好的研發(fā)生態(tài)環(huán)境，實際上這也確實是很重要的。

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

有哪些挑戰(zhàn)、哪些經(jīng)驗可以分享？

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

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

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

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

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

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

我們后來也分析了一下，為什么搬到云上能節(jié)省到這么多資源？因為在虛機環(huán)境下：第一，團隊通常會超配申請資源，超額申請但最后并沒有使用到，從而導致了資源浪費；第二，很多時候我們實際使用的系統(tǒng)很多，運行的技術(shù)環(huán)境不同，有的運行在紅帽上，有的運行在Ubuntu上，有的中間件是Tomcat，有的是WebLogic……很多系統(tǒng)不能部署在同一臺機器上，必須分開部署，需要的機器資源自然更多。

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

另外一個就是研發(fā)效率的極大提升。就以申請環(huán)境這么一個過程為具體例子吧。因為中國人壽有研發(fā)中心和數(shù)據(jù)中心，通常是研發(fā)中心向我們架構(gòu)團隊提出要求，架構(gòu)團隊內(nèi)部討論審核這個資源要求合不合理；如果合理就給到數(shù)據(jù)中心的架構(gòu)團隊，數(shù)據(jù)中心架構(gòu)團隊再內(nèi)部溝通審核；如果數(shù)據(jù)中心架構(gòu)團隊覺得要求不合理，那雙方再開會來達成共識吧；之后再把這個達成共識的需求給到數(shù)據(jù)中心的運維團隊，運維團隊去制作虛機，然后安裝軟件，然后再交還給我們研發(fā)團隊。這個流程相當?shù)膹碗s，一般我們申請一些機器、一些設備，需要大概一周左右的時間才能到位。但也沒有辦法，規(guī)模大、結(jié)構(gòu)復雜的企業(yè)團隊就是常面臨這種問題。

而上了PaaS之后，我們用到了PaaS里面的應用商店，把一些基礎的應用打包成鏡像上架到應用商店。后續(xù)使用時基本上是秒用，需要一個環(huán)境的話，基本上一點用商店就能立馬拉起來。這是一個上百倍的環(huán)境準備效率的提升。

持續(xù)集成

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

并不是中國人壽的所有開發(fā)人員都清楚什么是Docker，什么是PaaS。他不太了解也不需要了解，他可能只是關(guān)注一套業(yè)務代碼的開發(fā)。所以我們在幫助應用團隊將應用遷到PaaS的過程中，先給應用團隊的應用進行持續(xù)集成。這個開發(fā)團隊只要提交代碼，剩下的由我們通過持續(xù)集成為他們進行代碼編譯、鏡像打包、做PaaS平臺的托起，整個過程是不用項目組參與的，而是通過持續(xù)集成、通過自動化去完成的。如此一來，有效降低了他們技術(shù)上的使用門檻。

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

微服務的拆分或改造經(jīng)驗

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

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

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

數(shù)據(jù)庫拆分

中國人壽沒有做額外的數(shù)據(jù)庫拆分，因為目前這個云對數(shù)據(jù)庫拆分起不到太大的幫助。若是新建系統(tǒng)，我們進行原生設計時就會考慮好數(shù)據(jù)結(jié)構(gòu)。原有的老系統(tǒng)，目前我們碰到的正在拆的系統(tǒng)都還沒有從數(shù)據(jù)層面去下手。

我們的Oracle、MySQL都在容器上實現(xiàn)容器化，都能在云環(huán)境上運行。在開發(fā)環(huán)境上，如果說如果項目組急切需要一個數(shù)據(jù)庫，我們會直接用鏡像在云上給他托起Oracle、MySQL或MangoDB這些，直接給到項目組。生產(chǎn)環(huán)境上，我們沒有把數(shù)據(jù)庫運行在生產(chǎn)云上。

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