|
微服务的概念由Martin Fowler和James Lewis于2014年共同提出，它是一种软件架构思想，将单一应用程序拆分为众多的小型服务组件进行开发，其中每个服务组件拥有自己的进程和通信机制，可实现自动化轻量级独立部署，且各个服务可通过不同的编程语言实现并使用不同的数据存储技术。 高校信息化发展已进入智慧校园建设阶段，但制约其快速发展的一个重要因素即是数据，部分高校已经建设了统一的中心化数据平台并提供数据服务，然而效果并不明显，主要表现为以下几个方面：1.信息系统分散，核心业务数据同步至中间库（共享库）滞后或者无法获取；2.数据质量不高，数据更新不及时，形成断层现象，导致数据不一致；3.业务部门缺乏安全意识，数据泄漏或线下传递现象频发；4.重复的硬件成本投入；这种中心化的建设方式在数据准确性、及时性及系统的扩展性和易维护性等方面均难以满足智慧校园建设对数据服务的要求。 本文从高校信息化建设自身特征出发，基于微服务架构思想，采用分而治之，集中监控管理的方法，构建分布式数据服务平台（DaaS），规范数据接口和数据来源，为应用系统、移动应用等提供权威的数据保障，助力智慧校园快速发展。 平台设计方案 服务划分原则 要实施微服务治理，首先面对的问题如何划分业务从而实现服务化，基本的解决思路是拆分和分层。拆分的策略有两种即横向拆分和纵向拆分，横向是指根据业务域进行，从而形成独立的业务微服务集群。纵向是指针对某一模块或组件拆分形成独立的原子服务。分层是指梳理、抽取核心或者公共的原子服务下沉至核心或公共服务层，逐步形成稳定的底层服务。其次是拆分的粒度，这是服务拆分的难点，微服务架构也是循序演进的过程，可参考以下原则：1.功能完整，职责单一；2.API版本兼容性优先；3.迭代演进，团队可接受。 业务梳理 高校业务系统的建设质量参差不齐，大部分业务系统管理严谨，数据完整，接口规范，能独立向外提供数据服务。相反，部分业务系统在数据和对外接口方面均不完善，形成了数据孤岛。针对高校业务系统的现状和数据的提供源，本文将微服务数据平台的服务分为两类：原生型和代理型。原生型是指业务系统本身不对外提供数据接口服务，基于微服务技术进行开发集成，数据源直接取自（非）关系型数据库。而代理型是指业务系统已有基于SOAP协议的WebService服务，将其封装注册至微服务组件中。 架构设计 如图1所示，本文构建的微服务分布式数据平台主要包括三个部分：数据源、微服务组件、数据管理平台。
数据源是微服务事实的实际数据提供者，从数据库种类上分，既有关系型数据库，也有非关系型数据库。从来源上分，既有实际的业务数据库，也有基于数据同步机制的传统共享库。实际业务库主要提供实时的数据来源，如统一认证库、人事数据库、一卡通账户等，而共享库主要提供离线的数据分析，将分析结果对外提供数据服务，如科研成果、一卡通历史消费、论文数量等。 在微服务架构设计中，需要核心组件作为技术支撑，包括：1.服务注册中心，主要实现服务的注册与发现，微服务之间通过注册中心彼此感知，同时从注册中心订阅自己需要引用的服务。2.服务网关，它是外部调用数据的唯一入口，对外屏蔽系统内部结构，提供动态路由、监控、授权等功能。3.容错机制，每个微服务一般会有多个实例服务提供服务，为保证服务高可用，需要提供负载均衡及熔断机制。4.统一的配置管理，提供集群中心化的统一集中配置，简化开发和运维的繁琐。5.日志和监控管理，微服务是独立的服务组件，种类和数量繁多，需要通过日志和统一管理界面监控各项指标及出错的链路跟踪。 数据管理平台主要负责对平台的界面化统一管理，包括微服务节点状态监控、应用授权、开发者账号授权、标准化文档维护等。 技术实现方案 通信协议 本文设计的微服务平台采用轻量级的通信规范，微服务之间的通信遵循REST风格，而数据交换格式采用JSON。对于REST及JSON的相关概念，本文不再赘述。基于这种风格的通讯机制，与传统的基于SOAP和WSDL的服务相比更简洁。 技术框架 目前实施微服务架构可供选择的方案有Dubbo和SpringCloud，前者是开源的服务治理框架，服务调用方式采用RPC，是实现微服务的基础组件，对于微服务涉及的其他必要组件未必提供。而SpringCloud是由Spring开源社区提供，整合了现有的服务治理的主流技术，包括服务注册中心（Eureka）、网关（Zuul）、配置管理（Spring CloudConfig）、消息总线（Spring CloudBus）、负载均衡（Ribbon/Feign）、熔断器（Hystrix）及一些工具包，比如数据流操作工具（Spring CloudStream）、安全工具包（Spring CloudSecurity）等，覆盖微服务实施的方方面面，底层基于SpringBoot技术，天然的支持RESTful风格。 平台实现 基于SpringCloud微服务框架可方便的构建出数据平台的原型，如图2所示。每个独立的微服务均提前注册至注册中心（EUREKA），客户端的请求通过网关（ZULL）分发，根据请求接口路由至相应的微服务，对于每个微服务一般会有多个节点，采用Ribbon做负载均衡保证服务可用，而Hystrix做熔断器来避免服务调用的雪崩现象，集群的统一配置文件通过配置中心及时更新实现。
为保证微服务之间接口调用的安全，需要进行服务之间的身份认证。简单的做法可以使用IP地址段隔离来保护被拆分的服务，适合于短时间内迅速迁移服务的场景。从长远来看，此种方式存在局限性，对网络架构存在依赖性，故本文设计的架构中采用JWT（JSON Web Token）方式进行身份认证，客户端的请求经过网关时会向授权中心（AUTH）请求JWT，当实际请求到达某个微服务的时候，微服务会向授权中心获取JWT验证是否是合法的请求。同时授权中心还承担给应用授权的任务，一般新申请的应用授权中心会分配一组App ID和App Secret，通过数字签名和验签的过程来校验应用的合法性。 根据实际业务出发，本文设计的微服务分为两种，一种是公开信息类服务，另一种是受限类服务。前者是指无需数据拥有者授权即可使用，此时只需申请的应用在授权中心注册即可，比如通知公告类，本身新闻数据是对外公开的，为防止接口的恶意调用，只需对应用进行授权验证即可。后者指的是私人敏感数据，需要数据拥有者授权后方可使用，比如课程、成绩等，该服务基于Oauth 2.0协议，配合学校统一身份认证平台实现，用户一卡通号和密码经过统一身份认证后，授权给第三方应用使用数据。 数据安全管理 数据安全是高校信息化建设过程中一直面临的问题，主要原因在于业务系统分散管理，业务部门对数据的安全性重视程度不够，作为私有财产保护的同时缺乏技术手段进行管理。数据安全管理需要技术和行政手段共同发挥作用，本文构建的分布式数据平台从技术层面进行统一规范管理，基于授权认证机制保证数据的相对安全。在业务系统作为微服务接入数据平台的过程中，对数据库账户密码安全性、授权范围、防火墙配置等方面进行规范，而对于使用数据的开发者，平台通过注册授权方式指定特定数据接口的使用范围、使用期限，遵守接口文档的使用规范，开发调试期间数据经过脱敏处理。而行政管理手段，首先是健全数据管理队伍，学校层面大力支持，信息化部门和二级单位积极配合，明确实行数据共享的意义。其次对数据使用者而言，按照“谁使用，谁负责”的原则，在严格履行数据使用申请、审批、签署保密协议的基础上，信息化部门还要加强数据的使用监督和安全风险提示，对存在安全隐患的使用方式停止数据提供。 微服务数据平台不是对原有数据仓库或共享库的颠覆，而是有效补充，原有的数据中心或者数据仓库是离线数据挖掘和分析的重要数据源，是微服务数据平台重要的数据支撑。从实践效果来看，平台服务松耦合，易扩展，数据共享灵活，运维方便，是构建统一数据平台强有力的技术手段。（责编：杨燕婷） （作者单位为江苏大学信息化处互联网与计算技术研究所） 本文刊载于《中国教育网络》杂志2018年6月刊 |
