基于螺旋法的信息系統(tǒng)設計與開發(fā)

【關(guān)鍵詞】系統(tǒng)架構(gòu)設計；螺旋法；子階段

一、項目背景

隨著大數(shù)據(jù)、機器學習、人工智能等新興技術(shù)的興起，加之銀行業(yè)在數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)量以及業(yè)務場景豐富性方面的先天優(yōu)勢，AI模型可優(yōu)先在銀行場景落地，尤其是銀行的營銷與風控場景，比如理財產(chǎn)品推薦，客戶畫像，客戶交易圖譜以及信貸場景的ABC卡等都是常見應用場景，但目前各銀行AI模型開發(fā)訓練工具主要使用的是業(yè)界主流的商業(yè)數(shù)據(jù)挖掘工具（比如：SAS）或者是一些開源機器學習框架（比如Anaconda，R），前者比較昂貴，尤其是每年的證書續(xù)期費用，后者則是無法做到開發(fā)工具、硬件資源、開發(fā)模型的統(tǒng)一管理，但這兩者都比較難把開發(fā)后的模型直接發(fā)布成在線服務供各業(yè)務系統(tǒng)進行調(diào)用。A項目就在此背景下誕生，此項目建設工期約10個月，本項目建設內(nèi)容包括兩個子系統(tǒng)，一個是AI模型開發(fā)訓練平臺，另一個是AI模型服務管理平臺，前者主要完成AI模型的開發(fā)訓練，后者主要完成將模型鏡像發(fā)布成在線服務。本項目中，筆者擔任系統(tǒng)架構(gòu)師，主要負責系統(tǒng)架構(gòu)設計及開發(fā)技術(shù)指導等工作。鑒于本項目總體功能框架明確，但詳細的業(yè)務功能范圍和實現(xiàn)都較為模糊，加上功能投產(chǎn)的緊迫程度不一致，考慮到螺旋法是一種將結(jié)構(gòu)化開發(fā)方法與原型法相結(jié)合的一種開發(fā)方法，既靈活又能不斷地對系統(tǒng)進行迭代完善的特點，經(jīng)筆者提議，在與項目組討論后決定采用螺旋法進行系統(tǒng)設計。

二、相關(guān)理論

螺旋法采用一種周期性的開發(fā)方法，在每個子周期內(nèi)采用瀑布模型法，每一個周期又產(chǎn)出一個軟件過程版本，此為快速原型法[1]，也就是它充分結(jié)合了瀑布模型法與原型法[2]兩種開發(fā)模型的優(yōu)勢，將整個系統(tǒng)開發(fā)過程分成幾個階段，每個階段內(nèi)又定義四個子過程，首先是目標確定子過程，它定義在本階段內(nèi)要實現(xiàn)哪些業(yè)務目標，也就是實現(xiàn)哪些系統(tǒng)功能；接著是風險分析子過程，這也是螺旋法區(qū)別于前面兩種模型的一個比較重要的特點，在此過程中主要解決若要實現(xiàn)本階段內(nèi)的這些功能，存在哪些技術(shù)上的、業(yè)務上的、管理上的約束等風險因素，這需要與項目組全體成員一起來討論；再者是開發(fā)與驗證子過程，主要完成本階段內(nèi)的功能開發(fā)、測試以及業(yè)務驗證，由于將系統(tǒng)開發(fā)分成了若干個階段，每階段內(nèi)要開發(fā)的功能粒度就更小，則比較適合采用原型法進行開發(fā)[3]；最后是階段性復盤子過程，主要總結(jié)在本階段內(nèi)所遇到的一些問題、解決方法以及一些遺留事項，用于進一步?jīng)Q策是否需要進入下一階段以及如何更好開展下一階段的工作。

三、實踐

下面詳細闡述螺旋法在本項目中的具體實踐情況

（一）項目整體階段劃分

首先，項目組向用戶演示了我司模型服務管理方面的成熟產(chǎn)品，包括功能、性能、架構(gòu)等內(nèi)容，并著重突出了產(chǎn)品的亮點。接著，項目組征詢了客戶對本項目AI模型服務管理平臺功能的初步想法，主要側(cè)重點在鏡像同步、服務部署、服務編排、API發(fā)布、流量控制以及服務監(jiān)控等方面的功能。然后，就客戶提出的問題進行了應答，闡述了對AI模型服務管理平臺的初步設計理念。另外，也聽取了客戶對于本項目各功能投產(chǎn)先后順序的需求，比如客戶也同步在開展一些模型的建設，比如OCR模型、語音識別模型，所以需要服務部署以及API發(fā)布等主體功能優(yōu)先上線，最終，雙方達成了初步的一致的意見。具體而言，架構(gòu)層面，系統(tǒng)總體使用雙中心架構(gòu)，為保證模型服務的高可用性、可伸縮性以及安全性，各中心采用K8S集群進行模型部署管理，服務管理平臺端采用三層架構(gòu)，使用SSM+Redis框架，另外為配合甲方信創(chuàng)要求，數(shù)據(jù)庫使用國產(chǎn)OB數(shù)據(jù)庫；功能層面，分三階段進行，首先是主體功能部分，比如服務部署，API發(fā)布等，其次是與客戶現(xiàn)有相關(guān)業(yè)務系統(tǒng)對接，比如統(tǒng)一登錄、客服系統(tǒng)等，最后是雙活與流量控制功能。實踐表明，分階段分批次開發(fā)與投產(chǎn)，既滿足了客戶的實際需求又可以根據(jù)項目實際人力投入進行合理安排。

（二）目標確定子過程

各階段要完成的業(yè)務目標確定后，接下來進入每一階段時，需要對階段目標進一步細化，也就是對階段內(nèi)要完成的功能進一步拆解，常用的功能分解方法有結(jié)構(gòu)化分析方法，此方法是面向數(shù)據(jù)流的分析方法，通過功能分解方式把系統(tǒng)功能分解到各個模塊中，它有三個常用工具，分別是數(shù)據(jù)流圖、狀態(tài)轉(zhuǎn)換圖以及實體關(guān)系圖，此處項目組使用數(shù)據(jù)流圖工具，功能拆解大體思路是首先將本階段內(nèi)要完成的功能作為頂層數(shù)據(jù)流圖，比如在本項目中，頂層數(shù)據(jù)流圖如下圖所示：

經(jīng)與客戶溝通得知，其內(nèi)部的組織架構(gòu)分為研發(fā)條線與運維條線。系統(tǒng)在正式上線之前，也就是項目開發(fā)階段時，主要由研發(fā)條線負責，而系統(tǒng)一旦上線后，系統(tǒng)就交付給運維條線進行負責，運維條線關(guān)注重點系統(tǒng)軟硬件的運行健康情況，而研發(fā)條線在系統(tǒng)上線后則關(guān)注重點系統(tǒng)功能層面的運行及使用情況，另外，AI模型服務管理平臺還需要與AI模型開發(fā)訓練平臺進行對接，如本文“項目背景”所述，它需要將在AI模型開發(fā)訓練平臺中開發(fā)的模型發(fā)布成API服務，供其他系統(tǒng)調(diào)用，所以，AI模型開發(fā)訓練平臺需將開發(fā)完成的模型鏡像推送到AI模型服務管理平臺的鏡像倉庫中，最后，無論是其他系統(tǒng)調(diào)用AI模型服務管理平臺的模型API，還是AI模型服務管理平臺去調(diào)用其他系統(tǒng)的接口都需要經(jīng)過企業(yè)服務總線ESB，所以，本系統(tǒng)的頂層數(shù)據(jù)流圖中外部實體應至少包含系統(tǒng)管理員、系統(tǒng)運維人員、AI模型開發(fā)訓練平臺與ESB四個，而各個外部實體與本系統(tǒng)之間交互的信息也如圖1所示。

接著，對頂層數(shù)據(jù)流圖進一步細分為各層級數(shù)據(jù)流圖，比如AI模型服務管理平臺主要功能包括鏡像管理、服務管理、API管理、渠道管理、服務總覽等業(yè)務模塊，則第二級數(shù)據(jù)流圖應圍繞著這些功能展開，詳細列出對應的外部實體，輸入輸出數(shù)據(jù)。另外，為了保證整個細化過程不發(fā)散，控制項目范圍，在細分各層級數(shù)據(jù)流圖時，先向客戶演示我司類似產(chǎn)品相關(guān)功能或者使用Axure原型設計工具將功能界面原型圖展示給客戶，然后確定本階段具體要實現(xiàn)的功能目標。實踐表明，采用類似產(chǎn)品做原型展示讓客戶更有直觀感受，另外，使用數(shù)據(jù)流圖能更清晰地展示功能之間的層次關(guān)系與交互關(guān)系。

（三）風險分析子過程

每階段因為要實現(xiàn)的功能不一樣，所以受到的約束條件也不一樣，比如有些功能的實現(xiàn)是依賴銀行內(nèi)其他系統(tǒng)的配合，需要對方提供一些技術(shù)對接細節(jié)，因此需要綜合考慮這些風險因素。為了能全面識別這些潛在的風險因素，需采用一套比較科學的風險識別方法，目前常用的項目風險識別方法工具有專家判斷、頭腦風暴、訪談以及SWOT分析法[4]等，其中SWOT分析法更多是應用于一項新技術(shù)或者新產(chǎn)品的研發(fā)分析，它著眼于全局，而頭腦風暴與訪談又局限于參與對象的項目經(jīng)驗，所以，最終還是采用專家判斷法。項目組主要邀請甲方技術(shù)負責人以及架構(gòu)專家一起討論，討論步驟具體為：首先，將風險劃分為三個大類，分別為技術(shù)風險、業(yè)務風險以及管理風險；其次，分別針對三大風險進一步討論細項，比如技術(shù)風險中有一項是與ESB對接，如何對接，存在怎樣的接口定義規(guī)范，報文要求以及實現(xiàn)的難度等，都將影響開發(fā)進度的正常開展，所以對于涉及行內(nèi)系統(tǒng)對接的，盡量讓對方給出對接DEMO以及相關(guān)接口文檔，或者提供行內(nèi)技術(shù)文檔知識庫，比如SVN，以供查詢。而業(yè)務風險主要來源于業(yè)務人員的測試安排，對技術(shù)的了解程度等，與之對應的應對方法是業(yè)務人員的測試投入計劃表，交測前的系統(tǒng)測試培訓等。最后將細化后的風險清單以及應對方法文檔化，得到項目風險手冊，將其歸檔到項目知識庫中并同步做成在線共享文檔方便后續(xù)進一步維護。

（四）開發(fā)及驗證子過程

由于是分階段開發(fā)，而各階段雖然業(yè)務功能不一樣，但總體還是一種B/S架構(gòu)，分為表現(xiàn)層、邏輯實現(xiàn)層（SERVICE）以及數(shù)據(jù)訪問層DAO，而各功能的實現(xiàn)無非是繪制各功能特有的頁面，而定義各功能特有的業(yè)務邏輯、中間的控制轉(zhuǎn)換、對象管理以及數(shù)據(jù)庫訪問機制都是一樣的，所以對與該子過程筆者將整個開發(fā)團隊分成三個角色，一是負責前端UI界面的設計與開發(fā)，二是負責中間框架層的業(yè)務功能實現(xiàn)，最后是數(shù)據(jù)庫層的SQL代碼實現(xiàn)。這樣的話，可以保證快速地做出客戶想要的頁面原型，及時與客戶溝通，另外，也可以做到整體底層模塊的復用，不用每個子功能都要獨立實現(xiàn)。

最后，在本系統(tǒng)架構(gòu)設計中，使用了微服務思想，采用SpringBoot框架，傳統(tǒng)的WEB開發(fā)，每次的測試與發(fā)布時，都是需要將所有功能模塊代碼一起進行編譯發(fā)布，對于系統(tǒng)比較龐大以及協(xié)作開發(fā)的場景，這種編譯發(fā)布模式，往往使單個功能模塊的測試過程變得非常困難，而采用微服務框架，每個服務模塊都是獨立運行，所以也方便開發(fā)人員進行測試，特別地，對于這種分階段開發(fā)的項目，每個階段完成的功能模塊不一樣，所以，采用微服務模式，就更顯優(yōu)勢，相當于各階段的開發(fā)都不存在強耦合關(guān)系，比如，在本系統(tǒng)中，鏡像倉庫，系統(tǒng)日志模塊，用戶管理模塊，模型調(diào)用網(wǎng)關(guān)模塊等都是獨立運行在K8S集群容器中，為了保證各服務的高可用性，每個容器都采用多副本機制。實踐證明，采用微服務與K8S集群進行系統(tǒng)架構(gòu)設計，是一種非常有效的系統(tǒng)設計與開發(fā)方法。

（五）階段性復盤子過程

階段性復盤，目前主流的方法是敏捷開發(fā)方法Scrum[2]中的沖刺回顧，即沖刺結(jié)束后，團隊會開兩場會議，一個是評審會，由開發(fā)團隊給產(chǎn)品負責人演示交付功能，并接受評價；另一個是反思回顧會，對本次沖刺進行總結(jié)，所有團隊成員都要反思這個沖刺，以便下一次沖刺可以更好地進行。在本項目中，每階段投產(chǎn)后，會進行投產(chǎn)后驗證、評價以及階段內(nèi)復盤，前者主要由業(yè)務人員主導，分別從功能可使用性、體驗性、加分項三個方面進行評估， 而階段內(nèi)復盤主要盤點功能實現(xiàn)方面是否存在較臃腫的，不靈活的，或者性能不好的，比如，為什么投產(chǎn)功能與開發(fā)測試環(huán)境不一致問題，有時會出現(xiàn)在開發(fā)測試環(huán)境的運行正常的功能在生產(chǎn)環(huán)境卻運行異常，原因有可能是配置文件未進行多環(huán)境設置，因此需要后期將相關(guān)配置信息做成參數(shù)化頁面，方便客戶維護，也提高了系統(tǒng)的可維護性。最后就是評審本階段功能，若已驗證無問題，則可以開啟下一階段的功能開發(fā)。

四、結(jié)尾

項目組經(jīng)過10個月的艱苦奮戰(zhàn)研發(fā)，系統(tǒng)在經(jīng)過多次迭代發(fā)布之后于2023年9月成功上線，現(xiàn)已基本處于穩(wěn)定運行狀態(tài)，得到了客戶、領(lǐng)導的一致認可，現(xiàn)如今也已經(jīng)部署了ASR、TTS、OCR、業(yè)務類型推薦等AI模型，并向多個部門進行了推廣使用，而且這些模型服務發(fā)布到服務管理平臺后也都穩(wěn)定運行，扛住了高并發(fā)的壓力。得益于螺旋法的正確使用，項目才能快速穩(wěn)定地上線。通過本次項目的設計與實現(xiàn)，筆者愈發(fā)體會到選擇正確的軟件開發(fā)方法能夠讓整個項目開發(fā)工作節(jié)省很多不必要的時間、精力、財力的支出，從而達到事半功倍的效果。筆者也深刻體會到持續(xù)學習、與時俱進，將會是貫穿筆者作為系統(tǒng)架構(gòu)師生涯的永恒主題。