基于SOA技術架構的多并發異構業務系統中臺技術設計

沈進波

摘要：面對傳統商業行業信息系統建設中出現的信息孤島問題，本文采用SOA技術架構，利用對應用層的二次分層架構設計，將復雜的中間應用組件進行松耦合處理，同時對不同分層的關鍵技術加以研究，有效實現信息系統的快速迭代和敏捷開發，解決多異構系統的業務一體化整合中的關鍵問題。

[關鍵詞]商業信息系統分層架構異構系統融合負載均衡SOA

1背景

商業零售業信息管理管理系統應用超過20年，隨著各種零售業務的不斷出現，信息系統也從單一的商品進銷存管理系統，逐步擴展為功能細分的ERP進銷存、CRM會員、SCM供應鏈、WMS倉儲、TMS物流配送等等幾十種獨立系統。近些年，隨著線上線下一體化業務的興起，又衍生出更多的線上運維管理業務系統。這些異構系統在提供各類專業業務的同時，也在企業內形成了一個個系統孤島。

以滿足消費者多種多樣的需求為目標，現在商業業務變得日趨復雜多變，亟需打通各個異構系統之間的壁壘，使得各個系統可以靈活地按業務功能要求交互運轉。技術的發展提供了可能，SOA技術架構應運而生。為了適應零售業業務的快速多變的需求，可以在復雜的系統之上，采用基于SOA技術架構的中臺設計，實現在各個系統間的破壁運行，快速完成軟件開發的落地工作，讓信息系統變得更好用。

2SOA技術架構優勢分析

2.1SOA技術架構

SOA（service-orientedarchitecture），面向服務的體系結構，通過在中間層建立一系列的模塊化組件，可以把中間應用程序的各種功能單元，按更細的維度進行劃分，在接口中以契約的方式進行聯系。利用這些標準接口的協議，構建系統的各個服務之間，都使用統一的方式來聯系。SOA技術架構自身具有多種新的特性，如架構的松耦合、模塊的可復用、標準接口模式、外部訪問支持、標準消息模式等。

2.2SOA技術架構優勢

SOA技術架構利用新的業務和管理能力，實時集成。對數據和應用采用集中式系統，易于部署和管理，也易于技術功能調整，可以提高業務響應速度，并保持系統的穩定性。通過選用成熟的中間件，實現一個架構支持多種應用，降低成本（架構和人員）。在與第三方的系統對接開發上，API接口利用微服務平臺提供標準服務，在與第三方對接的過程中再無后顧之憂。

SOA技術在多系統應用中起到核心作用。技術架構上，在傳統B/S的三層架構內，增加一級基礎服務平臺層，將中間應用層拆分成上下層架構，對原中間層的服務功能再次分層，拆分出更小的數據服務模塊。這些小模塊為新的中間層提供與數據庫層的業務交換訪問，而應用層的開發者就不需要再面對底層數據庫的約束，把全部設計意圖實現到業務功能上。在基礎服務平臺層上，比如出現增加數據庫類型時，可以通過快速上線一個新數據庫訪問連接字的適配小模塊，即解決所有應用層對新數據庫類型的數據訪問功能，這將極大提高中間服務層的開發效率，業務功能調試也變得更簡單。SOA技術四層架構示意圖如圖1所示。

2.3技術架構的擴展性

如表1所示。

3業務架構設計

3.1業務分割架構

分割架構主要是指業務拆分。根據具體的業務內容和高內聚、低耦合的原則，將復雜的業務進行模塊化的劃分，單獨部署，接口化操作數據，實現業務的橫向分割。細粒度分割復雜的業務系統，可以降低業務系統的復雜度，按照模塊進行開發和維護，降低整體系統的宕機時間。

一般來說，分割架構需要開發、業務為主，運維、測試為輔，架構師統一主導進行，共同進行系統劃分工作。

業務劃分因公司的業務不同而異，支持服務化的開源技術框架也很多，常見的有Dubbo、Dubbox以及比較新的SpringBoot、SpringCloud等。

首先是不可避免。一般系統初期，公司為了業務盡快上線，大多將業務功能堆加在一起。隨著公司業務發展，系統拆分、系統重構不可避免。

做好計劃，持久作戰。系統拆分、系統重構時間相對較長，一定要提前做好計劃，避免出現項目持續時間久，項目疲憊的情況。

業務拆分要科學。業務的拆分一定要經過架構、開發、業務、DBA等部門共同討論，共同制定出既適合當下，又能夠適合未來一段時間內（2～3年）的業務發展。

業務拆分要徹底。業務拆分不應該只是系統或是程序工程的拆分，還應該包括數據庫的拆分。我們之前就是拆分了程序，未徹底拆分數據庫，導致程序實現服務化后，后端數據庫的壓力不斷增大。采用數據庫中間件實現后端數據庫的分庫，但因為中間件的一些限制，開發又不得不修改一些跨庫查詢和跨庫事務的情況。所以業務拆分一定要徹底，不管是項目工程，還是數據庫。如圖2所示。

3.2 OAuth2.0開放性授權

OAuth（開放授權）是一個開放的標準。允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的網站，在特定的時段內訪問特定的資源。這樣，OAuth允許用戶授權第三方網站訪問他們存儲在另外的服務提供者上的信息，而不需要分享他們的訪問許可或他們數據的所有內容。

3.3異步事務訪問

使用異步事務替代同步事務。在業務處理過程中，將大的同步事務，根據業務特征拆分成多個異步執行的事務，分布式處理提高處理業務的效能。如圖3所示。

4分層架構設計

系統在做分層架構后，一般情況下要主要包括前端接入層、中間應用層、公共服務層、數據存儲層四個層次，其中接入層包括CDN、DNS轉發、負載均衡、靜態資源層等。信用負載均衡的系統分層架構圖如圖4所示。

4.1業務應用層設計

業務應用層比較大的一塊是做服務化，這會在下面的分割架構進行詳細說明。這里主要說明簡單的業務拆分和應用集群的部署方式。

高內聚、低耦合是業務應用層實現目標，業務拆分是解耦的重要利器之一。一般根據公司業務系統的特點和關聯進行拆分，對公共業務系統進行抽取形成公共業務應用，對所有業務系統進行接口化服務。各個業務系統之間獨立部署，降低耦合度，減少了業務系統之間的依賴和影響，提高整個系統的利用率。

因為有前面的負載均衡和反向代理層，所有后端的應用服務器可以橫向部署多臺，實現高可用也起到用戶訪問分流，增加吞吐、提高并發量。實際應用部署中主要以Java應用居多，且多部署在Tomcat中，以此為例，在應用服務器部署時，主要考慮以下幾個問題或是建議：

統一JDK和Tomcat版本。主要是為了方便管理，另外也方便做自動化運維部署。其中統一部署中的操作系統優化、安全加固，Tomcat優化。我們在做Tomcat自動部署的時候，采用的是根據系統配置自動優化的方式和安全加固策略進行。另外就是自動備份和日志的自動切割，都在統一部署腳本中體現。這樣所有部署下來，安裝位置、部署方式等都是一一致的，方便統一管理，統一備份和升級。

動態頁面靜態化。這個根據訪問量選擇系統進行，提高頁面的訪問速度。

4.2公共服務層設計

公共服務層將上層業務層公共用到的一些緩存、消息隊列、session、文件圖片、統一調度、定時任務等抽取出來，作為單獨的服務進行部署，為業務層提供緩存、消息隊列以及圖片等服務。

緩存主要是指的緩存數據。應用服務器通過緩存服務器查詢常用數據，提高系統的查詢速度。消息隊列主要針對高并發的寫，采用異步調用消息隊列，進行數據的臨時存儲，提高系統的并發量和系統效率。

數據緩存以及session存儲主要是Redis。Redis的集群部署方式在數據存儲層會詳細說明。

消息隊列的主要中間件有ActiveMQ和RabbitMQ等，二者都提供master-slave或是集群的部署方式。Kafka主要在搭建日志分析平臺時用到過。對于ActiveMQ和RabbitMQ，二者并沒有太大的區別，都在生產用過，也沒遇到太大問題。在技術選擇中，還是選擇開發和運維最熟悉的為好，再具體點，建議以開發最熟悉的為標準。

文件圖片服務器，如果公司的數據比較敏感且有較高的保密性，加上核心生產系統只能內部使用的話，建議搭建內部分布式文件服務器、圖片服務器，使用FastDFS進行構建分布式集群文件服務器的。如果對外提供服務，建議采用購買云服務，方便運維管理，而且云服務自身的特性，也比較容易增加文件或圖片的加載速度。

公共服務層的架構和部署一般來說都提供了主從和集群兩種高可用方式，并且都實現分布式部署。由于公共服務的重要性，所有業務都在調用，所以在實際生產部署的時候，一定要采用高可用的方式進行部署，并且要有可伸縮性和可擴展性。結合我們公司實際情況，在進行公共服務部署時，除了采用主從或是Cluster的方式進行部署。

為了快速的響應即時擴容的需要，還增加了一鍵擴展的腳本，實現對集群中服務器的快速擴展。分布式擴展方式中的常用算法主要是一致性hash的方式。

4.3數據存儲層設計

數據存儲層主要分為關系型數據庫和NoSQL數據庫。主要從高可用集群包括負載均衡、讀寫分離、分庫分表等幾個方面。

NoSQL數據庫主要采用Redis為主。Redis常用的高可用方案有哨兵模式和Cluster。使用Redis除了上面講的做共享session存儲之外，最大的應用就是緩存常用數據。大應用建議生產環境中分集群部署。

關于非關系型數據庫，除了高可用、監控之外平常工作中還面臨很大的一“個工作就是分庫和分片，如何方便快速擴展，這很有用。對于Redis的使用，建議在一開始規劃時就考慮好擴展問題避免以后的遷移或是在線擴展等。這跟關系型數據庫的分庫分表有異曲同工之妙。Redis的分庫分片和擴展對系統架構來說很重要，尤其業務的高速發展期，越來越多的數據緩存在Redis中，如果沒有做好規劃，將會很被動。

Redis包含三種集群策略：

主從復制：在主從復制模式中，首先會有主數據庫（master）和從數據庫（slave）的定義。主數據庫是活動業務應用，隨時進行讀寫，讀寫的數據會按時序的規則，把變化內容同步進入從數據庫。一個master可以擁有多個slave，但是一個slave只能對應一個maste。

哨兵：哨兵的作用是監控redis系統的運行狀況，他的功能包括：監控主從數據庫是否正常運行;master出現故障時，自動將slave轉化為master;多哨兵配置的時候，哨兵之間也會自動監控;多個哨兵可以監控同一個redis。

集群：使用集群，將采用多主數據庫形式，需要同時打開每個數據庫的cluster-enable配置。每個集群組中，如果要保持穩定運行，應不低于三個以上主數據庫配置。

集群示意圖如圖5所示。

5結束語

利用SOA架構里的公共服務層設計，很好地解決中臺系統的開發復雜度問題，將系統架構變得松耦合，有利于信息系統相對于業務發展的隨需應變，使得快速迭代開發模式在多異構系統上得以實現。應用企業還可以在新架構基礎之上，逐步對原有舊系統進行抽取式更換，通過全新定義一套業務對接模型，并開始向不同軟件提供商提供服務，使得異構系統的信息孤島逐漸消除，為企業信息化應用提供更快捷的服務。

參考文獻

[1]李永紅.SOA在軟件工程開發中的應用[J].電子技術與軟件工程，2017（07）：38-41.

[2]倪楓.SOA敏捷架構的TOGAF層次化迭代建模[J]上海理工大學學報，2018（15）：133-135.

[3]劉家興，計算機輔助信息分析的技術框架及其發展趨勢[J].中國新通信，2018（09）：22-25.

[4]張婷，張鑫，張新剛，基于CPN的OAuth協議建模與分析[J].計算機系統應用，2018（03）：57-60.

[5]馮瑞青，張激，趙俊才.異構處理器多操作系統協同技術研究[J].計算機系統應用，2018（12）：177-180.

[6]叢紅藝.Linux平臺Tomcat的安全加固[J].網絡安全和信息化，2017（12）：73-75.

[7]丁志均，楊青等.異構Redis集群大規模評論數據存儲負載均衡設計[J].華東師范大學學報，2017（08）：119-122.

[8]王瑋.Linux服務器安全防護部署[J].計算機產品與流通，2018（17）：25-28.