3.1　H公司容器云建設(shè)案例

本節(jié)以H公司為例，該公司在中國開設(shè)了數(shù)百余家分支機(jī)構(gòu)和營業(yè)網(wǎng)點(diǎn)。在互聯(lián)網(wǎng)保險(xiǎn)業(yè)務(wù)領(lǐng)域，它通過技術(shù)創(chuàng)新和業(yè)務(wù)拓展，極大提升了互聯(lián)網(wǎng)保險(xiǎn)業(yè)務(wù)的競爭力。

3.1.1　H公司業(yè)務(wù)需求

為了進(jìn)一步提升企業(yè)在中國保險(xiǎn)市場的競爭優(yōu)勢，H公司希望利用云計(jì)算、大數(shù)據(jù)等技術(shù)，為業(yè)務(wù)增長提供更為有力的支撐，推動(dòng)創(chuàng)新業(yè)務(wù)轉(zhuǎn)型升級。但是，在數(shù)字化轉(zhuǎn)型的過程中，它發(fā)現(xiàn)IT系統(tǒng)建設(shè)面臨著嚴(yán)峻的挑戰(zhàn)。首先，互聯(lián)網(wǎng)保險(xiǎn)業(yè)務(wù)正處于快速的演進(jìn)之中，不但用戶需求不斷進(jìn)化，業(yè)務(wù)環(huán)境也瞬息萬變，這就對企業(yè)的敏捷響應(yīng)、快速開發(fā)能力提出了嚴(yán)格的要求。而客戶既有的IT系統(tǒng)基于閉源技術(shù)打造，缺乏自主能力，當(dāng)業(yè)務(wù)拓展亟需開發(fā)創(chuàng)新應(yīng)用時(shí)，IT部門很難敏捷地響應(yīng)應(yīng)用開發(fā)、升級等需求，不利于對客戶自身需求的敏銳洞察與引導(dǎo)。

此外，互聯(lián)網(wǎng)保險(xiǎn)業(yè)務(wù)具有大規(guī)模、高并發(fā)的特征，大量的應(yīng)用需要從海量用戶生成的龐大數(shù)據(jù)中抽絲剝繭，對數(shù)據(jù)洞察、反饋的響應(yīng)速度往往需要達(dá)到秒級甚至更高，這就對IT系統(tǒng)的處理能力、可用性提出了嚴(yán)苛的要求。由于H公司近幾年積極推動(dòng)互聯(lián)網(wǎng)保險(xiǎn)業(yè)務(wù)拓展，IT系統(tǒng)需要處理的業(yè)務(wù)與數(shù)據(jù)出現(xiàn)快速增長，在高負(fù)載的壓力下，舊的系統(tǒng)很快出現(xiàn)了運(yùn)行速度慢、可用性差等問題，如果要通過持續(xù)升級軟硬件的方式來應(yīng)對，將會(huì)給成本控制帶來巨大考驗(yàn)。

3.1.2　業(yè)務(wù)需求的技術(shù)實(shí)現(xiàn)

H公司的業(yè)務(wù)需求，可以轉(zhuǎn)化為以下三方面技術(shù)需求。

• 云環(huán)境應(yīng)用基礎(chǔ)設(shè)施：通過建立一個(gè)穩(wěn)定、高效、標(biāo)準(zhǔn)化的平臺，促進(jìn)產(chǎn)品創(chuàng)新，促使IT運(yùn)營更加敏捷靈活，為未來企業(yè)發(fā)展奠定堅(jiān)實(shí)基礎(chǔ)。
• 支持快速彈性伸縮：實(shí)現(xiàn)IT基礎(chǔ)設(shè)施資源的合理利用、按需動(dòng)態(tài)調(diào)整容量，支持應(yīng)用系統(tǒng)的快速部署和靈活調(diào)度。
• 實(shí)現(xiàn)應(yīng)用快速迭代：促進(jìn)協(xié)同合作，縮短應(yīng)用開發(fā)迭代周期，加快產(chǎn)品推出速度，更好地支持各類版本投產(chǎn)、日常運(yùn)維和互聯(lián)網(wǎng)應(yīng)用等的快速發(fā)展。

在上面的需求中，前兩個(gè)屬于PaaS平臺的需求，第三個(gè)屬于DevOps的需求。最終，H公司決定構(gòu)建基于容器和Kubernetes的容器云平臺，并選擇了紅帽的OpenShift平臺。容器云平臺使用的持久化存儲方案為紅帽的Ceph。通過容器云平臺，H公司打造了基于容器云的業(yè)務(wù)（包括但不限于）：互聯(lián)網(wǎng)核心、銷售管理系統(tǒng)、自主經(jīng)營分析平臺、保全無紙化、活動(dòng)量、增援。

H公司一期項(xiàng)目實(shí)施歷時(shí)4個(gè)月，具體實(shí)施內(nèi)容如表3-1所示。

一期項(xiàng)目實(shí)施后，H公司的業(yè)務(wù)能力有了明顯的提升，我們可以從如表3-2所示的6個(gè)方面進(jìn)行對比。

接下來我們查看容器云的系統(tǒng)架構(gòu)圖，如圖3-1所示。

在圖3-1中，客戶的請求會(huì)先經(jīng)過DMZ區(qū)的A10負(fù)載均衡器，轉(zhuǎn)發(fā)到OpenShift的Ingress，然后轉(zhuǎn)發(fā)到WebServer Pod上。在OpenShift上的WebServer Service中部署Tomcat應(yīng)用，Consul集群（一主二從）在OpenShift中使用DeploymentConfig形式進(jìn)行部署，在對集群內(nèi)部提供服務(wù)的同時(shí)又可以滿足高可用的要求。ActiveMQ作為消息中間件，以主從方式部署到OpenShift上。Web應(yīng)用與后端的應(yīng)用交互，通過ActiveMQ實(shí)現(xiàn)松耦合。此外，H公司將Redis以三主三從的模式部署到OpenShift上，為應(yīng)用提供分布式緩存。持久化數(shù)據(jù)通過在物理服務(wù)器部署的Ceph實(shí)現(xiàn)。Redis上沒有的數(shù)據(jù)，將會(huì)從Ceph中獲取。

應(yīng)用發(fā)布圖如圖3-2所示，一共部署兩個(gè)容器云集群：第一個(gè)集群運(yùn)行非生產(chǎn)環(huán)境，包括SIT、UAT、Pre-Prod三個(gè)環(huán)境，通過Namespace進(jìn)行隔離；第二個(gè)容器云集群為生產(chǎn)環(huán)境，非生產(chǎn)環(huán)境成功發(fā)布的容器鏡像通過容器鏡像倉庫復(fù)制到生產(chǎn)環(huán)境的容器鏡像倉庫進(jìn)行部署。CI工具使用OpenShift S2I和Jenkins相結(jié)合的方式，S2I實(shí)現(xiàn)從源碼構(gòu)建，Jenkins實(shí)現(xiàn)Pipeline的管理。

借助上述容器云架構(gòu)，H公司實(shí)現(xiàn)了“小核心、大外圍”的架構(gòu)。容器云平臺對接的外圍系統(tǒng)包括微信銷售平臺、渠道管理平臺、電子保單、易保核心等。

在實(shí)施容器云之前，H公司的業(yè)務(wù)系統(tǒng)主要部署在物理服務(wù)器上。所以我們在實(shí)施容器云的時(shí)候，就會(huì)涉及對現(xiàn)有傳統(tǒng)應(yīng)用的容器化改造。在傳統(tǒng)物理機(jī)或者虛擬化環(huán)境中，用得最多的App Server是WebLogic和WAS。但在容器環(huán)境中，無論是客戶還是ISV，都不會(huì)傾向于直接在容器云上部署WebLogic，而是傾向于使用類似Tomcat這樣輕量級的App Server。H公司的應(yīng)用拆分和應(yīng)用服務(wù)器遷移，主要是在ISV主導(dǎo)下完成的，遷移后運(yùn)行在容器化的Tomcat中。

在介紹了H公司業(yè)務(wù)需求的技術(shù)實(shí)現(xiàn)后，接下來介紹項(xiàng)目實(shí)施成功的關(guān)鍵因素與難點(diǎn)。

3.1.3　項(xiàng)目實(shí)施成功的關(guān)鍵因素與難點(diǎn)

我們知道，一個(gè)項(xiàng)目的順利實(shí)施，取決于人、流程、技術(shù)三方面。

本次項(xiàng)目實(shí)施領(lǐng)導(dǎo)小組的組長是H公司的IT經(jīng)理，該領(lǐng)導(dǎo)同時(shí)管理開發(fā)部門和運(yùn)維部門，且H公司技術(shù)人員的項(xiàng)目參與度很高，這相當(dāng)于掃清了開發(fā)部門和運(yùn)維部門在管理層的壁壘。在項(xiàng)目實(shí)施過程中，H公司和紅帽都設(shè)有項(xiàng)目經(jīng)理。項(xiàng)目采取項(xiàng)目管理的機(jī)制，每周舉行項(xiàng)目周例會(huì)，溝通一周的實(shí)施情況（每次會(huì)議時(shí)間不必太長，1個(gè)小時(shí)以內(nèi)為宜）以及遇到的困難，了解并控制項(xiàng)目實(shí)施周期。因此，H公司的容器云項(xiàng)目實(shí)施先天就消除了人和流程方面的障礙。具體項(xiàng)目管理周期如表3-3所示。

項(xiàng)目實(shí)施過程中的難點(diǎn)主要是H公司與紅帽O(jiān)penShift產(chǎn)品之間的技術(shù)分歧。社區(qū)和容器云相關(guān)的開源項(xiàng)目多達(dá)幾十個(gè)，在每一個(gè)功能點(diǎn)都可以有不同的選擇。H公司站在技術(shù)自主可控的角度，在技術(shù)細(xì)節(jié)選擇方面有自己的主張。OpenShift作為企業(yè)級容器云方案，在構(gòu)建容器云時(shí)，也會(huì)集成社區(qū)開源組件，并經(jīng)過大量穩(wěn)定性測試和Bug修復(fù)，才能正式發(fā)布。這就帶來一個(gè)問題：OpenShift默認(rèn)集成的某些開源組件，未必是最新版本，也未必是H公司想采用的。

例如在本次項(xiàng)目中，H公司的技術(shù)需求點(diǎn)（包括但不限于）如下所示：

• 容器云入口控制器采用Nginx；
• 容器云SDN使用Calico；
• 應(yīng)用服務(wù)注冊發(fā)現(xiàn)使用Consul。

這三個(gè)技術(shù)需求點(diǎn)，都是H公司基于開源社區(qū)的技術(shù)提出來的。經(jīng)過紅帽與H公司的溝通，站在項(xiàng)目按時(shí)上線、風(fēng)險(xiǎn)最低的角度，二者最終達(dá)成了一致。

• 針對入口控制器，項(xiàng)目最終使用容器化HAProxy，在七層實(shí)現(xiàn)上HAProxy的功能和性能并不比Nginx差，而且紅帽提供對HAProxy的技術(shù)支持。
• 在SDN方面，H公司主要認(rèn)為Calico的網(wǎng)絡(luò)開銷小，性能更好；而OpenShift默認(rèn)使用OVS。雖然OpenShift與Calico會(huì)在當(dāng)前最新的OpenShift版本上發(fā)布官方認(rèn)證，但紅帽不會(huì)提供Calico Kernel Bug級的問題修復(fù)，因此紅帽建議H公司在生產(chǎn)環(huán)境中使用OVS，以便獲得企業(yè)級支持。在開發(fā)測試環(huán)境，可以部署基于Calico的容器云（項(xiàng)目實(shí)施過程中，OpenShift發(fā)布了對Calico的認(rèn)證），以便進(jìn)行功能和性能對比。
• 在服務(wù)注冊發(fā)現(xiàn)方面，Kubernetes和OpenShift都使用etcd。最終，容器云平臺保留使用etcd，應(yīng)用的服務(wù)注冊發(fā)現(xiàn)使用Consul，且應(yīng)用和Consul均以模板方式部署。

開源社區(qū)的技術(shù)發(fā)現(xiàn)日新月異，迭代很快。但客戶在生產(chǎn)環(huán)境使用相關(guān)的技術(shù)時(shí)，需要從功能性和穩(wěn)定性綜合考慮，使用某個(gè)開源技術(shù)最新的版本或者最“潮”的技術(shù)未必最合適。像紅帽這樣的開源技術(shù)廠商，它會(huì)有清晰的產(chǎn)品路徑，緊跟開源社區(qū)的技術(shù)發(fā)展趨勢，可以防止陷入開源社區(qū)的技術(shù)債務(wù)。

H公司由于IT部門技術(shù)水平較高，因此未提出中文化的需求，使用OpenShift原生的英文界面。在其他的容器云項(xiàng)目中，有的客戶對中文化UI提出了較高的要求，即使本身提供中文化UI的容器云廠商，其界面也未必能滿足客戶對UI的所有需求，因此在項(xiàng)目實(shí)施過程中，需要花費(fèi)較大的成本和較多的時(shí)間進(jìn)行UI的定制化開發(fā)，而且結(jié)果往往不如人意。從技術(shù)角度，建議客戶著重關(guān)注PaaS平臺本身的穩(wěn)定性和健壯性，而對中文化的UI需求，可以適當(dāng)予以控制。或者通過單獨(dú)的開發(fā)商進(jìn)行UI的定制化開發(fā)，千萬不要將UI操作的便捷性作為容器云平臺選型的主要標(biāo)準(zhǔn)。

在介紹了H公司的容器化建設(shè)案例后，接下來我們介紹S公司的容器云建設(shè)案例。