李明 王偉 張棟棟

摘 要 為了實(shí)現(xiàn)信息化系統(tǒng)“一系統(tǒng)、一平臺(tái)、多場景、微應(yīng)用”的整體建設(shè)思路，傳統(tǒng)架構(gòu)已然滿足不了現(xiàn)在企業(yè)的需求。本文將著重講解微服務(wù)架構(gòu)下系統(tǒng)的總體框架設(shè)計(jì)，技術(shù)層面實(shí)現(xiàn)，災(zāi)備視圖設(shè)計(jì)以及系統(tǒng)解決方案。系統(tǒng)依托云平臺(tái)進(jìn)行建設(shè)，包括IaaS層和PaaS層基礎(chǔ)組件，并為系統(tǒng)提供核心運(yùn)維支撐。通過解決實(shí)際業(yè)務(wù)中的文件傳輸，數(shù)據(jù)存儲(chǔ)，加解密文件驗(yàn)證新架構(gòu)的可行性。公司一體化業(yè)務(wù)應(yīng)用建設(shè)，對(duì)原各業(yè)務(wù)應(yīng)用進(jìn)行組件化和服務(wù)化封裝，并基于自主可控的技術(shù)框架構(gòu)建微應(yīng)用，實(shí)現(xiàn)“統(tǒng)一展現(xiàn)、服務(wù)共享、數(shù)據(jù)共源”的一體化業(yè)務(wù)應(yīng)用。

關(guān)鍵詞 微服務(wù)；數(shù)據(jù)庫；災(zāi)備設(shè)計(jì)

中圖分類號(hào) TP3 文獻(xiàn)標(biāo)識(shí)碼 A 文章編號(hào) 1674-6708（2019）235-0140-03

基于傳統(tǒng)的企業(yè)級(jí)復(fù)雜應(yīng)用分析與發(fā)展方向研究結(jié)論，傳統(tǒng)架構(gòu)方式必然轉(zhuǎn)向微服務(wù)、微應(yīng)用架構(gòu)方式建成“穩(wěn)定安全、統(tǒng)一開放、簡潔友好、高效領(lǐng)先”必然是新一代企業(yè)級(jí)應(yīng)用系統(tǒng)形態(tài)，隨著技術(shù)發(fā)展及海量數(shù)據(jù)的增長，特別是大型企業(yè)電商系統(tǒng)，它本身業(yè)務(wù)非常復(fù)雜，存在海量業(yè)務(wù)數(shù)據(jù)的內(nèi)外網(wǎng)傳輸，并需要進(jìn)行大量的加解密計(jì)算，如何實(shí)現(xiàn)應(yīng)用快速迭代，快速部署，提高系統(tǒng)性能的新架構(gòu)迫不及待。微服務(wù)架構(gòu)是降低系統(tǒng)復(fù)雜度，提高系統(tǒng)性能的最優(yōu)選擇，是適合敏捷開發(fā)方法持續(xù)改進(jìn)的系統(tǒng)。微應(yīng)用是一個(gè)具有清晰邊界，有一定獨(dú)立性的業(yè)務(wù)單元，它通過調(diào)用一個(gè)或者多個(gè)微服務(wù)，實(shí)現(xiàn)一組同類型的單一業(yè)務(wù)目標(biāo)或業(yè)務(wù)場景的功能邏輯組合軟件包。

1 微服務(wù)與微應(yīng)用

1.1 總體介紹

微服務(wù)架構(gòu)模式的目的是將大型的業(yè)務(wù)應(yīng)用系統(tǒng)拆分為多個(gè)模塊相互配合的服務(wù)，每個(gè)服務(wù)都能夠很容易得局部調(diào)整或優(yōu)化。微服務(wù)應(yīng)該是從業(yè)務(wù)邏輯上符合SRP原則的才叫微服務(wù)，SRP原則是單一職責(zé)原則。分解后的微服務(wù)架構(gòu)包含多個(gè)前端服務(wù)和后端服務(wù)[1]。前端微應(yīng)用實(shí)現(xiàn)業(yè)務(wù)操作；后端服務(wù)微應(yīng)用實(shí)現(xiàn)業(yè)務(wù)邏輯模塊。

優(yōu)點(diǎn)：每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解、開發(fā)效率提高；服務(wù)之間可以獨(dú)立部署，微服務(wù)架構(gòu)讓持續(xù)部署成為可能；一個(gè)服務(wù)的內(nèi)存泄露并不會(huì)讓整個(gè)系統(tǒng)癱瘓；系統(tǒng)不會(huì)被長期限制在某個(gè)技術(shù)棧上，在微服務(wù)架構(gòu)下不會(huì)受限于開發(fā)語言。缺點(diǎn)：分布式系統(tǒng)架構(gòu)更加復(fù)雜；開發(fā)人員要設(shè)計(jì)服務(wù)之間的通信，微服務(wù)數(shù)量增加了服務(wù)治理的難度。

內(nèi)部服務(wù)之間的通信方式有兩種：基于HTTP協(xié)議的同步機(jī)制（REST、RPC）。依據(jù)應(yīng)用功能設(shè)計(jì)階段成果，系統(tǒng)與16個(gè)外部系統(tǒng)有集成關(guān)系，涵蓋平臺(tái)類、數(shù)據(jù)類、業(yè)務(wù)應(yīng)用類、三方支付、公共服務(wù)平臺(tái)，集成方式采用應(yīng)用集成、數(shù)據(jù)集成兩種。系統(tǒng)按照微服務(wù)架構(gòu)設(shè)計(jì)，將系統(tǒng)劃分為主體微服務(wù)、高負(fù)載（含資源消耗型）微服務(wù)、技術(shù)組件微服務(wù)等。

1.2 總體框架設(shè)計(jì)

系統(tǒng)總體技術(shù)架構(gòu)分為應(yīng)用層、服務(wù)層、數(shù)據(jù)層和平臺(tái)基礎(chǔ)層；系統(tǒng)依托云平臺(tái)進(jìn)行建設(shè)，包括IaaS層和PaaS層基礎(chǔ)組件，并為系統(tǒng)提供核心運(yùn)維支撐[2]。系統(tǒng)使用云平臺(tái)IaaS層軟硬件設(shè)施；系統(tǒng)使用云平臺(tái)PAAS層核心功能分布式服務(wù)總線，對(duì)微服務(wù)統(tǒng)一注冊(cè)管理。系統(tǒng)總體技術(shù)路線涵蓋服務(wù)端和三個(gè)客戶端（Web端、Windows端和移動(dòng)端）。

2 關(guān)鍵技術(shù)實(shí)現(xiàn)

IT系統(tǒng)微服務(wù)化，是一種更加徹底的模塊化，這種模塊化不僅僅某一層內(nèi)部的孤立切分和橫向解耦，而是包含展示層、服務(wù)層、應(yīng)用層甚至數(shù)據(jù)層的縱向、橫向徹底解耦，它不像傳統(tǒng)的模塊化一樣僅僅影響了設(shè)計(jì)，而是深刻影響了包括分析、設(shè)計(jì)、開發(fā)、測試、運(yùn)維在內(nèi)的軟件全生命期的整個(gè)過程。

2.1 優(yōu)先業(yè)務(wù)需求

業(yè)務(wù)功能包括：計(jì)劃管理、采購管理、合同管理、廢舊物資處置管理、供應(yīng)商關(guān)系管理、質(zhì)量監(jiān)督管理、專家管理、采購標(biāo)準(zhǔn)管理、監(jiān)察管理、運(yùn)維管理。基于“一個(gè)平臺(tái)，多個(gè)場景”的戰(zhàn)略思路，BPM模型應(yīng)當(dāng)縱向分層級(jí)，橫向分場景。借助業(yè)務(wù)流程監(jiān)控，可以看到平臺(tái)中所有的流程及其活動(dòng)狀態(tài)，并進(jìn)一步獲取流程績效數(shù)據(jù)，進(jìn)行大數(shù)據(jù)分析。

2.2 非功能需求

拆分微服務(wù)實(shí)際上存在兩個(gè)層面的決定：是否可拆分，有沒有必要拆分。第一個(gè)層面主要考慮業(yè)務(wù)獨(dú)立性、數(shù)據(jù)獨(dú)立性、技術(shù)獨(dú)立性，第二個(gè)方面的考慮主要是可維護(hù)性、可擴(kuò)展性、性能等非功能需要。決定微服務(wù)劃分的第一要素是可維護(hù)性、其次是性能、再次是擴(kuò)展性，如果某次劃分在這幾個(gè)方面對(duì)系統(tǒng)整體上沒有貢獻(xiàn)，則不應(yīng)該劃分為微服務(wù)。

2.3 系統(tǒng)災(zāi)備設(shè)計(jì)

微服務(wù)化是一個(gè)迭代的過程，從非功能需求角度抽象微服務(wù)：1）文件接收微服務(wù)文件下載微服務(wù)；2）內(nèi)外網(wǎng)穿透內(nèi)網(wǎng)接受微服務(wù)；3）內(nèi)外網(wǎng)穿透外網(wǎng)發(fā)送微服務(wù)；4）解密微服務(wù)；5）專家打分微服務(wù)；6）短信發(fā)送微服務(wù)；7）郵件發(fā)送微服務(wù)；8）鑒權(quán)微服務(wù)；9）非結(jié)構(gòu)化平臺(tái)數(shù)據(jù)傳送接口；10）供應(yīng)商查詢中標(biāo)結(jié)果；11）拍賣微服務(wù)。

階段一：兩地兩中心、異地?cái)?shù)據(jù)級(jí)災(zāi)備

建設(shè)內(nèi)容：生產(chǎn)中心數(shù)據(jù)持續(xù)保護(hù)、異地?cái)?shù)據(jù)級(jí)災(zāi)備架構(gòu)。資源部署方式：生產(chǎn)中心與異地災(zāi)備資源配比為1：0.5，即生產(chǎn)中心采用高可用設(shè)計(jì)，災(zāi)備中心采用單機(jī)；WEB、應(yīng)用服務(wù)器部署在云平臺(tái)；

災(zāi)備建設(shè)路線：生產(chǎn)高可用：當(dāng)系統(tǒng)生產(chǎn)環(huán)境中局部故障導(dǎo)致數(shù)據(jù)庫不可用時(shí)，或發(fā)生邏輯錯(cuò)誤時(shí)，生產(chǎn)本地高可用能夠快速恢復(fù)數(shù)據(jù)。

故障應(yīng)急恢復(fù)：當(dāng)生產(chǎn)環(huán)境發(fā)生大范圍故障或?yàn)?zāi)難時(shí)，為業(yè)務(wù)不間斷提供支撐。

透明集成：當(dāng)業(yè)務(wù)系統(tǒng)整體或局部切換到災(zāi)備環(huán)境后，仍然可以正常對(duì)外服務(wù)，而無需關(guān)心其它系統(tǒng)是運(yùn)行在生產(chǎn)環(huán)境還是災(zāi)備環(huán)境

階段二：數(shù)據(jù)災(zāi)備的技術(shù)架構(gòu)

對(duì)于數(shù)據(jù)災(zāi)備，Oracle Data Guard提供了一種數(shù)據(jù)同步技術(shù)來實(shí)現(xiàn)Oracle的高可用性、增強(qiáng)的性能以及自動(dòng)的故障轉(zhuǎn)移方案，為主數(shù)據(jù)庫創(chuàng)建和維護(hù)多個(gè)備用數(shù)據(jù)庫，主數(shù)據(jù)庫的改變能夠自動(dòng)將信息從主數(shù)據(jù)庫傳送到備用數(shù)據(jù)庫，并保證在此過程中沒有信息的丟失。

Oracle Data Guard是通過Oracle數(shù)據(jù)庫歸檔日志來實(shí)現(xiàn)的，并通過Oracle Net來傳輸日志；而Golden Gate是通過對(duì)歸檔日志的捕捉并分析其的變化來實(shí)現(xiàn)的，有自己獨(dú)享的傳輸方式；CDP技術(shù)是通過數(shù)據(jù)庫鏡像來實(shí)現(xiàn)數(shù)據(jù)同步，數(shù)據(jù)庫鏡像的歸檔以及傳送策略是通過CDP軟件來完成[3]。

數(shù)據(jù)一致性：無論系統(tǒng)從生產(chǎn)環(huán)境切換到災(zāi)備環(huán)境還是從災(zāi)備環(huán)境切換回生產(chǎn)環(huán)境，數(shù)據(jù)都不能出現(xiàn)混亂或丟失。

3 系統(tǒng)解決方案

解決非結(jié)構(gòu)化文件的網(wǎng)絡(luò)傳輸問題，實(shí)現(xiàn)對(duì)文件的存儲(chǔ)路徑和生命周期的管理。特別是大批次招標(biāo)過程中海量非結(jié)構(gòu)化文件處理的性能問題、穩(wěn)定性問題，基于非結(jié)構(gòu)化文件處理存在的性能問題，重點(diǎn)專注于解決資格預(yù)審文件、投標(biāo)文件加解密過程中的性能問題、安全問題、容錯(cuò)性問題、穩(wěn)定性問題以及功能需求實(shí)現(xiàn)問題，并提出可行的解決方案[2]。

為滿足系統(tǒng)文件上傳業(yè)務(wù)需求，提供以下幾點(diǎn)設(shè)計(jì)方案：應(yīng)用微服務(wù)、文件傳輸微服務(wù)分別部署在獨(dú)立的網(wǎng)絡(luò)和獨(dú)立的硬件設(shè)備上，實(shí)現(xiàn)網(wǎng)絡(luò)隔離，提高網(wǎng)絡(luò)性能；采用斷點(diǎn)續(xù)傳提高容錯(cuò)能力，提高文件上傳性能，利用消息隊(duì)列消峰，避免系統(tǒng)訪問過載導(dǎo)致崩潰；提升網(wǎng)絡(luò)帶寬滿足文件上傳需求[4]。

系統(tǒng)數(shù)據(jù)由結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)構(gòu)成。結(jié)構(gòu)化數(shù)據(jù)是指存儲(chǔ)于數(shù)據(jù)庫表中的數(shù)據(jù)，包括業(yè)務(wù)類數(shù)據(jù)、運(yùn)行監(jiān)控?cái)?shù)據(jù)等，結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和訪問由關(guān)系數(shù)據(jù)庫負(fù)責(zé)，采用Oracle數(shù)據(jù)庫管理系統(tǒng)。半結(jié)構(gòu)化數(shù)據(jù)包括采購標(biāo)準(zhǔn)、供應(yīng)商信息、投標(biāo)信息等模塊存在大量的動(dòng)態(tài)表單。非結(jié)構(gòu)化數(shù)據(jù)采用集中式存儲(chǔ)技術(shù)。供應(yīng)商上傳的投標(biāo)文件來源關(guān)系復(fù)雜，種類多、數(shù)量大，而且要求在較短時(shí)間內(nèi)完成內(nèi)外網(wǎng)的文件搬運(yùn)，對(duì)存儲(chǔ)的容量和性能都有較高的要求[5]。

關(guān)于加密過程特定算法描述如下：通過隨機(jī)函數(shù)生產(chǎn)隨機(jī)密鑰（對(duì)稱算法使用的密鑰）；待加密文件使用該對(duì)稱密鑰進(jìn)行加密得到密文；對(duì)稱密鑰使用密碼機(jī)的公鑰進(jìn)行非對(duì)稱加密得到密鑰的密文；將第2步的密文與第3步的密鑰密文通過統(tǒng)一格式捆綁形成最終的加密文件。

關(guān)于解密過程特定算法描述如下：通過對(duì)已加密文件的解綁得到原文密文以及密鑰密文；密鑰密文使用密碼機(jī)的私鑰進(jìn)行解密得到對(duì)稱密鑰；原文密文使用對(duì)稱密鑰（對(duì)稱算法）進(jìn)行解密得到原文。

4 結(jié)論

傳統(tǒng)IT架構(gòu)已無法應(yīng)對(duì)爆炸式的業(yè)務(wù)增長，部分國內(nèi)外企業(yè)已嘗試采用先進(jìn)的架構(gòu)。國內(nèi)外業(yè)務(wù)應(yīng)用的先進(jìn)實(shí)踐表明，技術(shù)上采用微服務(wù)架構(gòu)是解決復(fù)雜業(yè)務(wù)問題的有效手段；系統(tǒng)構(gòu)建方式上可結(jié)合業(yè)務(wù)特點(diǎn)對(duì)微服務(wù)進(jìn)行中心化管理；建設(shè)方式上適當(dāng)引入成熟產(chǎn)品，自主開發(fā)業(yè)務(wù)應(yīng)用。公司一體化業(yè)務(wù)應(yīng)用建設(shè)，應(yīng)基于微服務(wù)架構(gòu)，對(duì)原各業(yè)務(wù)應(yīng)用進(jìn)行組件化和服務(wù)化封裝，并基于自主可控的技術(shù)框架構(gòu)建微應(yīng)用，實(shí)現(xiàn)“統(tǒng)一展現(xiàn)、服務(wù)共享、數(shù)據(jù)共源”的緊耦合的一體化業(yè)務(wù)應(yīng)用。

參考文獻(xiàn)

[1]王磊.微服務(wù)架構(gòu)與實(shí)踐[M].北京：電子工業(yè)出版社，2015.

[2]劉輝軍，劉培峰，邱鈺峰，等.基于開源框架及容器技術(shù)的微服務(wù)架構(gòu)研究[J].電力信息與通信技術(shù)，2018，16（6）：90-94.

[3]黃嘉誠，董晶.基于微服務(wù)的智能檔案服務(wù)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].電子設(shè)計(jì)工程，2018.

[4] 龍新征，彭一明，李若淼.基于微服務(wù)框架的信息服務(wù)平臺(tái)[J].東南大學(xué)學(xué)報(bào)（自然科學(xué)版），2017，47（S1）：48-52.

[5]周丹，雷曉玲，章民融.基于微服務(wù)架構(gòu)的校車安全管理系統(tǒng)設(shè)計(jì)與應(yīng)用[J].計(jì)算機(jī)應(yīng)用與軟件，2018.