復(fù)旦大學(xué)基于容器化重構(gòu)一表通平臺(tái)

文/齊鳳林 張凱 高珺 張樂

微服務(wù)及其所驅(qū)動(dòng)的容器化技術(shù)日益成熟，微服務(wù)倡導(dǎo)將一個(gè)簡(jiǎn)單復(fù)雜的應(yīng)用分解為一組小型的、專門的服務(wù)，每一個(gè)服務(wù)運(yùn)行在各自獨(dú)立的進(jìn)程中，各個(gè)服務(wù)之間協(xié)調(diào)配合，實(shí)現(xiàn)業(yè)務(wù)的高內(nèi)聚、低耦合，成為當(dāng)前國內(nèi)外一線互聯(lián)網(wǎng)公司廣泛應(yīng)用的技術(shù)。以復(fù)旦大學(xué)為例，原有的師生填表服務(wù)分散在Spring MVC、Grails、eService 等不同的平臺(tái)架構(gòu)之上，這種混合架構(gòu)雖然曾臨時(shí)滿足了學(xué)校管理和服務(wù)綜合化發(fā)展的需要，但是在使用中也遇到一系列問題。

服務(wù)分散。師生填寫表單時(shí)，存在多個(gè)入口，界面不統(tǒng)一、操作方式不一致。由此導(dǎo)致用戶體驗(yàn)不佳。

開發(fā)與運(yùn)維效率低。由于各個(gè)業(yè)務(wù)系統(tǒng)創(chuàng)建時(shí)間不相同、原始開發(fā)環(huán)境各不相同、發(fā)展過程不平衡等原因，導(dǎo)致開發(fā)與運(yùn)維人員需維護(hù)多個(gè)不同的框架和部署環(huán)境。進(jìn)而造成需求響應(yīng)慢、業(yè)務(wù)部署慢等諸多問題。

更新迭代困難。由于服務(wù)使用的框架不同，造成后續(xù)系統(tǒng)之間對(duì)接困難。部分開發(fā)人員的流動(dòng)更導(dǎo)致部分業(yè)務(wù)無法更新，并可能存在潛在安全問題。

為了解決這些問題，復(fù)旦大學(xué)信息辦在考察了多個(gè)成熟的新技術(shù)之后，梳理現(xiàn)有校內(nèi)填表業(yè)務(wù)的實(shí)際情況，通過系統(tǒng)重構(gòu)將各個(gè)填表平臺(tái)進(jìn)行整合統(tǒng)一。在重構(gòu)過程中，積極融入容器化的思想，在設(shè)計(jì)階段就將目標(biāo)設(shè)定為一個(gè)可快速迭代、快速部署的統(tǒng)一填表平臺(tái)。利用Ruby on Rails、Docker、Swarm 等技術(shù)，最終完成了能夠快速響應(yīng)用戶需求、快速進(jìn)行部署、快速按需擴(kuò)展的一表通平臺(tái)。

架構(gòu)現(xiàn)狀

復(fù)旦大學(xué)一表通平臺(tái)是一個(gè)表單快速配置平臺(tái)，能夠基于個(gè)人數(shù)據(jù)中心快速完成絕大部分面向用戶的表單配置。該平臺(tái)是支撐學(xué)校職能部門及二級(jí)院系提高自身管理效率、減少重復(fù)填表問題的自主研發(fā)系統(tǒng)，也是全校試行完全無紙化的重要支撐平臺(tái)，曾開發(fā)了包括高等教育數(shù)據(jù)采集在內(nèi)的業(yè)務(wù)近100 項(xiàng)。

最初，一表通平臺(tái)框架是基于Grails進(jìn)行構(gòu)建的（以下簡(jiǎn)稱“G 類”業(yè)務(wù)表單）。Grails 是一個(gè)用于快速構(gòu)建Web 應(yīng)用的開源框架，是構(gòu)建在Spring 和Hibernate 等Java 已有的技術(shù)之上的一個(gè)full-stack 框架，借助于核心技術(shù)與相關(guān)插件來解決Web 開發(fā)中的各方面的問題，它的優(yōu)勢(shì)在于能很好的遵循“不要重復(fù)自己”（Don't Repeat Yourself,DRY）原則，利用內(nèi)置的Spring 容器實(shí)現(xiàn)依賴注入。但是，在運(yùn)維過程中發(fā)現(xiàn)Grails 也存在一定的缺陷。Grails 環(huán)境在服務(wù)器上更新部署的時(shí)間太長，一般約有幾分鐘，這在師生正常使用的系統(tǒng)上是不能忍受的。原因在于若更新時(shí)出現(xiàn)師生正在使用該業(yè)務(wù)，而此時(shí)該業(yè)務(wù)恰好正在更新部署，很可能導(dǎo)致業(yè)務(wù)無法正常使用。這不僅會(huì)給業(yè)務(wù)部門帶來困擾，也會(huì)大大降低用戶體驗(yàn)。

網(wǎng)上辦事服務(wù)大廳的一部分填表業(yè)務(wù)是委托公司基于Spring MVC 框架進(jìn)行構(gòu)建的（以下簡(jiǎn)稱“S 類”業(yè)務(wù)表單）。該架構(gòu)由于模型和視圖嚴(yán)格分離，每增加一個(gè)構(gòu)件，均需在模型層、視圖層和控制器增加對(duì)應(yīng)的描述，每個(gè)構(gòu)件在使用之前都需要進(jìn)行徹底的測(cè)試，給開發(fā)調(diào)試應(yīng)用帶來一定的困難，不適合高校小型、中等規(guī)模的應(yīng)用服務(wù)。

2007 年復(fù)旦大學(xué)上線的eService 服務(wù)（以下簡(jiǎn)稱“E 類”業(yè)務(wù)表單）是集用戶溝通、用戶服務(wù)支持、師生自助服務(wù)和信息辦內(nèi)部管理為一體的信息服務(wù)管理平臺(tái)。該平臺(tái)使用的Struts2 是Apache 基金會(huì)下的一個(gè)Web 框架，它需要針對(duì)每個(gè)request 進(jìn)行封裝，把request，session 等servlet 生命周期的變量封裝成單個(gè)Map，供給每個(gè)Action 使用，所以耗費(fèi)內(nèi)存，影響業(yè)務(wù)服務(wù)性能。另外，Struts2 的遠(yuǎn)程命令執(zhí)行漏洞和重定向漏洞給部分業(yè)務(wù)帶來一定的安全隱患。

表1 架構(gòu)現(xiàn)狀

由此可見，現(xiàn)有業(yè)務(wù)運(yùn)行依托的開發(fā)框架或多或少都存在各種形式的缺陷或漏洞，不能及時(shí)滿足日益增長的師生服務(wù)需求。需要探索更加便捷、可拓展、可復(fù)用和可快速迭代的開發(fā)框架，并且在重構(gòu)架構(gòu)的同時(shí)，將歷史遺留系統(tǒng)中的業(yè)務(wù)重構(gòu)。

業(yè)務(wù)重構(gòu)

如圖1 所示是表單業(yè)務(wù)重構(gòu)的詳細(xì)設(shè)計(jì)步驟，第一階段整理所有的關(guān)聯(lián)表單，分別有G 類表單、S 類表單和E 類表單。通過和業(yè)務(wù)部門溝通，理清所有表單最新的業(yè)務(wù)需求，確保重構(gòu)后表單滿足現(xiàn)有業(yè)務(wù)部門要求。第二階段除了做技術(shù)重構(gòu)外，根據(jù)業(yè)務(wù)部門最新需求，進(jìn)行內(nèi)容重構(gòu)；第三階段對(duì)接工作流平臺(tái)之后，統(tǒng)一形成基于Rails 的R 類表單：R-Ei，R-Si，R-Gi。

圖1 表單重構(gòu)設(shè)計(jì)步驟

下面按照分別對(duì)G 類、S 類、E 類表單重構(gòu)步驟分別陳述。在整個(gè)表單重構(gòu)過程中不會(huì)原版原樣復(fù)原，而是根據(jù)最新的功能需求添加校驗(yàn)和布置排版。重構(gòu)過程中不僅考慮PC 端的體驗(yàn)效果，更多地考慮移動(dòng)端的體驗(yàn)，讓其在符合新架構(gòu)下統(tǒng)一風(fēng)格的同時(shí)，進(jìn)一步提升師生用戶體驗(yàn)。

G 類表單

在不影響正常服務(wù)師生的情況下，梳理Grails 已有的表單使用情況，建立遷移優(yōu)先級(jí)分級(jí)機(jī)制。綜合考慮使用量和使用緊急度兩個(gè)因素。如表2 所示，序號(hào)以“G”開頭，共計(jì)33 個(gè)表單。Grails 原始表都是基于BaseForm 建立起來的，首先需要解綁BaseForm 基礎(chǔ)表，其次添加關(guān)鍵字段OWNER、CREATED_AT、UPDATED_AT，剩下的其余字段根據(jù)表單功能樣式在新環(huán)境上進(jìn)行復(fù)現(xiàn)，添加基本信息預(yù)填、基礎(chǔ)邏輯校驗(yàn)，并根據(jù)業(yè)務(wù)部門要求補(bǔ)充特殊邏輯校驗(yàn)。根據(jù)Rails 的Model 命名規(guī)則添加路徑映射，最后對(duì)接審批工作流。

表2 Grails 表單梳理

S 類表單

整理Spring MVC 框架下的業(yè)務(wù)表使用情況。如表3 所示，序號(hào)以“S”開頭，共計(jì)17 個(gè)業(yè)務(wù)表。Spring MVC 的原始表單針對(duì)每個(gè)業(yè)務(wù)均存在一個(gè)源文件。首先將源文件進(jìn)行拆解，按照目標(biāo)架構(gòu)進(jìn)行匹配，除了主鍵轉(zhuǎn)換（PK_ID 轉(zhuǎn)換為ID）適應(yīng)和添加三個(gè)關(guān)鍵字段外，還需要處理打印報(bào)表，對(duì)于大部分子表嵌套的打印表格，按照目標(biāo)格式設(shè)計(jì)對(duì)應(yīng)的html 代碼，最終達(dá)到適應(yīng)打印展示的效果。最后對(duì)接審批工作流。

表3 Spring MVC 表單梳理

E 類表單

目前基于目前信息辦舊版eService 的部分業(yè)務(wù)正在逐個(gè)業(yè)務(wù)解耦合，如表4 所示，序號(hào)以“E”開頭形成遷移需求的有4個(gè)。eService表單是舊版系統(tǒng)剝離的業(yè)務(wù)，首先將功能復(fù)現(xiàn)，除了添加基本信息預(yù)填、基礎(chǔ)邏輯校驗(yàn)外，為了業(yè)務(wù)的校驗(yàn)需要對(duì)接eService 庫，將提交內(nèi)容的校驗(yàn)結(jié)果通過工作流系統(tǒng)接口傳遞到一表通平臺(tái)。最后對(duì)接審批工作流。

表4 eService 表單梳理

以上三類表單適應(yīng)性改造完成后，通過使用約定的工作流接口，對(duì)接Rails 架構(gòu)。在后續(xù)的開發(fā)過程中具有更高的可維護(hù)性、可擴(kuò)展性、可復(fù)用性。此次涉及的重構(gòu)業(yè)務(wù)表單共達(dá)54 個(gè)。原來的技術(shù)架構(gòu)由于獨(dú)立部署，無法滿足業(yè)務(wù)之間復(fù)雜關(guān)聯(lián)的需求，在業(yè)務(wù)流程改造之后，新的技術(shù)框架破解了這種局限性。以業(yè)務(wù)“教育培訓(xùn)項(xiàng)目結(jié)項(xiàng)”為例，需要根據(jù)教育培訓(xùn)立項(xiàng)的項(xiàng)目編號(hào)及內(nèi)容進(jìn)行結(jié)項(xiàng)申請(qǐng)，申請(qǐng)人不可避免地需要人工查詢?cè)剂㈨?xiàng)的信息，業(yè)務(wù)重構(gòu)之后可以通過系統(tǒng)自動(dòng)關(guān)聯(lián)，省去了不少人工操作。

容器化部署架構(gòu)

在一表通平臺(tái)的部署中，將Ruby on Rails 項(xiàng)目和依賴包（基礎(chǔ)鏡像）制作成一個(gè)帶有啟動(dòng)指令的項(xiàng)目鏡像，然后在服務(wù)器上按需創(chuàng)建若干容器，讓鏡像分別在容器內(nèi)運(yùn)行，從而實(shí)現(xiàn)一表通平臺(tái)的容器化部署。圖2 是容器化部署架構(gòu)示意圖，D1和D2 分別是已部署的兩個(gè)容器，兩個(gè)容器的運(yùn)行基本確保面向師生的服務(wù)不會(huì)間斷。當(dāng)然，在空間允許的情況下，還可以部署Dn 個(gè)相同的容器服務(wù)，以確保服務(wù)的及時(shí)性和準(zhǔn)確性。Rails 利用“約定優(yōu)于配置”（Convention Over Configuration,COC）原則，提前封裝了約定的基礎(chǔ)設(shè)計(jì)層，來約定每個(gè)Model 共同使用的設(shè)置內(nèi)容。由于多數(shù)Model 的狀態(tài)變化是類似的，所以可以提前設(shè)定Model 的字段、類型、行為等各種展現(xiàn)形式。對(duì)于少數(shù)有特殊需求的業(yè)務(wù)可以通過定制化“Model-View”來進(jìn)行靈活擴(kuò)展。所以，后續(xù)每增加一個(gè)業(yè)務(wù)表單，只需要在圖2 中Model 部分增加一個(gè)業(yè)務(wù)表即可，無需額外重寫Controller 和View 部分。

圖2 架構(gòu)重構(gòu)示意

重構(gòu)后的一表通平臺(tái)具備以下特點(diǎn)：

橫向擴(kuò)展良好。如圖2 所示，容器化部署的優(yōu)勢(shì)是只要物理資源足夠，容器域中可以近乎無限量地增加容器的數(shù)量Dn，橫向擴(kuò)展性比較好。

分離文件存儲(chǔ)。原始一表通平臺(tái)所有文件存儲(chǔ)服務(wù)和一表通自身服務(wù)是放在同一個(gè)服務(wù)器上，當(dāng)文件的瀏覽量增加時(shí)，會(huì)增加一表通服務(wù)器的壓力。此次重構(gòu)將業(yè)務(wù)數(shù)據(jù)存儲(chǔ)在對(duì)象存儲(chǔ)S3 中，降低了一表通平臺(tái)服務(wù)器自身的負(fù)載壓力。當(dāng)有業(yè)務(wù)下載需求時(shí)，一表通服務(wù)器本身只對(duì)鏈接做簽名，利用帶有簽名的鏈接直接從S3 下載文件，該過程用戶認(rèn)證透明無感知。

開發(fā)效率顯著提升。按照“COC”原則，Controller、View 和Model 層都有一套通用的流程（模板、草稿、保存、提交等）。針對(duì)業(yè)務(wù)變動(dòng)的內(nèi)容只是信息字段的類型和數(shù)量的多少。按照“DRY”原則，每次新增業(yè)務(wù)僅需要描述對(duì)應(yīng)的Model 即可，無需撰寫冗余代碼。特殊需求時(shí)，可靈活支持三個(gè)層次的定制模型改動(dòng)。

創(chuàng)新點(diǎn)

從開發(fā)者角度來看，使用容器化部署后，加快了部署速度，代碼更新部署時(shí)間從分鐘級(jí)降低為秒級(jí)，僅需1～2 秒。從服務(wù)能力角度來看，容器化部署使得彈性擴(kuò)展變得非常容易，只需要通過修改配置文件，就可以實(shí)現(xiàn)在多服務(wù)器中快速增大或縮小計(jì)算能力。從管理運(yùn)維角度來看，如圖3 所示，首先提升了管理運(yùn)維的高效性和簡(jiǎn)便性，均衡了用戶響應(yīng)速度；其次降低了運(yùn)維管理的困難，開發(fā)人員無需同時(shí)維護(hù)不同環(huán)境下表單的業(yè)務(wù)變動(dòng)。從師生用戶角度來看，表單增加了新校驗(yàn)，減少用戶不必要的退回環(huán)節(jié)；增加信息預(yù)讀內(nèi)容，減少了用戶填寫的數(shù)據(jù)量，有效提升了師生用戶體驗(yàn)。從資源投入角度來看，減輕了運(yùn)維人力、時(shí)間的投入，降低項(xiàng)目投入成本。從未來發(fā)展角度來看，業(yè)務(wù)系統(tǒng)之間脈絡(luò)更加清晰，便于和其他業(yè)務(wù)系統(tǒng)快速對(duì)接，便于快速實(shí)現(xiàn)數(shù)據(jù)共享和統(tǒng)計(jì)，助力AI 智能分析和領(lǐng)導(dǎo)駕駛艙融合。

圖3 運(yùn)維方式對(duì)比

經(jīng)過多年的平臺(tái)重構(gòu)建設(shè)，復(fù)旦大學(xué)一表通平臺(tái)在實(shí)現(xiàn)校園一網(wǎng)通辦業(yè)務(wù)績(jī)效提升、價(jià)值創(chuàng)造、校園業(yè)務(wù)統(tǒng)籌治理方面發(fā)揮了非常重要的作用。然而，未來校園綜合業(yè)務(wù)信息化建設(shè)是一個(gè)復(fù)雜而長期的過程，在遇到多業(yè)務(wù)聯(lián)動(dòng)、多表交叉使用的需求時(shí)，依然存在一定的挑戰(zhàn)。下一步，將著重研發(fā)多業(yè)務(wù)聯(lián)動(dòng)的技術(shù)攻關(guān)，滿足師生更多復(fù)雜的功能需求，有針對(duì)性地優(yōu)化服務(wù)性能。