|
随着高校信息化的不断深入，高校内部的信息系统日益庞大。但由于历史原因，这些信息系统的数据服务一般都采用单一数据中心的方式提供服务，扩展性和维护性都较差。本文借鉴云计算中的相关概念，采用微服务实现解耦、去中心化的方式来为多样化的应用提供更灵活、易重构的数据服务。 1.引言 “数据即服务（Data as a Service，DaaS）”是近来在云服务领域的一个热点，它将原来云服务架构中的数据部分单独拆分出来，将数据存储和数据处理的功能进行服务化，以期实现云环境的下的数据共享。 高等院校信息化经历了数十年的历程，事实上已经积累了大量的数据。随着信息化进程的不断推进，生成数据的终端应用越来越多，积累的数据量也越来越大。如何挖掘和发挥这些数据的价值？一般认为，在数据的基础上提供云服务，是一种有效手段。然而，建设一个物理上统一的数据中心，并提供数据服务，需要重复的硬件投入。这种中心化应用建设，由于其体量庞大，在扩展性、灵活性和易维护性等方面都存在先天性不足。微服务的一个重要特性就是解耦合、去中心化，可以有效应对这些问题。 本文提出了一种基于微服务的数据服务框架设计，实现基于微服务的DaaS。参照该框架，利用微服务的先天特性，建设一个易扩展、便于运维的数据服务平台，可以实现更加灵活的数据共享。 2.相关研究 Ming Li等在文[2]中提出了一种通用的跨平台数据共享方案，采用XML描述数据元信息，指出数据使用方首先需要认证，然后才能访问数据提供方提供的数据服务，但是对于认证过程的具体要求和建议方案并未进一步阐述。Oliver Terzo等则在文[1]中分析了云服务下DaaS的特性，着重阐述了如何拆分数据存储和数据处理，但是没有提及数据服务的具体模式。 微服务是数据服务的一种有益的模式，它的解耦合、去中心化等特性非常有利于数据服务的扩展和便捷运维。J. Lewis等在文[3]中详细阐述微服务的特征，Catalin Strimbei 等在文[5]对微服务架构和其他的软件结构做了分析和对比。微服务在很多在线应用有非常成功的应用，例如Netflix。Matthias Vianden等将微服务应用于度量系统[4]，文[7]的Yuqiong Sun等将安全服务也以微服务的形式提供。D.I. Savchenko等则在文[6]中重点探讨了微服务的验证问题。 3.数据服务框架 建设数据服务平台，是打破壁垒、消除孤岛、实现数据共享的一种有效手段。传统的数据服务平台多是建设于一个物理上统一的数据中心之上，基于SOA架构，构建服务总线提供数据服务。这样“重量型”的数据服务平台，与数据中心一起形成了一个数据堡垒，随着时间的推移，它的缺陷越来越明显。 首先是可扩展性差。如果要增加一项的数据服务，需要将源数据交换至数据中心，然后定义好数据XML Schema，最后实现部署这项新的数据服务。协议复杂，上线周期长。更有甚者，如果要丰富原来一项数据服务的信息内容，需要修改原来定义好的数据XML Schema，这必然会影响已经在使用这项数据服务的应用。 其次是运维复杂。若某一项数据服务存在BUG，在修正之后，需要部署整个平台应用。由于其体量庞大，更新部署必然会影响到其他的正常的数据服务。 微服务的解耦合、去中心化等特性，非常有利于数据服务的扩展和便捷运维。微服务之间是松耦合的，可以实现自动部署，一项服务的更新和部署不会影响其他的服务。再有，微服务采用的都是轻量级的协议（如REST）和数据格式（如JSON），非常易于扩展。 3.1.主要内容 如图1所示，基于微服务的数据服务框架主要由五大部分组成：服务源，微服务容器，服务发布组件，服务发现组件和服务门户。
图1.数据服务框架 服务源是为数据微服务提供支撑的信息来源，也是数据微服务的实际提供者。这些服务源分别为微服务容器中的原生型微服务和代理型微服务提供支撑。Web信息源包括网络上的各类非结构化信息，传统WS是指支持SOAP协议的Web Service，它们与关系型数据源一起为原生型微服务提供支撑。服务源中的另一类：微服务，则为容器中的代理型微服务提供支撑，它是运行在其他在线服务容器中的一个承担实际功能的数据微服务。 微服务容器是框架的核心组成部分，所有数据微服务都在这个容器中运行。这些微服务大致可以划分为两种类型：原生型微服务和代理型微服务。原生型微服务是指承担实际功能的，从数据源或者信息源中获取数据，并加以处理的数据服务。代理型微服务是服务源中的微服务在容器中的一个代理，承担实际功能的是服务源中的微服务。这种代理型的微服务使得数据服务框架具有了一个很重要的特征：自生长，这一特征会在“主要特征”节中详细描述。为了适配微服务容器，代理型的微服务除了代理功能外，还必须具有安全授权和安全审计等功能。微服务容器中的安全套件具有授权、监控和审计等功能，为容器中的所有微服务提供服务。 服务发布组件是为其他在线服务容器提供服务的。当一项数据服务部署在其他的在线服务容器之后，可以通过服务发布组件，将该服务发布在数据服务门户平台中，平台将自动生成一项代理型微服务，代理该数据服务。当然，这项数据服务需要具有微服务的特征，遵循相应的规范和协议。 服务发现组件为服务使用者提供服务。服务门户则为服务使用者提供统一的访问入口。 3.2.重要特征 本文所述的数据服务框架具有如下一些显著特征： 1.数据即服务 如文[1]所述，DaaS是云服务环境下的另外一种服务模型，它侧重于数据存储和处理的服务化，忽略业务逻辑和业务状态转换。本文所述数据服务框架充分体现了DaaS要求，将数据服务化，服务组件化，实现充分的共享，充分发挥和发掘数据的潜在价值。 2.微服务架构 由于本文所述数据服务框架是基于微服务的，它具有微服务架构的一系列特征，例如服务组件化、轻量级、松耦合、去中心化、跨平台，等等。 组件是一个可独立替换和独立升级的软件单元，组件化软件的主要方式是分解成服务[3]。服务组件化的一个重大优势就是便于运维。传统应用也是通过不同组件构成，但是任何一个组件变更都必须重新部署整个应用。如果分解成服务，那么单个服务的变更只需要重新部署该服务即可。 不同于传统的基于SOAP协议和WSDL的Web Service，微服务使用的协议都是轻量级的，如REST和JSON，直接通过HTTP请求进行通信。微服务使用的这些协议也都是跨平台的，同时，跨平台的数据微服务可以实现异构数据的共享。 微服务之间充分的松耦合，这种去中心化的治理模式，在数据存储层面让每个服务管理自己的数据库，或者同一数据库技术的不同实例，或完全不同的数据库系统。最终，可以让使用这些微服务组装成的应用系统也是去中心化数据存储，更能适应需求变化。 3.开放及规范 基于本文所述框架建设的平台是开放的，允许任何经过授权的应用发现和使用数据服务，也允许任何经过授权的应用发布新的数据服务。 一个开放的平台有利于数据的充分共享，为了实现充分的开放，所有服务的接口都应当是规范的，但是这种规范是已有通信协议的轻量级规范，例如REST的通信规范、JSON的格式规范、OAuth的安全规范，等等。平台本身不应产生新的规范，只是一个轻量级的平台，如此可以实现便捷的数据共享。当然，具体某项微服务的数据项的格式和含义，由微服务自身定义，这应当是个性的。 4.服务自生长 基于开放的特征，任何应用只要经过授权，都可以使用数据服务，也可以发布数据服务。而且由于数据微服务是组件化的，应用可以依据具体的需求，组装已有的数据服务，按照规范实现新的数据服务，在自己的容器中部署运行，并通过平台发布。如此循环往复，可以实现服务的自生长，进而实现更加充分的数据共享。 3.3.关键技术 要实现本文所述框架，需要应用两项关键技术：一是轻量级的服务规范——REST；二是开放的授权协议——OAuth。 1.REST REST全称是Representational State Transfer，即代表性状态传输，它是传统的基于 SOAP 和 WSDL的 Web 服务的更为简单的替代方法。它于 2000 年由 Roy Fielding 在其博士论文“Architectural Styles and the Design of Network-based Software Architectures”[8]中首次提出，论文对使用 Web 服务作为分布式计算平台的一系列软件体系结构原则进行了分析。纯粹的 REST Web服务，应该遵循如下四个基本设计原则： 1、显式地使用HTTP方法； 2、无状态； 3、公开目录结构式的URI； 4、传输XML、JSON，或同时传输这两者。 REST更大的意义在于其至简的设计哲学，它完全是轻量级的，不产生新的协议，而是采用通用的简单通信协议（HTTP），更易于被接受和广泛应用。 2.OAuth 跨平台、跨应用之间的数据共享，安全授权非常重要，需要确保数据被安全可靠的共享，不允许未经授权的数据访问。 OAuth是一种专门针对跨平台的应用之间授权而设计的框架协议，其整体思路是通过跨应用之间的重定向，让用户显式而明确的参与授权过程，并且保护用户关键的凭证信息（如口令）不被第三方接触到[9][10]。在其2.0版本中，虽然为了更好的兼容各种应用系统而设计了多种模式，但其标准模式与1.0版本中的设计依然基本一致[11][12][13]。 4.原型实现 “北京大学信息服务开放平台”基于本文所述框架设计和实现，平台主要由开发者中心、管理中心和微服务容器构成，如图2所示。开发者中心用于开发者注册应用和注册需要发布的服务；管理中心用于开发者应用审核、发布服务审核、服务授权审核等。按照访问权限划分，运行在微服务容器中的数据服务大致分为三类： 1、公共信息服务：提供如通知公告类的公共信息，无需个人授权，任何通过审核的注册应用都可以访问； 2、个人信息服务：提供属于个人的相关信息，如个人课表等，需要个人明确授权； 3、受限信息服务：介于公共和个人之间的信息，无需个人授权，但需要对注册应用进行访问授权。 这三类服务都包含框架中“原生型微服务”和“代理型微服务”。例如公共信息服务中的“最新通知公告”属于“原生型微服务”，它是通过访问办公系统中源服务实现的，而办公系统中的源服务是基于SOAP的传统Web服务；“研究生招生专业信息”则属于“代理型微服务”，它代理了学生系统中提供的一项数据微服务。 目前“北京大学信息服务开放平台”共提供27项公共信息服务，18项个人信息服务，6项受限信息服务，面向全校各个应用平台和应用开发者开放校内信息服务。
图2. 信息服务开放平台 5.结束语 高校信息化在数据服务平台方面的建设经验表明，传统数据服务平台协议复杂，体量庞大，在扩展性和易维护性方面都存在不足。本文提出了一种基于微服务的数据服务框架，利用微服务的先天特性，使得服务之间松耦合，平台易扩展、便于运维，数据共享灵活。本文阐述了框架的主要内容，重点阐述了框架中微数据服务可能的实现类型：原生型微服务和代理型微服务。并在此基础上分析了框架的一系列重要特征：数据即服务、微服务架构、开放即规范和服务自生长，接着介绍了实现框架需应用的关键技术：REST和OAuth。 综合本文所述框架的内容和特征，以及“北京大学信息服务开放平台”的实践，本文认为基于该框架建设的数据服务平台，易于扩展，便于运维，可以实现更加灵活的数据共享。 参考文献 1.Oliver Terzo， Pietro Ruiu， Enrico Bucci， et al. Data as a Service（DaaS） for Sharing and Processing of Large Data Collections in the Cloud [C]. 2013 Seventh International Conference on Complex， Intelligent， and Software Intensive Systems. IEEE， 2013： 475-480 2.Ming Li， NianLong Luo. Data sharing between web applications based on the request of user [C]. 2009 ISECS International Colloquium on Computing， Communication， Control， and Management， CCCM 2009. IEEE， 2009： 280-282 3.J. Lewis， M. Fowler. Microservices [EB/OL]. [2014-04-25]. http：//martinfowler.com/articles/microservices.html. 4.Matthias Vianden， Horst Lichter， Andreas Steffens. Experience on a Microservice-based Refrence Architecture for Measurement Systems [C]. 2014 21st Asia-Pacific Software Engineering Conference. IEEE， 2014： 183-190 5.Catalin Strimbei， Ocatavian Dospinescu， Roxana-Marina Strainu， et al. Software Architectures – Present and Visions [J].Informatica Economica. Vol 19， no.4/2015： 13-26 6.D.I. Savchenko， G.I. Radchenko， O. Taipale. Microservices validation： Mjolnirr platform case study [C]. MIPRO 2015， 25-29 May 2015， Opatija， Croatia： 235-240 7.Yuqiong Sun， Susanta Nanda， Trent Jaeger. Security-as-a-Service form Microservices-Based Cloud Applications [C]. 2015 IEEE 7th International Conference on Cloud Computing Technology and Science. IEEE 2015：50-57 8.Fielding， Roy Thomas.？Architectural Styles and the Design of Network-based Software Architectures， Chapter 5 Representational State Transfer （REST）. Doctoral dissertation， University of California， Irvine， 2000. [EB/OL]. http：//www.ics.uci.edu/～fielding/pubs/dissertation/rest_arch_style.htm？cm_mc_uid=78931286748214666731807&cm_mc_sid_50200000=1466673180 9.Barry Leiba. OAuth Web Authorization Protocol [J]. IEEE Internet Computing， January/February 2012：74-77. 10.E. Hammer-Lahav. The OAuth 1.0 Protocol， RFC5849 [S]. Internet Engineering Task Force （IETF）. April 2010. 11.D. Hardt. The OAuth 2.0 Authorization Framework， RFC6749 [S]. Internet Engineering Task Force （IETF）. October 2012. 12.T. Lodderstedt， M. McGloin， P. Hunt. OAuth 2.0 Thread Model and Security Considerations， RFC6819 [S]. Internet Engineering Task Force （IETF）. January 2013. 13.M. Jones， D. Hardt. The OAuth 2.0 Authorization Framework： Bearer Token Usage， RFC6750 [S]. Internet Engineering Task Force （IETF）. October 2012 |
