案例分享丨为什么选择自建校园App？
数据分析机构QuestMobile发布的《中国移动互联网2019半年大报告》中指出，用户对移动互联网的依赖依旧强烈，平均每天花在移动互联网的时间近6小时。从近两年的报告中可以看出，移动互联网正在推进各行业的创新模式，各行各业都在积极填补不同场景下用户需求的洼地，争夺用户时长。而高校学生是移动互联网的主力军之一，在此背景下，学校应积极整合学校现有的信息和服务，建立自己的校园移动应用平台。
北京大学医学部
目前，越来越多的高校投入建设PC端一站式服务平台，一站式服务的理念将成为学校信息化建设的趋势。然而，在PC端一站式服务平台推进的过程中发现，以PC作为单一入口的服务模式在即时性和互动性等方面存在一定的局限性，已经不能满足高校师生的需要。随着移动互联网的发展和普及，移动服务可以作为一站式服务的新模式继续得到发展。
学校移动服务实现方式
学校移动服务的实现有多种方式，例如微信公众号、企业号或小程序，独立的定制化移动应用等。
1.微信公众号、企业号或小程序
由于微信的受众广泛，微信公众号、企业号或小程序可以得到广泛的传播和使用。微信公众号主要用于发布消息；微信企业号可以部署一些交互简单的服务，但是扩展性较差；小程序虽然能实现较为复杂的功能，但是消息推送能力受限，用户留存度普遍偏低。如果学校各部门申请自己的服务公众号或者基于小程序开发各类功能服务，会使用户获取校内信息和服务的来源增多，导致校园移动服务分散、用户分离和信息孤岛，不符合"一站式服务"的理念；即使学校使用统一的企业号或公众号，随着功能和信息的增加，也不符合微信公众号简单轻量的特质，用户体验较差。
另外，微信上部署的服务在功能上会受到一定程度的限制，例如基于微信开发学校的缴费类服务只能对接微信支付，无法接入多元化支付方式。
2.独立的定制化移动应用
相对而言，独立的App虽然开发周期较长，实施难度较大，但是其优势符合"一站式服务"的理念和长远规划。
独立的App可以更为充分地考虑用户需求，根据实际情况定制化开发和实现更为复杂的业务功能及交互逻辑，在保证功能全面的同时具备良好的使用体验。通过建设独立的定制化移动应用，学校可以统一移动端的信息化服务入口，将移动应用建设为一个与PC端一站式服务平台相辅相成的开放移动门户。移动应用可以多元化接入各类服务，包括身份认证、消息推送等基础服务，移机交互相对复杂的业务服务等，充分满足校园内各类用户的需求。同时，移动应用还可以用作学校的移动"消息网关"来统一推送消息，不但易于实现内容和权限的控制，而且不会受限于第三方平台。
总的来说，移动应用的建设可以在一定程度上提升用户体验，以"一站式移动门户"为建设目标，避免功能服务重复建设，集中用户，打破信息孤岛。
学校移动应用建设
北京大学医学部于2016年正式建成PC端综合服务平台，并投入使用。截至目前，综合服务平台上部署的服务已涵盖网络、教务、学工、人事、财务、办公、设备管理等多个业务领域，实现了"统一信息门户，统一入口"。因此，北京大学医学部的移动信息化建设具备良好的信息化基础。
建设目标
互联网移动应用产品之间激烈的竞争迫使各个公司的移动应用必须做到快速迭代以维持生命力，并应对日益变化的用户需求。北京大学医学部为充分满足校园用户的使用需求，不断提升用户体验，在移动应用平台建设过程中，主动向"以用户为中心"的互联网模式转变，开发实用的北医专属App，服务广大师生。
北京大学医学部于2018年开始进行移动应用平台建设，旨在实现以下目标：
1.与PC端服务平台共同构成"PC+App"双入口模式的校园信息化生态体系，为师生提供随时随地的校园信息化服务；
2.统一规划和部署移动应用平台基础架构，规范平台服务和功能的接入标准，实现一个平台，多元接入；
3.以用户为中心，注重收集不断增加和变更的用户需求，积极响应用户反馈，实现移动应用的灵活扩展和快速迭代。
技术架构与选型
基于传统的单一整体式应用架构开发的系统平台，随着时间的推移会变成"铁板一块"，往往会有服务划分粒度粗且过度耦合、升级维护难、无法快速迭代更新等问题。微服务应用架构是目前比较热门的一种开发软件的后端架构，是指将单个应用程序拆分设计为一套单独部署的小型服务群，这些小型服务可以独立进行开发、部署、测试、上线、下线，并独立运行在不同的进程中，服务之间通过轻量级的交互机制实现通信。相对于单一整体式应用架构来说，微服务架构具备开发效率高、持续部署、服务独立扩展、容错性能好等优点。基于微服务架构开发的系统更加健壮、易扩展，能够快速迭代更新、快速响应用户需求。
目前，市场上已存在一些成熟的微服务系统架构，主流的框架有Dubbo、SpringCloud、Thrift、Motan。相对来说，Dubbo和SpringCloud提供了比Thrift、Motan更为全面的技术支持，且社区活跃度更高、应用范围更广。其中，SpringCloud提供了一套更为完整的微服务架构生态体系，包含功能丰富齐全、可配置的轻量级组件，支持服务注册与发现、负载均衡、API网关、服务容错等功能，能够大大降低系统开发难度。Dubbo则需要额外整合服务网关，并且其服务容错功能也不完善。虽然SpringCloud采用的HTTP RESTful服务调用方式的网络性能相对于Dubbo的RPC方式低，但是也更加易用、灵活和轻量化，而且可以通过高速缓存、压缩等方法提升SpringCloud的网络性能。另外，SpringCloud框架下，还可以基于SpringBoot构建功能独立的微服务单元，减少开发时间和成本。
结合北京大学医学部潜在用户数及服务并发量、服务应用场景、开发能力现状等多个因素，最终选用了SpringCloud框架来搭建移动应用的底层架构。
图1 基于 SpringCloud 的微服务架构
在SpringCloud的微服务架构中，Zuul网关作为系统后台的唯一入口，用户所有的请求都要先经过网关，再由网关将其路由到指定的微服务；Eureka服务注册中心负责管理和记录各个微服务的IP、端口等网络信息，并将信息提供给Zuul网关来实现服务调用；Ribbon实现了客户端负载均衡，由客户端根据一定的负载均衡策略来调用对应的微服务；Feign则是一个声明式的JAVA HTTP客户端，用于实现各个微服务间的通信与调用；Hystrix可以用于解决微服务间交互超时的问题，并支持服务容错。
建设内容
北京大学医学部校园移动应用平台包括应用服务子平台、应用服务管理子平台及数据服务子平台三部分。其中，应用服务子平台，即"医信随行"App，主要面向学校师生提供各业务域的移动服务；应用服务管理子平台面向信息化部门管理员和各部门的二级管理员，用于对"医信随行"App进行管理配置；数据服务子平台主要向应用服务子平台和应用管理子平台提供数据服务。
图2 移动应用平台系统架构
1.应用服务子平台
应用服务子平台，即"医信随行"App，是整个移动应用平台建设的核心，直接面向用户提供服务，统一了不同角色用户的移动服务入口。在整合应用服务需求的过程中，避免了各类服务的盲目叠加和接入，充分考虑了PC端与移动端产品体验上的场景差异，统一规划设计，将适用于移动终端使用的应用服务逐步迁移到App上或重新定制开发。
（1）服务实现方式
"医信随行"App上的业务服务有两种实现方式：
根据业务实际需求，定制开发原生或H5移动服务。使用定制开发的方式可以灵活设计用户界面，从而提升用户体验，但是对团队的开发能力要求较高。
第三方业务系统在具备H5服务的情况下，可以快速集成和接入"医信随行"App，不必重复开发。例如，"医信随行"App的邮箱服务、OA服务。使用这种方式对接，"医信随行"App只需提供单点登录、图标配置、应用权限配置等支持即可，节约了开发时间，有利于解决学校开发能力不足的问题。
（2）功能模块
"医信随行"App内的应用服务可以分为通知公告、业务服务、消息推送三大功能模块。
通知公告服务可以向师生提供校园新闻、通知等动态，其内容与PC端综合服务平台同步，但以更适合手机端的形式展示出来，方便师生随时随地获取校园动态消息。同时，对于校园内部新闻，设置为限制校园网访问。
图3 通知公告服务
"医信随行"App提供校园内各类公共和专项业务服务，这些服务按不同的用户角色访问可以划分为校园公共服务、教师服务及学生服务，实现了各类角色用户访问统一入口，针对角色定制服务。"医信随行"App中面向学生角色开放的业务服务有缴学宿费、学宿费票据、成绩查询、志愿服务、学生钱包（奖助勤补）等；面向教师开放的业务服务有班级花名册、薪资查询、日程管理、OA；面向师生统一开放的公共业务服务有校历、课表、学校邮箱、上网服务、缴电费、缴网费、温馨提示等。现有的业务服务已涵盖学工、教务、财务、网络、办公等多个业务域。
在校园信息发布方面，"医信随行"App更加强化了主动性的信息传递，将碎片化信息、通知等消息主动推送给师生，提升信息时效价值。消息推送模块的主要功能是将信息、通知等以App内部消息通知的方式推送给师生。用户手机的通知栏可以收到推送的消息，也可以在"温馨提示"服务内查看所有的消息。
消息触发推送的方式有两种：后台程序设定好触发条件及推送内容，例如网络服务即将到期提醒、学宿费待缴提醒等，这种方式无需管理员额外配置，程序会自动触发推送；由系统管理员在服务管理子平台上配置推送内容及被推送用户后手动执行推送操作，这种方式适用于临时性的校内通知。
图5 消息推送服务
消息推送功能一方面可以作为学校师生获取即时性消息的渠道之一，一方面可以在一定程度上增强用户粘性、提升用户留存。消息推送功能的设计打破了"人找信息"的传统校园信息化模式，是校园移动应用向互联网模式转变的一个创新性设计。"医信随行"App目前已经实现了学宿费待缴提醒、网络服务即将到期提醒及各类支付缴纳结果实时通知等一系列消息推送服务。
2.应用服务管理子平台
服务管理子平台是面向信息化部门管理员和各部门二级管理员的一站式移动应用管理平台，支持对"医信随行"App进行用户角色及权限管理、应用服务管理、用户行为数据统计、安全及错误监控等。
角色及权限管理功能基于RBAC（Role-Based Access Control）角色的访问控制模型开发，即先把服务访问权限赋予角色，再将角色赋予用户，通过权限管理模块严格控制不同角色用户的服务访问权限。"医信随行"App的用户角色分为教职工、研究生、本科生等，用户与角色为一对多的关系。在发布应用时，管理员需要严格管控每一个应用对应的角色权限。
应用服务管理功能支持应用服务的分类管理、专题管理、新增和配置、上下线等，管理员可以严格管控每一个接入移动应用的服务。除此之外，该部分还支持对App内宣传图片、宣传文字的配置，支持管理员详细记录App每一次版本迭代的时间、内容，合理安排迭代周期。
用户行为数据统计部分包含新增和活跃用户统计、用户留存分析、各业务服务点击量统计等功能。用户行为数据统计可辅助了解学校师生的行为习惯及规律，从而协助发现移动应用运营中存在的问题，为"医信随行"App未来的迭代和功能扩展指明方向，实现数据运营。
安全监控部分主要是对"医信随行"App运行过程中出现的各类安全事件、安全威胁、安全风险进行实时监测；错误监控部分主要监控移动应用的崩溃及其他自定义异常，并标记问题的处理状态。安全及错误监控保障了"医信随行"App运行期间的安全，可以协助开发者及管理者及时处理随时可能发生的安全问题及运行错误。
3.数据服务子平台
数据服务子平台主要通过数据库、数据接口、数据缓存等多种方式向服务子平台及管理子平台提供数据服务。
图6 数据服务子平台模块
医学部各个部门产生的业务数据，有的已同步到学校的数据中心进行统一维护，有的存储在本部门的业务数据库中由业务部门独立维护。基于这种现状，数据服务子平台的设计采用了"一个基本库，多个数据源"的方案，在移动应用平台本地部署一个数据库作为基本库，使用ODI将数据从数据中心和各专项业务数据库抽取到基本库。除此之外，部分服务可以不对接基本库，根据实际需求直接对接第三方业务数据中间库或数据接口。
当移动应用访问并发量大时，直接访问数据库来获取数据就会变得很缓慢，可能出现访问连接超时的情况。因此在应用服务与数据库或数据接口访问之间部署了内存数据库，将热点数据先放入缓存中，从而提升查询效率，缓解数据访问压力。
实践效果
"医信随行"App于2019年7月8日暑期第一天上线试运行，已对接学校统一身份认证，校内师生无需重新注册。App在暑期试运行一个月后，新增用户959人；上线6个月时，累计用户为7328人，累计启动次数为225857次；期间最大日活为1826人，占当天累计用户的41.7%。
App自上线之后的6个月内，共迭代发版6次，每次更新的主要内容为上线新服务或用户体验优化、问题修复。目前，App共上线16个应用服务，涉及教务、网络、财务、办公等多个业务域。在运行过程中，访问量Top5的应用服务为缴学宿费、成绩查询、学校邮箱、学校新闻、缴网费。其中，缴学宿费服务在2019~2020学年新学期开学季8月份和9月份累计访问26395次，承担了大部分新学期学宿费缴纳和查询的业务，减轻了财务部门的负担；仅在2019~2020学年的最后一周，成绩查询服务累计访问达10101次。以上这些数据充分说明"医信随行"App的建设满足了学校师生对移动信息化服务的需求。
北京大学医学部"医信随行"App与PC端综合服务平台，构建成了"PC+App"双入口模式的校园信息化环境，拓展了信息化服务的时间和空间维度，增强了学校信息传递的能力。实践证明，移动应用平台的建设符合学校师生获取信息服务的迫切需求，可以有效解决校园信息化服务的痛点，更好地为在校师生提供方便快捷的信息服务。
移动互联网领域普遍认为，移动互联网产品的发展过程是一个不断证伪的过程，根据设想的或一段时间内收集的用户需求来开发产品，然后在广大用户实际使用的过程中才能验证最初的假设是否成立，进而不断的优化和调整。这个理念对于学校的移动应用也同样适用。移动应用平台的投产并不是项目的结束，北京大学医学部会继续积极响应用户需求，以提升用户体验为目的做到积极迭代更新，不断提升"医信随行"App的活力。
本文刊载于《中国教育网络》杂志2020年5月刊，作者为郑双燕，作者单位为北京大学医学部信息通讯中心。
投稿、转载或合作，请联系：eduinfo@cernet.com