金融渠道容器云平臺建設(shè)紅帽聯(lián)合解決方案技術(shù)白皮書

1、金融渠道容器云平臺建設(shè)紅帽聯(lián)合解決方案技術(shù)白皮書目錄 HYPERLINK l _TOC_250020 執(zhí)行摘要4 HYPERLINK l _TOC_250019 方案背景5 HYPERLINK l _TOC_250018 渠道 IT 業(yè)務(wù)發(fā)展趨勢5 HYPERLINK l _TOC_250017 渠道業(yè)務(wù)的技術(shù)發(fā)展趨勢5 HYPERLINK l _TOC_250016 渠道業(yè)務(wù)面臨的挑戰(zhàn)6 HYPERLINK l _TOC_250015 渠道資產(chǎn)孤立建設(shè)和重復(fù)建設(shè)6 HYPERLINK l _TOC_250014 現(xiàn)有渠道系統(tǒng)技術(shù)開放度低6 HYPERLINK l _TOC_250013 業(yè)務(wù)

2、協(xié)同能力較弱7 HYPERLINK l _TOC_250012 研發(fā)體系的轉(zhuǎn)型7 HYPERLINK l _TOC_250011 渠道業(yè)務(wù)的服務(wù)發(fā)布難8 HYPERLINK l _TOC_250010 建設(shè)的目標(biāo) : 建設(shè)統(tǒng)一、規(guī)范、安全的渠道云平臺8 HYPERLINK l _TOC_250009 微服務(wù)系統(tǒng)的自動化運(yùn)維體系9 HYPERLINK l _TOC_250008 線上線下渠道業(yè)務(wù)的統(tǒng)一9 HYPERLINK l _TOC_250007 敏態(tài)迭代9 HYPERLINK l _TOC_250006 安全與穩(wěn)定要求9 HYPERLINK l _TOC_250005 統(tǒng)一化版本控制10

3、HYPERLINK l _TOC_250004 方案概述10 HYPERLINK l _TOC_250003 金融渠道容器云平臺方案概述10ACaaS：10OpenShift:11渠道容器云管理平臺12 HYPERLINK l _TOC_250002 容器云平臺設(shè)計(jì)原則13 HYPERLINK l _TOC_250001 金融級服務(wù)更新策略13 HYPERLINK l _TOC_250000 網(wǎng)絡(luò)資產(chǎn)視角的管控原則14責(zé)任明確、可控的金融級流水線設(shè)計(jì)15面向金融業(yè)務(wù)的運(yùn)行時服務(wù)設(shè)計(jì)15金融服務(wù)資產(chǎn)建設(shè)與積累設(shè)計(jì)原則16容器云平臺帶來的應(yīng)用場景革新17場景一 : 渠道版本更新實(shí)施策略差異化介紹1

4、7傳統(tǒng)渠道業(yè)務(wù)應(yīng)用的現(xiàn)狀（未實(shí)施容器云平臺）17搭建容器云平臺后應(yīng)用策略的革新18場景二、渠道業(yè)務(wù)連續(xù)性保障20傳統(tǒng)渠道業(yè)務(wù)應(yīng)用的現(xiàn)狀（未實(shí)施容器云平臺）21搭建容器云平臺后應(yīng)用策略的革新21容器云平臺帶來的業(yè)務(wù)價值23提升運(yùn)維效率23標(biāo)準(zhǔn)化的部署與交付模式24DevOps 落地基座24有效整合各種系統(tǒng)資源24提升系統(tǒng)資源利用率24加速企業(yè)軟件資產(chǎn)積累24執(zhí)行摘要目前渠道系統(tǒng)的建設(shè)正處于技術(shù)轉(zhuǎn)型和革新的時期，原有的技術(shù)架構(gòu)體系逐漸無法滿足現(xiàn)有多樣、敏態(tài)的產(chǎn)品發(fā)展階段。渠道平臺的技術(shù)建設(shè)過程中，也存在著諸多的挑戰(zhàn)：渠道資產(chǎn)孤立建設(shè)和重復(fù)建設(shè)現(xiàn)有渠道系統(tǒng)技術(shù)開放度低業(yè)務(wù)協(xié)同能力較弱研發(fā)體系的轉(zhuǎn)型需

5、要新工具體系的支撐渠道業(yè)務(wù)的服務(wù)發(fā)布困難通過我們對行業(yè)背景的分析和建設(shè)目標(biāo)的思考，贊同科技推出了容器和云原生解決方案，承載次世代的金融渠道應(yīng)用。通過容器與原生技術(shù)，可以為應(yīng)用快捷地解決技術(shù)轉(zhuǎn)型中所出現(xiàn)的問題，使渠道系統(tǒng)建設(shè)中的挑戰(zhàn)迎刃而解。贊同科技云原生解決方案如下圖所示：此方案為用戶帶來的業(yè)務(wù)價值如下（根據(jù)成功案例計(jì)算）：提升軟件發(fā)布效率 80%極大縮減人力成本 70%有效降低系統(tǒng)故障風(fēng)險(xiǎn)率 80%方案背景渠道 IT 業(yè)務(wù)發(fā)展趨勢金融業(yè)渠道建設(shè)一直都是銀行 IT 技術(shù)建設(shè)的重中之重，過去的幾十年間，金融渠道走過了三個階段。如圖可以看出，渠道的發(fā)展伴隨著金融科技的發(fā)展走過了一條清晰的軌跡，這些

6、變化，一方面方便了銀行與客戶的交互，客戶可以隨時隨地獲得銀行服務(wù)，了解金融咨詢，銀行業(yè)可以隨時隨地向客戶提供產(chǎn)品和營銷信息；另一方面使得銀行與客戶的聯(lián)系變得越來越虛擬化，間接化。在網(wǎng)絡(luò)化、社交化和大數(shù)據(jù)化的時代， 接觸客戶的渠道本身就是資源。就像石油行業(yè)中，具備資源話語權(quán)的不是油田， 也不是煉油廠，而是加油站網(wǎng)絡(luò)。渠道業(yè)務(wù)的技術(shù)發(fā)展趨勢金融科技第一階段界定為金融 IT 階段，第二階段界定為互聯(lián)網(wǎng)金融階段，目前處于第三階段，進(jìn)入移動互聯(lián)和物聯(lián)網(wǎng)時代。同時，目前金融渠道的建設(shè)也從傳統(tǒng)的 IT 技術(shù)架構(gòu)逐漸轉(zhuǎn)型向?qū)I(yè)化、電子化、信息化與智能化。面對著技術(shù)架構(gòu)向信息化、智能化的不可逆趨勢發(fā)展，技術(shù)領(lǐng)域

7、發(fā)生著不斷創(chuàng)新。金融渠道業(yè)務(wù)的復(fù)雜度不斷提高，產(chǎn)品的迭代速率不斷加快，同時架構(gòu)演進(jìn)中， 不斷向著微服務(wù)化、分布式化轉(zhuǎn)變，在微服務(wù)架構(gòu)體系也帶來了對運(yùn)維的極大挑戰(zhàn)。針對于這樣的行業(yè)背景，金融渠道業(yè)的 IT 建設(shè)也發(fā)生的巨大的轉(zhuǎn)變，渠道側(cè)也在逐步向智能化運(yùn)維和敏態(tài)開發(fā)等方面進(jìn)行轉(zhuǎn)型，并且如何實(shí)現(xiàn)一個具有統(tǒng)一化、高效、智能、敏捷的基建化管理平臺，就成為了銀行金融業(yè) IT 建設(shè)的核心目標(biāo)， 也是銀行渠道業(yè)智能化技術(shù)轉(zhuǎn)型的發(fā)展思路。渠道業(yè)務(wù)面臨的挑戰(zhàn)目前渠道系統(tǒng)的建設(shè)正處于技術(shù)轉(zhuǎn)型和革新的時期，原有的技術(shù)架構(gòu)體系逐漸無法滿足現(xiàn)有多樣、敏態(tài)的產(chǎn)品發(fā)展階段。渠道平臺的技術(shù)建設(shè)過程中，也存在著諸多的挑戰(zhàn)。下面

8、羅列的目前行業(yè)建設(shè)的主要痛點(diǎn)和挑戰(zhàn)。渠道資產(chǎn)孤立建設(shè)和重復(fù)建設(shè)隨著銀行獲客渠道的持續(xù)豐富，大多數(shù)銀行都建立了自己的全渠道矩陣；這些渠道往往是彼此獨(dú)立。由于各個渠道孤立建設(shè)、且在不同時期建設(shè)，導(dǎo)致相同功能重復(fù)建設(shè)。在重復(fù)建設(shè)的過程之中，難以積累業(yè)務(wù)資產(chǎn)，隨著技術(shù)的發(fā)展，常出現(xiàn)業(yè)務(wù)場景的推倒重來的情況。以此帶來了人力資源和系統(tǒng)資源的重復(fù)投入。那么如何做好資產(chǎn)的積累，如何減少系統(tǒng)建設(shè)的重復(fù)投入，是本次渠道云建設(shè)需要解決的事情?，F(xiàn)有渠道系統(tǒng)技術(shù)開放度低在目前的銀行渠道中主要應(yīng)用的技術(shù)內(nèi)容較為陳舊，個別技術(shù)如 Delphi、VC、SWT 等面臨淘汰，缺少活躍社區(qū)的支持。在技術(shù)人才的支持上，缺少新生力量的

9、補(bǔ)充，未來的技術(shù)維護(hù)成本較高，并且由 PAGE 24于技術(shù)整體開發(fā)程度較低，在工程師人才培養(yǎng)中，也缺乏對技術(shù)的求知欲和行動力。那么在后續(xù)的渠道建設(shè)中，我們?nèi)绾谓鉀Q和避免此類的問題，首先我們需要選擇更加開放的技術(shù)生態(tài)體系，將技術(shù)體系擁抱于主流的開源社區(qū)之中，接受開源， 擁抱開源。其次在渠道中臺的技術(shù)選型過程中，應(yīng)該對多語言、多開發(fā)框架提供良好的支持能力。在實(shí)現(xiàn)細(xì)節(jié)中，應(yīng)不僅局限于對某一特定語言進(jìn)行強(qiáng)依賴綁定， 不利于長期的 IT 技術(shù)建設(shè)，應(yīng)重平臺化，輕應(yīng)用化思路建設(shè)。業(yè)務(wù)協(xié)同能力較弱在大規(guī)模渠道業(yè)務(wù)系統(tǒng)建設(shè)的過程中，業(yè)務(wù)間的協(xié)同將變得極為普遍和多樣。渠道間業(yè)務(wù)協(xié)同多采用接口串接控制業(yè)務(wù)流程，不

10、能很好的支持可視化運(yùn)營的要求，在大規(guī)模渠道業(yè)務(wù)系統(tǒng)建設(shè)的過程中，業(yè)務(wù)間協(xié)同普遍和多樣之后，如何觀測好協(xié)同的過程，如何制定好通訊的規(guī)范，都存在不少挑戰(zhàn)。同時，渠道系統(tǒng)主體的業(yè)務(wù)研發(fā)流程較為傳統(tǒng)，主要還是以純代碼層面對各種產(chǎn)品包和版本包進(jìn)行管控，流程化較為欠缺自動化管理的能力。同時在規(guī)范度的建設(shè)上，也存在一定的挑戰(zhàn)，如何做好職能劃分、權(quán)限劃分、責(zé)任劃分是在渠道領(lǐng)域改造和革新的建設(shè)過程中，尤為重要的一點(diǎn)。我們需要解決好開發(fā)協(xié)同、運(yùn)營協(xié)同、可觀測、流程規(guī)范、責(zé)任明確等內(nèi)容之后， 才能提升業(yè)務(wù)協(xié)同的建設(shè)能力。研發(fā)體系的轉(zhuǎn)型渠道系統(tǒng)建設(shè)過程中，由于在系統(tǒng)建設(shè)的早期，應(yīng)用系統(tǒng)更多的是大型單體應(yīng)用而存在于渠道

11、服務(wù)端的機(jī)器上，往往對敏捷開發(fā)的場景沒有過分關(guān)注。但目前在銀行金融渠道領(lǐng)域，銀行全面開始了全渠道的領(lǐng)域建設(shè)，全渠道建設(shè)需要給予用戶一致性的體驗(yàn)，同一業(yè)務(wù)跨渠道辦理提供一致性體驗(yàn)服務(wù)，從而渠道領(lǐng)域所承接的業(yè)務(wù)復(fù)雜度也越來越高，業(yè)務(wù)的變化也越來越頻繁，以大型單體架構(gòu)所建設(shè)的渠道應(yīng)用逐漸無法滿足當(dāng)前的場景要求。所以以系統(tǒng)的建設(shè)方向上需要轉(zhuǎn)型，轉(zhuǎn)型由單體系統(tǒng)向分布式、微服務(wù)化場景的轉(zhuǎn)型，由傳統(tǒng)研發(fā)方式向敏態(tài)與自動化的研發(fā)方式的轉(zhuǎn)型，傳統(tǒng)化向中臺化方式的轉(zhuǎn)型。渠道業(yè)務(wù)的服務(wù)發(fā)布難上面我們提到，目前渠道建設(shè)需要向分布式化、微服務(wù)化方向進(jìn)行演進(jìn)，在這種場景中，如何做好服務(wù)的發(fā)布策略就變得尤為重要。目前主流的

12、發(fā)布策略中，以灰度發(fā)布策略為主 , 如上圖所示 :首先渠道場景下，灰度的發(fā)布策略的圈定范圍應(yīng)該做好，如何做好灰度發(fā)布過程中的每個階段。除此之外，在大批量服務(wù)發(fā)布與更新過程中，由于涉及到諸多服務(wù)的一次性更新邏輯，由于服務(wù)間的交互能力，有些場景下，需要對本次所更新的動作進(jìn)行事務(wù)性控制，若在更新過程中，出現(xiàn)業(yè)務(wù)故障，可以按需通過回滾邏輯，將所有服務(wù)進(jìn)行回滾操作。建設(shè)的目標(biāo) : 建設(shè)統(tǒng)一、規(guī)范、安全的渠道云平臺通過我們對金融業(yè)渠道行業(yè)的背景分析和挑戰(zhàn)，我們可以清晰的認(rèn)知到金融渠道領(lǐng)域建設(shè)在朝著分布式化、微服務(wù)化、敏態(tài)化和開發(fā)體系的方向進(jìn)行建設(shè)，并且有越來越多的行業(yè)客戶已經(jīng)完成或開發(fā)進(jìn)行相關(guān)的工作投入。

13、對于金融 IT 建設(shè)的服務(wù)提供商而言，如何助力于金融企業(yè)客戶的建設(shè)落地，是主要的實(shí)現(xiàn)目標(biāo)和方向。分析背景和挑戰(zhàn)，我們認(rèn)證 IT 服務(wù)提供商應(yīng)該朝著統(tǒng)一化、高效、智能、敏捷的基建化管理平臺方向進(jìn)行思考建設(shè)，在這種情況下，渠道側(cè)在改造升級的過程中，以基建化的平臺來解決技術(shù)變革中的諸多的問題與挑戰(zhàn)。已為金融行業(yè)定制的一站式渠道開發(fā)和管理工具是首要思路，通過基建性的工具，提升產(chǎn)品系統(tǒng)的研發(fā)、運(yùn)維、監(jiān)控、敏態(tài)等幾個方面的生產(chǎn)力。這里我們羅列了我們建設(shè)的首要的幾點(diǎn)目標(biāo)。微服務(wù)系統(tǒng)的自動化運(yùn)維體系由于技術(shù)變革，所帶來的微服務(wù)技術(shù)架構(gòu)的轉(zhuǎn)變，如何管理和微服務(wù)應(yīng)用體系就尤為重要，所以往往需要建設(shè)一個完整的微服務(wù)

14、系統(tǒng)運(yùn)維平臺，此平臺可以高效的管理微服務(wù)體系。并且可以對行業(yè)的運(yùn)維與開發(fā)人員進(jìn)行合理化的權(quán)限劃分， 以不同需求視角對系統(tǒng)進(jìn)行多維度的管理。線上線下渠道業(yè)務(wù)的統(tǒng)一在移動互聯(lián)網(wǎng)時代下，線上與線下的融合正在成為一種新的商業(yè)模式?；ヂ?lián)網(wǎng)金融以大數(shù)據(jù)、低成本、高覆蓋、優(yōu)體驗(yàn)，延展了服務(wù)時間與空間，將金融融入生活場景，是其相對傳統(tǒng)金融的核心優(yōu)勢所在。在新的形勢和環(huán)境下，以應(yīng)對互聯(lián)網(wǎng)金融的挑戰(zhàn)，更好服務(wù)客戶；銀行必須在保持自身線下優(yōu)勢的前提下，整合各渠道資源，推動實(shí)體網(wǎng)點(diǎn)轉(zhuǎn)型和線上業(yè)務(wù)融合發(fā)展。此方向上，對系統(tǒng)的運(yùn)行上，就需要 7*24 的連續(xù)穩(wěn)定，并且應(yīng)該具備完整的穩(wěn)定性保障和故障修復(fù)能力。敏態(tài)迭代伴隨互

15、聯(lián)網(wǎng)的快速發(fā)展，巨大的流量也帶動了技術(shù)的不斷革新，研發(fā)的模式也在不斷變化。企業(yè)只有確保自己比競爭對手更加敏捷、更加快速的響應(yīng)數(shù)字化市場的變化，才能在這場數(shù)字經(jīng)濟(jì)革命中勝出。傳統(tǒng)企業(yè)紛紛效仿互聯(lián)網(wǎng)的做法，結(jié)合 DevOps 進(jìn)行數(shù)字化轉(zhuǎn)型。安全與穩(wěn)定要求銀行業(yè)一直的是對安全要求最為嚴(yán)格的產(chǎn)業(yè)，建設(shè)好一個安全穩(wěn)定的 IT 平臺，往往是金融行業(yè)首要考察的技術(shù)點(diǎn)。穩(wěn)定性上，保障應(yīng)從應(yīng)用穩(wěn)定性、網(wǎng)絡(luò)、存儲、集群等幾方面對穩(wěn)定性進(jìn)行明確的劃分，需要對故障等級進(jìn)行合理化的分級，不同等級的故障，要具備不能的修復(fù)時間和相應(yīng)的修復(fù)策略，以金融業(yè)行業(yè)要求為最低準(zhǔn)則。統(tǒng)一化版本控制金融業(yè)在版本管理上，要具備一個完善的

16、方案，應(yīng)該具備多方位的版本控制，通過版本的控制，合理化的提升代碼管理與持續(xù)發(fā)版的規(guī)范化。方便用戶可以快速的創(chuàng)建標(biāo)準(zhǔn)的 CI/CD 流水線。方案概述金融渠道容器云平臺方案概述通過我們對行業(yè)背景的分析和建設(shè)目標(biāo)的思考，我們認(rèn)為以容器和云原生的方案， 承載金融渠道領(lǐng)域整體系統(tǒng)建設(shè)是最佳的載體。通過容器與原生技術(shù)，可以為應(yīng)用快捷的完成技術(shù)轉(zhuǎn)型中所帶來的問題，云原生技術(shù)相關(guān)社區(qū)開發(fā)度高、社區(qū)活躍度高。以云原生技術(shù)為基建平臺的技術(shù)選型，可以解決業(yè)務(wù)開發(fā)中，語言依賴性的問題， 以容器、k8s、網(wǎng)格等核心技術(shù)，天然對支持多語言開發(fā)，支持多框架開發(fā)。下面我們來介紹一下產(chǎn)品的架構(gòu)說明：ACaaS：ACaaS 是贊

17、同科技有限公司自主研發(fā)的，面向于金融渠道領(lǐng)域建設(shè)的云原生管理平臺。平臺基于云原生社區(qū)的主要開源技術(shù)包括 Docker、Kubernetes、Ceph、Harbor、Prometheus、Istio 等，提供企業(yè)生產(chǎn)級渠道云管理服務(wù)，為企業(yè)應(yīng)用的開發(fā)、測試、集成、上線、運(yùn)維提供一站式的渠道云管理服務(wù)解決方案。ACaaS 幫助企業(yè)在公有云、私有云和物理機(jī)等任何環(huán)境中快速構(gòu)建、部署和運(yùn)維基于容器和云原生技術(shù)的 PaaS 云平臺，幫助用戶輕松實(shí)現(xiàn)微服務(wù)治理、多租戶管理、DevOps 文化支持、監(jiān)控告警、日志托管、鏡像托管、彈性伸縮、灰度發(fā)布、批次操作、應(yīng)用商店等業(yè)務(wù)場景。OpenShift :Open

18、Shift 是一個現(xiàn)代化的應(yīng)用運(yùn)行的平臺，能夠幫助企業(yè)開發(fā)、部署和管理各種不同類型的應(yīng)用無縫的運(yùn)行在不同的基礎(chǔ)設(shè)施平臺上，比如物理機(jī)、虛擬機(jī)、私有云和公有云等。OpenShift 不僅能支持基于容器的新型應(yīng)用也能夠運(yùn)行和管理現(xiàn)存的企業(yè)級應(yīng)用?；陬I(lǐng)先的開源技術(shù)，OpenShift 可以幫助開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)方便的使用新型的應(yīng)用架構(gòu)和開發(fā)方式、加速應(yīng)用開發(fā)流程、快速交付服務(wù)。針對開發(fā)人員的需求，OpenShift 提供自服務(wù)的能力，可以快速創(chuàng)建開發(fā)環(huán)境、編譯和部署應(yīng)用。OpenShift 集成了自動化的工作流，比如 s2i 流程，它可以從代碼庫獲得源代碼，對其進(jìn)行編譯打包，并最終生成基于模板的應(yīng)

19、用容器鏡像。同時 OpenShift 提供了各種不同類型的持續(xù)集成的工具，比如 Jenkins，極大的提高了開發(fā)團(tuán)隊(duì)的工作效率。針對運(yùn)維人員的需求，OpenShift 提供了基于策略的權(quán)限控制系統(tǒng)和自動化調(diào)度基于容器的應(yīng)用的能力。OpenShift 內(nèi)置了 Kubernetes 集群調(diào)度工具，可以快捷的提供負(fù)載均衡、容器調(diào)度、服務(wù)集群和自動擴(kuò)展等功能。多租戶的設(shè)計(jì)提高了平臺的安全性，不同租戶的網(wǎng)絡(luò)和物理設(shè)施可以完全隔離。OpenShift 可以將多種不同類型的存儲掛載到容器上，比如 NFS、Ceph、Gluster、SAN 等，這使得平臺不僅能夠支持無狀態(tài)的應(yīng)用，也可以支持有狀態(tài)的應(yīng)用。與所有

20、其他紅帽訂閱產(chǎn)品一樣，OpenShift 企業(yè)版從 OpenShift Origin 項(xiàng)目中提取上游開源代碼，成為一套穩(wěn)定可靠、享有支持的企業(yè)級產(chǎn)品。OpenShift 企業(yè)版的最新版本的重要發(fā)展之一就是采用了多種關(guān)鍵技術(shù)，使 PaaS 和現(xiàn)代云基礎(chǔ)架構(gòu)逐漸向?qū)崿F(xiàn)標(biāo)準(zhǔn)化邁進(jìn)。從一開始，OpenShift 就采用了容器隔離應(yīng)用，現(xiàn)在業(yè)界已將容器視為現(xiàn)代 PaaS 解決方案的基礎(chǔ)技術(shù)。隨著 OpenShift3 的推出，紅帽在容器中采用了新興標(biāo)準(zhǔn)， 并從技術(shù)和采用方面幫助推動其發(fā)展。例如，紅帽是 Docker 項(xiàng)目的首要貢獻(xiàn)者之一，該項(xiàng)目提供可移植、輕量級運(yùn)行時和打包工具。與 Google 和其他

21、企業(yè)一道， 紅帽還為 Kubernetes 編排工具的開發(fā)作出了巨大貢獻(xiàn)，其目的是通過其產(chǎn)品（如OpenShift、紅帽企業(yè) Linux）為企業(yè)客戶帶來不可變、原子級的基礎(chǔ)架構(gòu)概念。OpenShift 以 Docker 技術(shù)和 Kubernetes 框架為基礎(chǔ)，在此之上擴(kuò)展提供了軟件定義網(wǎng)絡(luò)、軟件定義存儲、權(quán)限管理、企業(yè)級鏡像倉庫、統(tǒng)一入口路由、持續(xù)集成流程（s2i/Jenkins）、統(tǒng)一管理控制臺、監(jiān)控日志等功能，形成覆蓋整個軟件生命周期的解決方案。企業(yè)若想提高開發(fā)人員的靈敏性和運(yùn)營效率，可以借助 OpenShift 企業(yè)版在企業(yè)內(nèi)部運(yùn)行經(jīng)安全固化、嚴(yán)格測試、并享有支持的 PaaS 解決方案

22、。該方案不但集合了源于上游開發(fā)社區(qū)的各類創(chuàng)新技術(shù)，更重要的是，很多使用 OpenShift 的企業(yè)用戶也將其使用的經(jīng)驗(yàn)反饋到社區(qū)和產(chǎn)品中，紅帽將所有創(chuàng)新技術(shù)有效整合后直接交付給用戶使用。OpenShift 以 Docker 技術(shù)和 Kubernetes 框架為基礎(chǔ)，在此之上擴(kuò)展提供了軟件定義網(wǎng)絡(luò)、軟件定義存儲、權(quán)限管理、企業(yè)級鏡像倉庫、統(tǒng)一入口路由、持續(xù)集成流程（s2i/Jenkins）、統(tǒng)一管理控制臺、監(jiān)控日志等功能，形成覆蓋整個軟件生命周期的解決方案。渠道容器云管理平臺 :渠道云管理平臺是由贊同云原生管理平臺 + 紅帽 -OpenShift 容器云平臺的聯(lián)合產(chǎn)品，相比于傳統(tǒng)容器云平臺廠商，

23、渠道云管理平臺更加專注于金融領(lǐng)域客戶的需求進(jìn)行建設(shè)，也是兼具了贊同科技將近三十年服務(wù)金融行業(yè)的技術(shù)沉淀和紅帽多年大型系統(tǒng)建設(shè)經(jīng)驗(yàn)。渠道云管理平臺在具備傳統(tǒng)容器云具有的能力基礎(chǔ)之上，拓展了的金融行業(yè)屬性和特性化能力建設(shè)，為渠道應(yīng)用的云化落地提供了一站式的管理系統(tǒng)，包括業(yè)務(wù)化的分析、開發(fā)、測試、部署、運(yùn)維、監(jiān)控等全方位的能力支撐。容器云平臺設(shè)計(jì)原則金融級服務(wù)更新策略金融客戶在上線系統(tǒng)應(yīng)用的過程中，往往不僅是一個應(yīng)用的發(fā)布過程，通常是多個服務(wù)一同發(fā)布，贊同渠道云管理平臺提供面向批次的一體化服務(wù)發(fā)布管理手段， 事務(wù)形服務(wù)發(fā)布控制，在發(fā)布過程中，遇到風(fēng)險(xiǎn)因素，全部服務(wù)可以進(jìn)行回退， 從而快速解決發(fā)布風(fēng)險(xiǎn)

24、。服務(wù)的發(fā)布更新過程，可以分為串行和并行兩種策略方式，對服務(wù)發(fā)布順序有強(qiáng)依賴的情況，交由串行方式。無強(qiáng)依賴的情況下，交由并行方式。發(fā)布周期故障分類為系統(tǒng)故障和業(yè)務(wù)故障。若服務(wù)發(fā)布出現(xiàn)系統(tǒng)級別故障時，由發(fā)布控制自動進(jìn)行識別標(biāo)記，自動進(jìn)行版本的回退，將可能出現(xiàn)的問題風(fēng)險(xiǎn)降低到最小，期間記錄相應(yīng)的系統(tǒng)故障審計(jì)日志， 便于跟蹤和查找問題。在故障的發(fā)布過程中，以發(fā)布單的方式進(jìn)行體現(xiàn)，可觀測業(yè)務(wù)服務(wù)所處于的狀態(tài)， 如下圖所示 :若服務(wù)發(fā)布出現(xiàn)業(yè)務(wù)形式的缺陷，管理員可以通過操作視圖，選取相應(yīng)的應(yīng)用進(jìn)行管理，可以選擇將所有版本進(jìn)行一次性的回退，還可以選擇將具體的指定版本進(jìn)行一次性的回退處理。網(wǎng)絡(luò)資產(chǎn)視角的管控

25、原則贊同渠道云管理平臺中的網(wǎng)格管理比傳統(tǒng)容器云平臺更為細(xì)粒度。針對網(wǎng)絡(luò)隔離性、端口資源管理、以網(wǎng)絡(luò)資產(chǎn)的視角對網(wǎng)絡(luò)資源進(jìn)行治理。尊重容器網(wǎng)絡(luò)開放性的前提下，具備合理化的管理手段。首先針對于網(wǎng)絡(luò)資產(chǎn)中的端口進(jìn)行統(tǒng)一化的分配管理。端口資源在網(wǎng)絡(luò)資產(chǎn)中是極為寶貴的資源，在私有云環(huán)境的建設(shè)中，合理化的端口分配機(jī)制是非常有必要的， 目前贊同基于 OpenShift 平臺，可以將端口資源以租戶、項(xiàng)目組等方式進(jìn)行劃分。在對網(wǎng)絡(luò)資源的帶寬資源上，渠道云管理平臺也具備完整的建設(shè)能力，平臺面向于租戶、項(xiàng)目組等維度，進(jìn)行網(wǎng)絡(luò)帶寬能力的劃分。由管理員通過統(tǒng)一視圖對資源進(jìn)行分配，每個用戶可以實(shí)時查看到自身的配額情況。在

26、網(wǎng)絡(luò)資源隔離性上，渠道云管理平臺具備細(xì)粒度的隔離手段，包括三個維度的隔離能力，分別包括：對應(yīng)用與應(yīng)用之間，項(xiàng)目組與項(xiàng)目組之間，租戶與租戶之間等。對應(yīng)的隔離權(quán)限也有管理員或項(xiàng)目組管理員通過統(tǒng)一化的視圖進(jìn)行實(shí)現(xiàn)。責(zé)任明確、可控的金融級流水線設(shè)計(jì) :金融級 IT 流水線能力提供，贊同渠道云管理平臺把安全可控放在第一位，在滿足效率的情況下，更加注重安全風(fēng)險(xiǎn)，不一味追求 DevOps 效率，在滿足流水線效能的情況下，對所有關(guān)鍵點(diǎn)進(jìn)行風(fēng)險(xiǎn)管控，在可控的監(jiān)管機(jī)制下，落地流水線建設(shè)。流水線的每一個環(huán)節(jié)都具備安全、可控的特點(diǎn)，并且所有環(huán)節(jié)和關(guān)鍵節(jié)點(diǎn)都具備明確的職責(zé)責(zé)任劃分。平臺提供完整 DevOps 能力的同時

27、，還將每一個環(huán)境都進(jìn)行責(zé)任人劃分，流程可以是自動執(zhí)行，也可以通過人工審批之后執(zhí)行，保障環(huán)境出現(xiàn)問題，都可進(jìn)行追溯。贊同渠道云管理平臺中的服務(wù)，是向于金融業(yè)務(wù)化的設(shè)計(jì)，以建設(shè)業(yè)務(wù)服務(wù)的視角進(jìn)行運(yùn)維化的治理，而非單純的容器化設(shè)計(jì)，容器化設(shè)計(jì)難以落地到具體應(yīng)用中，并且以一個個容器進(jìn)行運(yùn)行難以有效的責(zé)任劃分。贊同渠道云管理全部以應(yīng)用服務(wù)視角進(jìn)行平臺建設(shè)，降低復(fù)雜度和管理成本。贊同渠道云管理平臺是面向應(yīng)用業(yè)務(wù)式設(shè)計(jì)，對于開發(fā)人員和運(yùn)維人員來說，都是面向于應(yīng)用業(yè)務(wù)式的操作。開發(fā)人員提交代碼，通過流水線自動的將對應(yīng)的應(yīng)用版本進(jìn)行發(fā)布部署，配套業(yè)務(wù)版本也隨之進(jìn)行更新。運(yùn)維人員日常操作過程中，面向于應(yīng)用業(yè)務(wù)進(jìn)行

28、操作，而非面向于網(wǎng)絡(luò)、容器等非業(yè)務(wù)化的思路進(jìn)行操作，所有配置的資源都是面向于業(yè)務(wù)進(jìn)行建設(shè)，如查詢?nèi)罩举Y源，平臺僅需要輸入相關(guān)的應(yīng)用名稱，即可進(jìn)行檢索。贊同渠道云管理平臺是完全面向于金融業(yè)務(wù)化設(shè)計(jì)對服務(wù)的管理，平臺可以通過服務(wù)化的管理手段，積累自身的服務(wù)資產(chǎn)，我們的開發(fā)服務(wù)也是資產(chǎn)，贊同渠道云管理以對服務(wù)資產(chǎn)模塊化管理，助力金融客戶持續(xù)積累服務(wù)化資產(chǎn)。金融服務(wù)資產(chǎn)建設(shè)與積累設(shè)計(jì)原則贊同渠道云管理平臺是完全面向于金融業(yè)務(wù)化設(shè)計(jì)對服務(wù)的管理，平臺可以通過服務(wù)化的管理手段，積累自身的服務(wù)資產(chǎn)，我們的開發(fā)服務(wù)也是資產(chǎn)，贊同渠道云管理以對服務(wù)資產(chǎn)模塊化管理，助力金融客戶持續(xù)積累服務(wù)化資產(chǎn)。贊同渠道云管理平

29、臺將鏡像版本、源碼版本、編排文件、系統(tǒng)資源、流水線等五個部分與應(yīng)用資產(chǎn)進(jìn)行綁定，在應(yīng)用資產(chǎn)進(jìn)行打包之后，將記錄所有的資產(chǎn)信息。鏡像版本和源碼版本對應(yīng)的就是鏡像信息和源碼內(nèi)容。編排文件中記錄對于以應(yīng)用部署視角的統(tǒng)一編排文件，文件內(nèi)涵蓋網(wǎng)絡(luò)策略、啟動策略、部署形態(tài)等。系統(tǒng)資源中記錄系統(tǒng)不同資源檔位下，系統(tǒng)所具備的處理能力比對表，在后期資產(chǎn)部署的過程中，可根據(jù)處理能力的強(qiáng)弱，選擇對應(yīng)系統(tǒng)資源的檔位，而不是直接對應(yīng)用進(jìn)行如 CPU、內(nèi)存、磁盤空間的限制。流水線中記錄應(yīng)用的 DevOps 流水線編排情況，流水線記錄由代碼的研發(fā)、編譯、測試、打包、部署、環(huán)境同步等流程信息。容器云平臺帶來的應(yīng)用場景革新金融

30、渠道業(yè)務(wù)云平臺為 IT 技術(shù)轉(zhuǎn)型帶來諸多的優(yōu)化和價值，為行業(yè)的技術(shù)發(fā)展帶來了諸多變化，下面我們列舉常見的應(yīng)用場景，變更的同時，也為應(yīng)用業(yè)務(wù)帶來的諸多幫助，下面列舉了兩個常見的應(yīng)用場景，我們通過對應(yīng)用場景的講解來說明容器云平臺如何對應(yīng)用業(yè)務(wù)進(jìn)行助力。場景一 : 渠道版本更新實(shí)施策略差異化介紹傳統(tǒng)渠道業(yè)務(wù)應(yīng)用的現(xiàn)狀（未實(shí)施容器云平臺）在渠道業(yè)務(wù)的建設(shè)過程中，版本的更新過程一直都是極為重要的環(huán)節(jié)。在傳統(tǒng)架構(gòu)下，渠道應(yīng)用的更新手段相對較為單一，渠道端的版本需要涉及到服務(wù)端系統(tǒng)和客戶端系統(tǒng)兩方面內(nèi)容。目前傳統(tǒng)渠道業(yè)務(wù)更新的手段也存在一定的差異性，我們這里介紹最為常見的更新手段，此更新方式主要集中于客戶端

31、，由 IT 技術(shù)人員將柜員或者機(jī)柜中的應(yīng)用版本進(jìn)行部署升級，客戶端版本包中配置了對選定版本的路由配置，這樣就可以做到獨(dú)立柜員通過客戶端對指定版本的訪問，也控制住了響應(yīng)的版本影響范圍。在后續(xù)的驗(yàn)證過程中，逐步擴(kuò)大新版本客戶端的使用范圍。如下圖所示 :這種方式上，我們需要派 IT 工程師到指定的網(wǎng)點(diǎn)中，工程師手動的一一對客戶端進(jìn)行更新，會較為耗費(fèi)人力，并且存在人為操作的風(fēng)險(xiǎn)，效率也相對較低。在逐步擴(kuò)大影響范圍時，需要較大的人員投入，逐一到不同的網(wǎng)點(diǎn)中完成版本的更新過程，不夠靈活，規(guī)范程度也較低。搭建容器云平臺后應(yīng)用策略的革新基于渠道云的 IT 技術(shù)建設(shè)上，我們首先需要完成是客戶端的版本控制問題，上

32、面已經(jīng)提到，傳統(tǒng)架構(gòu)下，客戶端的版本更新相對復(fù)雜，靈活性也較差，基于此情況，我們首先完成了對渠道客戶端的版本更新方式的能力上收，統(tǒng)一交由上層服務(wù)端對客戶端的版本進(jìn)行控制，當(dāng)啟動更新計(jì)劃時，服務(wù)端可以根據(jù)我們的更新計(jì)劃，對指定的版本進(jìn)行更新操作。目前渠道建設(shè)的組織化劃分上，至少包含三級的組織結(jié)構(gòu)，分別為區(qū)域、網(wǎng)點(diǎn)、柜員。如下圖所示 :在渠道業(yè)務(wù)的版本更新過程中，我們期望對業(yè)務(wù)更新所帶來的影響范圍進(jìn)行合理的管控，在更新的初期，我們期望盡可能的將影響面縮小，如優(yōu)先由選定的柜員進(jìn)行測試，測試完成之后，由響應(yīng)的網(wǎng)點(diǎn)進(jìn)行測試驗(yàn)證，網(wǎng)點(diǎn)驗(yàn)證通過之后，逐步擴(kuò)大到區(qū)域和全行。所以在實(shí)際交付過程中，我們?yōu)榻鹑诳蛻?/p>

33、所建設(shè)的 IT 應(yīng)用中包含了預(yù)設(shè)的報(bào)文內(nèi)容，我們對應(yīng)用報(bào)文進(jìn)行了統(tǒng)一化的報(bào)文封裝，上報(bào)的信息包含了至少三級的組織結(jié)構(gòu)劃分的數(shù)據(jù)內(nèi)容，用以區(qū)分所上報(bào)的內(nèi)容來源于不同的組織結(jié)構(gòu)，如下所示，通訊報(bào)文的請求頭中至少包含如下三類請求頭信息 :在完成上送報(bào)文的封裝之后，可以使用容器云平臺來制定我們的灰度發(fā)布計(jì)劃。一個完整的灰度發(fā)布計(jì)劃中，首先我們需要選定首次灰度的測試范圍。在驗(yàn)證的過程中，我們根據(jù)驗(yàn)證的結(jié)果，逐步的擴(kuò)大灰度版本的影響范圍，之后在全行的推廣驗(yàn)證過程中，應(yīng)用可以妥善、優(yōu)雅的移除原有的版本。所以我們推薦通過容器云平臺服務(wù)網(wǎng)格管理策略實(shí)現(xiàn)此功能，首先服務(wù)網(wǎng)格的灰度方案是支持多語言建設(shè)的，可以適配渠

34、道業(yè)務(wù)多種多樣的 IT 技術(shù)方式。下面的介紹講解內(nèi)容，將以容器云平臺的方案視角進(jìn)行介紹。首先我們根據(jù)發(fā)布計(jì)劃，更新目標(biāo)的灰度版本，并自定義配置灰度版本的影響范圍。這里可以定義為柜員、網(wǎng)點(diǎn)等。完成版本發(fā)布之后，我們可以開始由指定的區(qū)域范圍開始對灰度版本進(jìn)行測試驗(yàn)證。期間可以隨時調(diào)整自定義的請求頭策略，用以更新灰度版本的影響范圍，同時所有的更新改動，都會實(shí)時生效：在我們完成全行級別的灰度版本驗(yàn)證之后，可以選擇繼續(xù)保留一段時間的灰度版本用以隨時回滾，也可以選擇結(jié)束灰度期，用以節(jié)省系統(tǒng)資源。通過基于渠道容器云平臺的更新策略，可以極大簡化操作流程，降低人力成本， 規(guī)范整套渠道業(yè)務(wù)的發(fā)布流程，并且功能全部

35、為可視化操作，使管理人員可以輕松上手平臺使用。場景二、渠道業(yè)務(wù)連續(xù)性保障對于渠道業(yè)務(wù)的連續(xù)性保障，也是 IT 建設(shè)中，非常重要的環(huán)節(jié)，并且在對于業(yè)務(wù)連續(xù)性的保障中，所涉及和投入的內(nèi)容項(xiàng)也不盡相同。傳統(tǒng)渠道業(yè)務(wù)應(yīng)用的現(xiàn)狀（未實(shí)施容器云平臺）在傳統(tǒng)的渠道業(yè)務(wù)技術(shù)建設(shè)中，常見保障業(yè)務(wù)連續(xù)性的手段有主備機(jī)制或者多實(shí)例機(jī)制，由上層一個網(wǎng)絡(luò)負(fù)載均衡器對后端多實(shí)例進(jìn)行負(fù)載分發(fā)。并且在渠道的應(yīng)用中，往往應(yīng)用是集中式的，諸多業(yè)務(wù)模塊都會集中在一個應(yīng)用中運(yùn)行，假如應(yīng)用運(yùn)行過程中出現(xiàn)問題，往往會影響較大的范圍，有時會諸多應(yīng)用系統(tǒng)都存在影響，并且難以有效的恢復(fù)手段，通常由運(yùn)維工程師進(jìn)到對應(yīng)的服務(wù)器中，人為排查情況，對

36、服務(wù)進(jìn)行修復(fù)動作。搭建容器云平臺后應(yīng)用策略的革新傳統(tǒng)的渠道業(yè)務(wù)系統(tǒng)建設(shè)對業(yè)務(wù)連續(xù)性的保障手段較少，相對匱乏，沒有更加完美的手段方式?；谇廊萜髟破脚_的方式的話，平臺會對應(yīng)用運(yùn)行態(tài)的整個生命周期進(jìn)行管控， 具備更為完美的管理手段。平臺的連續(xù)性保障分為兩個大的方面 : 我們定義為系統(tǒng)級保障和系統(tǒng)級保障：首先對于應(yīng)用級的保障主要包括多副本控制、自注冊自恢復(fù)、故障轉(zhuǎn)移、優(yōu)雅退出、彈性伸縮等幾個方面。以多副本控制為例，平臺提供完全可視化的副本控制管理能力，管理員可以根據(jù)自身的需求方式，隨時通過擴(kuò)容和縮容的指令按鈕完成對副本數(shù)量操作。同時還可以根據(jù)指標(biāo)數(shù)據(jù)設(shè)置自動化的彈性伸縮策略，此策略可以極大提升系統(tǒng)的資源利用率。在應(yīng)用的運(yùn)行過程里，平臺還會對應(yīng)用運(yùn)行狀態(tài)進(jìn)行實(shí)時的監(jiān)控