APP下载

基于Dubbo+ZooKeeper的CAMDS协同业务改造

2017-04-27任女尔张庆余林盛海

电脑知识与技术 2016年29期

任女尔 张庆余 林盛海

摘要:CAMDS中国汽车材料数据系统,作为整车企业管理供应商零件及其材料成分的重要依据,为中国的汽车材料市场建立了一套完整的机制。但与CAMDS协同管理、面向整车企业内部的环境合规系统,通过Web Service接口与CAMDS进行数据交互,无论在算法计算上还是数据响应速度上都需要进一步改善。本研究设计了通过Dubbo+ZooKeeper协同调度进行系统改造,从而改进了企业内部环境合规系统的架构,也大幅度提升了CAMDS响应速度。

关键词:CAMDS;Dubbo;ZooKeeper;并发扩展

中图分类号:TP311 文献标识码:A 文章编号:1009-3044(2016)29-0103-03

随着国家在汽车材料的可回收利用及有害物质方面的引导管控,中国汽车技术研究中心数据资源中心推出了国内唯一的支撑平台:CAMDS(China Automotive Material Data System)生态体系。它围绕管理企业零部件供应链的各级材料数据、提高汽车产品回收利用率而设计的材料数据管理体系,其中包括各种辅助填报工具及企业应用产品,从而辅助企业进行材料数据的管理,提高汽车生产阶段的可指导性。

1CAMDS生态体系

CAMDS生态体系是以平台为核心填报平台,集成各个整车、供应商零部件数据,以此作为基础支撑,辅助企业进行整车零部件、材料、物质分析的综合服务平台。

1.1业务介绍

CAMDS生态体系包含如下产品:

1)CAMDS中国汽车材料数据系统,为B/S架构,主要管理各级供应商及其对应的材料、半成品、零部件及总成等游离的材料数据。

2)辅助填报工具:

CAMDS离线,支持离线填报材料数据等;

CIE(CAMDS Interface Excel)辅助录入工具,支持通过excel进行数据填报;

3)CAI(CAMDS Advanced Interface)高级接口,通过webservice提供企业进行数据填报、同步、审核等功能。

在高级接口基础上,支持企业级产品:第一,ELV(End-of-Life Vehicle)环境合规系统,支持通过接口进行数据结构同步、审核,包括材料、半成品、零部件等,并整合企业整车BOM数据,进行整车可回收及可再利用率的计算;第二,VOC(volatileorganic compounds)环境合规系统,支持通过接口同步VOC数据,从而进行进一步模拟汽车挥发性气体的检测与指导生产。

在企业应用过程中,通过平台收集、创建游离的零部件和材料等数据,然后利用ELV、VOC等系统进行进一步的分析,包括分析基础材料是否环保合规、整车的有害物质含量是否超标、整车可回收利用率等。

在其核心业务中,伴随着整车BOM(Bill of Material)的构成设计、分析,以及审核沟通业务,其总体上划分为MDS创建、MDS检索、请求管理、分类管理、系统管理模块。

1.2当前技术及问题

核心平台采用了基于SSH的java技术作为基础实现,并在部署中采用了双机热备等辅助手段进行了性能调优和安全备份;在接口支撑中,采用了Web Service的WSDL技术提供服务满足各企业的访问需求。但在实际的运营过程进行集中访问和培训的期间,其并发访问量急剧上升,访问隔离性降低,导致部分请求不能及时响应或出现错误。本文设计基于Dubbo和ZooKeeper进行协同,从而大幅度提升系統运行效率,提高系统稳定性和安全性。

2Dubbo+ZooKeeDer技术

2.1Dubbo技术

Dubbo是阿里巴巴开发的一款高性能分布式服务框架,通过提供者和消费者模式管理运维服务。如下图所示,

Dubbo运行原理为:首先,启动服务容器Container,加载提供者Provider;此时向注册中心注册服务,生成服务列表;当有消费者Consumer需要调用服务时,向注册中心订阅服务,注册中心读取服务列表讲服务地址传给消费者进行调用;消费者在调用服务时,采用软件算法进行负载均衡,选择合适的服务提供出来;在整个消费提供的过程中,消费、提供服务将被监控中心进行统计。

Dubbo在进行服务注册时,可以通过存储到DB数据库、Re-dis缓存、ZooKeeper中进行服务的调控。在DB和Redis中,需要重新进行维护数据,在稳定性和同步策略方面不够成熟,因此官方推荐使用ZooKeeper进行集成。

在传统的远程过程调用技术中,Web Service模式的WSDL技术广泛应用于各种系统中,其基于XML方式起源,逐步发展和优化,在性能方面有了较大的改进。但是其数据交换过程中支持XML各种元素,相比较Dubbo以二进制流进行传输,其以文本方式进行传输则较为笨重、速度较慢。此外,Dubbo对原有接口的支持性较好,基于原有接口进行改造简单便捷;Dubbo作为分布式服务框架,对分布式支持实现简单,也是作为其扩展位SOA微服务框架的重要优势。综合Dubbo在各个系统中的表现,本文采用Dubbo对WSDL接口进行改造设计。

2.2ZooKeeper技术

ZooKeeper作为Dubbo官方推荐的分布式过程协同技术,基于对树形数据的简单维护,短小精悍,因此在长期的项目实践中展示了较强的稳定性、一致性和有序性等特性,是进行分布式协同的利器。例如Hbase、Kafka、solr、Fetching Service等的基础运行就需要依赖ZooKeeper。它通过简单的并发处理机制一原子广播保持数据同步,确保其在并发中的稳定性。

ZooKeeper设计通过维护不同的ZooKeeper server数据同步,从而提供给各个客户端相同的数据,而提供的数据以树形结构类似于UNIX文件的模式进行存储;通过选举模式,始终保持服务集群中存在一个主节点Leader,Leader在进行广播时保证原子性和顺序性,保证同步的一致性;通过建立心跳模式也维持了ZooKeeper集群的稳定性。

在和Dubbo的整合中,通过将Dubbo的服务注册到Zoo-Keeper中,来维持分布式服务的稳定性,如下为Dubbo在Zoo-Keeper中维护的数据结构:

如图所示,将服务注册到ZooKeeper的Provider里面,消费时也先注册,然后提供者将服务访问地址提供给对应的消费者。

2.3改造问题分析

针对CAMDS平台对支撑系统并发访问不足的问题,本文设计通过将接口基于Dubbo和ZooKeeper进行改造,并柔性的支撑CAMDS进一步改造为接口支撑平台,从而提升CAMDS在访问效率和高并发稳定性方面的表现。其中关键解决的问题,一是最大限度利用原有开发的接口进行改造,二是设计实现ZooKeeper服务的高并发注册调配。

3协同业务设计

3.1架构改造设计

在CAMDS当前的业务逻辑中,以CAMDS和Web Service接口为核心的协同业务形成了单点核心的趋势,使得在业务逻辑运行时,接口和平台负载较重,并发性能低,如下所示,

基于ZooKeeper和Dubbo的架构改造设计打破了这一趋势,形成了以ZooKeeper注册为整体核心的微服务模式,可以根据服务的负载情况配置Dubbo进行负载均衡。比如,当MDS表单下载服务访问并发性要求较高,则启动较多的MDS表单下载服务进行注册,配置Dubbo进行选择。

3.2业务归类整理

在CAMDS协同业务体系中,首先将业务体系的服务层进行分类整理,根据之前的使用经验,划分具体的Dubbo服务业务,如公用服务、VOC专用服务、ELV服务、平台服务等,同时将并发性要求较高的服务抽离出来,以便进行并发性配置。

1)公用服务,是指各个系统中均需进行调用的公用服务模块,如权限验证、MDS查询、下载基本物质、下载禁限用物质应用选项及代码、下载材料分类、聚合物材料标示、发送邮件等。在CAMDS平台及VOC、ELV进行底层实现调用时,可以直接调用该服务执行数据操作。该类公用操作支持系统较多,如下载材料等服务单独归纳,设置高并发性。

2)VOC专用服务,是指下载VOC数据及其检测报告等VOC环境合规系统专用业务,可以根据企业应用VOC环境合规系统产品情况酌情配置高并发性。

3)ELV专用服务,指ELV环境合规系统中专用的服务,如有害物质分析、发送请求、MDS审核等。

4)平台服务,如注册供应商、企业合并等服务。

此外,对于下载MDS占用资源大、使用频度高,则直接单独启用服务进行注册。

3.3Dubbo+ZooKeeper设计与实现

首先,将Dubbo与现有接口进行整合,整合过程需要先安装ZooKeeper,然后把基于WSDL的接口进行Dubbo改造。然后通过生成不同的服务进行ZooKeeper注册,提供给各个协同业务系统公用或专有的服务,从而提升系统的并发性可稳定性。

3.3.1dubbo与ZooKeeper和spring整合

第一步,安装ZooKeeper。下载安装包后,在Linux中解压,复制zoo_sample.cfg为ZOO.cfg文件,在文件中配置监听端口cli-entPort、心跳频率tickTime、数据目录dataDir。安装zoolnspec-tor可以查看ZooKeeper树形结构数据信息。

第二步,配置Dubbo管理界面。下载对应Dubbo的war包,解压到linux下的Tomcat中,配置dubbo.properties中的注册中心信息,指向ZooKeeper服务,如下图所示:

启动tomcm,能够正常登录验证界面配置成功。

第三步,Spring整合Dubbo。CAMDS的Web Service接口开发基于Spring,因此需要进行整合。在接口工程中加入Dub—bo和ZooKeeper的jar包,以下载MDS为例,定义下载接口,实现注册服务测试:

将服务注册到ZooKeeper,配置Spring文件:

其中,ZooKeeper配置为多个集群节点时,设置address为逗号隔开的多个地址。此时完成了一个注册服务的设置,启动Dubbo生成的程序,则服务启动,注册到ZooKeeper中。完成了接口整合Dubbo和ZooKeeper之后,通过业务归类对业务进行抽离,然后将接口分别进行服务改造。

3.3.2服务订阅与调用

服务注册到ZooKeeper之后,开发服务消费者,进行服务调用。在客户端应用中引入Dubbo和ZooKeeper的jar包,加入Dubbo服务的API接口的jar包。然后定义调用代码:

如上图所示,可以直接像调用本地方法一样调用接口方法,需注意的是,引用服務iar时需引用接口iar,而非实现。

最后,需要将在客户端配置对应的ZooKeeper进行管理引用服务:

如图所示,interface属性指明调用的服务地址信息。其中可以用loadbalance属性设置为随机random,轮循roundrobin,最少活跃leastactive调用,从而能够用不同的算法获取不同服务进行计算,进行负载均衡。比如,启动三个下载服务注册到ZooKeeper中,然后设置loadbalance为轮循,则在并发过程中,将按照顺序分别轮循调用三个服务,从而减轻每个服务器的工作负载。

4测试分析

相比于直接将Web Service服务进行高并发部署,当前方案对业务的结合更加紧密,并且对不同的业务区别处理,适配性更高。测试将相同配置的服务器进行部署,设置下载mds服务为五个服务并发,其并发响应如下对比所示:

当并发量在个位数据,其响应速度差距不大,但是随着并发量的提升,其普通的接口模式响应速度变化迅速提升,而设置了5个下载服务的ZooKeeper方便响应速度变化较慢。并且,在改造方案中,其扩展性非常强,很容易实现到更高的并发支撑。在改造过程中,可以实际根据需求自由的进行调整,从而提高硬件资源的利用率。

5结束语

本文针对CAMDS协同业务的底层支撑并发性的问题进行改造设计,通过Dubbo将当前的Web Service进行改造,以Zoo-Keeper作为注册中心,形成微服务模式的软件架构,支持灵活扩展服务数量,从而大幅度提升了CAMDS底层支撑的并发性和稳定性。