使用微服务构建智慧校园全生命周期服务平台

智慧校园全生命周期服务，是以“服务”为视角，实现面对全校师生的碎片化服务，建立校内有机的业务协作关系，将学校内的各种业务流程穿接起来，实现能够支持学生从新生入校、在校学习生活直至毕业离校的全生命周期管理。

要实现全生命周期的服务，智慧校园基础平台需要一种更先进、更适应变化、扩展性更强的技术架构作为支撑。微服务架构（Micro-Services Architecture）就是满足上述要求的一种技术架构。

一、微服务简介

常规Web应用的核心是由模块实现的业务逻辑，它定义了服务、领域对象和事件。围绕核心的是与外部接口对接的适配器，如数据库访问组件、生产和消费消息的消息组件、暴露了 API 或实现了一个用户界面的 Web 组件。尽管应用可能有一个逻辑模块化架构，但它一般会被作为一个单体进行打包和部署，实际格式取决于应用程序的语言和框架。这种构建Web应用的架构我们称之为单体应用（Monolithic Application）架构。

然而，随着业务需求及其复杂性的增加，上述架构的局限性逐步显现出来——应用的代码规模随着应用功能越来越丰富而急剧膨胀，进而对敏捷开发和交付产生极大的影响：

l 应用程序过于复杂，修复Bug和实现新功能困难且耗时，部署、启动也变得非常缓慢，阻碍持续集成的效率。

l 不同模块对于资源的需求可能不一致，比如有的模块是CPU密集型，有的模块是IO密集型，部署在一起的时候很难选择适合的硬件。

l 所有模块运行在同一进程中，对可靠性有很大影响，任何一个模块的Bug都可能导致整个应用不可用。

l 对于使用新技术产生重大障碍，无法采用更先进的新框架或程序语言。

微服务架构的思路则是将单体应用分解为一系列小规模的互连服务。一个服务通常实现一组不同的特性或功能，每个服务都是一个微型的单体应用，内部包括了相关的业务逻辑和所需的适配器。一些微服务会开放API供其他微服务或客户端使用，另一些微服务会用来呈现用户界面。通过这种方式，微服务架构很好的解决了单体应用的上述困境：

l 单个微服务的规模通常会控制在一定程度，客观上降低了复杂度，从而提高了Bug修改、新功能实现、测试和持续集成的效率。

l 每个微服务都可以由一个小团队独立开发、部署，采用/更换新技术框架/语言的成本大大降低。

l 不同服务能够独立运行、扩展，便于根据服务特点采取最匹配的硬件，同时还能隔离运行环境，不会相互影响可靠性。

虽然微服务架构很好的解决了单体应用的一系列问题，但它同时也在技术层面带来了一些新的挑战。微服务架构下，服务数量比之前大大增加，在开发时需要采用适合于分布式系统的跨进程通信机制，以及考虑数据一致性的机制，这都加大了研发本身的复杂程度；测试的复杂程度也会增加，原来测试只需启动单体应用即可，现在测试某一个服务可能需要同时启动多个关联服务；运维方面，服务的配置、部署、扩展复杂度都会随着服务数量的快速提升而大大增加，以至于依赖于手动操作无法处理。这些新问题也需要新的技术手段来解决。

二、基于微服务的智慧校园技术架构

图1 基于微服务的微哨智慧校园平台架构

如图1所示，基于微服务架构的微哨智慧校园平台由基础服务、业务/数据中台、API网关、服务保障几部分组成。

基础服务层由若干微服务构成，提供与具体业务无关的、最底层的基础能力（如存储、日志、检索、消息队列等），为上层面向业务的微服务提供底层能力支持。

中台将一系列基于智慧校园各类基础业务场景构建而成的微服务组合在一起，形成一套对应核心场景的微服务集合，如用户管理、权限控制、应用管理、通知中心、数据分析等。按照服务性质的不同，中台可进一步分为业务中台和数据中台，分别提供业务相关能力和数据相关能力。对于中台里面的微服务，其拆分的颗粒度应当结合业务需求和研发运维成本进行动态平衡；当业务发展变化时，相关的微服务也应根据需要进行相应的拆分或合并，达到一个效率和成本相对平衡的状态。

无论是融合门户还是应用，都需要基于智慧校园平台所提供的能力进行开发建设。在智慧校园微服务架构中，上述能力是通过API网关（API Gateway）对外提供出来的。API网关的主要作用是对业务/数据中台开放出来的能力进行聚合、封装；为了更好的支持用户界面的交互设计，方便API调用方的使用，它通常会调用多个微服务并聚合结果来对一个请求进行处理。此外，API网关还可以起到协议转换、负载均衡、访问控制、API计量和监控等作用。作为一个特殊的微服务，API网关也可以根据服务对象的不同进行拆分，以便提供更清晰易用的API接口。

如前所述，与单体应用相比，众多微服务也会给服务的部署、调度、伸缩、监控等运维方面带来一系列问题。微哨智慧校园平台是通过外围的服务保障层来解决上述问题，服务保障层由一系列的运维框架和系统组成，是平台中所有微服务的贴身管家、健康医生和安全卫士。无论是微服务的加入、退出、升级，还是服务节点的扩容、缩减，都能通过服务调度中心自动化进行服务发现、注册、调度；微服务的异常预警，或完整调用链路的问题跟踪，也能方便的通过监控平台完成。

三、微服务的交付与运维

在全生命周期的框架下，智慧校园对于快速需求响应的要求是很高的。采用微服务一方面带来了开发效率提升，另一方面也增加了服务部署的复杂度：在微服务架构下，一个完整的系统由很多微服务共同组成，而每个微服务都会有自己对于配置和依赖环境的要求，如果按照传统的模式逐个进行部署，其工作量将会非常大，所需时间也将会非常长。

容器（Container）是随微服务架构发展出来的一种虚拟化的技术，它能够让微服务的部署发布变得更加方便。容器技术借鉴了虚拟机的思路和特性，通过将应用和必要的依赖环境打包封装到镜像中，解决了配置和依赖的问题；通过提供运行时层（Runtime）的方式，镜像可直接运行，且相互之间进行隔离，完美的契合了微服务的理念。和虚拟机不同的是，容器中的应用是直接运行在宿主操作系统之上，并不需要一个虚拟底层接口的适配层和另外一个操作系统，因此相对来说更轻量，启动/运行快、资源占用少。

此外，容器也加速了微服务的持续交付。通过自动化的工具链，提交的代码在通过编译、自动化测试后，自动打包为镜像并上传到镜像仓库。在部署阶段，部署环境直接拉取仓库中的镜像到本地容器并运行即可完成部署，大大加速了部署效率，同时减少了依赖或配置错误的可能性。

图2 基于容器技术的微哨微服务持续交付

全生命周期服务平台的另一大挑战是服务的可用性。服务的可用性是运维中的一个重要指标，指的是服务保持正常运行的时间在总服务时间的占比。在众多校园业务场景中，部分业务存在突发大流量、高并发的需求，如入学、毕业、选课、报名、成绩查询等。要想让系统在上述情形下保持正常运转，就必须做到“高可用”。通俗来说，高可用的要求就是无论流量大小，服务越稳定越好，不能宕机。这就要求在系统的技术架构上进行一定设计，以保证在大流量的访问情况下系统依然能够正常应对。

实现系统高可用的基础思路可分为垂直扩展和水平扩展两个模式。垂直扩展的思路是提升单个实例的处理能力，整个系统在横向切分为几层，每一层负责相对比较单一的职责，同时上层对下层有依赖和调用。水平扩展则分为两类：一类是通过增加实例，线性扩充整体的系统性能；另一类是分离职责，根据功能/业务/特点将大的系统模块切分。由此可见，微服务架构也是符合分层和分割这种基础架构思路的：从前端到API网关，到业务中台，再到底层平台，无不贯彻了垂直扩展的分层原则；而微服务按照业务进行切分，则是水平扩展原则的最直接体现。

在上述两种基础模式之上，集群、缓存、冗余、异步等高可用手段都可运用于微服务中。微哨在这些方面也有丰富的实战经验，下面以迎新和通知发送两个实际场景为例加以说明。

1、 迎新：全生命周期服务从新生入校之前就会开始，而新生报到时会有大量用户集中使用信息查询、账号开通、在线缴费、选宿舍等多项业务，带来较高的并发流量。因此，对于相关的微服务，我们在入学报到前期会进行扩容，实施集群部署、负载均衡等手段，可顺利应对突发流量；

2、 通知发送：高校通常会发送通知、公文的。一方面，各类通知面向的对象不同，接收范围的计算也非常复杂，可能会混合部门院系、岗位、标签、职务等多个组织维度；另一方面，通知接收终端的数量也可能很大，单个通知的接收人数甚至可多达数万人（如全校发送）。为了保障通知及时、准确的发送，消息中心微服务也应用了很多高可用的手段。在接收范围计算上，消息中心使用了缓存的机制，对于重复的范围计算一次并缓存，后续的发送可直接从缓存读取，大大提高了响应时间；在消息发送上，采用批量+异步队列的方式进行消息推送，可稳定应对大批量的通知发送场景。

与单体应用相比，在实现高可用方面，微服务架构有显著的资源使用优势。例如：使用集群扩容手段应对高并发访问，如果采用单体应用的架构，扩容所需的资源会非常巨大，而且高频模块和低频模块都被复制、运行，整体资源无法得到高效利用；而采用微服务架构，只需针对高频业务链条上所涉及的服务进行扩展，甚至可以更精细化的根据链条上各环节的流量进行相应的资源分配，在确保业务和平台稳定的同时，也能有效的避免资源浪费。

结语

随着“最多跑一次”政务服务改革逐渐延伸到高校，智慧校园平台也提出了“全生命周期服务”的建设目标，客观上需要一种更灵活、扩展性更好的技术架构作为支撑，而微服务架构恰好满足上述要求。微服务带来的不仅是更先进的架构，还有更敏捷的产品开发、交付和运维，这正是建设新一代智慧校园全生命周期服务平台所需要的。

本文发表于由国家信息中心数字中国研究院编辑出版的《数字中国建设通讯》2019年第3期