Web服务的架构思想是尽可能兼容新系统,然后将不同的系统发布成对应的HTTP服务。先打包成一个War包,然后发布到JBoss容器或者Tomcat容器,一般通过JSON或者XML传输中间数据,最后,所有的服务集成到系统总线。这种思想在十几年前具备先进性,主要体现在兼容旧的单机系统。这种单机系统的架构思想也叫“单体式开发”(Monolithic)。
而微服务的架构思想是尽可能将一个服务变成一个独立的网络节点,并且可以进行网络容错,不会因为一个网络节点的崩溃导致整个网络的瘫痪,各个网络节点的开发和运维都是完全独立的。微服务和Web服务相比,重视的不是集成,而是重写。因此,每个Web服务都是一个Bean对象,而每个微服务都是一个独立的HTTP进程服务。因此,微服务的每项服务比Web服务的独立性更强。
Web服务诞生在十几年前,受限于当时的网络、内存、计算资源。现在,硬件和宽带价格极速下降,资源不再稀缺。微服务相比于Web服务而言,正因为每个服务是网络节点,因此消耗的内存资源和宽带资源更高,但是带来系统的可靠性和易扩展性的提升。
考虑到图书馆的服务场景,对Web服务和微服务从以下方面进行对比。
从技术实现上而言,Web服务对外提供服务的数据传输格式是JSON格式或者XML格式。Web服务的服务是水平扩展,一般会将服务分成数据实体层(Entity)、数据访问层(Data Access Object,DAO)、通讯传输层(Data Transfer Object,DTO)、对外服务层(Service)、对外服务实现层(Service Implement)、视图绑定对象层(View Object,VO)和视图层(View)。微服务是垂直扩展,每个微服务只关心自身实现的功能,不同层之间不是通过对外服务层(Service)实现,而是通过对外服务接口(Feign)发布服务。如果另一个微服务需要访问,则在对外服务接口客户端(FeignClient)实现。通常,Web服务的对外服务层和对外服务实现层在同一个服务容器的同一个应用中,而微服务的对外服务接口和对外服务接口客户端一般不在同一个服务容器中。
Web服务会把一类服务封装成一个服务,如一个图书馆的登录系统需要利用大学网络中心虚拟专用网络(VPN)的Web服务,大学网络中心会提供一个Web服务给图书馆信息系统来进行用户登录。如用户还想利用微信授权进行登录,则大学网络中心需要修改原有授权代码,增加微信登录代码,并确保该代码能够和其他数据库厂家的安全机制兼容,最后,将该代码集成到大学网络中心的授权总线。如果微信登录服务崩溃,则会导致现有的VPN登录服务失效。但是,基于微服务的架构,微信登录服务器被封装成一个独立网络节点,即对外服务接口服务。该网络节点不需要封装到VPN的服务代码中。如果用户通过微信登录,则直接通过对外服务接口客户端服务请求服务。如果微信登录服务崩溃,则微信登录服务作为网络节点会发送默认的容错性网络提示通知。
Web服务的早期设计是基于把本地服务改进后,发布成网络服务;而微服务一开始是具有网络特性,默认每个网络节点都有潜在故障。每个微服务节点在设计的过程中,都默认有错误网络节点或者离线网络节点的容错机制。微服务的网络容错机制一般通过Hystrix技术框架实现,能够及时处理服务调用时的超时和错误,防止由于其中一个微服务的问题而导致整体网络系统的瘫痪。Hystrix原理如图2-5所示。
图2-5 基于Hystrix的服务可靠性保障[20]
从图书馆信息系统维护的可靠性而言:
①从运维可靠性而言。如果把图书馆中一个数据库厂家的服务视作一个Web服务,那么图书馆购买了100个数据库就有100个Web服务。如果基于微服务,一个数据库厂家的服务可以被拆分为更多的微服务,这些微服务可以互相调用。如IEEE的论文被Web of Science(WOS)检索,那么可以通过编程对IEEE的数据服务程序包装(Wrapper),发布成新的微服务。这个过程不需要IEEE或者WOS更新现有的程序。Web服务的运维级别是应用程序级别,属于应用程序级的监控和自动化部署。而微服务的运维级别是功能级别,每个功能就是一个独立网络节点,属于网络节点级的程序级监控和自动化部署。通常,网络节点级的运维的可靠性要强于应用程序级。
②从服务器的负债均衡而言。每个Web服务需要进行统一的负债均衡和服务请求的队列管理,常见的负债均衡和转发服务器如Nginx服务器。而微服务的每个服务都是独立的网络节点(通常基于Jetty服务器)。在技术设计上,微服务是把负载均衡的功能以程序库的方式分散到服务调用方的客户端进程内,这种方案也称为“软负载均衡”。这样的优势是微服务的负债均衡既可以在服务端处理,又可以在客户端处理。但是,Web服务的负债均衡主要在服务端处理。
另外,Web服务多为同步请求服务,微服务多为异步请求服务。异步请求服务对服务器的性能要求很低,可以极大地提高服务器的负载能力。图书馆场景中的科技查新服务需要对读者的科研成果进行跨库检索。如果基于Web服务架构,则消耗的资源比微服务多。通常,读者并不需要实时得到科技查新服务的结果,因此,可以采用微服务架构进行优化。
微服务在进行负载均衡时,其工作原理可以概括为下面4个步骤:①根据其所在区优先选择一个负载较少的服务器;②从请求转发服务器,更新并过滤服务实例列表;③根据指定的负载均衡策略,从服务器列表中选择一个实例的地址;④通过REST客户端进行服务调用。
常用的微服务统一服务管理框架,如阿里巴巴公司开发的Nacos框架。本节构建的图书馆信息系统的Nacos服务端的运行后台,如图2-6所示。
图2-6 图书馆信息系统的Nacos服务端运行后台
从图2-6可以看到一个完整的图书馆信息系统的各个Nacos服务,具体含义如下。
user:图书馆信息系统的用户管理服务。
auth:图书馆信息系统的统一授权管理接口服务。
admin:图书馆信息系统的管理员可视化管理后台服务。
log:图书馆信息系统的用户日志服务。
system:图书馆信息系统的文献管理服务。
gateway:图书馆信息系统的统一网关管理服务,用来将不同的微服务端口号通过Nginx服务转发到80端口。
resource:图书馆信息系统的静态资源管理服务。
同样,常用的队列管理框架,如阿里巴巴公司开发的Sentinel框架,本书构架的图书馆信息系统的Sentinel服务端的运行后台,如图2-7所示。
图2-7 图书馆信息系统的Sentinel服务端运行后台
从图2-7可以看到一个完整的图书馆信息系统的各个Sentinel服务。图2-7的Sentinel服务和图2-6的Nacos服务一一对应,每个Sentinel服务包含的功能如图2-7所示,如“实时监控”“簇点链路”“流控规则”“降级规则”“热点规则”“系统规则”“授权规则”“集群流控”“机器列表”等。通过这些功能,可以对图书馆信息系统中使用的流量进行网址级的负债均衡。(www.xing528.com)
③从服务扩展的可靠性而言。Web服务所有的服务在一个服务器上运行,例如一个Tomcat容器可以同时运行10个Web服务,一般通过域名来区分不同的服务。如果Tomcat缺乏第三方依赖程序库,会导致整个Web服务不可用。微服务的每个服务是一个独立服务器,如一个Jetty容器只允许一个微服务。通过不同的端口号来区分不同的微服务,所有的端口通过统一的应用程序接口(Application Programming Interface,API)网关进行注册。Jetty容器的第三方运行库完全独立。这样,对于第三方服务来说,可以根据Jetty容器的资源消耗情况优化不同的硬件环境,合理降低整个网络的成本。图2-8是Web服务直接请求服务和微服务通过API网关进行统一请求的对比图。
图2-8 Web服务和微服务请求服务对比图[21]
④从代码维护的可靠性而言。在Web服务进行编码和测试时,需要统一编程命名规则,同时,需要用Apache Maven来管理服务容器依赖库。Web服务的每个应用功能糅合在一起,可维护性差,代码修改不灵活,一个微小的改动需要重新编译和部署整个服务。对于微服务来说,由于每个微服务都是独立容器,因此不同程序员的编码习惯可以完全不同。在进行自动化测试时,微服务架构可以减少运行环境和命名规则所带来的潜在隐患。由于代码独立,可以独立打包和自动化部署,带来代码开发的敏捷性和代码维护的灵活性,提高代码维护的整体可靠性,降低代码开发难度。
通过对比研究,采用微服务架构的图书馆检索信息系统的维护性优于基于Web服务的单体式架构,利于提高图书馆信息系统的服务质量。采用微服务的架构,可以将图书馆不同数据库厂家的信息资源进行整合,提供统一的共享服务,并且整合时不需要破坏现有的系统。此外,在图书馆信息共享过程中,如涉及鉴权机制,亦可以重写授权的微服务,而不需要修改大学网络中心的安全代码。微服务架构思路和Web服务架构思路的核心区别是,微服务更关注局部重写解决问题,而不是整体系统总线的设计。基于这种思路,在图书馆信息系统中提供涉及不同的数据厂家和共享服务时,如跨库检索服务,可以极大地提高系统的可靠性。
另一方面,基于微服务的架构,可以提高代码的灵活性,减少服务的约束,利于提供个性化服务。面对图书馆对读者提供的第三方服务,尤其是实时性要求不高的服务,如科技查新、文献传递等服务,微服务可以减少资源的消耗,提高图书馆信息系统的可用性和图书馆的服务质量。
【注释】
[1]丁遒劲,曾建勋.文献元数据集成管理研究[J].情报学报,2019,38(06):568-577.
[2]董克,邱均平.论大数据环境对情报学发展的影响[J].情报学报,2017,36(09):886-893.
[3]曹树金,刘慧云,王连喜.大数据驱动的图书馆精准服务研究[J].大学图书馆学报,2019,37(04):54-60.
[4]苏新宁.大数据时代数字图书馆面临的机遇和挑战[J].中国图书馆学报,2015,41(06):4-12.
[5]顾立平.科研模式变革中的数据管理服务:实现开放获取、开放数据、开放科学的途径[J].中国图书馆学报,2018,44(06):43-58.
[6]陈祖琴,蒋勋,苏新宁.图书馆视角下的大数据资源共建共享[J].情报杂志,2015,34(4):165-168.
[7]王丽敏.大数据环境下图书馆信息服务模式探析[J].情报工程,2015,1(02):91-95.
[8]李树青,丁浩,徐侠.大数据时代数字图书馆用户服务思考[J].情报学报,2018,37(06):569-579.
[9]贾静.加强高校图书馆科研服务工作探析[J].图书情报工作,2015,59(S2):41-44.
[10]毕强,马卓,李洁.数字图书馆微服务的核心特征分析[J].图书情报工作,2016,60(21):32-38.
[11]李白杨,白广思.图书馆大数据与微服务的技术融合体系研究[J].数字图书馆论坛,2016(01):68-72.
[12]彭爱东,夏丽君.用户感知视角下高校图书馆微服务效果影响因素研究[J].图书情报工作,2018,62(17):33-43.
[13]董颖,张艳蕾,任晓辉,于子清.大数据环境下高校图书馆嵌入式学科服务模式研究[J].大学图书馆学报,2017,35(03):25-28.
[14]Tomas Cerny,Michael J Donahoo,Jiri Pechanec.Disambiguation and Comparison of SOA,Microservices and Self-Contained Systems.RACS'17,New York,NY,USA,2017[C].
[15]Adalberto R Sampaio,Julia Rubin,Ivan Beschastnikh,Nelson S Rosa.Improving Microservice-Based Applications with Runtime Placement Adaptation[J].Journal of Internet Services and Applications,2019,10(1).
[16]欧阳荣彬,王倩宜,龙新征.基于微服务的数据服务框架设计[J].华中科技大学学报(自然科学版),2016,44(S1):126-130.
[17]Yilong Yang,Quan Zu,Peng Liu,et al.MicroShare:Privacy-Preserved Medical Resource Sharing through MicroService Architecture[J].International Journal of Biological Sciences,2018,14(8):907-919.
[18]叶春蕾.基于Hadoop的高校图书馆大数据关键技术研究[J].数字图书馆论坛,2017(05):33-38.
[19]温浩宇,李京京.大数据时代的数字图书馆异构数据集成研究[J].情报杂志,2013,32(9):139-141.
[20]龙新征,彭一明,李若淼.基于微服务框架的信息服务平台[J].东南大学学报(自然科学版),2017,47(S1):48-52.
[21]Microservices[EB/OL].https://martinfowler.com/articles/microservices.html.
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。