微服务架构在商务领域信息系统集中化建设中的应用研究

桂思思 陈幺华 秦 伟

(1.武汉科技大学 城市学院,湖北 武汉 430083；2. 神龙汽车有限公司, 湖北 武汉 430056)

0 引言

近年来随着移动业务的迅猛发展，汽车厂商传统业务模式受到了移动互联网新型业务模式的冲击，客户服务触点中移动互联的应用日趋活跃，传统渠道认知向数字媒介认知转向，产品竞争向服务竞争转化。部分汽车厂商开始尝试从BtoBtoC向BtoCtoB的模式进行转变，给用户带来更极致的业务体验将对营销环节起到重要作用。在此环境下，需要商务领域的信息系统承接更多面向最终用户的业务需求，并且能够满足应用入口多样化；操作友好，流程短；应用、服务变化快的特点。

1 商务领域信息系统架构对比

1.1 系统建立模式对比

绝大多数厂商商务领域信息系统建设，一方面满足业务发展要求；另一方面结合技术环境和发展方向，建立最适合主机厂的系统模式。我国主机厂的商务领域系统大体上有两种建设模式：

(1)分散式，主要表现为系统按照业务或功能类别划分为多个单体结构系统，单体系统各自独立部署，独立存在，系统与系统之间通过各类接口进行数据交互，如商务领域涉及售后保修的保用系统、涉及车辆采购与分配的整车管理系统等。此种模式，对单个系统而言，不易进行大规模的功能扩展，任何修改都需要将应用重新发布部署，编译时间长，且系统与系统之间存在数据冗余，耦合性较大，接口多，数据交互复杂。

(2)集中式，将分散的各个单体结构系统融合建立成统一的系统，例如将经销商管理功能、整车管理功能、售后保修功能等均融合在新建的系统中，实现商务领域数据的集中存储。此种模式减少了系统间的各种数据交互，减少接口数量，增加系统处理的效率与及时性，新功能扩展也更灵活，很好的解决了垂直架构弊端。

通过对国内主机厂的商务领域系统架构进行调研时发现，2012年前，受到当时网络带宽、服务器性能等硬件环境的限制，商务领域系统大多采用分散模式，经销商管理系统采用C/S架构。2012年后主机厂开始向商务领域全功能集中式的平台发展，将经销商管理系统与其他商务领域管理系统进行融合建立，实现数据库集中。

1.2 集中式系统架构对比

对于集中式架构，主机厂主要采用的系统架构主要有两种，SOA架构与微服务架构。

SOA架构将应用部分功能进行拆分，以服务形式提供，系统与服务之间通过ESB采用webservice、异步接口等方式进行通信。此种架构，系统与服务的界限模糊，服务的粒度过大，系统与服务之间耦合性高，虽然使用了ESB，但是服务的接口协议不固定，种类繁多。

对微服务架构，业务逻辑被拆分成一系列小而松散耦合的分布式组件，共同构成了较大的应用。每个组件都被称为微服务，而每个微服务都在整体架构中执行单独的任务，或负责单独的功能。每个微服务可能会被一个或多个其他微服务调用，以执行较大应用需要完成的具体任务。此种架构强调的是微服务之间总是松耦合，着重分散管理，微服务的目的是有效的拆分应用，实现开发和部署。

SOA架构与微服务架构的对比，如表1所示。

表1 SOA架构与微服务架构的对比

微服务架构和SOA架构相比更适合面向最终用户的移动互联网的应用模式，更倾向于基于多种技术栈的敏捷开发和快速上线，并能支持服务级别的独立部署更新及面向不同用户的灰度发布。在近1～2年中，新建主机厂在商务领域系统建设中采用了集中式的微服务架构，一方面实现所有商务领域数据的集中化管理；另一方面通过业务功能的颗粒度切分，实现新功能的灵活发布与调用。满足应用入口多样化，应用、服务变化快的业务要求。

2 商务领域系统集中式微服务架构

2.1 商务领域一体化构建

对于新建的主机厂，在没有建立任何商务领域系统时，可以直接构建集中式的微服务架构系统。但是对老主机厂，经过了早期的系统部署，已建立了分散式模式，在建立新的集中式微服务架构的商务领域系统的同时，还需要考虑已有系统的功能及历史数据迁移。因此对分散式模式的老主机厂，商务领域集中化信息系统的构建有两个主要的实现过程：一方面基于现有系统的功能及新的功能演变要求构建集中式的微服务架构系统；另一方面需要将各个独立的单体系统的数据进行迁移，对特殊应用进行特殊处理。

2.2 微服务应用架构

微服务的应用架构大致可分为4层：

(1)应用层。提供各种功能模块，例如售前相关功能，整车相关功能等，同时面向主机厂、经销商、最终用户提供不同形式的使用窗口，如经销商可通过门户或客户端或移动端使用线索跟踪、整车采购等功能，用户通过官网、商城或微信等渠道使用在线订单、在线支付等功能。

(2)网关层。服务或微服务通过网关层提供给各类应用调研，根据应用类型，可能会有不同的网关，如面向移动应用的网关，面向外部第三方系统的调用网关等。

(3)服务层。服务层属于整个系统的中台，为所有的应用功能提供服务支撑，根据业务需求完成微服务的拆分与逻辑划分，如和用户相关的所有微服务都属于用户中心，和销售相关的微服务都属于销售中心。所有的微服务需要在服务层进行注册和配置，实现微服务的对外提供及微服务间的通信。同时服务层还需具备安全认证、资源动态调整、微服务监控等多种公共功能与监控功能。

(4)数据层。基于系统的数据结构考虑建立一体化的交易数据库，用于存储结构化的数据，对流媒体、语音、图片等数据可考虑存放到非结构化数据库中，根据实际情况考虑采用私有云、共有云或混合云的模式进行各类数据的存储。

微服务应用架构，如图1所示。

图1 微服务应用架构

2.3 技术架构及工具

目前开源的微服务框架工具比较多，比较普遍使用的有springcloud、DUBBO等，框架中已涵盖基于分布式系统的微服务配置管理、微服务的发布、负载均衡、消息队列、事件、断路器、智能路由、控制总线等开发工具包功能。在微服务的注册/协同上，不同的微服务框架有些区别，dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心可使用eureka。微服务和前端的API调用大多会提供轻量化的接口模式，如Spring Cloud框架支持REST(HTTP、HTTPS等)方式，DUBBO的框架支持RPC(二进制接口消息)方式。对于各种形式的前端展现，可通过前端数据API及数据缓存实现应用端的数据快速调用。微服务框架可支持Oracle、MySql、Nosql等各类数据库，并支持不同类型数据库之间的数据存储与调用。技术架构如图2所示。

图2 微服务技术架构

2.4 微服务拆分

采用微服务架构构建系统时的一个重要设计环节是微服务的拆分，按照业务的功能进行拆分，直到每个微服务的功能和职责单一，甚至不可再拆分为止，每个服务都能独立部署，扩容和缩容方便，能够有效地提高利用率。拆得越细，服务的内聚性越好，越适合敏捷开发和上线。然而，拆得太细会导致系统的微服务数量较多，相互依赖的关系较复杂，微服务的调度协调难度增加，运维困难。对微服务的拆分颗粒度应该保持适当的度，原则是拆分到让使用方自由地编排获得相应的组合服务即可。

图3 线索管理中心微服务拆分

微服的拆分从业务层面进行拆分，也可从性能层面进行拆分。从业务层面的拆分主要是保证微服务的独立性和完整性，在提供服务的同时也能被其他服务所调用。从性能层面的拆分主要将有特殊性能要求，或经常进行变更的微服务拆分出来，满足微服务的特殊环境要求，并能在微服务变化不影响其他微服务。

图3为线索管理中心的微服拆分及服务的调用与组合。线索管理相关功能可以切分为多个的细小的微服务，如线索清洗微服务、重复商机清理微服务等，各种微服务的排列组合，形成多种不同的功能或服务，这些服务通过服务网关提供给展现层的不同客户群的不同应用，形成不同的功能模块。

3 系统架构迁移

3.1 历史数据迁移

原有系统经过了多年的运行已产生了大量的历史数据，历史数据为新系统的运行提供数据支撑，保证业务的连续性。历史数据需要迁移到新搭建的商务领域集中化的系统中，保证历史数据在新系统的正常呈现和调取。历史数据的迁移大致包含以下几个步骤：

(1)环境准备。准备相关的硬件、软件环境，并确定迁移历史数据的范围，时间点。

(2)历史数据镜像。将单系统的历史数据进行全量备份和数据量检测。

(3)临界数据处理。后台抽取并检查未处理完成的临界数据，由用户完成临界数据的处理，完成中间业务流程的操作。

(4)数据迁移。停用旧系统，启用新系统，完成新系统初始化数据的导入，将第2步的历史数据进行导入，核对历史数据的完整性。

(5)系统跟踪。跟踪用户作业熟练度、跟踪系统线上线下作业效率、跟踪系统问题、跟踪业务规范情况。

3.2 特殊业务处理

对部分特殊的应用在商务领域系统集中化后会受到较大影响，因此特殊应用需要特殊分析。

3.2.1 语音业务

语音业务需要考虑两个方面的业务整合和处理：①主机厂语音业务的整合。对于主机厂会有很多面向用户的语音业务分支，如客户关系维系、车联网语音业务等，从主机厂的角度需要考虑语音业务平台的业务功能整合，能实时调取所有的商务领域及车联网业务数据，保证客服人员随时查看用户或车辆的全维度数据，并能记录最新信息；②主机厂语音业务与网点语音业务的互通。主机厂到网点之间存在工单派发及工单更新、跟踪的相关功能，因此需要实现主机厂客服人员与网点客服人员的语音互转，及工单数据的实时传递。

对语音业务的处理方案包括：①基于商务领域系统集中化平台建立相关的语音业务服务功能，例如用户呼叫工单建立，工单的派发与跟踪，用户基本信息的查询等功能；②在主机厂统一建立语音平台，实现话务功能，包括客户的呼入呼出、座席间的转呼等，网点客服作为新建语音平台的远程客服接入，实现语音的互转；③引入新型智能化功能，例如智能机器人、智能排班、智能外呼等，并实现新型智能化功能与商务领域系统集中化平台的数据交互。

3.2.2 车间透明化业务

车间透明化业务涉及到网点的车牌识别、车间派工、质检、客户看板、交车看板等功能，以及车牌识别摄像头、车间摄像头、存储设备、车间PAD、各类看板等硬件设备。建立商务领域集中化平台后，对车间透明化业务也会造成较大的改动。网点端仍需部署透明车间的服务，包括车牌识别服务、工位摄像头信息读取服务等，通过新部署的服务实现视频信息与工单数据的组合或校验。新部署的服务需要从网点或云端调取网点的车牌信息或车间视频信息，并从商务领域集中化平台获取工单及工单状态信息，并将车牌信息、视频信息、工单信息等进行各类数据匹配实现相应的看板功能。

4 结语

商务领域信息系统的集中化建设能够实现数据统一存取，打破现有的分散式信息系统的数据传输壁垒，实现数据的统一存取标准，提升数据的使用效率，简化信息流程。通过微服务架构实现应用功能的切分和松耦合，快速实现新应用或新功能的快速部署，应对需求的快速变化，面向用户提供多入口的应用接入，聚焦客户体验，提升一体化客户服务能力。