機(jī)關(guān)后勤綜合管控平臺(tái)項(xiàng)目投標(biāo)方案（技術(shù)方案）

機(jī)關(guān)后勤綜合管控平臺(tái)項(xiàng)目投標(biāo)方案

目錄

第一章技術(shù)方案及說明6

1.1.技術(shù)方案措施6

1.1.1.項(xiàng)目背景6

1.1.2.項(xiàng)目目標(biāo)6

1.1.3.建設(shè)內(nèi)容7

1.1.4.建設(shè)原則9

1.1.5.安全要求10

1.1.6.總體要求15

1.1.7.系統(tǒng)架構(gòu)16

1.1.8.架構(gòu)的主要優(yōu)勢(shì)16

1.1.9.關(guān)鍵技術(shù)26

第二章系統(tǒng)安全方案49

2.1.方案設(shè)計(jì)目標(biāo)49

2.1.1.方案設(shè)計(jì)框架49

2.2.安全技術(shù)體系設(shè)計(jì)51

2.2.1.物理安全設(shè)計(jì)51

2.2.2.機(jī)房選址51

2.2.3.機(jī)房管理51

2.2.4.機(jī)房環(huán)境51

2.2.5.設(shè)備與介質(zhì)管理52

2.3.計(jì)算環(huán)境安全設(shè)計(jì)53

1

2.3.1.身份鑒別53

2.3.2.訪問控制54

2.3.3.系統(tǒng)安全審計(jì)55

2.3.4.入侵防范56

2.3.5.主機(jī)惡意代碼防范57

2.3.6.軟件容錯(cuò)58

2.3.7.數(shù)據(jù)完整性與保密性59

2.3.8.SSL無需終端用戶配置61

2.3.9.備份與恢復(fù)61

2.3.10.資源控制62

2.4.區(qū)域邊界安全設(shè)計(jì)64

2.4.1.邊界訪問控制64

2.4.2.邊界完整性檢查66

2.4.3.邊界入侵防范66

2.5.通信網(wǎng)絡(luò)安全設(shè)計(jì)69

2.5.1.網(wǎng)絡(luò)結(jié)構(gòu)安全69

2.5.2.網(wǎng)絡(luò)安全審計(jì)69

2.5.3.網(wǎng)絡(luò)設(shè)備防護(hù)70

2.6.安全管理中心設(shè)計(jì)72

2.6.1.系統(tǒng)管理72

2.6.2.審計(jì)管理73

2.7.不同等級(jí)系統(tǒng)互聯(lián)互通76

第三章實(shí)施方案77

3.1.質(zhì)量保證體系77

2

3.2.項(xiàng)目實(shí)施管理78

3.2.1.項(xiàng)目實(shí)施管理目標(biāo)78

3.2.2.項(xiàng)目實(shí)施管理內(nèi)容79

3.2.3.項(xiàng)目實(shí)施管理方式82

3.2.4.工程組織結(jié)構(gòu)82

3.2.5.系統(tǒng)開發(fā)與實(shí)施控制88

3.2.6.成本與進(jìn)度控制89

3.2.7.項(xiàng)目實(shí)施計(jì)劃89

3.2.8.項(xiàng)目質(zhì)量保證體系96

第四章測試與驗(yàn)收97

4.1.測試97

4.1.1.測試目標(biāo)97

4.1.2.測試流程說明97

4.1.3.測試需求分析97

4.1.4.測試方法與規(guī)范98

4.1.5.測試計(jì)劃104

4.1.6.測試附件105

4.1.7.缺陷管理流程和缺陷級(jí)別定義105

4.1.8.測試實(shí)施110

4.1.9.測試評(píng)估110

4.1.10.測試報(bào)告111

4.2.驗(yàn)收112

4.2.1.目的112

4.2.2.驗(yàn)收范圍112

3

4.2.3.驗(yàn)收依據(jù)112

4.2.4.驗(yàn)收內(nèi)容112

4.2.5.驗(yàn)收小組及職責(zé)114

4.2.6.驗(yàn)收工作流程115

4.3.服務(wù)團(tuán)隊(duì)整體情況119

4.4.質(zhì)量保證措施125

4.4.1.質(zhì)量管理體系標(biāo)準(zhǔn)125

4.4.2.質(zhì)量控制過程125

4.4.3.質(zhì)量評(píng)定計(jì)劃125

4.4.4.質(zhì)量管理措施127

4.4.5.軟件質(zhì)量控制127

第五章進(jìn)度保證措施130

5.1.項(xiàng)目實(shí)施計(jì)劃130

5.1.1.開發(fā)方案130

5.1.2.系統(tǒng)分析階段131

5.1.3.系統(tǒng)總體結(jié)構(gòu)設(shè)計(jì)131

5.1.4.應(yīng)用軟件概要設(shè)計(jì)131

5.1.5.系統(tǒng)詳細(xì)設(shè)計(jì)與實(shí)施階段132

5.2.培訓(xùn)計(jì)劃133

5.2.1.平臺(tái)培訓(xùn)方案133

5.2.2.培訓(xùn)方式133

5.2.3.培訓(xùn)計(jì)劃表133

5.2.4.培訓(xùn)對(duì)象134

5.2.5.培訓(xùn)方式和內(nèi)容135

4

5.3.培訓(xùn)教學(xué)方案137

5.3.1.培訓(xùn)質(zhì)量保障137

第六章售后服務(wù)140

6.1.售后服務(wù)機(jī)構(gòu)140

6.1.1.售后服務(wù)團(tuán)隊(duì)140

6.2.服務(wù)宗旨141

6.2.1.售后服務(wù)承諾內(nèi)容及措施后服務(wù)方案.141

6.2.2.特殊技術(shù)服務(wù)和支持方式141

6.2.3.日常管理制度和故障處理流程圖146

6.2.4.故障處理流程圖147

6.3.系統(tǒng)運(yùn)行與維護(hù)方案148

6.3.1.服務(wù)目標(biāo)148

6.3.2.信息資產(chǎn)統(tǒng)計(jì)服務(wù)149

6.3.3.網(wǎng)絡(luò)、安全系統(tǒng)運(yùn)維服務(wù)149

6.3.4.主機(jī)、存儲(chǔ)系統(tǒng)運(yùn)維服務(wù)155

6.3.5.數(shù)據(jù)庫系統(tǒng)運(yùn)維服務(wù)157

6.3.6.中間件運(yùn)維服務(wù)160

6.3.7.運(yùn)維服務(wù)流程161

6.4.應(yīng)急服務(wù)響應(yīng)措施168

6.4.1.應(yīng)急基本流程168

6.4.2.維護(hù)服務(wù)應(yīng)急處理流程168

6.4.3.突發(fā)事件應(yīng)急策略170

5

第一章技術(shù)方案及說明

1.1.技術(shù)方案措施

1.1.1.項(xiàng)目背景

十四五以來，中共中央多次提出加快轉(zhuǎn)變政府職能，建

設(shè)法治政府和服務(wù)型政府。黨中央和國務(wù)院的八項(xiàng)規(guī)定和

“約法三章”,對(duì)節(jié)約型機(jī)關(guān)建設(shè)有了更高的要求。為全面

規(guī)范機(jī)關(guān)事務(wù)管理工作，國務(wù)院出臺(tái)了《機(jī)關(guān)事務(wù)管理?xiàng)l

例》,行業(yè)也印發(fā)了相關(guān)條例。尤其強(qiáng)調(diào)推進(jìn)政務(wù)服務(wù)標(biāo)準(zhǔn)

化、規(guī)范化、便利化，深化政務(wù)公開，圍繞節(jié)儉節(jié)約，弘揚(yáng)

綠色機(jī)關(guān)文化，為建設(shè)節(jié)約型社會(huì)發(fā)揮示范引領(lǐng)作用。從信

息化發(fā)展角度看，以物聯(lián)網(wǎng)、數(shù)字孿生、人工智能、云平臺(tái)

為代表的信息技術(shù)發(fā)展，已使后勤信息建設(shè)具備信息基礎(chǔ)和

產(chǎn)業(yè)基礎(chǔ)；同時(shí)，不斷提升的設(shè)備智能化水平，也為后勤信

息建設(shè)創(chuàng)造了良好的技術(shù)支撐。

1.1.2.項(xiàng)目目標(biāo)

后勤服務(wù)綜合管理平臺(tái)主要是根據(jù)省局(公司)服務(wù)中

心后勤管理的內(nèi)容(如資產(chǎn)、食堂、公車、物業(yè)、安保、日

常辦公等業(yè)務(wù)),擬實(shí)現(xiàn)資產(chǎn)管理、食堂管理、公車管理、

物業(yè)管理、安保管理、日常事務(wù)管理等功能，利用物聯(lián)網(wǎng)、

三維數(shù)字化、移動(dòng)終端等技術(shù)，建設(shè)一體化、一站式的后勤

可視化管理平臺(tái)，服務(wù)于后勤管理和企業(yè)員工，實(shí)現(xiàn)智慧后

勤、精益后勤、節(jié)儉后勤、平安后勤、廉潔后勤。

6

1.1.3.建設(shè)內(nèi)容

3.1資產(chǎn)管理

借助物聯(lián)網(wǎng)技術(shù)實(shí)現(xiàn)覆蓋后勤資產(chǎn)檔案、計(jì)劃、采購、

出入庫、借用、調(diào)撥、租借、維修、盤點(diǎn)、耗材、檢測等業(yè)

務(wù)需求。應(yīng)包含固定資產(chǎn)管理、耗材管理、維修管理等。

3.2食堂管理

通過人臉識(shí)別技術(shù)和信息化管理系統(tǒng)搭載不同智能硬

件，打造便捷的食堂就餐模式，實(shí)現(xiàn)進(jìn)銷存等多模板管理，

同時(shí)收集多維度數(shù)據(jù)分析助力后勤經(jīng)營管理優(yōu)化。包括菜譜

管理、計(jì)劃管理、采購管理、消耗管理、庫存管理、就餐管

理、評(píng)價(jià)管理等。

3.3公車管理

通過北斗定位、移動(dòng)應(yīng)用等技術(shù)方案為企業(yè)提供便捷派

車、車輛監(jiān)控、實(shí)時(shí)查詢等解決方案。包括車輛檔案管理、

車輛費(fèi)用管理、車輛調(diào)度管理、駕駛員管理、智能提醒等。

3.4物業(yè)管理

集成多種智能化設(shè)備，全面覆蓋企業(yè)物業(yè)服務(wù)的各個(gè)方

面包括：宿舍管理、環(huán)境管理、停車管理(授權(quán))、快遞收

發(fā)、內(nèi)部物流、訂水、場地預(yù)約、工具借用等場景。

3.5安保管理

通過接入視頻監(jiān)控、報(bào)警檢測、梯控等系統(tǒng)的設(shè)備，獲

取邊緣節(jié)點(diǎn)數(shù)據(jù)，結(jié)合門禁、巡檢、訪客等業(yè)務(wù)功能實(shí)現(xiàn)數(shù)

7

據(jù)集成與聯(lián)動(dòng)。

3.6日常管理

包括會(huì)議室管理、考勤管理、合同管理、供應(yīng)商管理、

項(xiàng)目進(jìn)度管理等。

3.7移動(dòng)辦公

分為后勤管理人員、后勤服務(wù)人員、機(jī)關(guān)單位員工3種

角色，配合后端系統(tǒng)的各個(gè)業(yè)務(wù)模塊實(shí)現(xiàn)全流程的無紙化辦

公，用戶和后勤員工不再奔波于各種流程的人工審批。

3.8三維可視化展示

實(shí)現(xiàn)園區(qū)三維立體化數(shù)字展示。對(duì)公司園區(qū)及大樓內(nèi)部

進(jìn)行三維展示結(jié)合采集的資產(chǎn)、車輛、食堂、門禁、監(jiān)控等

數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)與三維界面相結(jié)合的動(dòng)態(tài)數(shù)據(jù)展示。

3.9與其他系統(tǒng)的接口

實(shí)現(xiàn)數(shù)字化后勤業(yè)務(wù)全場景覆蓋，不僅僅要完成業(yè)務(wù)流

程梳理和建設(shè)，還需實(shí)現(xiàn)已有業(yè)務(wù)系統(tǒng)(如財(cái)務(wù)系統(tǒng)、0A系

統(tǒng)、數(shù)據(jù)中臺(tái)等)的集成、數(shù)據(jù)交互、場景聯(lián)動(dòng)等問題。此

外還需要與門禁系統(tǒng)、道閘設(shè)備、視頻監(jiān)控系統(tǒng)、食堂消費(fèi)

系統(tǒng)、會(huì)議室系統(tǒng)、車輛導(dǎo)航系統(tǒng)等做出相應(yīng)的接口聯(lián)動(dòng)。

3.10本項(xiàng)目所包含的移動(dòng)應(yīng)用要兼容釘釘、企業(yè)微信等

主流移動(dòng)平臺(tái)產(chǎn)品，支持釘釘、企業(yè)微信等主流移動(dòng)平臺(tái)的

核心功能。

3.11兼容性要求

8

系統(tǒng)需對(duì)各類常見瀏覽器進(jìn)行兼容性優(yōu)化，保障系統(tǒng)能

在各類瀏覽器下正確打開與使用，支持主流軟、硬件。系統(tǒng)

應(yīng)同時(shí)支持但不限于x86、飛騰、鯤鵬等產(chǎn)品；應(yīng)同時(shí)支持

火狐、安全360、谷歌和IE等主流瀏覽器；應(yīng)支持金山、永

中、微軟等主流流式辦公軟件；應(yīng)支持?jǐn)?shù)科、福昕、書生和

PDF等版式軟件，其涉及的外接控件等應(yīng)用運(yùn)行環(huán)境應(yīng)同時(shí)

通過相應(yīng)生態(tài)的兼容性驗(yàn)證和現(xiàn)有windows環(huán)境兼容性驗(yàn)

證，確保終端適配；應(yīng)對(duì)移動(dòng)端Android系統(tǒng)和I0S系統(tǒng)、pc

端windows系統(tǒng)及銀河麒麟、統(tǒng)信等主流操作系統(tǒng)等進(jìn)行兼

容性支持；應(yīng)支持國產(chǎn)主流、國內(nèi)主流打印機(jī)等外設(shè)。

系統(tǒng)支持web類系統(tǒng)，根據(jù)業(yè)務(wù)需要，需對(duì)移動(dòng)與PC端

進(jìn)行雙端支持，保證各設(shè)備不同屏幕尺寸下、不同系統(tǒng)下能

夠合理、正確的展示與使用各項(xiàng)功能。移動(dòng)端應(yīng)同時(shí)支持

SaaS版和私有化版企業(yè)微信、釘釘?shù)戎髁饕苿?dòng)平臺(tái)的核心功

能，后臺(tái)管控子系統(tǒng)要求按照互聯(lián)網(wǎng)架構(gòu)，基于數(shù)字中臺(tái)共

享服務(wù)中心設(shè)計(jì)和開發(fā)。

3.12數(shù)據(jù)對(duì)接一些要求

和其他應(yīng)用系統(tǒng)進(jìn)行數(shù)據(jù)對(duì)接時(shí)，應(yīng)符合招標(biāo)方總體技

術(shù)路線，符合招標(biāo)方相關(guān)技術(shù)要求，支持多種數(shù)據(jù)對(duì)接方式，

并充分利用現(xiàn)有數(shù)據(jù)接口完成數(shù)據(jù)對(duì)接。

1.1.4.建設(shè)原則

河北煙草后勤服務(wù)綜合管理平臺(tái)的建設(shè)遵循以下基本

9

原則：

4.1.堅(jiān)持統(tǒng)籌規(guī)劃。統(tǒng)一領(lǐng)導(dǎo)，統(tǒng)一步調(diào)，協(xié)調(diào)有序推

進(jìn)，打造統(tǒng)一平臺(tái)，實(shí)現(xiàn)統(tǒng)一標(biāo)準(zhǔn)，確保后勤服務(wù)效能全面

提升。

4.2.遵循平臺(tái)戰(zhàn)略。先進(jìn)性：采用先進(jìn)的、符合標(biāo)準(zhǔn)的

平臺(tái)軟件開發(fā)技術(shù)。穩(wěn)定性：鑒于平臺(tái)應(yīng)用需求，平臺(tái)需7*24

小時(shí)穩(wěn)定運(yùn)行?？煽啃裕浩脚_(tái)運(yùn)行具有極高的可靠性，平臺(tái)

應(yīng)該有足夠的手段來保證在嚴(yán)重故障后的恢復(fù)能力。

4.3.注重用戶體驗(yàn)。以用戶為中心，注重用戶體驗(yàn)及用

戶真實(shí)需求，全面增加各個(gè)環(huán)節(jié)各個(gè)參與方的黏性。建立全

渠道、全業(yè)務(wù)、全觸點(diǎn)的用戶服務(wù)模式，重點(diǎn)提升用戶體驗(yàn)，

使得用戶在任何時(shí)間、任何地點(diǎn)、任何終端都能獲得適合自

己的服務(wù)。

4.4.重視信息安全。建立嚴(yán)格有效的安全管理制度，運(yùn)

用先進(jìn)的信息安全技術(shù)，提高系統(tǒng)防護(hù)能力，確保信息授權(quán)

訪問，確保信息公開依法合規(guī)，保證系統(tǒng)穩(wěn)定、可靠、高效

運(yùn)行。

1.1.5.安全要求

5.1基本原則

5.1.1、本項(xiàng)目要按照安全開發(fā)生命周期進(jìn)行開發(fā)。

5.1.2、按照國家信息系統(tǒng)安全等級(jí)保護(hù)防護(hù)要求，信

息系統(tǒng)在軟件開發(fā)過程中要同步梳理、同步防護(hù)相關(guān)的安全

10

技術(shù)措施、管理措施，在本項(xiàng)目建設(shè)中須嚴(yán)格執(zhí)行、不得遺

漏。

5.1.3、系統(tǒng)建設(shè)要符合行業(yè)及河北煙草信息系統(tǒng)建設(shè)

安全管理規(guī)定求。

5.1.4、安全防護(hù)中需要另行投資建設(shè)的安全防護(hù)措施，

不在本項(xiàng)目建設(shè)范圍之內(nèi)。

5.2具體要求

本系統(tǒng)必須做到的安全措施包括：在編碼階段，要具體

安全的開發(fā)框架供開發(fā)人員使用，同時(shí)要求開發(fā)人員嚴(yán)格遵

循安全編碼規(guī)范；在測試階段，通過滲透測試和代碼審計(jì)發(fā)

現(xiàn)漏洞；在發(fā)布階段，要經(jīng)過安全測試并通過后，系統(tǒng)才能

發(fā)布到線上環(huán)境，以防止產(chǎn)品攜帶安全漏洞在生產(chǎn)環(huán)境運(yùn)

行；發(fā)布過程按照安全上線規(guī)范對(duì)系統(tǒng)進(jìn)行整體加固。具體

分類要求如下：

5.2.1人員安全

投標(biāo)人及其項(xiàng)目人員需要簽訂“信息安全保密協(xié)議”,

項(xiàng)目人員進(jìn)出信息機(jī)房須按有關(guān)規(guī)定進(jìn)行登記。

5.2.2管理安全

項(xiàng)目相關(guān)介質(zhì)要進(jìn)行分類標(biāo)識(shí)，并提交信息中心統(tǒng)一歸

檔保管。硬件設(shè)備和主要部件安裝要進(jìn)行固定，并設(shè)置明顯

的不易除去的標(biāo)記，使用的通訊線須按有關(guān)規(guī)定鋪設(shè)。

5.2.3安全域

11

設(shè)計(jì)建設(shè)時(shí)，應(yīng)考慮將應(yīng)用服務(wù)與數(shù)據(jù)存儲(chǔ)服務(wù)劃分在

不同安全組，不同網(wǎng)段之間的傳輸要采取訪問防護(hù)措施。

5.2.4身份鑒別

對(duì)于操作系統(tǒng)和數(shù)據(jù)庫系統(tǒng)管理用戶要采用兩種或兩

種以上組合的鑒別技術(shù)進(jìn)行身份鑒別，不同的用戶要分配不

同的用戶名，確保用戶名具有唯一性；登錄口令必須滿足長

度8位以上且必須字母數(shù)字和特殊符號(hào)的組合，并要求定期

更換。主機(jī)、數(shù)據(jù)庫、應(yīng)用系統(tǒng)的口令應(yīng)完全獨(dú)立性，任何

一個(gè)口令的更改，不得影響其它相關(guān)系統(tǒng)的正常運(yùn)行。

5.2.5訪問控制

對(duì)服務(wù)器重要的文件、資源設(shè)置合理的訪問權(quán)限；根據(jù)

實(shí)際崗位分配用戶權(quán)限，僅授予管理需要的最小權(quán)限；操作

系統(tǒng)和數(shù)據(jù)庫系統(tǒng)特權(quán)用戶要權(quán)限分離；要限制終端登錄接

入方式、網(wǎng)絡(luò)地址范圍，登錄終端要設(shè)置超時(shí)鎖定功能；要

限制單個(gè)用戶對(duì)系統(tǒng)資源的最大或最小使用限度。

5.2.6安全審計(jì)

開啟操作系統(tǒng)、數(shù)據(jù)庫和應(yīng)用系統(tǒng)安全審計(jì)功能。管理

員、使用人員的操作日志必須可審計(jì)、可提供給第三方審計(jì)

平臺(tái)。

5.2.7軟件容錯(cuò)

系統(tǒng)具備數(shù)據(jù)有效性檢驗(yàn)和自我保護(hù)功能，保證通過人

機(jī)接口輸入或通過通信接口輸入的數(shù)據(jù)格式或長度符合系

12

統(tǒng)設(shè)定要求，當(dāng)故障發(fā)生時(shí)自動(dòng)保護(hù)當(dāng)前所有狀態(tài)，保證系

統(tǒng)能夠進(jìn)行恢復(fù)。

5.2.8資源控制

系統(tǒng)具備當(dāng)通信雙方中的一方在一段時(shí)間內(nèi)未作任何

響應(yīng)，另一方應(yīng)能夠自動(dòng)結(jié)束會(huì)話；能限制系統(tǒng)的最大并發(fā)

會(huì)話連接數(shù)；能限制單個(gè)帳戶的多重并發(fā)會(huì)話；能限制一個(gè)

時(shí)間段內(nèi)可能的并發(fā)會(huì)話連接數(shù)；能對(duì)一個(gè)訪問帳戶或一個(gè)

請(qǐng)求進(jìn)程占用的資源分配最大限額和最小限額；對(duì)以系統(tǒng)服

務(wù)水平降低到預(yù)先規(guī)定的最小值進(jìn)行檢測和報(bào)警；有服務(wù)優(yōu)

先級(jí)設(shè)定功能，并根據(jù)優(yōu)先級(jí)分配系統(tǒng)資源。

5.2.9數(shù)據(jù)安全及其備份

①、數(shù)據(jù)完整性：應(yīng)提供數(shù)據(jù)傳輸和存儲(chǔ)過程中完整性

校驗(yàn)功能，并有必要的恢復(fù)措施；②、數(shù)據(jù)保密性：對(duì)數(shù)據(jù)

的傳輸和存儲(chǔ)要采用加密措施，保證數(shù)據(jù)傳輸和存儲(chǔ)保密

性；③、備份和恢復(fù)：進(jìn)行異地?cái)?shù)據(jù)備份；采用網(wǎng)絡(luò)負(fù)載均

衡、鏈路冗余備份、設(shè)備雙機(jī)熱備等措施保證系統(tǒng)的高可用

性。

5.2.10等級(jí)保護(hù)要求

1、按照國家信息系統(tǒng)安全等級(jí)保護(hù)第二級(jí)防護(hù)要求，

進(jìn)行全面梳理、管理和防護(hù)。

2、安全防護(hù)中需要另行投資建設(shè)的安全防護(hù)措施，不

在本項(xiàng)目建設(shè)范圍之內(nèi)。

13

3、有關(guān)“二級(jí)”系統(tǒng)相關(guān)技術(shù)措施、管理措施，在本

項(xiàng)目建設(shè)中嚴(yán)格執(zhí)行、不得遺漏

5.2.11安全測評(píng)要求

以下評(píng)測的評(píng)測報(bào)告將作為本項(xiàng)目驗(yàn)收的組成部分。

5.3、信息安全等級(jí)保護(hù)的評(píng)測

5.3.1系統(tǒng)上線前應(yīng)由具有專業(yè)資質(zhì)的機(jī)構(gòu)進(jìn)行系統(tǒng)安

全性測試，測試內(nèi)容至少應(yīng)包含漏洞掃描、代碼審計(jì)等，其

測試報(bào)告作為本項(xiàng)目驗(yàn)收的組成部分。安全性測試啟動(dòng)、整

改直至測試通過所產(chǎn)生的相關(guān)費(fèi)用均包含在本次招標(biāo)中。

5.3.2本項(xiàng)目建設(shè)全過程應(yīng)嚴(yán)格落實(shí)網(wǎng)絡(luò)安全工作各項(xiàng)

要求，應(yīng)做好網(wǎng)絡(luò)安全要求的各項(xiàng)測試、整改等工作。

5.4、信息安全風(fēng)險(xiǎn)評(píng)估的評(píng)測

5.4.1本項(xiàng)目須由專業(yè)的第三方單位從風(fēng)險(xiǎn)管理角度，

評(píng)估系統(tǒng)面臨的威脅以及脆弱性導(dǎo)致安全事件的可能性，并

結(jié)合安全事件所涉及的資產(chǎn)價(jià)值進(jìn)行安全評(píng)測，提出有針對(duì)

性的抵御威脅的方法措施，為保證項(xiàng)目的安全建設(shè)、穩(wěn)定運(yùn)

行提供技術(shù)參考，將風(fēng)險(xiǎn)控制在可接受的范圍內(nèi)，達(dá)到系統(tǒng)

穩(wěn)定運(yùn)行的目的。

5.4.2信息安全風(fēng)險(xiǎn)評(píng)估測評(píng)后需要及時(shí)對(duì)信息系統(tǒng)進(jìn)

行整改。

5.4.3信息安全風(fēng)險(xiǎn)評(píng)估的評(píng)測費(fèi)用含在本次招標(biāo)中。

14

1.1.6.總體要求

本項(xiàng)目建設(shè)必須緊密結(jié)合河北省局(公司)管理的需要，

突出重點(diǎn)，穩(wěn)步推進(jìn)。系統(tǒng)開發(fā)與集成應(yīng)遵循《煙草行業(yè)信

息化建設(shè)統(tǒng)一技術(shù)平臺(tái)要求》及行業(yè)信息化總體技術(shù)架構(gòu)中

的相關(guān)規(guī)定，做到“統(tǒng)一平臺(tái)、統(tǒng)一網(wǎng)絡(luò)、統(tǒng)一數(shù)據(jù)庫、統(tǒng)

一標(biāo)準(zhǔn)”,遵循國際上先進(jìn)、成熟的技術(shù)標(biāo)準(zhǔn)，構(gòu)建應(yīng)用平

臺(tái)。以提高開發(fā)效率和系統(tǒng)的可擴(kuò)展性，降低系統(tǒng)升級(jí)、維

護(hù)成本并切實(shí)加強(qiáng)個(gè)人信息安全管理，在傳輸和存儲(chǔ)個(gè)人敏

感信息時(shí)應(yīng)采取加密措施，設(shè)置信息數(shù)據(jù)復(fù)制、下載、打印

限制等功能。項(xiàng)目建設(shè)將采用已有的企業(yè)標(biāo)準(zhǔn)、行業(yè)標(biāo)準(zhǔn)和

國家標(biāo)準(zhǔn)，遵循但不僅限于以下標(biāo)準(zhǔn)體系和要求：

《煙草行業(yè)信息化建設(shè)統(tǒng)一技術(shù)平臺(tái)要求》、《煙草行

業(yè)數(shù)字證書應(yīng)用接口規(guī)范》、《煙草行業(yè)信息系統(tǒng)安全等級(jí)

保護(hù)定級(jí)指南》等行業(yè)規(guī)范及國標(biāo)、《煙草行業(yè)網(wǎng)絡(luò)安全基

線安全規(guī)范》、《個(gè)人信息安全規(guī)范》(GB/T35273-2017)。

15

1.1.7.系統(tǒng)架構(gòu)

數(shù)字中臺(tái)

開發(fā)及運(yùn)營管理

iPaaS層

業(yè)務(wù)中臺(tái)數(shù)據(jù)中臺(tái)平臺(tái)

PaaS層數(shù)據(jù)庫緩存微服務(wù)治理消息隊(duì)列大數(shù)據(jù)處理

laaS層云管理平臺(tái)公有云&私有云&混合云

1.1.8.架構(gòu)的主要優(yōu)勢(shì)

常用的B/S系統(tǒng)開發(fā)，一般是基于單體應(yīng)用架構(gòu)，例如

Java技術(shù)開發(fā)的B/S系統(tǒng)，一般選用SSH,(Struct2、Spring、

Hibernate)或者SSM,(SpringMVC、Spring、Mybatis)框架，

開發(fā)出一個(gè)war包后將其部署到Tomcat中發(fā)布。單體應(yīng)用架

構(gòu)的開發(fā)、部署、測試較為容易，但隨著需求的不斷增加，

每一次系統(tǒng)的更新，都需要將war包重新部署，并且war包如

同滾雪球一般越滾越大，系統(tǒng)的可維護(hù)性、可靠性、靈活性

逐漸降低，維護(hù)成本越來越高，任何一個(gè)bug都會(huì)導(dǎo)致系統(tǒng)

崩潰，隨著時(shí)間的推移，整個(gè)程序的代碼量變得越來越大，

使得已有的系統(tǒng)設(shè)計(jì)和代碼變得難以維護(hù)，系統(tǒng)的構(gòu)建和部

署時(shí)間也不斷增加，單體應(yīng)用中每次功能變更、bug修復(fù)都

會(huì)導(dǎo)致整個(gè)項(xiàng)目需要進(jìn)行重新部署，增加了項(xiàng)目部署時(shí)間、

16

成本和風(fēng)險(xiǎn)。

為解決單體應(yīng)用的缺陷，F(xiàn)owler,M提出了微服務(wù)架構(gòu)，

它完全不同于單體應(yīng)用架構(gòu)，將應(yīng)用程序邏輯拆分、設(shè)計(jì)、

開發(fā)為一組小型服務(wù)，這些小型服務(wù)只關(guān)注自身所負(fù)責(zé)的功

能，不關(guān)心其他服務(wù)及其內(nèi)部實(shí)現(xiàn)。這些服務(wù)可以獨(dú)立部署

在平臺(tái)即服務(wù)PaaS(PlatformasaService)上，或者運(yùn)行在自

己的進(jìn)程中，進(jìn)程與進(jìn)程之間相互隔離，降低各服務(wù)的耦合

性，服務(wù)間通信采用輕量級(jí)通信機(jī)制REST風(fēng)格，REST是資源

表現(xiàn)層狀態(tài)轉(zhuǎn)換(REpresentationalStateTransfer),所有

獨(dú)立的服務(wù)構(gòu)成了一個(gè)完整的軟件系統(tǒng)，這些服務(wù)由于部署

在各自獨(dú)立的進(jìn)程中，各服務(wù)間內(nèi)聚性大，耦合性小，可以

采用不同的編程語言、不同的數(shù)據(jù)存儲(chǔ)技術(shù)實(shí)現(xiàn)系統(tǒng)功能，

微服務(wù)架構(gòu)由于將服務(wù)分割專注化，因此不會(huì)像傳統(tǒng)的單體

應(yīng)用程序一樣，修改一個(gè)bug或增加一個(gè)功能就要重新進(jìn)行

部署，只需要將修改的服務(wù)重新部署，不會(huì)影響其他服務(wù)的

運(yùn)行

本項(xiàng)目是基于微服務(wù)架構(gòu)的B/S應(yīng)用系統(tǒng)，后端使用

SpringCloud技術(shù)，前端使用JQueryBootstrap以及

Thymeleaf模板，數(shù)據(jù)庫使用MySQL,并采用非關(guān)系內(nèi)存數(shù)據(jù)

庫Redis進(jìn)行Session模擬和部分基礎(chǔ)功能的實(shí)現(xiàn)，使用

Intellij,IDEA集成開發(fā)環(huán)境，由于SpringCloud內(nèi)部集成

了Tomcat,所以只需要運(yùn)行啟動(dòng)類，通過相應(yīng)地址就可以訪

17

問相關(guān)服務(wù)，系統(tǒng)使用了Jmeter測試工具，對(duì)單體應(yīng)用和微

服務(wù)架構(gòu)進(jìn)行不同級(jí)別的測試，性能指標(biāo)上微服務(wù)系統(tǒng)架構(gòu)

體現(xiàn)出明顯優(yōu)勢(shì)

1、微服務(wù)技術(shù)

系統(tǒng)前端技術(shù)采用開源的Bootstrap和JQuery框架，用

戶輸入字符驗(yàn)證采用JQueryvalidate框架，Bootstrap已經(jīng)

處于github上星級(jí)項(xiàng)目(starredproject)前列，利于技術(shù)人

員編寫用戶體驗(yàn)良好的前端組件和動(dòng)作。

后端采用SpringCloud框架實(shí)現(xiàn)微服務(wù)的基本框架搭

建，數(shù)據(jù)連接與操作采用Mybatis,用戶密碼采用Shiro的MD5

加密，防止被非法人員侵入數(shù)據(jù)庫后得到用戶密碼后進(jìn)行非

法活動(dòng)，系統(tǒng)后端與前端之間的數(shù)據(jù)交互采用json字符串格

式，方便前端解析后端傳遞的內(nèi)容，數(shù)據(jù)方面，選用MySQL

來存儲(chǔ)用戶以及系統(tǒng)等的基本數(shù)據(jù)，由于各微服務(wù)運(yùn)行于各

自隔離的進(jìn)程中，無法將HTTP,Session交于統(tǒng)一的Servlet

容器，因此采用內(nèi)存數(shù)據(jù)庫Redis模擬實(shí)現(xiàn)Session,系統(tǒng)選

用Maven進(jìn)行Java的依賴包管理和項(xiàng)目的搭建，并使用Git進(jìn)

行項(xiàng)目的版本控制。

1)SpringCloud是在Java快速開發(fā)框架SpringBoot基礎(chǔ)

上構(gòu)建的一個(gè)開發(fā)框架，它在SpringBoot便利性的基礎(chǔ)上很

好地降低了微服務(wù)系統(tǒng)實(shí)現(xiàn)的門檻，如實(shí)現(xiàn)微服務(wù)的注冊(cè)與

發(fā)現(xiàn)，實(shí)現(xiàn)負(fù)載均衡，實(shí)現(xiàn)REST通信，構(gòu)建微服務(wù)網(wǎng)關(guān)等一

18

系列功能，都可以使用SpringCloud通過最簡單的配置或者

幾行編碼就完成實(shí)現(xiàn)與部署。

2)Redis是一個(gè)非關(guān)系數(shù)據(jù)庫，它可以存儲(chǔ)鍵與其他五

種不同類型的值之間的映射關(guān)系，因?yàn)镽edis數(shù)據(jù)庫本身是

基于內(nèi)存存儲(chǔ)的，所以redis的處理與運(yùn)行速度相比于傳統(tǒng)

的數(shù)據(jù)庫快速高效，Redis還可以通過簡單的設(shè)置就將存儲(chǔ)

在內(nèi)存的數(shù)據(jù)持久化到硬盤中，使之下次讀取的時(shí)候就可以

直接從硬盤中獲取數(shù)據(jù)，因?yàn)镽edis不使用關(guān)系表結(jié)構(gòu)來進(jìn)

行數(shù)據(jù)的存儲(chǔ)，所以Redis的數(shù)據(jù)庫不會(huì)強(qiáng)制要求用戶對(duì)

Redis存儲(chǔ)不同的數(shù)據(jù)進(jìn)行相應(yīng)的關(guān)聯(lián)，使用Redis使得用戶

要求進(jìn)行數(shù)據(jù)持久化時(shí)，才將這些數(shù)據(jù)存儲(chǔ)在硬盤中，從而

提高整個(gè)系統(tǒng)代碼的運(yùn)行效率，給用戶提供更好的運(yùn)行體

驗(yàn)。

3)REST是一種軟件架構(gòu)風(fēng)格，并不是一種軟件設(shè)計(jì)的標(biāo)

準(zhǔn)，REST提供了一組設(shè)計(jì)原則和約束條件，以尋求降低開發(fā)

的復(fù)雜性，提高系統(tǒng)的可伸縮性的目的。

4)Mybatis封裝了系統(tǒng)與數(shù)據(jù)庫的連接、校驗(yàn)、操作實(shí)

現(xiàn)等底層代碼的實(shí)現(xiàn)，使得用戶可以使用ML配置或者

Mybatis注解完成數(shù)據(jù)庫的連接，操作，關(guān)閉數(shù)據(jù)連接池等

基本操作，相比于JDBC、Hibernate操作數(shù)據(jù)庫，Mybatis代

碼更具易讀性優(yōu)勢(shì)。

5)Git是目前軟件開發(fā)領(lǐng)域中最好的分布式版本控制工

19

具，是Linu之父為了幫助管理Linu內(nèi)核開發(fā)所制作的一個(gè)開

源版本控制軟件。

6)Maven是一個(gè)項(xiàng)目管理工具，開發(fā)團(tuán)隊(duì)可以通過Maven

自動(dòng)完成項(xiàng)目的基礎(chǔ)工具建設(shè)，Maven使用標(biāo)準(zhǔn)的目錄結(jié)構(gòu)

和默認(rèn)構(gòu)建生命周期，基于Maven的Java項(xiàng)目中，其項(xiàng)目的

依賴包是統(tǒng)一管理的，有效避免Java項(xiàng)目的依賴包因?yàn)榘姹?/p>

原因而產(chǎn)生沖突。

7)Zuul是微服務(wù)網(wǎng)關(guān)組件，微服務(wù)網(wǎng)關(guān)是介于客戶端和

服務(wù)器端的中間層，用戶提交的所有外部請(qǐng)求都會(huì)先經(jīng)過微

服務(wù)網(wǎng)關(guān)的處理和過濾，可以實(shí)現(xiàn)用戶身份認(rèn)證與安全、審

查與監(jiān)控、動(dòng)態(tài)路由、壓力測試、負(fù)載分配、靜態(tài)響應(yīng)處理

等功能，使用Zuul微服務(wù)網(wǎng)關(guān)后，實(shí)際上封裝了系統(tǒng)內(nèi)部的

所有服務(wù)，用戶只需要和微服務(wù)網(wǎng)關(guān)交互，不必直接調(diào)用微

服務(wù)的相關(guān)接口。

8)Eureka是用于實(shí)現(xiàn)微服務(wù)架構(gòu)中的服務(wù)注冊(cè)與發(fā)現(xiàn)

的組件，服務(wù)提供者在服務(wù)啟動(dòng)時(shí)，將自身以及URL等一些

信息注冊(cè)到注冊(cè)組件中，而服務(wù)注冊(cè)組件會(huì)存儲(chǔ)各個(gè)服務(wù)提

供者的這些基本信息，各個(gè)微服務(wù)與服務(wù)發(fā)現(xiàn)組件之間通過

一定機(jī)制進(jìn)行通信，例如心跳機(jī)制，即各個(gè)微服務(wù)每隔一定

的時(shí)間向服務(wù)發(fā)現(xiàn)組件發(fā)送信息，表示自己還在運(yùn)行中，可

以被調(diào)用，若持續(xù)一段時(shí)間未向服務(wù)發(fā)現(xiàn)組件提供信息，則

服務(wù)發(fā)現(xiàn)組件會(huì)認(rèn)為該服務(wù)出現(xiàn)故障或者已被關(guān)閉，則從注

20

冊(cè)表中注銷該服務(wù)。

2、系統(tǒng)整體采用微服務(wù)架構(gòu)，如圖所示

Zuul

客戶端

請(qǐng)求

注冊(cè)

EurekaZuul

serverserver

獲取服務(wù)列表

注冊(cè)請(qǐng)求

RESTREST

類別用戶文章REST管理員REST評(píng)論

服務(wù)服務(wù)服務(wù)服務(wù)服務(wù)

每一個(gè)服務(wù)采用MVC架構(gòu)并擁有自己獨(dú)立數(shù)據(jù)源，每個(gè)

服務(wù)不需要其他服務(wù)的支持就可以獨(dú)立運(yùn)行，同時(shí)這些服務(wù)

都注冊(cè)到Eureka組件中，相互之間使用REST進(jìn)行通信，充分

降低了各服務(wù)之間的耦合度，增加了系統(tǒng)的內(nèi)聚性。

3、微服務(wù)性能分析

雪崩效應(yīng)處理機(jī)制

微服務(wù)之間是使用輕量級(jí)通信機(jī)制進(jìn)行通信，當(dāng)某一個(gè)

服務(wù)提供者因?yàn)榫W(wǎng)絡(luò)原因無法被調(diào)用時(shí)，其后的服務(wù)消費(fèi)者

都會(huì)出現(xiàn)“級(jí)聯(lián)故障”,即雪崩效應(yīng)，如下圖

21

服務(wù)C調(diào)用成功調(diào)用成功

服務(wù)B服務(wù)A正常

服務(wù)D

服務(wù)C調(diào)用成功調(diào)用失敗

服務(wù)B服務(wù)AA不可用時(shí)

服務(wù)D間

推

服務(wù)C調(diào)用失敗調(diào)用失敗移

服務(wù)B服務(wù)AA、B不可用

服務(wù)D

服務(wù)C調(diào)用失敗

調(diào)用失敗服務(wù)B服務(wù)A系統(tǒng)不可用

服務(wù)D

表1

使用Spring,Cloud的Hystri提供的熔斷機(jī)制，一旦服

務(wù)提供者出現(xiàn)錯(cuò)誤導(dǎo)致服務(wù)消費(fèi)者無法調(diào)用，系統(tǒng)會(huì)立即根

據(jù)編碼人員的設(shè)置，對(duì)請(qǐng)求失敗、超時(shí)執(zhí)行回退代碼，防止

雪崩效應(yīng)，從而提升整個(gè)系統(tǒng)的可用性

性能測試

使用Jmeter測試工具，在近似相同環(huán)境下對(duì)基于微服務(wù)

架構(gòu)系統(tǒng)與基于單體應(yīng)用的系統(tǒng)進(jìn)行測試，為了盡可能保持

測試數(shù)據(jù)的客觀性，兩個(gè)系統(tǒng)的業(yè)務(wù)功能邏輯代碼實(shí)現(xiàn)基本

相同，微服務(wù)系統(tǒng)測試結(jié)構(gòu)如下圖所示

22

JMeter

測試軟件

測試。

客戶端

獲取自

Zuul網(wǎng)

關(guān)

調(diào)用

UserAdminHomeDiscussArticleCategory

主機(jī)1主機(jī)2主機(jī)3主機(jī)4主機(jī)5主機(jī)6

表2

部署時(shí)間分析

微服務(wù)架構(gòu)相較于單體應(yīng)用的最大優(yōu)勢(shì)就是部署效率

較高，傳統(tǒng)單體應(yīng)用每修改一個(gè)功能或者缺陷就必須關(guān)閉服

務(wù)器重新部署整個(gè)項(xiàng)目，隨著需求的不斷增大，項(xiàng)目代碼量

不斷增多，重新部署耗費(fèi)更多時(shí)間，微服務(wù)由于采用領(lǐng)域驅(qū)

動(dòng)設(shè)計(jì)，每個(gè)微服務(wù)之間相互隔離，低耦合、高內(nèi)聚性使得

微服務(wù)每修改一個(gè)功能或者缺陷只需要重新部署相對(duì)應(yīng)的

微服務(wù)，其他服務(wù)可以繼續(xù)運(yùn)行不必停止。

1、分別對(duì)單體應(yīng)用和微服務(wù)架構(gòu)系統(tǒng)進(jìn)行部署，記錄

不同服務(wù)修改的部署平均時(shí)間，每個(gè)服務(wù)修改一個(gè)功能，部

署時(shí)間下表

23

不同服務(wù)數(shù)修改一個(gè)功能部署平均時(shí)間(ms)

功能1個(gè)服務(wù)2個(gè)服務(wù)3個(gè)服務(wù)

微服務(wù)223442276346

單體應(yīng)用595158276023

表3

2、分別修改單體應(yīng)用和微服務(wù)架構(gòu)系統(tǒng)中的同個(gè)服務(wù)

中的多個(gè)功能，平均部署時(shí)間數(shù)據(jù)見下表所示，修改并部署

較少服務(wù)的時(shí)候，相比于單體應(yīng)用架構(gòu)的系統(tǒng)，微服務(wù)架構(gòu)

在部署時(shí)間上花費(fèi)更少，節(jié)省了約60%的部署時(shí)間

同個(gè)服務(wù)中修改不同功能后部署平均時(shí)間(ms)

功能1個(gè)功能2個(gè)功能3個(gè)功能

微服務(wù)2222.672139.672088.67

單體應(yīng)用5971.6759295868.3

表4

24

基于微服務(wù)架構(gòu)的測試系統(tǒng)共由8個(gè)不同服務(wù)構(gòu)成，由

表3數(shù)據(jù)可得，當(dāng)修改服務(wù)數(shù)不超過兩個(gè)時(shí)，即修改服務(wù)數(shù)

占總系統(tǒng)服務(wù)數(shù)的20%左右時(shí)，微服務(wù)部署時(shí)間少于單體應(yīng)

用架構(gòu)的部署時(shí)間，實(shí)驗(yàn)結(jié)果也符合軟件故障80/20原則，

依據(jù)表4可知，當(dāng)所有修改的功能模塊是位于同個(gè)服務(wù)中時(shí)，

微服務(wù)架構(gòu)的部署的時(shí)間相比于單體應(yīng)用架構(gòu)明顯加快，原

因在于微服務(wù)修改功能模塊都在同一個(gè)服務(wù)中，只要部署該

服務(wù)而不必重新部署整個(gè)系統(tǒng)，所以避免花費(fèi)許多不必要的

部署時(shí)間和資源，相反，單體應(yīng)用架構(gòu)的系統(tǒng)，無論修改的

功能是否在同一個(gè)模塊中，都得重新部署整個(gè)系統(tǒng)，大大浪

費(fèi)了部署資源和時(shí)間，因此，微服務(wù)架構(gòu)對(duì)于軟件系統(tǒng)的維

護(hù)與部署有著很好的性能優(yōu)勢(shì)。

微服務(wù)是一個(gè)細(xì)粒度的S0A,(Service-Oriented,

Architecture,面向服務(wù)架構(gòu)),服務(wù)的劃分基于領(lǐng)域驅(qū)動(dòng)

設(shè)計(jì)，每個(gè)微服務(wù)只專注自己的職責(zé)，符合軟件設(shè)計(jì)高內(nèi)聚、

低耦合原則，微服務(wù)單獨(dú)部署，服務(wù)之間使用REST風(fēng)格通信

機(jī)制，各個(gè)微服務(wù)部署在不同主機(jī)并采用分布式管理機(jī)制。

傳統(tǒng)單體應(yīng)用程序在項(xiàng)目變得越來越龐大時(shí)，任意一個(gè)

bug將導(dǎo)致整個(gè)應(yīng)用系統(tǒng)重新部署，微服務(wù)架構(gòu)只需要部署

更新的微服務(wù)，任何一個(gè)功能修改，只需要停止對(duì)應(yīng)的微服

務(wù)，不需要暫停整個(gè)系統(tǒng)，解決了bug修復(fù)和系統(tǒng)更新需要

停止整個(gè)系統(tǒng)訪問的問題，從實(shí)驗(yàn)結(jié)果看，系統(tǒng)的性能在微

25

服務(wù)架構(gòu)系統(tǒng)上具有明顯優(yōu)勢(shì)。

未來將使用容器引擎Docker更快地將微服務(wù)進(jìn)行打包、

測試以及部署，基于進(jìn)程隔離技術(shù)的Docker,將縮短從編碼

到部署運(yùn)行的周期。

1.1.9.關(guān)鍵技術(shù)

4.1基于B/S/D三層體系結(jié)構(gòu)的運(yùn)行環(huán)境

瀏覽器Browser/WEB服務(wù)器Server/數(shù)據(jù)庫服務(wù)器

Database是解決公共信息服務(wù)以及交互相應(yīng)動(dòng)態(tài)服務(wù)最適

用的一種應(yīng)用模型。實(shí)現(xiàn)了真正意義上的瘦客戶，大大簡化

了應(yīng)用系統(tǒng)的分發(fā)、配置管理和版本管理工作。

必見叩

歐

各器生

請(qǐng)請(qǐng)求輸

庫

響應(yīng)響應(yīng)

基于B/S/D三層體系結(jié)構(gòu)的運(yùn)行環(huán)境示意圖

其中，WEB客戶端是WEB瀏覽器，例如NetscapeNavigator

或者M(jìn)icrosoftInternetEplorer。WEB服務(wù)器是任何基于

HTML的服務(wù)器，例如NetscapeEnterpriseServer或者

26

SybaseApplicationServer等。應(yīng)用服務(wù)器是對(duì)WEB服務(wù)器功

能的一種擴(kuò)展，負(fù)責(zé)權(quán)限，組件，事務(wù)，數(shù)據(jù)庫連接等管理。

最終用戶可以通過WEB瀏覽器發(fā)出請(qǐng)求，通過HTTP協(xié)議與WEB

服務(wù)器進(jìn)行通信。如果是數(shù)據(jù)請(qǐng)求，WEB服務(wù)器(應(yīng)用服務(wù)

器)與數(shù)據(jù)庫服務(wù)器通信，將返回?cái)?shù)據(jù)構(gòu)造成瀏覽器頁面返

回給用戶。

三層體系結(jié)構(gòu)特別適用于電子商務(wù)：

1.在前臺(tái)，客戶并不需要安裝特別復(fù)雜和龐大的應(yīng)用

系統(tǒng)，只需要使用操作系統(tǒng)集成的網(wǎng)絡(luò)瀏覽器即可，這使得

前臺(tái)系統(tǒng)非常方便的推廣，適用于存在非常龐大的客戶群的

情況。

2.商務(wù)處理完全放在中間的應(yīng)用服務(wù)層。客戶通過瀏

覽器發(fā)出命令(比如說：查詢，下訂單等),應(yīng)用服務(wù)層獲

得命令，進(jìn)行相應(yīng)的處理，并以HTTP的形式返回用戶結(jié)果。

這同樣適合于分散用戶，集中處理的特性。

3.數(shù)據(jù)一般存放于一個(gè)強(qiáng)大的數(shù)據(jù)服務(wù)器中，所有用

戶可以通過應(yīng)用服務(wù)器訪問數(shù)據(jù)服務(wù)器。這樣可以使用數(shù)據(jù)

集中存放，便于維護(hù)和管理。這也是當(dāng)前數(shù)據(jù)管理形式的發(fā)

展方向。

由以上敘述可知，如果用戶系統(tǒng)是一個(gè)多用戶但又需

要集中處理，數(shù)據(jù)需要集中存放的情況的話，三層結(jié)構(gòu)將是

一個(gè)不錯(cuò)的軟件模型。

27

4.2數(shù)據(jù)后臺(tái)MySQL的技術(shù)特點(diǎn)

1、MySQL的定義

MySQL是一個(gè)真正的多用戶、多線程SQL數(shù)據(jù)庫服務(wù)器。

SQL(結(jié)構(gòu)化查詢語言)是世界上最流行的和標(biāo)準(zhǔn)化的數(shù)據(jù)

庫語言。MySQL是以一個(gè)客戶機(jī)/服務(wù)器結(jié)構(gòu)的實(shí)現(xiàn)，它由一

個(gè)服務(wù)器守護(hù)程序mysqld和很多不同的客戶程序和庫組成。

SQL是一種標(biāo)準(zhǔn)化的語言，它使得存儲(chǔ)、更新和存取信

息更容易。例如，你能用SQL語言為一個(gè)網(wǎng)站檢索產(chǎn)品信息

及存儲(chǔ)顧客信息，同時(shí)MySQL也足夠快和靈活以允許你存儲(chǔ)

記錄文件和圖像。

MySQL主要目標(biāo)是快速、健壯和易用。最初是因?yàn)槲覀?/p>

需要這樣一個(gè)SQL服務(wù)器，它能處理與任何可不昂貴硬件平

臺(tái)上提供數(shù)據(jù)庫的廠家在一個(gè)數(shù)量級(jí)上的大型數(shù)據(jù)庫，但速

度更快，MySQL就開發(fā)出來。自1996年以來，我們一直都在

使用MySQL,其環(huán)境有超過40個(gè)數(shù)據(jù)庫，包含10,000個(gè)表，

其中500多個(gè)表超過7百萬行，這大約有100個(gè)吉字節(jié)(GB)的

關(guān)鍵應(yīng)用數(shù)據(jù)。

2、主要特征

下表描述MySQL一些重要的特征：

1、使用核心線程的完全多線程。這意味著它能很容易

地利用多CPU資源，以及對(duì)大量開發(fā)語言的支持，如C、C++、

Eiffel、Java、Perl、PHP、Python、和TCLAPI等等。

28

2、可運(yùn)行在不同的平臺(tái)上，適合作為以Linu為后臺(tái)服

務(wù)器和Windows環(huán)境為通用客戶端的本系統(tǒng)數(shù)據(jù)后臺(tái)。

3、支持多種列類型：1、2、3、4、和8字節(jié)長度的有符

號(hào)/無符號(hào)整數(shù)。

4、完全支持SQL結(jié)構(gòu)化查詢語言的方法，在查詢的

SELECT和WHERE部分支持全部運(yùn)算符和函數(shù)。通過一個(gè)高度

優(yōu)化的類庫實(shí)現(xiàn)SQL函數(shù)庫并且像他們能達(dá)到的一樣快速，

通常在查詢初始化后不應(yīng)該有任何內(nèi)存分配。全面支持SQL

的GROUPBY和ORDERBY子句，支持聚合函數(shù)。

5、支持ODBC語法和JDBC語法。

6、靈活且安全的權(quán)限和口令系統(tǒng)。并且它允許基于主

機(jī)的認(rèn)證?？诹钍前踩?，因?yàn)楫?dāng)與一個(gè)服務(wù)器連接時(shí)，所

有的口令傳送被加密。

7、客戶端可使用TCP/IP連接或Uni套接字(socket)或

NT下的命名管道連接MySQL。MySQL特有的SHOW命令可用來檢

索數(shù)據(jù)庫、表和索引的信息。

3、穩(wěn)定性要求

MySQL以多層結(jié)構(gòu)和不同的獨(dú)立模塊編寫，在本系統(tǒng)中，

對(duì)涉及其中有限的模塊所作的測試表明其穩(wěn)定性可以信賴：

1、ISAM表處理器--穩(wěn)定

它管理所有在MySQL3.22和早期版本中的數(shù)據(jù)的存儲(chǔ)和

檢索。在所有MySQL版本中，代碼中已經(jīng)沒有一個(gè)單獨(dú)(報(bào)

29

告的)錯(cuò)誤。得到一個(gè)損壞的數(shù)據(jù)庫表的唯一已知方法是在

一個(gè)更新中途殺死服務(wù)器，即使這樣也不大可能破壞任何數(shù)

據(jù)而不能挽救，因?yàn)樗袛?shù)據(jù)在每個(gè)查詢之間被倒入(flush)

到磁盤，而且從來沒有一個(gè)有關(guān)由于MySQL中的錯(cuò)誤而丟失

數(shù)據(jù)的錯(cuò)誤報(bào)告。

2、語法處理器和詞法分析器--穩(wěn)定

3、標(biāo)準(zhǔn)客戶程序--穩(wěn)定

這些包括mysql、mysqladmin和mysqlshow、mysqldump

及mysqlimport。

4、基本結(jié)構(gòu)式查詢語言--穩(wěn)定

基本SQL函數(shù)系統(tǒng)、字符串類和動(dòng)態(tài)內(nèi)存處理，實(shí)際測

試中未發(fā)現(xiàn)錯(cuò)誤。

5、Linu線程--Gamma

唯一發(fā)現(xiàn)的問題是fcnt1()調(diào)用，它通過使用mysqld的

--skip-locking選項(xiàng)解決。但不影響相關(guān)操作的執(zhí)行。

6、考慮JDBC與ODBC互連的操作

MyODBC(使用ODBCSDK2.5)使用良好，在通過JSP頁面

的JDBC語法通過0DBC調(diào)用后臺(tái)MySQL的試驗(yàn)中表現(xiàn)良好。

4.3JSP技術(shù)一跨平臺(tái)的網(wǎng)絡(luò)開發(fā)語言

何為JavaServerPage?

ApplicationServer支持一種功效強(qiáng)大的制作動(dòng)態(tài)Web

頁面方法：JavaServerPages(JSP)。JSP的優(yōu)點(diǎn)之一就是它

30

們使您能在Web頁面中有效地分離HTML編碼和商業(yè)邏輯。JSP

規(guī)范的IBM擴(kuò)展中包括類似HTML標(biāo)記的JSP標(biāo)記，并且便于

HTML編程人員將Java的強(qiáng)大功能添加到Web頁面中。

缺乏程序設(shè)計(jì)技巧的HTML編程人員可開發(fā)用于訪問數(shù)

據(jù)庫和可重用Java組件的JSP,例如小服務(wù)程序和

JavaBeans。程序員創(chuàng)建了可重用Java組件，并為HTML編程

人員提供組件名稱和屬性。數(shù)據(jù)庫管理員則為HTML編程人員

提供數(shù)據(jù)庫訪問和表名信息。

4.4Java技術(shù)的應(yīng)用

1、Servlet技術(shù)一靈活的服務(wù)器端應(yīng)用程序

1.1何為Servlet技術(shù)

Servlet是是JAVA2.0中新增的一個(gè)全新功能。他是與

Applet相對(duì)應(yīng)的，Applet是運(yùn)行在客戶端的瀏覽器，而

Servlet是運(yùn)行在服務(wù)器端的。JAVAServlets是運(yùn)行在請(qǐng)求/

面向請(qǐng)求服務(wù)器上的模塊，一個(gè)servlet可以從一個(gè)HTML訂

單表中獲取數(shù)據(jù)然后用一些商業(yè)上的算法來更新公司相應(yīng)

的訂單數(shù)據(jù)庫。

也就是說：servlet能夠象CGI腳本一樣擴(kuò)展WEB服務(wù)器

功能，但是servlet占用很少密集資源，當(dāng)一個(gè)服務(wù)器裝載

servlet時(shí)，它運(yùn)行servlet的init方法.這個(gè)方法不能反復(fù)

調(diào)用，一旦調(diào)用就是再裝載servlet.直到服務(wù)器調(diào)用

destroy方法卸載servlet后才能再調(diào)用.每個(gè)新的CGI要求

31

在服務(wù)器上新增一個(gè)進(jìn)程。如果多個(gè)用戶并發(fā)地訪問該程

序，這些進(jìn)程將消耗該Web服務(wù)器所有的可用資源，并且系

統(tǒng)性能降低到極其低下的地步。有很多用CGI腳本編制的一

些站點(diǎn)由于訪問量劇增，性能迅速下降，這是CGI腳本一個(gè)

缺點(diǎn)。同時(shí)由于servlet是用java編寫的，因此是跨平臺(tái)的。

1.2Servlet工作原理

與小應(yīng)用程序在瀏覽器上運(yùn)行并擴(kuò)展了瀏覽器的功能

相似，HTTP小服務(wù)程序在啟用Java的Web服務(wù)器上運(yùn)行并擴(kuò)

展了Web服務(wù)器的功能。小服務(wù)程序是使用Java小服務(wù)程序

應(yīng)用程序設(shè)計(jì)界面(API)以及關(guān)聯(lián)的類和方法的Java程序。

除了JavaServletAPI外，小服務(wù)程序還可以使用擴(kuò)展API的

Java類軟件包。

HTTP小服務(wù)程序通過創(chuàng)建在Web上提供請(qǐng)求和響應(yīng)服務(wù)

的框架，擴(kuò)展了Web服務(wù)器的功能。當(dāng)客戶機(jī)發(fā)送請(qǐng)求至服

務(wù)器時(shí)，服務(wù)器可以將此請(qǐng)求信息發(fā)送給小服務(wù)程序，并讓

小服務(wù)程序構(gòu)造客戶機(jī)響應(yīng)。

小服務(wù)程序可在裝入應(yīng)用程序時(shí)自動(dòng)裝入，也可以在客

戶機(jī)第一次請(qǐng)求它提供服務(wù)時(shí)裝入。裝入完成后，小服務(wù)程

序仍繼續(xù)運(yùn)行，以等待其它客戶機(jī)請(qǐng)求。通過使用小服務(wù)程

序別名(小服務(wù)程序URL),您可以裝入小服務(wù)程序的多個(gè)

實(shí)例(每個(gè)別名都有不同的實(shí)例)。

小服務(wù)程序可執(zhí)行的功能范圍很廣。例如，它能夠：

32

根據(jù)客戶機(jī)請(qǐng)求的性質(zhì)，創(chuàng)建并返回一個(gè)包含相應(yīng)動(dòng)態(tài)

內(nèi)容的HTML頁面。

創(chuàng)建可嵌入到現(xiàn)有HTML頁面中的部分HTML頁面(HTML片

段)。

與其它服務(wù)器資源(包括數(shù)據(jù)庫和基于Java的應(yīng)用程

序)進(jìn)行通信。

與其它小服務(wù)程序進(jìn)行通信。例如，您可以使用

“WebSphere管理控制臺(tái)”來定義小服務(wù)程序過濾(一系列

小服務(wù)程序，也稱為小服務(wù)程序鏈)。

對(duì)特殊處理采用MIME類型過濾數(shù)據(jù)，例如圖像轉(zhuǎn)換和服

務(wù)器端包括(SSI)。

處理與多個(gè)客戶機(jī)的連接，接收來自多個(gè)客戶機(jī)的輸

入，并將結(jié)果廣播到多個(gè)客戶機(jī)上。例如，一個(gè)小服務(wù)程序

可以是多參與者的游戲服務(wù)器。

1.3Servlet的生命周期

如下圖中所說明的，小服務(wù)程序的生命周期始于將它裝

入Web服務(wù)器的內(nèi)存，結(jié)束于小服務(wù)程序終止或重新裝入時(shí)。

33

創(chuàng)紅

初女白化

(初女白化失文)

可用于務(wù)不可用于服務(wù)

不可用

4天棄

服務(wù)請(qǐng)求皮不

年p載

Servlet的生命周期

ServletAPI,是用來寫servlet的，編寫servlet是已沒

有CGI腳本那樣諸如關(guān)心一個(gè)servlet是這樣被裝載，

servlet運(yùn)行的服務(wù)器環(huán)境是什么,或者用來傳輸數(shù)據(jù)的協(xié)

議是什么等等，這樣servlets就可以融合在不同的web服務(wù)

器中。

Servlet可以相當(dāng)有效地替代CGI腳本：它可以方便地產(chǎn)

生容易編寫而且運(yùn)行快的動(dòng)態(tài)文本。可以很方便的調(diào)試尋找

出程序問題。Servlet程序是用JavaServletAPI開發(fā)的。

1.4Servlet應(yīng)用范圍

下面是一些Servlet應(yīng)用范圍：

?用于處理HTML表單通過HTTPS產(chǎn)生POST數(shù)據(jù)。包括買賣

訂單或信用卡數(shù)據(jù)。因此Servlet可以成為訂單處理系統(tǒng)的

一部分，和產(chǎn)品存貨數(shù)據(jù)庫一道工作，也許可以用在在線支

34

付系統(tǒng)上。

?允許人們之間的合作。一個(gè)Servlet能并發(fā)處理多個(gè)請(qǐng)

求；他們可以使用在諸如在線會(huì)議這樣的同步請(qǐng)求支持系

統(tǒng)。

?轉(zhuǎn)送請(qǐng)求。Servlet可以轉(zhuǎn)送請(qǐng)求給其他的服務(wù)器和

Servlets,這就允許在鏡象同樣內(nèi)容的幾個(gè)服務(wù)器之間平衡

負(fù)載，按照任務(wù)類型或組織范圍，可以允許被用來在幾個(gè)服

務(wù)器中劃分邏輯上的服務(wù)器。

?Servlet編寫者們可以定義彼此之間共同工作的激活

代理，每個(gè)代理者是一個(gè)Servlet,而且代理者能夠在他們

之間傳送數(shù)據(jù)。

1.5JavaApple技術(shù)一實(shí)現(xiàn)統(tǒng)計(jì)數(shù)據(jù)在網(wǎng)頁上的動(dòng)態(tài)顯

示

JavaApplet是專門用于Web頁面中運(yùn)行的程序。當(dāng)一個(gè)

JavaApplet嵌入在Web頁面并且當(dāng)用戶訪問該頁面時(shí)，

Applet被下載到用戶的計(jì)算機(jī)中并開始執(zhí)行。

系統(tǒng)的重要功能之一是統(tǒng)計(jì)的功能，具體到網(wǎng)頁設(shè)計(jì)

中，即統(tǒng)計(jì)數(shù)據(jù)的圖形化顯示，如chart表，餅狀圖等，通

過這些圖表在網(wǎng)頁上的自動(dòng)生成可以為企業(yè)的管理提供直

接的幫助。

圖表的生成完全可以通過JavaApplet小程序?qū)崿F(xiàn)在網(wǎng)

頁上。通過JavaGraphics類，我們可以方便的畫出任何給定

35

數(shù)據(jù)的圖表，從而對(duì)企業(yè)的決策提供重要的幫助。

1.5JavaBeans技術(shù)一組件開發(fā)概念

JavaBeans是為了重用目的而專門設(shè)計(jì)的Java類。這種

可重用類在許多程序設(shè)計(jì)語言中都被應(yīng)用，稱為軟件組件。

在本系統(tǒng)的開發(fā)上，應(yīng)用JavaBeans技術(shù)，可以簡化后

臺(tái)應(yīng)用程序的開發(fā)，通過定義組件，可以將開發(fā)的對(duì)象由40

個(gè)簡化為10多個(gè)基類，通過定義可重用的類，提高了開發(fā)效

率，也提高了后臺(tái)服務(wù)程序的可讀性和可維護(hù)性。

4.5通過ML語言實(shí)現(xiàn)Internet上的數(shù)據(jù)交換

1ML會(huì)帶來什么

SGML(通用標(biāo)記語言標(biāo)準(zhǔn)IS08879:1986)是HTML的前身

技術(shù)。它是文件和文件中信息的構(gòu)成主體。SGML與HTML不同，

它允許用戶擴(kuò)展tag集合，允許用戶建立一定的規(guī)則。SGML

所產(chǎn)生的tag集合是用來描敘信息段特征的。而HTML僅僅只

是一個(gè)tag集合。所以我們可以說HTML是一個(gè)SGML的子集。

ML開發(fā)者源于SGML的設(shè)計(jì)和應(yīng)用者。他們已經(jīng)在SGML上

投入了大量精力。但他們卻發(fā)現(xiàn)SGML并沒有完全發(fā)揮它的作

用，他們當(dāng)然有其充分的理由。我們可以列舉以下幾個(gè)重要

方面給大家.在這些方面SGML帶來的影響可以說是一場革

命。

對(duì)EDI的支持

EDI就是電子數(shù)據(jù)交換。它是網(wǎng)絡(luò)發(fā)展的一個(gè)主要目的

36

市場。結(jié)構(gòu)化信息的一個(gè)主要目的就要使數(shù)據(jù)交換成為可

能。不同的工業(yè)都制定本工業(yè)統(tǒng)一的模型.就像是不同的國

家有著不同的語言，這便于本國文化的交流。不同的工業(yè)內(nèi)

部信息用統(tǒng)一的模型標(biāo)識(shí)，便能方便和高效地共享。這樣一

個(gè)統(tǒng)一的模型就是DTD(文件類型定義)。當(dāng)然DTD已經(jīng)落伍

了，它正被ML的Schema(模式)所替代。很明顯的，網(wǎng)絡(luò)是一

個(gè)理想的電子數(shù)據(jù)的集散地。在這里HTML是顯然有缺陷的數(shù)

據(jù)形式.HTML不能完全表示不同工業(yè)中所需的不同的令人滿

意的模型和它的語義。能不能有一種新的語言來解決這個(gè)問

題呢?答案就是ML。

對(duì)Java技術(shù)的幫助

Java技術(shù)是本世紀(jì)最重要的技術(shù)發(fā)展之一.Java使瀏覽

器工作時(shí)就像在通用的應(yīng)用平臺(tái)上，而平臺(tái)與平臺(tái)之間卻是

獨(dú)立的.但固定的tag集合和HTML語義上的貧瘠使得Java的

應(yīng)用受到了極大的限制.正如前面提到的，在HTML中不同的

語義無法表現(xiàn).故數(shù)據(jù)元中豐富的信息得不到一種統(tǒng)一的表

示.ML卻能完全勝任這份工作.

HTML頁面要依賴網(wǎng)絡(luò)服務(wù)器上的CGI腳本來表現(xiàn)幾乎每

一個(gè)編程函數(shù).這顯然使服務(wù)器工作量太大.有了ML和Java

技術(shù)，更多的應(yīng)用軟件處理起來將不占用多少網(wǎng)絡(luò)通信量.

這使得網(wǎng)絡(luò)更加快捷，客戶可以同時(shí)應(yīng)用多個(gè)應(yīng)用軟件.

2、ML的應(yīng)用

37

最初ML的目標(biāo)是讓各種結(jié)構(gòu)的文件都作為統(tǒng)一的網(wǎng)絡(luò)

文件的一部分在網(wǎng)上傳輸。HTML允許指定明確的元素類型說

明，比如特定的商品標(biāo)號(hào)，文檔標(biāo)識(shí)，或是可測量的數(shù)值。

和HTML相比，ML允許客戶定義他們自己的文件元素集合，同

時(shí)也可以指示這些素元在屏幕上如何按指定的要求表現(xiàn)。

為了解決怎樣在固定的目標(biāo)之間傳輸數(shù)據(jù)元，ML被定義

為一種自然的編碼形式。一種被稱為RDF(資源描敘框架)的

方案倍受親睞。RDF為ML提供了數(shù)據(jù)元編碼定義，這就像是

一個(gè)公用的翻譯器，為不同的固定目標(biāo)之間的數(shù)據(jù)提供翻

譯。

ML支持更加專業(yè)的數(shù)據(jù)語言。比如說0SD(開放軟件描

敘).0SD是由Microsoft和Marimba提出的一種新的格式描敘

語言。在這種格式下，軟件在網(wǎng)上能時(shí)時(shí)檢查，時(shí)時(shí)刷新版

本。不是等用戶自己更新，或由是軟件提供商提供類似的服

務(wù)。當(dāng)0SD鑲嵌于ML支持的CDF(頻道定義格式)中時(shí)，0SD更

能使支持頻道的桌面自動(dòng)地更新。

ML的應(yīng)用彌補(bǔ)了許多HTML的缺陷，我們把它在網(wǎng)上的應(yīng)

用總結(jié)為四點(diǎn)：

1.當(dāng)網(wǎng)絡(luò)客戶必須在不同的數(shù)據(jù)庫之間傳遞信息時(shí)的

應(yīng)用.

2.當(dāng)需要把大部分從網(wǎng)絡(luò)服務(wù)器載下的數(shù)據(jù)在用戶端

處理時(shí)的應(yīng)用.

38

3.當(dāng)相同的數(shù)據(jù)對(duì)于不同的用戶需要有不同的界面時(shí)

的應(yīng)用.

4.當(dāng)網(wǎng)絡(luò)情報(bào)供貨商要把發(fā)現(xiàn)的信息精心裁減，并發(fā)送

給不同的個(gè)人用戶時(shí)的應(yīng)用.

4.6中臺(tái)

一、中臺(tái)的誕生

中臺(tái)戰(zhàn)略是企業(yè)數(shù)字化轉(zhuǎn)型過程中的一個(gè)熱門話題。說

到中臺(tái)轉(zhuǎn)型，企業(yè)大多對(duì)標(biāo)阿里巴巴。

2015年阿里巴巴提出了“大中臺(tái)，小前臺(tái)”的中臺(tái)戰(zhàn)略，

提出之初阿里有近4億用戶，為超過1000萬各類企業(yè)提供服

務(wù)，業(yè)務(wù)種類繁多，業(yè)務(wù)之間相互網(wǎng)狀依賴。同時(shí)，阿里部

門也越來越多，分工越來越細(xì)，溝通過多，相互依賴，創(chuàng)新

成本非常高，對(duì)業(yè)務(wù)響應(yīng)也越來越慢。阿里需要找到能夠?qū)?/p>

外界變化快速反應(yīng)，整合阿里各種基礎(chǔ)能力，高效支撐業(yè)務(wù)

創(chuàng)新的機(jī)制。

相信很多公司或多或少都遇到過類似的問題，或者隨著

企業(yè)規(guī)模越來越大，也正面臨著同樣的問題。

二、中臺(tái)與平臺(tái)

阿里業(yè)務(wù)中臺(tái)的發(fā)展歷程。

阿里中臺(tái)從業(yè)務(wù)中臺(tái)和數(shù)據(jù)中臺(tái)開始，后來發(fā)展出移動(dòng)

中臺(tái)、技術(shù)中臺(tái)、研發(fā)中臺(tái)等。

39

企業(yè)中臺(tái)典型架構(gòu)

互聯(lián)屬(移動(dòng))社交甲臺(tái)體檢式量銷通傳統(tǒng)營銷通道

營銷

客推廣云商運(yùn)nt體情廣告每深體電話，位，

戶

前

開臺(tái)

練下同點(diǎn)

而轉(zhuǎn)化大障h棉動(dòng)

營和交享商城商門戶需a直ga

信機(jī)在服務(wù)

者

電訂單口

中營

業(yè)務(wù)中臺(tái)數(shù)據(jù)中臺(tái)

營臺(tái)責(zé)撐

人

贊

管3戶管薄管鋼理

后內(nèi)部

臺(tái)管理

臺(tái)及后務(wù)管

人勤支

勝替人

語偶公管

有的企業(yè)十多年前就已經(jīng)完成了大一統(tǒng)的集中式系統(tǒng)

拆分，將公共能力和核心能力分開建設(shè)，解決了公共模塊重

復(fù)投入和重復(fù)建設(shè)的問題。有的企業(yè)共享平臺(tái)建設(shè)時(shí)間甚至

比阿里還要早，但并沒有發(fā)展成為像阿里一樣的中臺(tái)。

阿里這十年經(jīng)歷了光速發(fā)展，同時(shí)業(yè)務(wù)領(lǐng)域快速擴(kuò)張也

增加了業(yè)務(wù)的復(fù)雜性，這種業(yè)務(wù)發(fā)展也只有像阿里這樣的互

聯(lián)網(wǎng)企業(yè)才會(huì)遇到?？梢哉f：業(yè)務(wù)的發(fā)展和復(fù)雜性推動(dòng)了阿

里中臺(tái)的誕生。

我們?cè)龠M(jìn)一步來了解阿里業(yè)務(wù)中臺(tái)的目標(biāo)。

“業(yè)務(wù)中臺(tái)是把核心服務(wù)鏈路(會(huì)員、商品、交易、營

銷、店鋪、資金結(jié)算等)整體當(dāng)作一個(gè)平臺(tái)產(chǎn)品來做，為前

端業(yè)務(wù)提供的是業(yè)務(wù)解決方案，而不是彼此獨(dú)立的系統(tǒng)?！?/p>

平臺(tái)化只是將部分公共模塊獨(dú)立為共享平臺(tái)。雖然平臺(tái)

通過API接口或者數(shù)據(jù)共享對(duì)外提供公共服務(wù)，解決了重復(fù)

40

建設(shè)的問題，但由于這類平臺(tái)并沒有與企業(yè)內(nèi)其他平臺(tái)或應(yīng)

用實(shí)現(xiàn)頁面、業(yè)務(wù)流程和數(shù)據(jù)從前端到后端企業(yè)級(jí)的全面融

合，沒有將核心業(yè)務(wù)服務(wù)鏈路作為一個(gè)整體方案考慮，各平

臺(tái)仍然是獨(dú)立和分離的，本質(zhì)上仍然為豎井式建設(shè)模式。

三、中臺(tái)

“中臺(tái)是一個(gè)基礎(chǔ)的理念和架構(gòu)，我們要把所有的基礎(chǔ)

服務(wù)用中臺(tái)的思路建設(shè)，進(jìn)行聯(lián)通，共同支持上端的業(yè)務(wù)。

業(yè)務(wù)中臺(tái)更多的是支持在線業(yè)務(wù)，數(shù)據(jù)中臺(tái)提供了基礎(chǔ)數(shù)據(jù)

處理能力和很多的數(shù)據(jù)產(chǎn)品給所有業(yè)務(wù)方去用。業(yè)務(wù)中臺(tái)、

數(shù)據(jù)中臺(tái)、算法中臺(tái)等等一起提供對(duì)上層業(yè)務(wù)的支撐。”

我們提煉幾個(gè)中臺(tái)的關(guān)鍵詞：“共享、聯(lián)通、融合和創(chuàng)

新”。聯(lián)通是前臺(tái)以及中臺(tái)之間的聯(lián)通，融合是前臺(tái)流程和

數(shù)據(jù)的融合，以共享的方式支持前端一線業(yè)務(wù)發(fā)展和創(chuàng)新。

中臺(tái)首先體現(xiàn)的是一種企業(yè)級(jí)的能力，它提供的是一套

企業(yè)級(jí)的整體解決方案，解決小到企業(yè)、集團(tuán)、大到生態(tài)圈

的能力共享、聯(lián)通和融合的問題，支持業(yè)務(wù)和商業(yè)模式創(chuàng)新。

通過平臺(tái)聯(lián)通和數(shù)據(jù)融合為用戶提供一致的體驗(yàn)，更敏捷的

支撐前臺(tái)一線業(yè)務(wù)。

中臺(tái)源于平臺(tái)，但中臺(tái)與平臺(tái)比，它更多的體現(xiàn)在一種

理念的轉(zhuǎn)變，它更主要體現(xiàn)在三個(gè)關(guān)鍵能力上：

1.對(duì)前臺(tái)業(yè)務(wù)的快速響應(yīng)能力；

2.企業(yè)級(jí)能力的復(fù)用能力；

41

3.從前臺(tái)、中臺(tái)到后臺(tái)的設(shè)計(jì)研發(fā)、頁面操作、流程服

務(wù)和數(shù)據(jù)的無縫聯(lián)通和融合能力。

其中最關(guān)鍵的是第3點(diǎn)：企業(yè)級(jí)的無縫聯(lián)通和融合能力，

尤其對(duì)于集團(tuán)化的超大企業(yè)而言，這一點(diǎn)至關(guān)重要。

四、如何做中臺(tái)

傳統(tǒng)企業(yè)有別于互聯(lián)網(wǎng)企業(yè)，阿里、騰訊等公司是互聯(lián)

網(wǎng)生態(tài)圈的創(chuàng)造者和流量入口，傳統(tǒng)企業(yè)作為生態(tài)圈種群中

的個(gè)體，除了需要做好原有的傳統(tǒng)渠道業(yè)務(wù)外，還需要融入

互聯(lián)網(wǎng)生態(tài)圈，其商業(yè)模式、個(gè)體能力、與其他個(gè)體共生的

能力決定了它的發(fā)展?jié)摿Α?/p>

為了適應(yīng)不同業(yè)務(wù)和渠道的發(fā)展，過去很多企業(yè)的做法

是開發(fā)很多獨(dú)立的應(yīng)用或APP。但由于IT系統(tǒng)建設(shè)初期沒有

企業(yè)級(jí)的整體規(guī)劃，平臺(tái)之間融合不好，導(dǎo)致用戶體驗(yàn)不好，

關(guān)鍵的是用戶也并不想裝那么多APP!

為了提高用戶體驗(yàn)，實(shí)現(xiàn)統(tǒng)一運(yùn)營，很多企業(yè)開始縮減

APP數(shù)量，通過一個(gè)APP集成企業(yè)內(nèi)所有能力，聯(lián)通前臺(tái)所有

核心業(yè)務(wù)鏈路。

由于傳統(tǒng)企業(yè)的商業(yè)模式和IT系統(tǒng)建設(shè)發(fā)展的歷程與

互聯(lián)網(wǎng)企業(yè)不完全一樣，因此傳統(tǒng)企業(yè)的中臺(tái)建設(shè)策略與阿

里中臺(tái)戰(zhàn)略也應(yīng)該有所差異。

由于渠道多樣化，傳統(tǒng)企業(yè)不僅要將通用能力中臺(tái)化

(對(duì)應(yīng)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的通用域或支撐域),以實(shí)現(xiàn)通用能力

42

的沉淀、共享和復(fù)用。還需要將核心能力中臺(tái)化(對(duì)應(yīng)領(lǐng)域

驅(qū)動(dòng)設(shè)計(jì)的核心域),以滿足不同渠道的核心業(yè)務(wù)能力復(fù)用

的需求，避免傳統(tǒng)核心和互聯(lián)網(wǎng)不同渠道應(yīng)用出現(xiàn)“后端雙

核心、前端兩張皮”的問題。這屬于業(yè)務(wù)中臺(tái)的范疇，需解

決核心業(yè)務(wù)鏈路的聯(lián)通和不同渠道服務(wù)共享的問題。

前臺(tái)

業(yè)務(wù)中臺(tái)

1

通用能核心能數(shù)據(jù)中臺(tái)

力中臺(tái)力中臺(tái)

后臺(tái)

除了核心業(yè)務(wù)鏈路的聯(lián)通和服務(wù)共享，還需要解決系統(tǒng)

微服務(wù)分拆后的數(shù)據(jù)孤島、數(shù)據(jù)融合和業(yè)務(wù)創(chuàng)新的問題。這

屬于數(shù)據(jù)中臺(tái)的范疇。采用分布式架構(gòu)后更應(yīng)關(guān)注微服務(wù)拆

分后的數(shù)據(jù)融合。

在中臺(tái)設(shè)計(jì)和規(guī)劃時(shí)，需要整體考慮企業(yè)內(nèi)前臺(tái)、中臺(tái)

以及后臺(tái)應(yīng)用的協(xié)同，實(shí)現(xiàn)不同渠道應(yīng)用的前端頁面、流程

和服務(wù)的共享，實(shí)現(xiàn)核心業(yè)務(wù)鏈路的聯(lián)通以及前臺(tái)流程和數(shù)

據(jù)的融合，支持業(yè)務(wù)和商業(yè)模式的創(chuàng)新。

43

中臺(tái)轉(zhuǎn)型要做到：前臺(tái)流程融合、中臺(tái)服務(wù)共享、數(shù)據(jù)

融合創(chuàng)新。

五、中臺(tái)建設(shè)共享

分布式和云原生等開源技術(shù)的逐步成熟，阿里、騰訊等

互聯(lián)網(wǎng)企業(yè)也從互聯(lián)網(wǎng)業(yè)務(wù)主戰(zhàn)場轉(zhuǎn)型為面向企業(yè)的2B技

術(shù)能力輸出。這些成熟的云計(jì)算技術(shù)將為傳統(tǒng)企業(yè)中臺(tái)戰(zhàn)略

轉(zhuǎn)型賦能，也為傳統(tǒng)企業(yè)中臺(tái)建設(shè)的技術(shù)路線選擇提供了多

種可能。

1.前臺(tái)

傳統(tǒng)企業(yè)早期系統(tǒng)有不少是基于業(yè)務(wù)領(lǐng)域或組織架構(gòu)

來建設(shè)的，每個(gè)系統(tǒng)都有自己的前端，相互獨(dú)立，用戶操作

是豎井式，需要登錄多個(gè)系統(tǒng)才能完成完整的業(yè)務(wù)流程。

中臺(tái)后的前臺(tái)建設(shè)要有一套綜合考慮業(yè)務(wù)邊界、流程和

平臺(tái)的整體解決方案，實(shí)現(xiàn)各不同中臺(tái)前端操作、流程和界

面的聯(lián)通和融合。不管后端有多少個(gè)中臺(tái)，前端用戶感受只

有一個(gè)前臺(tái)!

前臺(tái)設(shè)計(jì)中可以借鑒微前端的設(shè)計(jì)思想，在企業(yè)內(nèi)不僅

實(shí)現(xiàn)前端解耦和復(fù)用，還可以根據(jù)核心鏈路和業(yè)務(wù)流程，通

過對(duì)微前端頁面的動(dòng)態(tài)組合和流程編排，實(shí)現(xiàn)前臺(tái)業(yè)務(wù)的融

合。

2.中臺(tái)

業(yè)務(wù)中臺(tái)和數(shù)據(jù)中臺(tái)。

44

傳統(tǒng)企業(yè)核心業(yè)務(wù)大多基于集中式架構(gòu)開發(fā)，單體系統(tǒng)

存在擴(kuò)展性和彈性伸縮能力差的問題，無法適應(yīng)忽高忽低的

互聯(lián)網(wǎng)業(yè)務(wù)場景。而數(shù)據(jù)類應(yīng)用也多數(shù)通過ETL工具抽取數(shù)

據(jù)實(shí)現(xiàn)數(shù)據(jù)建模、統(tǒng)計(jì)和報(bào)表分析功能，但由于數(shù)據(jù)時(shí)效和

融合能力不夠，再加上傳統(tǒng)數(shù)據(jù)類應(yīng)用本來不是為前端而

生，難以快速響應(yīng)前端一線業(yè)務(wù)。

業(yè)務(wù)中臺(tái)的建設(shè)可采用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)方法，通過領(lǐng)域建

模，將可復(fù)用的公共能力從各單體剝離，沉淀并組合，采用

微服務(wù)架構(gòu)模式，建設(shè)成為可共享的通用能力中臺(tái)。同樣的

將核心能力采用微服務(wù)架構(gòu)模式，建設(shè)成為可面向不同渠道

和場景的可復(fù)用的核心能力中臺(tái)。業(yè)務(wù)中臺(tái)面向前臺(tái)、第三

方和其它中臺(tái)提供API服務(wù)，實(shí)現(xiàn)通用能力