复旦大学基于容器化重构一表通平台

文/齐凤林 张凯 高珺 张乐

微服务及其所驱动的容器化技术日益成熟，微服务倡导将一个简单复杂的应用分解为一组小型的、专门的服务，每一个服务运行在各自独立的进程中，各个服务之间协调配合，实现业务的高内聚、低耦合，成为当前国内外一线互联网公司广泛应用的技术。以复旦大学为例，原有的师生填表服务分散在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 运维方式对比

经过多年的平台重构建设，复旦大学一表通平台在实现校园一网通办业务绩效提升、价值创造、校园业务统筹治理方面发挥了非常重要的作用。然而，未来校园综合业务信息化建设是一个复杂而长期的过程，在遇到多业务联动、多表交叉使用的需求时，依然存在一定的挑战。下一步，将着重研发多业务联动的技术攻关，满足师生更多复杂的功能需求，有针对性地优化服务性能。