復旦大學基于容器化重構一表通平臺

文/齊鳳林 張凱 高珺 張樂

微服務及其所驅動的容器化技術日益成熟，微服務倡導將一個簡單復雜的應用分解為一組小型的、專門的服務，每一個服務運行在各自獨立的進程中，各個服務之間協調配合，實現業務的高內聚、低耦合，成為當前國內外一線互聯網公司廣泛應用的技術。以復旦大學為例，原有的師生填表服務分散在Spring MVC、Grails、eService 等不同的平臺架構之上，這種混合架構雖然曾臨時滿足了學校管理和服務綜合化發展的需要，但是在使用中也遇到一系列問題。

服務分散。師生填寫表單時，存在多個入口，界面不統一、操作方式不一致。由此導致用戶體驗不佳。

開發與運維效率低。由于各個業務系統創建時間不相同、原始開發環境各不相同、發展過程不平衡等原因，導致開發與運維人員需維護多個不同的框架和部署環境。進而造成需求響應慢、業務部署慢等諸多問題。

更新迭代困難。由于服務使用的框架不同，造成后續系統之間對接困難。部分開發人員的流動更導致部分業務無法更新，并可能存在潛在安全問題。

為了解決這些問題，復旦大學信息辦在考察了多個成熟的新技術之后，梳理現有校內填表業務的實際情況，通過系統重構將各個填表平臺進行整合統一。在重構過程中，積極融入容器化的思想，在設計階段就將目標設定為一個可快速迭代、快速部署的統一填表平臺。利用Ruby on Rails、Docker、Swarm 等技術，最終完成了能夠快速響應用戶需求、快速進行部署、快速按需擴展的一表通平臺。

架構現狀

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

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

網上辦事服務大廳的一部分填表業務是委托公司基于Spring MVC 框架進行構建的（以下簡稱“S 類”業務表單）。該架構由于模型和視圖嚴格分離，每增加一個構件，均需在模型層、視圖層和控制器增加對應的描述，每個構件在使用之前都需要進行徹底的測試，給開發調試應用帶來一定的困難，不適合高校小型、中等規模的應用服務。

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

表1 架構現狀

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

業務重構

如圖1 所示是表單業務重構的詳細設計步驟，第一階段整理所有的關聯表單，分別有G 類表單、S 類表單和E 類表單。通過和業務部門溝通，理清所有表單最新的業務需求，確保重構后表單滿足現有業務部門要求。第二階段除了做技術重構外，根據業務部門最新需求，進行內容重構；第三階段對接工作流平臺之后，統一形成基于Rails 的R 類表單：R-Ei，R-Si，R-Gi。

圖1 表單重構設計步驟

下面按照分別對G 類、S 類、E 類表單重構步驟分別陳述。在整個表單重構過程中不會原版原樣復原，而是根據最新的功能需求添加校驗和布置排版。重構過程中不僅考慮PC 端的體驗效果，更多地考慮移動端的體驗，讓其在符合新架構下統一風格的同時，進一步提升師生用戶體驗。

G 類表單

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

表2 Grails 表單梳理

S 類表單

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

表3 Spring MVC 表單梳理

E 類表單

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

表4 eService 表單梳理

以上三類表單適應性改造完成后，通過使用約定的工作流接口，對接Rails 架構。在后續的開發過程中具有更高的可維護性、可擴展性、可復用性。此次涉及的重構業務表單共達54 個。原來的技術架構由于獨立部署，無法滿足業務之間復雜關聯的需求，在業務流程改造之后，新的技術框架破解了這種局限性。以業務“教育培訓項目結項”為例，需要根據教育培訓立項的項目編號及內容進行結項申請，申請人不可避免地需要人工查詢原始立項的信息，業務重構之后可以通過系統自動關聯，省去了不少人工操作。

容器化部署架構

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

圖2 架構重構示意

重構后的一表通平臺具備以下特點：

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

分離文件存儲。原始一表通平臺所有文件存儲服務和一表通自身服務是放在同一個服務器上，當文件的瀏覽量增加時，會增加一表通服務器的壓力。此次重構將業務數據存儲在對象存儲S3 中，降低了一表通平臺服務器自身的負載壓力。當有業務下載需求時，一表通服務器本身只對鏈接做簽名，利用帶有簽名的鏈接直接從S3 下載文件，該過程用戶認證透明無感知。

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

創新點

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

圖3 運維方式對比

經過多年的平臺重構建設，復旦大學一表通平臺在實現校園一網通辦業務績效提升、價值創造、校園業務統籌治理方面發揮了非常重要的作用。然而，未來校園綜合業務信息化建設是一個復雜而長期的過程，在遇到多業務聯動、多表交叉使用的需求時，依然存在一定的挑戰。下一步，將著重研發多業務聯動的技術攻關，滿足師生更多復雜的功能需求，有針對性地優化服務性能。