编辑点评：本文从如何构建微服务入手，阐述了微服务的构建流程，并对微服务的未来发展进行探索。指出微服务的构建是一项持续的信息化服务，每一项微服务都是校园里智慧的枝叶，众多的微服务汇聚在一起浇灌出智慧校园的参天大树，对于其他学校进行微服务建设具有借鉴意义。

　　智慧校园背景下的信息化微服务，就目前而言，它应该架构在已建成的数字化校园各基础平台之上，包括信息门户平台、数据共享与交换平台、统一通信平台、大数据分析平台、统一身份认证平台、互动教学或教学资源库平台，以及众多的职能业务系统，以催化剂的方式将各个平台和业务融合形成微服务的核心，即微服务不能脱离现存平台，但又高于每个平台和系统的既定运行逻辑和应用群体，它将跨职能跨部门的业务或数据串联成更贴近师生、更便捷管理的服务内容，用户只需发出需求指令，指令涉及的分析计算、数据抽取、业务流程等都通过原有平台获取和加工。简言之，原有的业务系统与平台仍然各司其职，做各自擅长的业务领域和业务流程，微服务以具体的，甚至很微小的服务需求为本，将不同平台与系统搭建沟通桥梁。微服务的内容多为一个平台或系统自身无法解决的服务需求，包括不足以新建一个软件项目或不值得新建一个软件项目来解决的具体问题。

　　构建信息化微服务的目的是梳理原有信息化建设过程中落后的、痒而不痛的服务环节，基于信息化全局优势，构建一套具备快速开发，由校本人员简单培训就能定义功能与服务的信息化能力，精简事务流程，提高业务系统基本数据共享与利用能力，以小事不小的理念和微服务体现信息化建设的价值，拉近师生用户对信息化建设的认同感和满意度，这也是对信息化重建设轻应用的理念转变和管理模式创新。

　　如何构建微服务

　　微服务不是一项服务，可以有许许多多不相关联的服务项组成；微服务也不是某一项或几项固定的职能，因此它也不是任何一种管理信息系统；微服务不是综合服务，类似门户的平台对微服务而言太过庞大。本文认为，微服务应有两种释义，一种是服务的事项本身是微小的，但能够基于信息化手段提供更贴近用户的服务体验；第二种是将大型或繁琐的服务事项微小化，以精简的流程手续服务师生。

　　微服务架构设计

　　智慧校园背景下的微服务，我们把它定义为基于成熟的社交平台构建与用户互动界面，重新融合已建成的管理系统和信息平台，催化出跨界的服务功能，核心理念是将大型且复杂的应用分解为小且内聚的服务，将没有归属的小需求实现为微服务。如图1所示为微服务架构设计示意图。

　　从垂直方向来看，微服务构建与系统平台构建是两个不同的方向，大系统与大平台侧重的是大而全，定位在通过一个系统平台尽可能收纳更多的功能与服务，开发的周期较长，开发过程涉及不同业务系统之间数据流的复杂联系，有赖于系统承建厂商的支持，功能迭代与扩展面临较高复杂度。微服务注重的是轻量服务，定位在以自有力量快速地解决信息应用上的痛点和难点问题，开发必须快速响应，因此以应用催化层关联其各个业务系统、数据库以及各个已建成平台，将各个业务系统和平台所擅长的事情仍交给各系统和平台去处理，应用催化层起到融合的作用，将流程性功能送回原系统平台去处理，将结果性数据直接拿来使用，这样就能最大程度保证应用催化层的轻量。数据交互接口比较XML和JSON两种格式，以JSON格式传递给消息收发前置更适合机器处理，消息收发前置也是一个轻量的功能结构，对内请求和获取消息结果，对外与社交平台进行消息转码和收发，在拓扑上也隔离内部系统与外部社交平台。

　　从水平方向来看，微服务架构设计是可扩展的弹性架构，一个应用催化结构可基于一个微服务功能关联多个应用系统或数据库，也可按URL或SQL等不同事务划分给不同的应用催化结构处理。消息前置结构能以多种方式实现负载均衡与冗余，对应应用催化层即可一对多，也可多对一，对应社交平台也能做到逐一对应或集中对应。

　　应用催化层和消息前置的功能编程，均可由开发人员选择自己熟悉的编程语言，使微服务可以吸纳更多的技术人员参与其中，不同的开发语言实现不同的微服务功能，相应创建多个应用催化结构，每个微服务也就实现了相对隔离，即使某一个应用催化结构存在Bug也不会影响到其他微服务的运行。此外，由于应用催化层是一个轻量结构，相应代码的行数则有限，这也使得代码的阅读与检查变得可行。

　　交互界面上，微信、钉钉等都是用户熟悉的移动社交平台，作为微服务的入口更贴近用户的使用习惯，在操作方式和功能发现上门槛更低，还可省去美工设计而更专注于服务功能实现，这使得微服务在未来具有更宽广的应用场景适应性。此外，作为公共社交平台，不用担心微服务使用热度增加后的资源扩充，节省的人力和财力都可投入到更直接的微服务应用中。

　　安全方面，应用催化层与其他系统平台保护在数据中心内，它与消息收发前置交互数据仅为JSON格式，不需与数据中心外部有其他任何通信，阻断了被破坏或被利用的可能，而消息收发前置与社交平台只是收发消息，并且限定社交平台的接口IP，真正与用户交互发生在社交平台终端，用户发出的功能指令由社交平台处理，再转向消息收发前置，也就是说，用户与微服务的交互并不直接面向消息收发前置，由用户端发出的威胁均有移动社交平台抵受，也就进一步缩小的安全风险。