組件化與服務(wù)化軟件架構(gòu)在中小企業(yè)中的建設(shè)

董長青　鄧程鵬　任女爾

摘要：隨著互聯(lián)網(wǎng)企業(yè)的日益發(fā)展，軟件研發(fā)的智能化也得到了進一步提升。但在傳統(tǒng)的中小型IT企業(yè)中，技術(shù)框架比較單一、固定，軟件項目研發(fā)的復(fù)用程度低、研發(fā)效率慢，互聯(lián)網(wǎng)架構(gòu)知識體系相對龐雜。針對中小企業(yè)的轉(zhuǎn)型發(fā)展，結(jié)合互聯(lián)網(wǎng)架構(gòu)的思路，提出組件化與服務(wù)化的軟件架構(gòu)體系，支撐中小企業(yè)的技術(shù)轉(zhuǎn)型，助力軟件技術(shù)的積累與快速研發(fā)交付高質(zhì)量軟件。

關(guān)鍵詞：高效研發(fā)；組件化；服務(wù)化；技術(shù)轉(zhuǎn)型

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2018）18-0217-03

1引言

在傳統(tǒng)的中小企業(yè)中，常用的技術(shù)框架如單體J2EE技術(shù)框架，往往為了快速交付而造成軟件質(zhì)量低下的情況；同時，為了對應(yīng)頻繁變化的需求、不同開發(fā)人員采取了不同的策略解決問題導(dǎo)致代碼風(fēng)格不統(tǒng)一、運維困難；而運維人員由開發(fā)人員監(jiān)管，或運維人員監(jiān)管多個項目，導(dǎo)致問題定位、質(zhì)量風(fēng)險等問題加??；企業(yè)方則為了賺取更大的利益，不注重軟件技術(shù)的積累與復(fù)用，導(dǎo)致重復(fù)開發(fā)、資源浪費。相比大型的互聯(lián)網(wǎng)企業(yè)，研發(fā)、運維體系及技術(shù)架構(gòu)相對適應(yīng)能力更強，也便于不斷衍生新的業(yè)務(wù)發(fā)展，極大地促進了企業(yè)的發(fā)展進程。分析先進的解決方案，都離不開軟件資產(chǎn)管理、組件化研發(fā)與服務(wù)化研發(fā)，但中小企業(yè)在實踐過程中往往存在技術(shù)跨度大、人員投入成本高、收益見效慢、評估困難等問題。那么針對中小企業(yè)制定轉(zhuǎn)型思路，并實施步驟的梳理和驗證，建立有效的評估模型至關(guān)重要【1】。

2 技術(shù)架構(gòu)分析與設(shè)計

技術(shù)架構(gòu)包含技術(shù)框架、軟件工具、通用組件及軟件開發(fā)方法學(xué)。而java的技術(shù)框架體系在當前的中小企業(yè)中市場占有率較高，依據(jù)J2EE技術(shù)做技術(shù)架構(gòu)具有一定的代表性，思路和方法可以遷移至C#等項目研發(fā)中。

2.1互聯(lián)網(wǎng)技術(shù)架構(gòu)

互聯(lián)網(wǎng)技術(shù)架構(gòu)離不開云計算、大數(shù)據(jù)、微服務(wù)、DevOps。其中云計算從IaaS基礎(chǔ)設(shè)施即服務(wù)、PaaS平臺即服務(wù)、SaaS軟件即服務(wù)，詮釋了以計算資源為基礎(chǔ)的一切服務(wù)化思想【2】；大數(shù)據(jù)通過業(yè)務(wù)數(shù)據(jù)或采集數(shù)據(jù)的不斷積累，深度發(fā)掘潛在知識并進行預(yù)測，從而輔助企業(yè)決策、信息再建等；微服務(wù)作為應(yīng)對多變的業(yè)務(wù)擴展需求及并發(fā)擴展需求而逐步演進出來的技術(shù)框架，技術(shù)體系完善，具有非常好的適應(yīng)能力；Devops作為研發(fā)、運維與測試一體化構(gòu)建的自動化管理方案【3】，體現(xiàn)了“一切自動化”的思想，并且在企業(yè)中逐步推廣，與微服務(wù)的復(fù)雜運維體系相輔相成，極大地促進了軟件研發(fā)質(zhì)量管理和效率管理【4】。

以電商云平臺作為互聯(lián)網(wǎng)架構(gòu)的典型案例，基于服務(wù)化的思想，從底層構(gòu)建IaaSAPI平臺，進行資源的統(tǒng)一調(diào)配管理；上層以平臺即服務(wù)的模式、用容器技術(shù)將平臺資源以服務(wù)模式完成對外支持【5】；最終針對用戶業(yè)務(wù)將軟件均形成微服務(wù)，以SaaS模式提供出來；在輔助管理方面，結(jié)合用戶中心、配置中心、流程中心、監(jiān)控中心等支撐平臺擴展和業(yè)務(wù)發(fā)展【6】。

2.2傳統(tǒng)中小企業(yè)技術(shù)架構(gòu)轉(zhuǎn)型問題

傳統(tǒng)中小企業(yè)面臨的客戶往往也較小，因此用戶量小、開發(fā)人員動態(tài)調(diào)增、開發(fā)周期小等特點作為主要特點，為了能夠最快的軟件技術(shù)變現(xiàn)，對技術(shù)積累不夠重視；但是隨著軟件越做越大、越做越成熟，企業(yè)則面臨技術(shù)轉(zhuǎn)型問題。

但單純對標互聯(lián)網(wǎng)企業(yè)架構(gòu)，技術(shù)人員水平要求高、短期內(nèi)開發(fā)成本和運維成本明顯增加、碰到問題無法及時解決，因此并不是明智的決策。比如，原本的部署只需用tomcat中間件即可，即使負載量增長也可以采用集群部署方式解決；但是采用微服務(wù)，tomcat內(nèi)置不方便開發(fā)，分布式一致性問題、解耦問題難以控制，原本2分鐘部署的應(yīng)用，確需要幾天時間部署整體微服務(wù)環(huán)境，然后進行應(yīng)用部署，成本是幾十甚至上百倍。

2.3技術(shù)架構(gòu)設(shè)計思路

在解決技術(shù)架構(gòu)轉(zhuǎn)型中的問題過程中，需對準目標方案，然后選擇合適的路線。針對解決代碼復(fù)用率的問題，可以進行組件化研發(fā)方式；針對研發(fā)效率問題，可以提升框架的易用性和智能化研發(fā)進行改進，同時可以輔助自動化工具；針對運維并發(fā)問題，可以采用服務(wù)化的思想進行調(diào)整。針對不同的技術(shù)轉(zhuǎn)型階段，應(yīng)當合理調(diào)整目標。

在每一項技術(shù)選型及技術(shù)落地過程中，分析投入學(xué)習(xí)成本和產(chǎn)出節(jié)約工作量，以及分析除節(jié)約工作量之外的效益，如質(zhì)量提升后的效益、并發(fā)升級的效益等。正確的評估效益有助于落地實施。

同時要注重知識儲備與人員培養(yǎng)。人員培養(yǎng)過程也是解決問題的過程，應(yīng)對不同的業(yè)務(wù)場景和技能攻堅問題，逐步將人員按照合理的崗位進行劃分，如運維與開發(fā)分離等。在人員數(shù)量有限的情況下，可以采用臨崗互備的原則，確保知識體系與技能體系構(gòu)建過程中，人員崗位能夠匹配上。

對標、評估與人員儲備，屬于三項基本工作。針對中小型企業(yè)技術(shù)轉(zhuǎn)型，前期目標以快速研發(fā)高質(zhì)量軟件為核心目標，中期以構(gòu)建領(lǐng)域型復(fù)用產(chǎn)品為目標，后期以高精尖技術(shù)體系為目標進行。

3 組件化與服務(wù)化軟件架構(gòu)

組件化架構(gòu)注重軟件代碼層復(fù)用，服務(wù)化架構(gòu)更注重運行層的復(fù)用。

3.1組件化架構(gòu)

在組件化架構(gòu)中，主要服務(wù)于前期和中期目標。首先針對框架進行規(guī)范化建設(shè)，選擇合適的平臺，再補充通用性組件。通用組件包括技術(shù)組件和業(yè)務(wù)組件兩部分，技術(shù)組件進行了常用的工具類組件封裝，盡可能將基于組件的業(yè)務(wù)實現(xiàn)變得簡單，并且保證研發(fā)的統(tǒng)一性，便于后期運維；業(yè)務(wù)組件基于汽車行業(yè)的業(yè)務(wù)體系進行拆分而來，也便于進一步進行研發(fā)集成。常用的技術(shù)組件包括：工作流引擎、郵件發(fā)送、word導(dǎo)出、Excel導(dǎo)入導(dǎo)出、文件上傳下載、日志、國際化、系統(tǒng)管理等。

技術(shù)組件一方面能夠提升單一功能的研發(fā)效率，原本50行的代碼經(jīng)過組件封裝后可以用20行實現(xiàn)；另一方面能夠統(tǒng)一技術(shù)，各項目組采用的技術(shù)不同，導(dǎo)致沒有分享和交流，最終不能有效的復(fù)用，同一功能在不同項目組研發(fā)可能用1小時或3天都是可能的，甚至是無法解決的技術(shù)問題；此外，通過一段時間的使用，組件趨于成熟，避免了相同問題反復(fù)調(diào)試，大大減少潛在bug。

業(yè)務(wù)組件的梳理有兩種方式，一種根據(jù)新項目逐步生成，另一種是梳理舊項目，后者成本更高，見效更慢，短期內(nèi)無法有效的形成生產(chǎn)力。因此兩種方式可以綜合考慮，一方面在研發(fā)模式上進行改進，另一方面結(jié)合舊項目盡可能地抽取新項目使用到的新組件。研發(fā)模式如下所示：

考慮將研發(fā)模式結(jié)合組件化研發(fā)進行。在軟件設(shè)計之后，將要研發(fā)的內(nèi)容與既有組件進行匹配篩選，部分直接可用、部分修改可用、部分全新研發(fā)。每次新項目都能生成對應(yīng)的內(nèi)容。

在舊項目中梳理業(yè)務(wù)，可以采用梳理業(yè)務(wù)架構(gòu)圖的形式，以產(chǎn)品線為單位，結(jié)合項目變更情況、項目模塊類似情況、模塊功能發(fā)展趨勢，構(gòu)建業(yè)務(wù)架構(gòu)圖，從業(yè)務(wù)角度描述可復(fù)用性，如圖所示，進一步輔助業(yè)務(wù)組件的積累和構(gòu)建。

業(yè)務(wù)架構(gòu)圖中，復(fù)用程度不同，用不同的顏色來標示，方便后續(xù)演進；該部分內(nèi)容由對產(chǎn)品非常熟悉的項目組完成。

3.2服務(wù)化架構(gòu)

組件化架構(gòu)重點解決復(fù)用問題，也就是快速研發(fā)高質(zhì)量軟件的問題；服務(wù)化架構(gòu)則針對逐步擴展的大型軟件進行的，可以解決并發(fā)、擴展等問題。以郵件為例，將發(fā)送郵件封裝成技術(shù)組件、形成接口，那么可以非常方便地調(diào)用開發(fā)特定業(yè)務(wù)；但是當整個業(yè)務(wù)系統(tǒng)的并發(fā)性要求逐步提升，單點的郵件登錄無法支撐該問題，那么必須進行有效分布式部署方案；傳統(tǒng)的分布式是將整個項目多節(jié)點部署，而服務(wù)化可以將郵件啟動為獨立運行的服務(wù)，當郵件服務(wù)無法支撐并發(fā)時，可以將郵件服務(wù)部署成集群。這種方式更加靈活和便捷，但是也就意味著1個應(yīng)用被拆分的較為零散，運維復(fù)雜度成倍增加。因此服務(wù)化架構(gòu)要到公司產(chǎn)品發(fā)展至一定階段時再執(zhí)行，并且針對特定復(fù)雜產(chǎn)品執(zhí)行。

最終架構(gòu)建設(shè)確定整體方案后啟動建設(shè)，對大部分中小型企業(yè)，首先進行組件化，然后針對特定產(chǎn)品實施服務(wù)化；對于單一產(chǎn)品的中小企業(yè)，隨著產(chǎn)品規(guī)模擴大，也可以直接轉(zhuǎn)型到服務(wù)化。

4 架構(gòu)建設(shè)步驟

架構(gòu)建設(shè)步驟主要有：基礎(chǔ)平臺建設(shè)，框架改進與統(tǒng)一，技術(shù)組件實施，中間件實施，標準規(guī)范構(gòu)建，工具實施，微服務(wù)逐步實施，其中技術(shù)組件、工具類、中間件、標準規(guī)范可以同步逐步完善。以Java體系的技術(shù)架構(gòu)而言，可以按照如下實施。

（1）基礎(chǔ)平臺建設(shè)：構(gòu)建以Maven為組件驅(qū)動式研發(fā)模式的基礎(chǔ)平臺，包括maven倉庫、gitlab代碼平臺、技術(shù)共享信息發(fā)布網(wǎng)站。Maven將單一的J2EE應(yīng)用拆分為父工程與子模塊的形式，然后模塊和組件可以發(fā)布到maven倉庫中，可以采用nexus進行構(gòu)建。

（2）框架改進與統(tǒng)一：按照公司常用框架及問題進行統(tǒng)一改進，如可以規(guī)范采用ssm（SpringMVC+Spring+Mybatis）的方式，集成如Jmetrics代碼性能檢測、Druid數(shù)據(jù)庫連接池sql性能檢測、XSS攔截跨站腳本攻擊、權(quán)限管理等；因前端復(fù)用率較低，進行前后端分離，能夠更進一步提升軟件復(fù)用率、并且方便后期擴展微服務(wù)模式。

（3）技術(shù)組件實施：完成日志、系統(tǒng)管理、郵件等工具類的封裝，可以針對性的梳理既有項目提供多種方式。如導(dǎo)出excel，可以采用拼接文檔、模板導(dǎo)出等不同方式。

（4）中間件實施：針對redis、memcached、ES等中間件，可以采用共享服務(wù)器部署+封裝組件的方式，極大的降低開發(fā)難度。如redis在服務(wù)器上部署之后，開發(fā)人員用maven引用組件，就可以直接進行業(yè)務(wù)緩存；不需要擔(dān)心運維、部署、接口調(diào)研等問題。

（5）標準規(guī)范實施：針對框架、組件的使用和實施，應(yīng)當安排專有人員進行規(guī)范的制定與發(fā)布、執(zhí)行監(jiān)督與反饋收集工作。針對項目繁忙的情況，該方式能夠大幅度提升實施成果的推進。項目組沒有很好的了解組件應(yīng)用不充分導(dǎo)致的溝通成本過高、浪費，相對于規(guī)范實施與監(jiān)督的成本要高很多。

（6）工具實施：按照“一切自動化”的思路執(zhí)行，先執(zhí)行jenkins，以持續(xù)集成為主要，逐步集成sonar技術(shù)債務(wù)、docker平臺等。然后從開發(fā)、測試環(huán)境逐步過渡到生產(chǎn)環(huán)境。

（7）微服務(wù)實施：針對特定產(chǎn)品線，進行微服務(wù)實施，首先針對框架進行springcloud改進升級，然后將特定無狀態(tài)的功能轉(zhuǎn)成服務(wù)，構(gòu)建注冊、熔斷等服務(wù)機制，進步一步再實施監(jiān)控體系。當單微服務(wù)構(gòu)建完成之后，逐步擴展成產(chǎn)品線的微服務(wù)化。

5 成果評估模型

成果評估模型決定著整體技術(shù)轉(zhuǎn)型過程中的投入、成效是否達成目標?？傮w評估基于人力成本的投入產(chǎn)出分析，附加技術(shù)債務(wù)、代碼提交次數(shù)、運維工作量比例等工作綜合評估。對于新項目，先進行項目工作總量的預(yù)估x人天，然后在使用框架、組件、工具過程中，溝通學(xué)習(xí)成本為y，技術(shù)解決消耗為z，那么節(jié)約工作量為x-y-z，均以人天為單位。同時，跟蹤在測試過程中的問題規(guī)避情況，如歷史系統(tǒng)安全測試修改人天數(shù)為m，采用新框架為n，則節(jié)約人天數(shù)為m-n人天。在舊項目改造中，可以評估單月運維量在改造前后的工作量。

模型在每個企業(yè)中應(yīng)有自己的變更，包括對于質(zhì)量的提升效益占比、并發(fā)性提升對產(chǎn)品推廣的效益占比等，都應(yīng)該進行特定方案的評估模型建立，從而確保實施方案收到足夠的認可。

6 總結(jié)

以中小企業(yè)為架構(gòu)技術(shù)轉(zhuǎn)型為核心，對標互聯(lián)網(wǎng)架構(gòu)，圍繞組件化、服務(wù)化中常見的問題和建設(shè)步驟進行系統(tǒng)性規(guī)劃與實施，能夠大幅度提升中小企業(yè)技術(shù)競爭力。目前，該方案已經(jīng)在多家中小型企業(yè)技術(shù)轉(zhuǎn)型構(gòu)建成功，提升企業(yè)研發(fā)效率和技術(shù)實力明顯，為傳統(tǒng)架構(gòu)與互聯(lián)網(wǎng)架構(gòu)打通了一條中間方案。

參考文獻：

[1] 楊波谷.IT應(yīng)用對接業(yè)務(wù)需求，打造企業(yè)核心競爭力[J].數(shù)字通信世界，2017（11）.

[2] 張春波，汪軍陸.云計算技術(shù)及應(yīng)用[J].信息與電腦（理論版），2018（07）.

[3] 周振興.基于Docker和持續(xù)交付的項目管理系統(tǒng)設(shè)計與實現(xiàn)[D].大連理工大學(xué)，2016.

[4] 洪華軍，吳建波，冷文浩.一種基于微服務(wù)架構(gòu)的業(yè)務(wù)系統(tǒng)設(shè)計與實現(xiàn)[J].計算機與數(shù)字工程，2018（1）.

[5] 霍躍華，劉銀龍.物流大數(shù)據(jù)分析平臺架構(gòu)及關(guān)鍵技術(shù)研究[J].信息技術(shù)與信息化，2016（9）.

[6] 胡宇航.“互聯(lián)網(wǎng)+”結(jié)合云計算在傳統(tǒng)行業(yè)中的應(yīng)用[J].科技創(chuàng)新與應(yīng)用，2018（6）.