基于Service Mesh的多图书馆统一服务平台管理

2019-07-03■

长江丛刊 2019年15期

■

一、前言

图书馆信息系统的起源可追溯至从20世纪60年代的自动化系统，计算机技术的不断发展也使得逐步形成了包括采购、编目、流通、馆藏等主要功能的图书馆管理系统，国外出现了包括Dynix、Sirsi、3M等，国内也有金蝶、瑞天、汇文等众多的图书馆系统软件服务商。图书情报专家Marshall Breeding的报告中提出了图书馆服务平台(Library Service Platform，LSP)的概念，但仍未能摆脱传统业务的思维局限。

对于图书馆服务模式的升级，传统的方式是各馆逐步升级其业务管理系统，提高业务管理水平。但因历史原因，同一个市域内多家图书馆业务系统软件的供货商、开发语言、数据库系统、业务规则都各不相同。本文将通过为Z市建立全市图书馆统一服务平台为例，介绍一种新的架构理念和思想，以新技术、高标准、低成本的方式实现全新的业务体系。

二、Z市的统一服务平台需求

Z市现有市级图书馆2所，区县级图书馆13所，高校图书馆3所，其他图书馆22所。上述图书馆均采购了不同的业务管理系统，其中市级使用的是汇文RFID图书馆系统，其他馆则包含立博、美萍等，共5种异构管理系统。各图书馆均有独立的馆藏、读者数据。

建立统一的服务平台，需要满足如下需求：一是业务延续原则，无论服务平台的业务如何演化，不能改变原有系统的业务运行；二是数据完整一致原则，在统一服务平台提供各类新业务时，需要确保原业务系统数据的一致性和完整性；三是实体惟一原则，对读者而言，要求按身份证号进行惟一识别，一人多馆的读者信息既有效统一又各自独立，书目根据ISBN码进行识别，馆藏图书则拥有统一规则的条码号；四是高效服务原则，要通过分布式架构保证大规模数据业务的运行效率，提供低延迟的用户体验；五是安全保密原则，要保证原业务系统的安全运行，同时不能泄露原系统的数据；六是持续开发部署，在服务平台的搭建过程中，要能够优先实现三个主要的图书馆的业务整合，之后逐步扩展到全市所有图书馆，且平台业务同样需要持续扩展，需采用DevOps以满足需求。

三、Service Mesh服务网格技术

通过对需求的评估，系统研发团队决定采用分布式微服务架构搭建统一服务平台。在目前主流的微服务架构中，SpringCloud凭借着Spring框架的优势，被众多开发团队所选择。但不可忽视的问题是，SpringCloud包含的内容非常多，团队学习周期和成本都比较高。相比而言，Service Mesh具有更简单的服务治理方式，通过Sidecar控制所有系统流量，将所有的请求集中管理。团队可以将主要的时间精力聚集在业务逻辑中来。

Service Mesh可以在复杂的服务拓扑中实现请求的可靠传递，由开发Linkerd的Buoyant公司最早提出，是一个基础设施层，用于处理服务间的通信。目前市场的主流解决方案是由Google、IBM和Lyft合作开发的Istio，经过近两年的发展，已经可以满足微服务架构的需求。通常来说，Istio Service Mesh包含两部分内容：一是由Envoy作为Sidecar部署在服务单元中，对流入和流出服务的网络请求进行拦截，同时实现如服务发现、负载均衡、流量拆分、故障识别、熔断器、版本控制等微服务治理功能；二是运行服务运行管理的控制面板，包括管理代理配置、分发通信策略的Pilot，通过适配器集成基础服务、标准配置等的Mixer，为服务间通信进行证书签名轮换、双向认证授权的Istio Auth。

四、业务架构

服务平台的用户有市民(读者)、书店销售员、图书馆管理员、决策用户等。其中，读者的需求主要有：可通过网站、微信和移动客户端注册登录，绑定读者证，查询图书信息，查询借阅记录，读者转借，在线充值，书店购书，查看排名，预约图书等；书店销售员实现的是扫码、售书、打印、代还功能，售书功能是指书店出售给读者的图书，视为读者代图书馆进行采购，扣除的是借阅证的押金，且在还书后可退还；图书馆管理员的功能是对涉及本馆的采购记录、借还记录、馆藏情况进行查询和统计，同时监控服务平台的运行情况；决策用户则可以对所有图书馆的信息进行数据统计分析，获得全局的运行情况。整体业务架构如图1所示。

五、系统架构

系统架构设计的主要目的是，为各种客户端提供统一规范的请求，同时满足持续开发部署的要求。整体架构分为多个层次，如图2所示。

(一)客户端层

客户端支持多种设备，系统管理员、图书馆管理员、书店管理员、决策人员均可使用PC端和移动端进行操作，普通读者可使用移动客户端和微信端进行操作。

(二)Istio控制层

采用Kubenetes中集成Istio的方式对服务集群进行治理。Istio是一个开源的服务网格，包括服务发现、负载均衡、故障恢复、指标收集、监控及复杂运维等多样化功能。可以透明地分层到现有的分布式应用程序上。同时也允许集成到日志记录、监测和决策系统的API。可以高效的运行分布式微服务架构，并提供保护、连接和服务监控。

(三)公共服务层

公共服务层是将各业务领域都可能用到的服务进行抽象独立，开放接口，由其他服务进行调用。在每个服务中，均集成Istio的Envoy，进行服务注册。其中，面向用户的服务使用Oauth2进行无状态的令牌授权，而服务间的请求均采用双向TLS进行认证，确保服务调用的安全可靠。同时提供公共的日志服务、LCN分布式事务服务、服务监控、数据索引、消息中间件等服务，平台中运行的各个服务模块均可调用。

图1

图2

(四)业务服务层

在业务服务体系中，根据业务领域的不同，划分为读者服务、图书服务、借还服务、借阅记录服务、图书馆服务、系统管理服务、数据分析服务等。各业务服务独立部署，降低耦合，同时也可根据实际需求相互调用，形成业务链条。在涉及多个业务服务的业务过程中，使用Tx-lcn进行分布式事务管理，保证了数据的完整和一致。

(五)数据层

服务平台运行过程中，需要建立本地数据服务体系，不仅是提供关系型数据，还包含为搜索和日志服务提供的Lucene索引文件。为提供系统响应效率和吞吐量，采用了高性能高容量高可用的Redis作为数据缓存技术。

(六)数据适配层

由于原图书馆系统存在异构性，与原厂商协商数据接口并不现实，因此，需要针对不同管理系统的情况提供不同的解决方案。采用适配器模式，将不同类型的数据输入，如数据库直连、WebService接口、SIP2接口的数据以相同格式进行输出。每个子馆的管理系统均对应一个数据适配服务(同构系统可多对一)，由数据适配服务负责从数据库或数据接口获取并输出统一标准的数据及将业务数据写入相应管理系统。

六、云服务与持续开发部署

为保证服务平台的上线时间，同时兼顾业务的扩展需求，采用持续开发部署是必然的选择。DevOps是通过自动化的“业务变更”与“软件交付”的管理流程，使得软件的开发、构建、测试、发布能够更加敏捷可靠的实现。统一服务平台是在现有成熟业务系统基础上建立的新型服务平台，要求能够满足快速扩展、业务迭代的需求。本系统的建设计划以三个图书馆的作为试点，先期实现与三馆的数据适配与通讯，并对外提供最重要的读者、图书、借还等服务。

技术上使用Kubernetes、Docker、Git、Jekins相结合的方式实现，实现过程如下：(1)开发人员从镜像库中获取Docker基础镜像，对应用进行开发；(2)开发人员将代码提交到Git；(3)Git收到代码后通过hook触发Jenkins master;(4)Jenkins master收到请求后在Kubernetes平台上动态生成相应的业务节点slave；(5)在slave上对源码进行编译打包并生成新的Docker镜像；(6)将新Docker镜像上传到registry仓库；(7)通过Jenkins拉取镜像，自动部署应用；(8)对应用进行测试，通过后在Kubernetes生产环境进行应用部署上线。

容器化的DevOps解决方案，实现了开发人员在代码提供后的自动化编译打包、自动化部署测试、自动化交付上线。优化了整个系统开发、测试、运维之间的交互流程，极大的提高了生产效率，也使得整个平台得以快速的横向扩展和功能迭代。

七、系统应用情况

平台主要的功能已经完成，三个图书馆的业务整合也进入了试运行阶段。共计为170余万册图书建立目录索引，为19万余读者建立了便捷服务通道，在9个新华书店实现了售书借阅服务以及图书代还点。读者通过移动客户端，可快速定位图书的馆藏情况及借阅情况，还可以直接通过扫码传阅图书。一是方便了读者借还图书，二是为图书馆提供了集中的数据可视化服务，三是提高了图书采购途径和效率，四是扩充了读者流量入口和用户粘性，五是具备了开展图书馆互联网+业务的基础条件。