x86云化數(shù)據(jù)庫(kù)在電信企業(yè)數(shù)據(jù)中心的應(yīng)用與實(shí)踐

季卿 鄭夢(mèng)妍 班正波 劉娟

【摘要】? ? 本文通過對(duì)近年新興的x86云化數(shù)據(jù)庫(kù)部署方案進(jìn)行的展開分析，探索研究x86云化數(shù)據(jù)庫(kù)架構(gòu)的部署實(shí)施帶來的實(shí)際支撐能力以及集群技術(shù)的可靠性，本文以電信企業(yè)的核心數(shù)據(jù)庫(kù)作為研究主體，嘗試通過x86云化數(shù)據(jù)庫(kù)來遷移承載原有核心應(yīng)用如CBOSS、CRM、計(jì)費(fèi)等系統(tǒng)數(shù)據(jù)庫(kù)應(yīng)用。本文采用了通過梳理核心應(yīng)用系統(tǒng)，制度整體核心數(shù)據(jù)庫(kù)云化工作機(jī)制，預(yù)估云化后承載平臺(tái)的穩(wěn)定性和可靠性，進(jìn)而展開了一系列探索嘗試工作，通過實(shí)踐統(tǒng)計(jì)分析，驗(yàn)證了x86云化數(shù)據(jù)庫(kù)部署機(jī)制來承載的機(jī)制成效，為電信企業(yè)帶來了巨大的價(jià)值分析;從而為社會(huì)各大電信企業(yè)核心類應(yīng)用數(shù)據(jù)庫(kù)系統(tǒng)升級(jí)創(chuàng)新需求提供應(yīng)用實(shí)質(zhì)性的參考價(jià)值。

【關(guān)鍵詞】? ? x86云化數(shù)據(jù)庫(kù)? ? 高可用? ? 雙活容災(zāi)機(jī)制? ? CBOSS系統(tǒng)

引言

隨著數(shù)字化服務(wù)、互聯(lián)網(wǎng)+、智能終端、智能管道和流量經(jīng)營(yíng)的快速發(fā)展，為應(yīng)對(duì)數(shù)據(jù)流量爆發(fā)式增長(zhǎng)，以及用戶對(duì)服務(wù)水平要求的不斷提高，相當(dāng)長(zhǎng)的一段時(shí)間以來，傳統(tǒng)數(shù)據(jù)庫(kù)技術(shù)在生產(chǎn)實(shí)踐中表現(xiàn)出明顯的能力不足。面對(duì)現(xiàn)在業(yè)務(wù)的快速發(fā)展、數(shù)據(jù)量呈指數(shù)型增長(zhǎng)，開始存在業(yè)務(wù)風(fēng)險(xiǎn)高、投資費(fèi)用高、資源利用率低等問題，已經(jīng)無法滿足新型業(yè)務(wù)發(fā)展的需求。傳統(tǒng)電信企業(yè)核心生產(chǎn)數(shù)據(jù)庫(kù)優(yōu)化遇到新難題。

一是普遍存在設(shè)備使用年限長(zhǎng)，設(shè)備老舊，故障率較高。

二是資源利用率低，各系統(tǒng)數(shù)據(jù)庫(kù)孤島式建設(shè)，計(jì)算和存儲(chǔ)資源無法動(dòng)態(tài)調(diào)整、錯(cuò)峰共享。

三是擴(kuò)展性差，小型機(jī)單節(jié)點(diǎn)處理能力強(qiáng)，但無法水平擴(kuò)展。集中式的高端盤陣系統(tǒng)可靠性較高，同樣無法水平擴(kuò)展。

四是維護(hù)管理成本方面，小型機(jī)維護(hù)成本高，維護(hù)困難。各系統(tǒng)數(shù)據(jù)庫(kù)孤島式建設(shè)，數(shù)據(jù)庫(kù)數(shù)量多，造成維護(hù)工作量大。

五是高可用方面，大部分?jǐn)?shù)據(jù)庫(kù)雖然都是雙節(jié)點(diǎn)RAC架構(gòu)，但單節(jié)點(diǎn)月忙時(shí)使用率峰值都超過了50%，如果出現(xiàn)其中一臺(tái)故障，另外一臺(tái)無法接管全量業(yè)務(wù)，存在高風(fēng)險(xiǎn)。

為提升用戶體驗(yàn)、業(yè)務(wù)效率，IT支撐系統(tǒng)應(yīng)加快云計(jì)算和大數(shù)據(jù)技術(shù)的應(yīng)用，對(duì)采集到的數(shù)據(jù)進(jìn)行深度挖掘，構(gòu)建集中化、融合化、平臺(tái)化、安全又靈活的云化架構(gòu)是信息化發(fā)展的必然趨勢(shì)，傳統(tǒng)的數(shù)據(jù)庫(kù)架構(gòu)將逐漸被淘汰。

一、需求分析

根據(jù)調(diào)研分析，貴州公司傳統(tǒng)數(shù)據(jù)的中心生產(chǎn)集群物理機(jī)采用80c+512G+Oracle Linux 7.6，使用HP FC-SAN高端存儲(chǔ)，測(cè)試集群虛擬機(jī)采用了24c+192G+Suse 12sp3，使用的是普通共享存儲(chǔ)。我們對(duì)貴州公司三大承載中心的核心庫(kù)的業(yè)務(wù)量進(jìn)行了評(píng)估預(yù)測(cè)，如表1所示，從預(yù)測(cè)增長(zhǎng)數(shù)據(jù)來看，參照業(yè)界權(quán)威的Specint_Ratebase標(biāo)準(zhǔn)評(píng)測(cè)，對(duì)各種開放系統(tǒng)的服務(wù)器進(jìn)行性能測(cè)試，我們發(fā)現(xiàn)，現(xiàn)有“小型機(jī)+高端盤陣” 的傳統(tǒng)數(shù)據(jù)庫(kù)部署架構(gòu)已經(jīng)無法繼續(xù)滿足業(yè)務(wù)發(fā)展的需要。

傳統(tǒng)的“小型機(jī)+233高端盤陣”雖然支持對(duì)計(jì)算能力、I/O能力、可靠性要求很高的關(guān)鍵數(shù)據(jù)庫(kù)業(yè)務(wù)部署場(chǎng)景，但其橫向擴(kuò)展能力受限，性價(jià)比低，不符合x86云化原則。 “x86虛擬化資源池”IaaS技術(shù)重點(diǎn)支持應(yīng)用層（通常為無狀態(tài)）的場(chǎng)景部署，而核心數(shù)據(jù)庫(kù)需要實(shí)現(xiàn)的“x86云化數(shù)據(jù)庫(kù)部署方案”，則是采用分布式架構(gòu)，支持計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)的分布式橫向擴(kuò)展的DBaaS技術(shù)，同時(shí)也是數(shù)據(jù)庫(kù)的演進(jìn)方向。DBaaS是一種能夠快速便捷地按需從網(wǎng)絡(luò)訪問“共享的”，“可配置的” ，“彈性的”數(shù)據(jù)庫(kù)私有云，其特征是：

一是數(shù)據(jù)庫(kù)整合。公司戰(zhàn)略規(guī)劃在3年內(nèi)將目前生產(chǎn)數(shù)據(jù)庫(kù)數(shù)量減少70%。

二是數(shù)據(jù)庫(kù)資源快速交付。以前信息科技部門申請(qǐng)一套數(shù)據(jù)庫(kù)，從操作系統(tǒng)安裝，數(shù)據(jù)庫(kù)安裝，存儲(chǔ)劃分，系統(tǒng)配置，測(cè)試到交付至少需要5～10天。使用DBaaS平臺(tái)，當(dāng)天即可完成資源發(fā)布。

三是提前適應(yīng)未來的技術(shù)構(gòu)架。容器化、云化是未來數(shù)據(jù)庫(kù)的發(fā)展方向。數(shù)據(jù)庫(kù)云化從模板管理，資源分配，性能監(jiān)控，配置全量，服務(wù)提供的全棧道服務(wù)。并提供了REST接口給用戶進(jìn)行二次開發(fā)。減少用戶的運(yùn)維成本和運(yùn)維難度。

四是集群技術(shù)使用更多的集群節(jié)點(diǎn)，能提供更好的高可用性和均衡負(fù)載。

二、技術(shù)方案

因此，如何采用云化技術(shù)來設(shè)計(jì)一個(gè)健壯，靈活，高可用數(shù)據(jù)庫(kù)基礎(chǔ)架構(gòu)，將企業(yè)的核心數(shù)據(jù)庫(kù)整合到x86云化數(shù)據(jù)庫(kù)，從而為電信企業(yè)提供一個(gè)敏捷、高效、低成本的數(shù)據(jù)庫(kù)資源池。

數(shù)據(jù)庫(kù)云化技術(shù)架構(gòu)是通過引入CDB與PDB的特性搭建數(shù)據(jù)庫(kù)集群。其中CDB全稱為Container Database，即容器化數(shù)據(jù)庫(kù)容器，PDB全稱為Pluggable Database，即可插拔數(shù)據(jù)庫(kù)。傳統(tǒng)的數(shù)據(jù)庫(kù)架構(gòu)，實(shí)例與數(shù)據(jù)庫(kù)是一對(duì)一或多對(duì)一關(guān)系（RAC）：即一個(gè)實(shí)例只能與一個(gè)數(shù)據(jù)庫(kù)相關(guān)聯(lián)，數(shù)據(jù)庫(kù)可以被多個(gè)實(shí)例所加載。而實(shí)例與數(shù)據(jù)庫(kù)不可能是一對(duì)多的關(guān)系。當(dāng)使用容器化數(shù)據(jù)庫(kù)后，實(shí)例與數(shù)據(jù)庫(kù)可以是一對(duì)多的關(guān)系。我們可以使用云資源池的多臺(tái)x86機(jī)器搭建容器化數(shù)據(jù)庫(kù)集群，然后在集群中創(chuàng)建多個(gè)可插拔數(shù)據(jù)庫(kù)。

本項(xiàng)目通過采用分布式的部署方式來實(shí)現(xiàn)對(duì)上層業(yè)務(wù)的透明化。整合后，單臺(tái)服務(wù)器出現(xiàn)故障后，不影響整個(gè)平臺(tái)的服務(wù)能力，且不影響數(shù)據(jù)庫(kù)對(duì)外提供正常服務(wù)，在其中某個(gè)或多個(gè)服務(wù)器停服后，業(yè)務(wù)應(yīng)用服務(wù)器能夠透明的連接到存活的數(shù)據(jù)庫(kù)服務(wù)器上，業(yè)務(wù)無明顯感知數(shù)據(jù)庫(kù)異常。其次基于集群技術(shù)，實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)縮容能力，上層的數(shù)據(jù)庫(kù)集群，能夠利用底層的伸縮性計(jì)算資源，來實(shí)現(xiàn)集群服務(wù)能力;既數(shù)據(jù)庫(kù)對(duì)外服務(wù)具有整體性，一致性的統(tǒng)一視圖，對(duì)外層應(yīng)用完全透明，即應(yīng)用無需關(guān)注底層的架構(gòu)情況，只需關(guān)注數(shù)據(jù)庫(kù)是否能夠提供正常服務(wù)，這得益于基于云化架構(gòu)下的數(shù)據(jù)庫(kù)集群能力。

高可用方面，本項(xiàng)目采用了基于DNS+SCANIP+service的高可用方式。DNS控制容災(zāi)環(huán)境的主備切換，SCAN IP控制連接到集群內(nèi)各節(jié)點(diǎn)VIP的重定向，service控制各個(gè)數(shù)據(jù)庫(kù)之間的故障切換，如圖1所示。根據(jù)電信企業(yè)業(yè)務(wù)特性及需求，在可插拔數(shù)據(jù)庫(kù)的部署方式上，我們使用“模擬全故障場(chǎng)景資源評(píng)估法”，計(jì)算出節(jié)點(diǎn)崩潰排列組合的所有可能性，利用代碼循環(huán)的驗(yàn)證所有場(chǎng)景的資源利用情況，從而得到最優(yōu)部署方案?；谠撃Ｊ剑?dāng)出現(xiàn)單庫(kù)故障的情況下，業(yè)務(wù)可在1秒之內(nèi)自動(dòng)切換到正常節(jié)點(diǎn)，用戶對(duì)故障無感知;當(dāng)出現(xiàn)災(zāi)難級(jí)故障情況下，業(yè)務(wù)可在2分鐘內(nèi)自動(dòng)切換到容災(zāi)端恢復(fù)業(yè)務(wù)，業(yè)務(wù)連續(xù)性能力大大提高。

三、應(yīng)用情況分析

本項(xiàng)目從節(jié)約成本，最大化資源共享的角度出發(fā)，使用30臺(tái)x86服務(wù)器部署3套云化數(shù)據(jù)庫(kù)集群，分別部署在三大數(shù)據(jù)中心，共計(jì)16計(jì)算節(jié)點(diǎn)和14存儲(chǔ)節(jié)點(diǎn)，承載10套核心數(shù)據(jù)庫(kù)業(yè)務(wù)，按照雙中心架構(gòu)部署。雙中心之間通過數(shù)據(jù)庫(kù)復(fù)制技術(shù)，實(shí)現(xiàn)了數(shù)據(jù)保護(hù)，的整合，同時(shí)還包含了三中心的雙活容災(zāi)環(huán)境和UAT環(huán)境。

核心數(shù)據(jù)庫(kù)整合遷移上云分為了三個(gè)階段。第一階段為數(shù)據(jù)庫(kù)云部署設(shè)計(jì)階段。本次數(shù)據(jù)庫(kù)整合為跨平臺(tái)、版本遷移，從IBM/SUN小型機(jī)遷移至x86平臺(tái)，數(shù)據(jù)庫(kù)版本從11g/12c升級(jí)至19c。通過在老生產(chǎn)庫(kù)采集詳細(xì)的硬件信息和數(shù)據(jù)庫(kù)性能概況。對(duì)照業(yè)務(wù)需求，在集群內(nèi)合理進(jìn)行資源分配、數(shù)據(jù)庫(kù)部署設(shè)計(jì)。同時(shí)為滿足業(yè)務(wù)連續(xù)性，對(duì)災(zāi)難場(chǎng)景進(jìn)行統(tǒng)計(jì)和分析，完成PDB/Service、Dataguard的高可用部署設(shè)計(jì)，如圖2所示;第二階段為數(shù)據(jù)庫(kù)創(chuàng)建、數(shù)據(jù)遷移和測(cè)試階段。通過參考數(shù)據(jù)庫(kù)系統(tǒng)最佳實(shí)踐完成對(duì)數(shù)據(jù)庫(kù)的參數(shù)設(shè)計(jì)并創(chuàng)建數(shù)據(jù)庫(kù)。根據(jù)基準(zhǔn)測(cè)試文檔完成對(duì)集群的數(shù)據(jù)庫(kù)性能測(cè)試。由于大型業(yè)務(wù)關(guān)鍵應(yīng)用程序要在響應(yīng)時(shí)間、吞吐量、運(yùn)行時(shí)間和可用性方面提供特定服務(wù)級(jí)別的保證。對(duì)系統(tǒng)的任何更改（如升級(jí)數(shù)據(jù)庫(kù)）通常都需要進(jìn)行全面的測(cè)試和驗(yàn)證，然后才能在生產(chǎn)系統(tǒng)中實(shí)施這些更改。因此有必要在數(shù)據(jù)遷移測(cè)試完成后進(jìn)行SPA（SQL性能分析）測(cè)試，檢測(cè)由于系統(tǒng)、數(shù)據(jù)庫(kù)變更對(duì)SQL性能的影響。并通過針對(duì)性的優(yōu)化盡量減少由于系統(tǒng)環(huán)境變更對(duì)業(yè)務(wù)的影響。同時(shí)為驗(yàn)證應(yīng)用連續(xù)性、可用性，還需模擬各災(zāi)難場(chǎng)景進(jìn)行高可用測(cè)試。第三階段為遷移上云階段。在6個(gè)月內(nèi)完成10個(gè)核心數(shù)據(jù)庫(kù)（CRM、賬務(wù)等）的上云工作。

在參數(shù)設(shè)計(jì)方面，因?yàn)槿齻€(gè)集群集合了多套數(shù)據(jù)庫(kù)，需要考慮節(jié)點(diǎn)失效的情況。參考數(shù)據(jù)庫(kù)系統(tǒng)最佳實(shí)踐、Critical Issue等文檔，完成對(duì)數(shù)據(jù)庫(kù)版本的補(bǔ)丁分析及參數(shù)設(shè)計(jì)。并根據(jù)原數(shù)據(jù)庫(kù)內(nèi)存，CPU連接數(shù)，歸檔日志路徑設(shè)置，參考原數(shù)據(jù)庫(kù)參數(shù)設(shè)置，取消不需要的參數(shù)。同時(shí)按照容災(zāi)高可用的要求，極限情況下，參數(shù)設(shè)計(jì)需要滿足一個(gè)集群能夠承擔(dān)所有業(yè)務(wù)的情況。

在基礎(chǔ)性能測(cè)試方面，我們對(duì)三個(gè)數(shù)據(jù)庫(kù)集群進(jìn)行性能測(cè)試旨在驗(yàn)證數(shù)據(jù)庫(kù)在新x86架構(gòu)下的性能表現(xiàn)。通過測(cè)試工具OTEST，執(zhí)行測(cè)試SQL語(yǔ)句。監(jiān)控?cái)?shù)據(jù)庫(kù)關(guān)鍵性能指標(biāo)、吞吐量、響應(yīng)時(shí)間、數(shù)據(jù)庫(kù)統(tǒng)計(jì)、等待事件等。

在資源管理方面，為滿足業(yè)務(wù)特性及需求、針對(duì)此前分析的災(zāi)難場(chǎng)景，我們進(jìn)行了IORM（資源控制）測(cè)試。IORM（資源控制）旨在軟件層面對(duì)數(shù)據(jù)庫(kù)資源（CPU/IO）進(jìn)行限制，效果立竿見影且不需要進(jìn)行額外調(diào)整。例如在PDB發(fā)生故障切換時(shí)，通過調(diào)整同一節(jié)點(diǎn)另一PDB的CPU/IO使用量，達(dá)到故障切換時(shí)兩個(gè)PDB共存不會(huì)發(fā)生資源爭(zhēng)用的目的。

在壓力測(cè)試方面，其中最大壓力測(cè)試設(shè)計(jì)要求達(dá)到老生產(chǎn)庫(kù)最大壓力峰值的3倍以上，測(cè)試時(shí)間8小時(shí)以上。我們要求云化數(shù)據(jù)庫(kù)的單節(jié)點(diǎn)負(fù)載的CPU利用率達(dá)到85%以上、連接數(shù)達(dá)到15000、瞬時(shí)活動(dòng)連接數(shù)達(dá)到300、邏輯讀達(dá)到800萬/Sec、心跳流量>50MB/Sec、事務(wù)數(shù)量達(dá)到3000/Sec、物理讀達(dá)到1800Mb/Sec、物理寫達(dá)到500Mb/Sec（帳管數(shù)據(jù)庫(kù)增加為1500MB/Sec）、登錄達(dá)到30/Sec、硬解析達(dá)到80/Sec。

在高可用測(cè)試（PDB/Service Failover、Dataguard Failover、PDB relocate）方面，通過和業(yè)務(wù)側(cè)配合，檢測(cè)各場(chǎng)景下應(yīng)用連續(xù)性、可用性，并記錄數(shù)據(jù)庫(kù)恢復(fù)時(shí)間、應(yīng)用受影響時(shí)間。本文以CBOSS數(shù)據(jù)庫(kù)的應(yīng)用為例，CBOSS庫(kù)是該電信企業(yè)的核心業(yè)務(wù)數(shù)據(jù)庫(kù)之一，對(duì)該數(shù)據(jù)庫(kù)進(jìn)行7種場(chǎng)景的高可用測(cè)試。

在SQL性能測(cè)試方面，我們使用SPA（SQL性能分析器）進(jìn)行新老數(shù)據(jù)庫(kù)性能對(duì)比。在遷移到生產(chǎn)系統(tǒng)之前為了保證安全，必須讓測(cè)試系統(tǒng)承受與生產(chǎn)環(huán)境中的工作量很近似的壓力，以便分析系統(tǒng)級(jí)更改對(duì)整體SQL性能的影響，并在遷移到生產(chǎn)環(huán)境之前進(jìn)行必要的優(yōu)化。采集生產(chǎn)庫(kù)SPA可以在數(shù)據(jù)遷移過程中進(jìn)行。在完成SPA測(cè)試后，重點(diǎn)關(guān)注性能下降的SQL，并著手從以下4個(gè)方面進(jìn)行優(yōu)化，然后制定合理的優(yōu)化方案并驗(yàn)證方案的全局影響。

1. 對(duì)比執(zhí)行計(jì)劃和運(yùn)行統(tǒng)計(jì)的變化;

2. 抽取該SQL相關(guān)統(tǒng)計(jì)信息并分析;

3. 分析源數(shù)據(jù)庫(kù)中運(yùn)行正常的原因、19c中降級(jí)的原因;

4. 分析版本變更后控制相關(guān)變化的key（參數(shù)，隱藏參數(shù)，或者fix control）。

為了有序的完成核心數(shù)據(jù)庫(kù)上云，我們?cè)跀?shù)據(jù)遷移及各項(xiàng)測(cè)試工作完成后，對(duì)數(shù)據(jù)庫(kù)上線前做了封版檢查。根據(jù)一次停機(jī)窗口遷移一至兩個(gè)庫(kù)的工作原則，貴州移動(dòng)僅用了5個(gè)月就成功整合遷移了貴州移動(dòng)業(yè)務(wù)支撐系統(tǒng)全部10套核心數(shù)據(jù)庫(kù)。遷移割接過程平穩(wěn)順利，未出現(xiàn)回退，遷移后的數(shù)據(jù)庫(kù)性能大幅提升，業(yè)務(wù)體驗(yàn)提升顯著，且真正實(shí)現(xiàn)業(yè)務(wù)對(duì)故障無感知。

四、效益分析

4.1經(jīng)濟(jì)效益

本項(xiàng)目共計(jì)每年可為公司節(jié)省成本（設(shè)備維保、電費(fèi)等）1795萬元，并且節(jié)省的機(jī)柜位每年可間接創(chuàng)造效益318萬元。

通過本項(xiàng)目提升資源的整合度，實(shí)現(xiàn)降本增效。將之前分散在各個(gè)垂直系統(tǒng)上的數(shù)據(jù)庫(kù)整合在基于多租戶數(shù)據(jù)庫(kù)中，建立了集中式的資源集合，能夠提供統(tǒng)一的管理維護(hù)入口。老舊小型機(jī)、x86主機(jī)得以回收，降低了資源成本和維護(hù)成本。利用私有云資源池動(dòng)態(tài)擴(kuò)縮容特性，提升資源使用率。在設(shè)備維保成本方面，本項(xiàng)目采用x86云化數(shù)據(jù)庫(kù)整合了10套核心數(shù)據(jù)庫(kù)以及對(duì)應(yīng)的容災(zāi)、UAT環(huán)境，共計(jì)小型機(jī)50臺(tái)、存儲(chǔ)6套，平均每臺(tái)小型機(jī)一年維保費(fèi)用25萬元，平均每套存儲(chǔ)一年維保費(fèi)用65萬元，則每年在維保成本上可節(jié)省1640萬元。

在電費(fèi)成本方面，現(xiàn)有x86設(shè)備功耗較小，較以前減少約264千瓦/小時(shí)，按每度電0.67元計(jì)算，每年可節(jié)省電費(fèi)成本155萬元。

此外采用云化架構(gòu)后，使用的x86機(jī)器僅需要3個(gè)機(jī)柜，而此前小型機(jī)共使用50個(gè)機(jī)柜，存儲(chǔ)盤陣使用6個(gè)機(jī)柜。以IDC每個(gè)機(jī)柜年租賃費(fèi)用6萬元計(jì)算，每年可為公司間接創(chuàng)造效益318萬元。

4.2提升前臺(tái)服務(wù)感知

DBtime是反映數(shù)據(jù)庫(kù)綜合性能的核心指標(biāo)，DBtime越低，表示數(shù)據(jù)庫(kù)性能更好，本文以遷移到云化數(shù)據(jù)庫(kù)集群的CBOSS庫(kù)為例，平均綜合性能提升4倍，業(yè)務(wù)最高峰時(shí)段性能提升了13倍。 且老庫(kù)尖刺較多，新庫(kù)較老庫(kù)運(yùn)行更加平穩(wěn)。如圖4所示。

10套核心數(shù)據(jù)庫(kù)上云后，業(yè)務(wù)支撐系統(tǒng)業(yè)務(wù)體驗(yàn)明顯提升，一線業(yè)務(wù)員普遍反饋“系統(tǒng)明顯快多了”，業(yè)務(wù)體驗(yàn)明顯提升，前臺(tái)人員滿意度提高。從后臺(tái)業(yè)務(wù)辦理探測(cè)數(shù)據(jù)統(tǒng)計(jì)來看，各種關(guān)鍵業(yè)務(wù)的辦理速度均大幅提升：入網(wǎng)業(yè)務(wù)運(yùn)行速度提升4倍、套餐類業(yè)務(wù)運(yùn)行速度提升6倍、客戶資料類業(yè)務(wù)運(yùn)行速度提高34倍、繳費(fèi)賬單類業(yè)務(wù)運(yùn)行速度提升2倍;另外，日賬、月帳的出賬效率提升也非常明顯，主要出賬步驟運(yùn)行速度提升4倍。

x86服務(wù)器在穩(wěn)定性方面較傳統(tǒng)小型機(jī)要差，2020年x86計(jì)算節(jié)點(diǎn)發(fā)生故障10余次，導(dǎo)致節(jié)點(diǎn)重啟，由于采用了云化架構(gòu)的高可用設(shè)計(jì)，故障對(duì)業(yè)務(wù)是透明的，故障處理是自動(dòng)的、在線的，故障發(fā)生到恢復(fù)的全過程，業(yè)務(wù)完全無感知、無中斷，極大提升了業(yè)務(wù)支撐系統(tǒng)的服務(wù)能力，提高了客戶滿意度。

五、結(jié)束語(yǔ)

本項(xiàng)目采用了核心數(shù)據(jù)庫(kù)云化架構(gòu)，淘汰了落后產(chǎn)能，極大的降低了核心數(shù)據(jù)庫(kù)的總擁有成本，大幅提高了數(shù)據(jù)庫(kù)性能和業(yè)務(wù)響應(yīng)速度，降低故障率，提升了客戶滿意度，并且實(shí)現(xiàn)節(jié)能減排，減少對(duì)日益昂貴的機(jī)房資源等配套需求，起到降本增效的作用。