基于微服务架构的新零售系统设计与应用

李 俊，江 海

(中国石化广东石油分公司，广东 广州 510000)

0 引言

自从马云在2016 年10 月的杭州云栖大会提出“新零售”[1]理念以来，伴随着国家政策的不断加持，国内新零售业态发展如火如荼。然而线上业务出现了爆发式增长，用户规模和数据量呈指数级上升，应用复杂度急剧升高，这些都导致系统频繁地迭代更新，传统IT架构不堪重负，必须升级改造。

与此同时，微服务的兴起为传统企业变革IT 架构、提升IT 效率指明了方向[2]。微服务架构风格是以开发一组小型服务作为一个独立的应用系统，每个服务都运行在自己的进程中，采用分布式的去中心化管理模式。相对于单体架构，微服务架构具有易于开发和维护、支持高并发高可用、支持丰富技术栈、利于团队协作及技术创新等显著优点[3]，与新零售的业务对IT架构的内在要求高度契合。

因此，本文针对传统零售企业转型过程中IT 架构重塑的需要，提出一种基于Spring Cloud 微服务框架的新零售平台技术方案，针对服务治理、服务请求认证、服务配置等给出一整套自主研发设计的体系架构和实践方法。最后，将此方案应用在某大型国有企业新零售平台建设中，从技术和业务两个层面验证了方案的可行性和实际效果。

1 微服务架构实现

微服务体系架构（MicroServices Architecture）是根据应用系统的实际业务需求，通过对预定义的微服务进行重组而形成企业级应用的分布式体系结构[4]，其基本思想是将传统的单体应用按业务功能拆分为一系列可被独立设计、开发、部署、运维的软件服务单元，服务间彼此配合、相互协作以实现最终价值[5]。相比传统单体架构，微服务体系架构解决了系统数据、服务呈爆炸式增长而造成的各种问题，因此逐渐成为了当前最流行的分布式系统架构之一，已被应用到很多大型公司的系统实践中[6]。

微服务框架（MicroService Framework）是微服务体系架构的具体实现方法，它是企业在构建微服务架构的实践过程中考虑将服务注册与配置、服务部署与管理以及服务通信等众多关键技术，集成为一种高效运行的整体技术框架[7]。目前较主流的微服务框架有Spring Cloud、Motan、gRPC、Thrift 以及Dubbo 等。基于框架完整性、技术易用性以及社区活跃程度考虑，本文采用当前应用最为广泛的Spring Cloud构建一套全局的微服务协调治理框架。

1.1 微服务框架设计

本文设计的微服务技术框架如图1 所示，基于Spring Cloud Finchley SR2 版本和Spring Boot2.0.7构建。Spring Cloud 是关注全局的微服务协调治理的框架，它对基于Spring Boot开发的一个个单体微服务进行管理协调并实现正常互联互通，并为各个微服务之间提供服务发现与注册、服务配置、负载均衡、服务熔断及全链路监控等集成服务[8-9]。

图1 微服务技术框架图

因在实际应用中，Spring Cloud 原生框架自带的标准组件在微服务运行监控及运维、配置项权限管理、服务间调用安全认证及微服务应用日志管理等方面存在明显不足，本文根据微服务协调治理需要，自主研发设计部分组件，与原生组件一起构成一套完整的微服务技术框架，包括服务网关、服务管理中心、配置管理中心、服务鉴权中心、日志管理中心等核心组件。

服务管理中心（Service Management Center）以Spring-Cloud-Eureka 组件为基础，结合自研探针Agent 扩展微服务治理功能，在Eureka 的服务注册与发现功能基础上，增加服务状态实时监测、服务实例上下线实时通知、服务自动化部署等管理功能。

配置管理中心（Config Management Center）以Spring-Cloud-Config 组件为基础，使用MySql 作为配置项存储介质。配置项管理功能以微服务应用为最小粒度进行权限控制，实现灵活安全、操作友好的配置文件管理功能。

服务鉴权中心（Service Authentication Center）以Spring-Cloud-Feign 组件为基础，进行二次封装，设计了一种简单高效的微服务间调用鉴权方法。既有效保障了微服务接口安全、防止未授权访问，又不会对微服务性能造成影响。

日志管理中心（Log Management Center）使用Elastic 公司Logstash、Filebeat 组件，结合Kafka，实现分散在各服务器上微服务应用日志的自动归集、筛选查询和压缩归档，并结合Agent技术实现日志查看。

1.2 服务管理中心

Spring Cloud Eureka 是对Netflix 公司的Eureka的二次封装，实现了服务治理的功能，提供Eureka Server 服务端与Eureka Client 客户端，服务端即是Eureka 服务注册中心，客户端完成微服务向Eureka 服务的注册与发现。此外，Spring Cloud 原生组件并没有提供对微服务应用实例进行全面管理的功能，然而在实际生产环境中，面对成百上千的微服务，一个集中式的微服务管理与监控中心是必不可少的。

为了解决上述问题，本文基于Eureka+Agent架构，自主研发了服务管理中心，其架构原理如图2所示。

图2 服务管理中心架构原理图

服务管理中心主要由管控台与自研探针应用Agent 两部分组成，管控台采用集中部署方式，Agent则部署在微服务宿主主机上。

管控台使用Web+Socket技术，集中管理微服务应用的发布、启动、停止、更新等功能，支持批量操作。此外，通过与Eureka 和即时通讯系统集成，实现微服务实例的上、下线实时通知；通过服务监控模块实现所有微服务健康状态的可视化监控功能。

Agent 应用支持管理容器化和非容器化混合部署的微服务实例，通过执行shell 命令以及调用其他系统接口的方式，采集宿主主机上的微服务实例信息；使用基于Netty的Socket技术与管控台建立长链接通道，通过该通道接收管控台下发的指令并反馈执行结果，协助管控台实现远程管理和监控。

1.3 服务配置中心

Spring Cloud Config 是目前比较成熟的配置中心组件之一，为各个不同的微服务应用的所有环境提供了一个中心化的外部配置支持。官方推荐采用Git来存储配置信息，支持多版本管理、分支管理等功能。但是，基于Git 的管理系统开发难度较大，并且Git 是基于文件的版本管理工具，对单个配置项的CRUD 操作提交会导致整个文件的更改，因此，在数据细粒度权限控制方面有很大的局限性。

为解决上述问题，本文提出了一种以Spring Cloud Config 为基础，MySql 数据库为配置项存储介质的服务配置中心实现方案，其架构原理如图3所示。在该架构下，通过对配置项在数据库中的存储结构来进行扩展，数据权限控制的最小粒度可以支持到数据库的行记录，同时支持按应用、分支、部署环境多维度管理，以满足开发、测试、灰度、生产等不同环境下的配置项管理需求，实现统一配置、环境隔离的效果。

图3 服务配置中心架构原理图

该方案利用MySql 的mysql-udf-http 自定义函数以及数据库触发器技术，实现配置项数据变更时主动通知服务配置中心。配置中心收到变更通知后向RocketMQ 发送广播消息，同时使用消息中的Tag属性标记变更配置所属微服务应用；每个微服务实例都会收到该消息，通过消息中的Tag属性，确定是否是当前应用的配置项，若是则实现配置实时更新，反之直接丢弃该消息。

ConfigMgtUI 是配置管理端，包括公共配置和应用配置。公共配置是各微服务应用中统一使用的配置项信息，应用配置指各微服务应用中的个性化配置。各应用间配置相互隔离，应用配置优先级高于公共配置。

1.4 服务鉴权中心

微服务鉴权是指在安全认证机制保证下，对系统内部各微服务之间的调用行为进行鉴权，目的是防止微服务接口未授权调用，然而Spring Cloud 没有直接提供微服务间安全认证的功能。

因此，本文提出了一种基于动态签名机制构建微服务鉴权中心的方法，以实现服务间的安全认证，其原理如图4所示。

图4 服务鉴权中心原理图

调用方微服务实例启动后，向鉴权中心发起包含安全认证信息的动态密钥认证请求，认证通过后获得动态密钥（signkey）以及密钥编码（signkeycode），动态密钥与该微服务实例所在容器的IP 绑定。调用方在每一次调用其他微服务实例之前，需对当次请求进行签名，并将签名结果加入到请求数据包的Header 中，用于被调用微服务实例验证签名使用。

被调用的微服务实例收到请求后，获取Header 中的信息，根据密钥编码向鉴权中心获取请求方的动态密钥及IP。只有签名验证正确、unix_timestamp 间隔在60s 内且请求方的IP 与Auth 中一致，才认为该请求是合法的。

2 系统总体设计

2.1 需求分析

传统企业都有大量的旧架构IT 系统，包括一些核心业务系统，在向微服务架构升级过程中，完全丢掉这些历史包袱、全部推翻重建并不现实。因此，基于微服务的企业IT 架构重塑，首先需要对原有系统架构进行科学评估，要在新架构与旧系统之间处理好平衡关系，既要实现应用模块之间的解耦重构，又要根据企业实际情况选择最合适的落地roadmap[10]。

本文将前述设计和实现的基于Spring Cloud 的微服务框架在国内某传统零售企业进行实施。该企业原有IT 系统采用传统的轻量级Web 框架MVC（Model-View-Controller），主要面向传统线下业务和企业内部用户提供服务，系统技术瓶颈并不明显。随着近两年的新零售业务转型，线上会员数迅速突破2000 万人，数据量对比三年前增加了十倍，业务复杂度急剧上升，开发团队规模扩大了三倍。新零售模式下的高并发、高灵活性使得企业核心业务系统承受着巨大压力，已经严重制约新零售业务的持续发展。

2.2 系统架构设计

为了支撑该企业转型发展长远需要，构建了以微服务框架为基础的新零售系统（New Retail System，NRS）整体架构，如图5所示。

图5 NRS系统架构图

NRS 架构保留了该企业旧IT 架构中的部分核心业务系统如ERP、门店交易、IC 卡系统等，并对旧架构中运算量大、并发压力高的模块如CRM、电子商务后台进行拆分、解耦和重新整合，变为一个个边界清晰、相互独立的微服务，并通过本文设计的Spring Cloud框架对这些微服务进行集中管理和协调工作[11-12]。

拆分后的微服务主要分为两大类：一类是只关注特定业务功能，与其他微服务不存在或存在极少耦合关系的基础微服务，如会员中心、账户中心、支付中心等；另一类是基于基础微服务构建，与其他微服务存在一定耦合关系的聚合微服务，例如订单中心、营销中心等。通过这种方式可以最大程度地实现服务间业务解耦，以及避免服务间循环依赖。

3 系统应用效果

3.1 微服务可视化管理

本系统上线后，管理员可以通过服务管理中心的界面实现所有微服务运行状态的可视化监控，如图6所示。经过解耦重构，本文设计的NRS系统共有52个微服务，结合业务复杂度以及高可用等因素，在实际生产环境中部署了313个微服务实例。

图6 微服务监控界面

由于分布式系统固有的复杂性，以及成百上千的微服务实例，使得NRS 系统运维复杂度较升级前成倍增长。因此服务管理中心通过建立完整的自动化体系，实现了微服务的智能化管理，如图7 所示。包括单个微服务实例灵活发布、微服务集群滚动发布、实时日志监控、历史日志管理以及微服务状态监控等，大大降低了运维工作量。

图7 微服务运维

3.2 性能对比分析

在旧架构系统中，请求中任何一个环节逻辑处理的高延时都会影响整个系统的吞吐量，且缺乏灵活应对措施。升级为NRS 架构后，当某个微服务接口出现高延时或业务逻辑请求突增时，可以更灵活地对部分微服务进行横向扩容，以此来提高系统整体性能。

本文对重构前后系统性能进行对比测试，选取并发访问量最大的交易下单和订单查询接口，在相同硬件条件下分别进行压力测试。重构前后业务逻辑未发生明显变化，压测并发数设定为1500，压测时长30分钟，测试结果如表1所示。

表1 新旧架构性能对比分析表

测试结果显示，NRS 架构平均响应时间比旧架构降低了约50%，同时请求错误率从1%下降到0.01%，性能提升明显。此外，对响应时间按照2s、5s、10s三个阶梯进行分类统计，结果显示，NRS 架构的接口性能均得到不同程度的提高，以查询接口为例，服务响应时间小于2s 的请求占比提高了24.1%，小于5s 的请求占比提高了22.5%。由此可见，NRS 架构系统在低延时响应方面明显优于旧架构系统。

对重构前后系统在生产环境中进行全链路压测，结果如图8所示，这里使用QPS（Query Per Second，每秒的响应请求数）来考量系统吞吐量。

图8 新旧架构系统吞吐量对比图

测试结果显示，随着并发用户数增长，NRS 架构平均响应时间增长的速度明显低于旧架构系统，性能优势明显。此外，从图中QPS 随并发用户数的变化趋势可以看出，NRS 架构最大QPS 在8200 左右，旧架构QPS在1900左右，系统的吞吐量提升显著。

4 结束语

传统行业向新零售转型过程中对IT 架构的内在变革需求是如今微服务架构体系炙手可热的主要驱动因素。本文介绍了一种基于微服务架构的NRS 设计方案，优化、完善了微服务组件和整体框架，解决了传统IT 架构面对新零售业务模式持续创新和数据量爆发式增长无法支撑的问题。

通过将该方案应用到国内某传统企业，进一步验证了可行性和实践效果。由此可见，对于旨在开拓新业务、转型新零售的传统企业，微服务架构具有很好的推广价值与广阔的应用前景。下一步将对ServiceMesh（服务网格）技术展开研究，期望搭建一种对应用透明、更轻量级的服务发现和治理机制，屏蔽分布式系统的通信复杂性，同时满足多语言和容器化发展的趋势。