傳統架構升級微服務的設計與實現

李明 王偉 張棟棟

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

關鍵詞 微服務；數據庫；災備設計

中圖分類號 TP3 文獻標識碼 A 文章編號 1674-6708（2019）235-0140-03

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

1 微服務與微應用

1.1 總體介紹

微服務架構模式的目的是將大型的業務應用系統拆分為多個模塊相互配合的服務，每個服務都能夠很容易得局部調整或優化。微服務應該是從業務邏輯上符合SRP原則的才叫微服務，SRP原則是單一職責原則。分解后的微服務架構包含多個前端服務和后端服務[1]。前端微應用實現業務操作；后端服務微應用實現業務邏輯模塊。

優點：每個服務足夠內聚，足夠小，代碼容易理解、開發效率提高；服務之間可以獨立部署，微服務架構讓持續部署成為可能；一個服務的內存泄露并不會讓整個系統癱瘓；系統不會被長期限制在某個技術棧上，在微服務架構下不會受限于開發語言。缺點：分布式系統架構更加復雜；開發人員要設計服務之間的通信，微服務數量增加了服務治理的難度。

內部服務之間的通信方式有兩種：基于HTTP協議的同步機制（REST、RPC）。依據應用功能設計階段成果，系統與16個外部系統有集成關系，涵蓋平臺類、數據類、業務應用類、三方支付、公共服務平臺，集成方式采用應用集成、數據集成兩種。系統按照微服務架構設計，將系統劃分為主體微服務、高負載（含資源消耗型）微服務、技術組件微服務等。

1.2 總體框架設計

系統總體技術架構分為應用層、服務層、數據層和平臺基礎層；系統依托云平臺進行建設，包括IaaS層和PaaS層基礎組件，并為系統提供核心運維支撐[2]。系統使用云平臺IaaS層軟硬件設施；系統使用云平臺PAAS層核心功能分布式服務總線，對微服務統一注冊管理。系統總體技術路線涵蓋服務端和三個客戶端（Web端、Windows端和移動端）。

2 關鍵技術實現

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

2.1 優先業務需求

業務功能包括：計劃管理、采購管理、合同管理、廢舊物資處置管理、供應商關系管理、質量監督管理、專家管理、采購標準管理、監察管理、運維管理。基于“一個平臺，多個場景”的戰略思路，BPM模型應當縱向分層級，橫向分場景。借助業務流程監控，可以看到平臺中所有的流程及其活動狀態，并進一步獲取流程績效數據，進行大數據分析。

2.2 非功能需求

拆分微服務實際上存在兩個層面的決定：是否可拆分，有沒有必要拆分。第一個層面主要考慮業務獨立性、數據獨立性、技術獨立性，第二個方面的考慮主要是可維護性、可擴展性、性能等非功能需要。決定微服務劃分的第一要素是可維護性、其次是性能、再次是擴展性，如果某次劃分在這幾個方面對系統整體上沒有貢獻，則不應該劃分為微服務。

2.3 系統災備設計

微服務化是一個迭代的過程，從非功能需求角度抽象微服務：1）文件接收微服務文件下載微服務；2）內外網穿透內網接受微服務；3）內外網穿透外網發送微服務；4）解密微服務；5）專家打分微服務；6）短信發送微服務；7）郵件發送微服務；8）鑒權微服務；9）非結構化平臺數據傳送接口；10）供應商查詢中標結果；11）拍賣微服務。

階段一：兩地兩中心、異地數據級災備

建設內容：生產中心數據持續保護、異地數據級災備架構。資源部署方式：生產中心與異地災備資源配比為1：0.5，即生產中心采用高可用設計，災備中心采用單機；WEB、應用服務器部署在云平臺；

災備建設路線：生產高可用：當系統生產環境中局部故障導致數據庫不可用時，或發生邏輯錯誤時，生產本地高可用能夠快速恢復數據。

故障應急恢復：當生產環境發生大范圍故障或災難時，為業務不間斷提供支撐。

透明集成：當業務系統整體或局部切換到災備環境后，仍然可以正常對外服務，而無需關心其它系統是運行在生產環境還是災備環境

階段二：數據災備的技術架構

對于數據災備，Oracle Data Guard提供了一種數據同步技術來實現Oracle的高可用性、增強的性能以及自動的故障轉移方案，為主數據庫創建和維護多個備用數據庫，主數據庫的改變能夠自動將信息從主數據庫傳送到備用數據庫，并保證在此過程中沒有信息的丟失。

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

數據一致性：無論系統從生產環境切換到災備環境還是從災備環境切換回生產環境，數據都不能出現混亂或丟失。

3 系統解決方案

解決非結構化文件的網絡傳輸問題，實現對文件的存儲路徑和生命周期的管理。特別是大批次招標過程中海量非結構化文件處理的性能問題、穩定性問題，基于非結構化文件處理存在的性能問題，重點專注于解決資格預審文件、投標文件加解密過程中的性能問題、安全問題、容錯性問題、穩定性問題以及功能需求實現問題，并提出可行的解決方案[2]。

為滿足系統文件上傳業務需求，提供以下幾點設計方案：應用微服務、文件傳輸微服務分別部署在獨立的網絡和獨立的硬件設備上，實現網絡隔離，提高網絡性能；采用斷點續傳提高容錯能力，提高文件上傳性能，利用消息隊列消峰，避免系統訪問過載導致崩潰；提升網絡帶寬滿足文件上傳需求[4]。

系統數據由結構化數據、半結構化數據和非結構化數據構成。結構化數據是指存儲于數據庫表中的數據，包括業務類數據、運行監控數據等，結構化數據的存儲和訪問由關系數據庫負責，采用Oracle數據庫管理系統。半結構化數據包括采購標準、供應商信息、投標信息等模塊存在大量的動態表單。非結構化數據采用集中式存儲技術。供應商上傳的投標文件來源關系復雜，種類多、數量大，而且要求在較短時間內完成內外網的文件搬運，對存儲的容量和性能都有較高的要求[5]。

關于加密過程特定算法描述如下：通過隨機函數生產隨機密鑰（對稱算法使用的密鑰）；待加密文件使用該對稱密鑰進行加密得到密文；對稱密鑰使用密碼機的公鑰進行非對稱加密得到密鑰的密文；將第2步的密文與第3步的密鑰密文通過統一格式捆綁形成最終的加密文件。

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

4 結論

傳統IT架構已無法應對爆炸式的業務增長，部分國內外企業已嘗試采用先進的架構。國內外業務應用的先進實踐表明，技術上采用微服務架構是解決復雜業務問題的有效手段；系統構建方式上可結合業務特點對微服務進行中心化管理；建設方式上適當引入成熟產品，自主開發業務應用。公司一體化業務應用建設，應基于微服務架構，對原各業務應用進行組件化和服務化封裝，并基于自主可控的技術框架構建微應用，實現“統一展現、服務共享、數據共源”的緊耦合的一體化業務應用。

參考文獻

[1]王磊.微服務架構與實踐[M].北京：電子工業出版社，2015.

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

[3]黃嘉誠，董晶.基于微服務的智能檔案服務系統設計與實現[J].電子設計工程，2018.

[4] 龍新征，彭一明，李若淼.基于微服務框架的信息服務平臺[J].東南大學學報（自然科學版），2017，47（S1）：48-52.

[5]周丹，雷曉玲，章民融.基于微服務架構的校車安全管理系統設計與應用[J].計算機應用與軟件，2018.