在電信行業(yè)轉(zhuǎn)型過程中，IT架構(gòu)的轉(zhuǎn)型占有十分重要的地位，對轉(zhuǎn)型的成功有著重要的支撐作用。而要了解IT架構(gòu)，首先要分析業(yè)務(wù)需求，畢竟業(yè)務(wù)需求才是IT架構(gòu)設(shè)計的本源。IT架構(gòu)設(shè)計的目標(biāo)就是滿足業(yè)務(wù)的支撐需求，換句話說，有什么樣的需求就會催生出什么樣的架構(gòu)。

業(yè)務(wù)需求的巨大差異必然帶來迥異的IT架構(gòu)設(shè)計。為什么互聯(lián)網(wǎng)業(yè)務(wù)的需求與傳統(tǒng)通信業(yè)務(wù)需求有如此巨大的差異呢？

按照Moore, Geoffrey在2011年提出的定義，傳統(tǒng)業(yè)務(wù)及其系統(tǒng)被稱為交易記錄系統(tǒng)（Systems of Record），如傳統(tǒng)的ERP系統(tǒng)，電信運營商核心BOSS系統(tǒng)，金融銀行的核心交易系統(tǒng)等；而新興的互聯(lián)網(wǎng)業(yè)務(wù)系統(tǒng)被稱為互動體驗系統(tǒng)（Systems of Engagement），如Baidu搜索引擎，淘寶商城，騰訊QQ/微信，大眾點評網(wǎng)等等。

交易記錄系統(tǒng)側(cè)重的是記錄交易數(shù)據(jù)，確保交易的安全可靠；交互體驗系統(tǒng)則側(cè)重于滿足用戶的交互體驗，在用戶交互使用中不斷發(fā)展完善。交易記錄系統(tǒng)與交互體驗系統(tǒng)在需求側(cè)重點和設(shè)計思路上都有很大的區(qū)別。

有了交易記錄系統(tǒng)和交互體驗系統(tǒng)，積累了大量的交易記錄數(shù)據(jù)和用戶交互體驗數(shù)據(jù)，數(shù)據(jù)量和數(shù)據(jù)類型的快速增長已經(jīng)超出了企業(yè)傳統(tǒng)BI系統(tǒng)的處理能力，則需要第三類系統(tǒng)來實現(xiàn)對交易記錄系統(tǒng)和交互體驗系統(tǒng)的數(shù)據(jù)聯(lián)合分析，進而推動基于數(shù)據(jù)的決策和運營，這就是大數(shù)據(jù)分析洞察系統(tǒng)。

從傳統(tǒng)電信運營商IT系統(tǒng)架構(gòu)向面向移動互聯(lián)網(wǎng)的IT系統(tǒng)架構(gòu)轉(zhuǎn)型，其背后就是從交易記錄系統(tǒng)向交互體驗系統(tǒng)的轉(zhuǎn)型思路。因此我們要想分析電信運營商IT架構(gòu)如何向互聯(lián)網(wǎng)架構(gòu)轉(zhuǎn)型，則必須分析清楚交互體驗系統(tǒng)在設(shè)計思路和方法上與交易記錄系統(tǒng)的不同。

不管是交易記錄系統(tǒng)，還是交互體驗系統(tǒng)，抑或是分析洞察系統(tǒng)，在進行系統(tǒng)架構(gòu)設(shè)計的時候，首先需要考慮三個核心的問題，即一致性（C）、可用性（A）和分區(qū)容忍性（P）三個要素的需求程度和取舍方法。根據(jù)美國著名科學(xué)家和企業(yè)家Eric Brewer提出的CAP理論：一個系統(tǒng)不可能同時滿足一致性、可用性和分區(qū)容錯性這三個需求，最多只能同時滿足其中的兩個需求。因此應(yīng)用系統(tǒng)的關(guān)注點不同，采用的策略也是不一樣的，只有準(zhǔn)確把握了應(yīng)用需求，才有可能利用好CAP理論。

對于互聯(lián)網(wǎng)應(yīng)用而言，可用性與分區(qū)容忍性的優(yōu)先級要高于數(shù)據(jù)一致性，在系統(tǒng)架構(gòu)設(shè)計上，一般將A排在第一位，可以適當(dāng)降低對C的要求，故而傾向于采用分布式架構(gòu)（即P），也就是說，對于面向互聯(lián)網(wǎng)業(yè)務(wù)的系統(tǒng)，其IT架構(gòu)的核心特征是分布式。對于傳統(tǒng)的運營商IT系統(tǒng)而言，數(shù)據(jù)一致性的優(yōu)先級最高，因此在IT架構(gòu)設(shè)計時將C排在第一位，同時兼顧A，故一般只能舍棄P，因此傾向采用集中式架構(gòu)。

那么，運營商IT架構(gòu)轉(zhuǎn)型是不是需要全盤轉(zhuǎn)向互聯(lián)網(wǎng)架構(gòu)就能成功呢？答案顯然并不能如此簡單。正確的做法應(yīng)當(dāng)是根據(jù)業(yè)務(wù)需求的不同而采取不同的策略。按照系統(tǒng)業(yè)務(wù)需求和應(yīng)用場景的不同，我們可以把運營商的業(yè)務(wù)系統(tǒng)分成三類，并根據(jù)其特點來確定IT架構(gòu)轉(zhuǎn)型的方案。

1.傳統(tǒng)BOSS交易處理系統(tǒng)

BOSS系統(tǒng)中的交易處理部分，如用戶數(shù)據(jù)庫、產(chǎn)品數(shù)據(jù)庫、訂單數(shù)據(jù)庫、賬務(wù)數(shù)據(jù)庫、用戶余額/累積量數(shù)據(jù)庫等是CAP沖突高發(fā)區(qū)，至今缺乏分布化的有效手段和方案。BOSS系統(tǒng)強調(diào)對事務(wù)的支撐，強調(diào)數(shù)據(jù)的一致性和完整性，而采用集中式數(shù)據(jù)庫模式，基于shared-disk或shared-memory技術(shù)架構(gòu)仍然是未來一段時間最現(xiàn)實穩(wěn)妥的選擇。

以O(shè)racle為代表的關(guān)系數(shù)據(jù)庫到目前為止仍然是最完善、最容易運營維護、最穩(wěn)定可靠和綜合性能最好的OLTP數(shù)據(jù)庫。因此以O(shè)racle為基礎(chǔ)進行性能的挖掘和優(yōu)化，不失為一條更具有可操作性的路子。

Oracle數(shù)據(jù)庫性能優(yōu)化主要有兩條路，一個是存儲層分布式化+數(shù)據(jù)庫一體機，這種方式成本高昂，軟硬件緊密耦合綁定，且增加了運營維護難度。另一種思路是利用全閃存介質(zhì)替代磁盤陣列作為持久化存儲，從而大幅提高數(shù)據(jù)庫性能。此種方式對Oracle數(shù)據(jù)庫應(yīng)用架構(gòu)沒有任何更改，保持了運維手段的一致性。典型的代表有IBM全閃存陣列方案，今年在國內(nèi)各大券商得到廣泛應(yīng)用和推廣，在保持現(xiàn)有應(yīng)用架構(gòu)不變的基礎(chǔ)上均提高交易能力5倍以上。

2.新興的面向互聯(lián)網(wǎng)業(yè)務(wù)平臺

運營商的面向互聯(lián)網(wǎng)業(yè)務(wù)平臺，與OTT公司的業(yè)務(wù)系統(tǒng)有著相似的業(yè)務(wù)特征和系統(tǒng)建設(shè)需求，因此可以全面學(xué)習(xí)OTT公司的系統(tǒng)架構(gòu)和建設(shè)思路。

針對互聯(lián)網(wǎng)業(yè)務(wù)平臺的應(yīng)用場景，需要根據(jù)數(shù)據(jù)類型和數(shù)據(jù)價值考慮結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲方案。此外，需要格外關(guān)注動態(tài)可擴展性和分布式計算，基于shared-nothing技術(shù)架構(gòu)構(gòu)建分布式數(shù)據(jù)庫，支持?jǐn)?shù)據(jù)節(jié)點的最大橫向擴展要求，滿足海量數(shù)據(jù)存儲與海量用戶的并發(fā)處理能力。同時采用讀寫分離操作模式，有效地減輕數(shù)據(jù)庫與I/O壓力。

3.大數(shù)據(jù)平臺

大數(shù)據(jù)領(lǐng)域?qū)儆谧x多寫少分析為主的場景，一般不用考慮CAP沖突，因此可以方便地使用分布式架構(gòu)進行設(shè)計。需重點考慮分布式文件系統(tǒng)、NoSQL數(shù)據(jù)庫、并行計算框架和流數(shù)據(jù)處理等技術(shù)，從而支持海量數(shù)據(jù)的存儲、檢索、分析及對流數(shù)據(jù)的動態(tài)實時分析處理。大數(shù)據(jù)分析提供的客戶與市場洞察、網(wǎng)絡(luò)與客戶體驗洞察優(yōu)化、運營洞察與優(yōu)化能力促進了運營商核心競爭力的提升，同時催生出新的商業(yè)模式創(chuàng)新和新的產(chǎn)品創(chuàng)新，而這正是互聯(lián)網(wǎng)時代運營商轉(zhuǎn)型戰(zhàn)略的內(nèi)容。此外，針對客戶行為及喜好的分析，為客戶提供個性化、精準(zhǔn)的服務(wù)，從而達到提升用戶體驗的目的。