CN109284089B - 一种基于微服务技术的电商平台的实现系统及方法 - Google Patents

Abstract

本发明公开了一种基于微服务技术的电商平台的实现系统及方法，通过在传统架构的商城项目中，将需要拆解的业务进行横向拆解成具有专业业务的应用，纵向拆解出具有特定功能的底层实现作为服务，实现传统架构的商城项目向微服务架构的商城项目循序渐进地代码重构。另外，网关、应用、服务三者配合缓存联合处理复杂度高，信息多，访问频率高的业务逻辑，从而使用户能高效快速地获取所需要访问的信息，并且减少服务器压力，而且通过MQ和Dubbo配合实现同步/异步的远程调用，提高了微服务的逻辑处理效率。

Description

一种基于微服务技术的电商平台的实现系统及方法

技术领域

本专利涉及信息网络技术领域，具体涉及大型电商平台的WEB层和微服务之间的调用，是一种电商微服务的架构方式。

背景技术

随着金融电商平台的业务的不断发展、技术的不断改进、应用的不断推广，金融电商平台的代码业务越来越复杂，如何保证系统或关联系统的可用性，避免由于交易量过大导致系统性能急剧下降甚至系统宕机，迫在眉睫。

传统的应用研发成本高，主要原因是：传统的垂直的架构、产品功能开发模式导致代码重复率过高；代码重复率过高导致功能需求变更困难(主要体现为功能修改不一致引起后续的测试、部署问题)；当代码重复率过高及需求变更困难导致产品无法赶上日益变化的市场需求，不能快速上线、敏捷交付产品。

同时，传统的架构设计导致运维效率低。产品业务不断新增使得整个系统的可维护性愈来愈差，产品各个功能模块关联孤立。当这种情况体现到整个企业管理中时，会使得所有的功能模块运维困难。

微服务架构(Microservices Architecture)的诞生是互联网时代倒逼传统技术和架构而产生的变革。如何从传统的架构设计向微服务架构过度是一个需要深入研究的问题。

发明内容

针对现有技术的不足，本发明旨在提供一种基于微服务技术的电商平台的实现系统及方法，

为了实现上述目的，本发明采用如下技术方案：

一种基于微服务技术的电商平台的实现系统，包括：

用户端：供用户根据所需要的服务向网关层发起对应的请求；

网关层：由Nginx和动态网关结合实现，与用户端、缓存服务器redis和应用层相关联，用于接收用户端的请求，根据用户的请求从缓存服务器redis调出相应的内容或向应用层中相应的应用发送请求；所述动态网关包括首页动态网关、商品动态网关、定位动态网关；

应用层：与网关层、缓存服务器redis、服务层、注册中心、配置中心和信息中心相关联，设置有多个应用，每个应用根据网关层的请求向相应的服务发起请求并进行业务处理；应用层中包含有商城端应用、商户端应用、运营端应用，所述商城端应用包括PC商城端应用、移动商城端应用、微商城端应用；

服务层：与应用层相关联，设置有多种服务，用于根据应用层的请求提供对应的服务；所述服务层包括有商品详情服务和首页服务；

缓存服务器redis：与所述服务层、应用层和网关层相关联，用于根据各个服务、应用和网关层的需要提供存入和取出功能；

注册中心：使用Zookeeper作为注册中心，与应用层和服务层相关联，用于统一管理服务层和应用层；

配置中心：使用Disconf作为配置中心，与应用层和服务层相关联，统一管理服务层和应用层的配置信息；

信息中心：使用RocketMQ作为信息中心，与应用层和服务层相关联，用于异步远程调用服务，作为Dubbo调用远程服务的补充。

进一步地，所述应用层中还包括有收银台应用、客服中心应用和短信控制台应用，所述服务层还设置有清算服务和短信服务。

进一步地，所述动态网关由OpenResty实现。

上述基于微服务技术的电商平台的实现系统的实现方法，包括：

当使用商品详情服务时：

1.1)商户在商户端应用向商品详情服务发起生成商品详情信息的请求，商品详情服务将生成的各个商品的商品详情信息在缓存服务器redis中分别生成两份缓存，其中一份为临时缓存，另一份为永久缓存；

1.2)用户在用户端发起展示某商品的商品详情信息的请求，请求先经过Nginx，Nginx判断发起请求的是PC端浏览器、移动端APP还是移动端浏览器，然后请求被代理到商品动态网关；

1.3)商品动态网关根据请求从缓存服务器redis中获取对应的商品详情信息的临时缓存并返回；若是商品动态网关获取不到对应的商品详情信息的临时缓存，则商品动态网关向对应的商城端应用发送请求，商城端应用从缓存服务器Redis中获取该商品详情信息的永久缓存，同时通过信息中心RocketMQ请求所述商品详情服务更新该商品详情信息的临时缓存和永久缓存；若是商城端应用获取不到该商品详情信息的永久缓存，就直接通过Dubbo请求商品详情服务获取该商品的商品详情信息返回给用户，同时商品详情服务也会将生成的商品详情信息进行缓存；

当使用首页服务时：

2.1)各个地方的运营人员在运营端应用请求首页服务获取对应地方的首页信息，调整对应地方的首页内容后首页服务将首页信息缓存到缓存服务器redis，采用永久缓存的方式；

2.2)当用户在用户端请求访问首页时，请求通过Nginx，判断发起请求的是PC端浏览器、移动端APP还是移动端浏览器，然后该请求被Nginx代理到定位动态网关，定位动态网关通过用户的ip地址获取用户的地址，从而重定向到对应地方的首页；

2.3)此时用户再次发起请求，该请求被Nginx代理到首页动态网关，首页动态网关从缓存服务器redis中获取对应地方的首页信息的永久缓存返回给用户；若是没有找到对应地方的首页信息的缓存，首页动态网关就会访问对应的商城端应用，商城端应用访问首页服务获取对应地方的首页信息，返回给用户端，不缓存该首页信息。

需要说明的是，在商品详情服务中，当商户在商户端应用修改商品信息时，通过信息中心RocketMQ请求商品详情服务更新此商品的商品详情信息的临时缓存和永久缓存。

需要说明的是，所述商品详情信息可以为html页面或json对象。

需要说明的是，所述首页信息为html页面或json对象。

需要说明的是，上述实现方法还包括：

当下单支付时：

当用户通过用户端发起提交订单的请求后，跳转至收银台应用，用户支付后，收银台应用负责确认支付成功，同时通过清算服务进行对账以及和商户端应用进行清算；

需要说明的是，上述实现方法还包括：

当需要发送短信时：

各应用有需要发送短信时调用短信服务发送短信，运营人员在短信控制台应用进行短信服务监控和控制短信的发送。

需要说明的是，上述实现方法还包括：

当需要和客服沟通时：

商城端应用、商户端应用、运营端应用都在前端页面有对应逻辑，直接打开新窗口，向客服中心应用发起请求，通过客户中心应用与客服进行沟通。

本发明的有益效果在于：

1.通过在传统架构的商城项目中，将需要拆解的业务进行横向拆解成具有专业业务的应用，纵向拆解出具有特定功能的底层实现作为服务，实现传统架构的商城项目向微服务架构的商城项目循序渐进地代码重构。

2.网关、应用、服务三者配合缓存联合处理复杂度高，信息多，访问频率高的业务逻辑，从而使用户能高效快速地获取所需要访问的信息，并且减少服务器压力。

3.通过MQ和Dubbo配合实现同步/异步的远程调用，提高了微服务的逻辑处理效率。

附图说明

图1为本发明实施例的系统组成示意图。

具体实施方式

以下将结合附图对本发明作进一步的描述，需要说明的是，以下实施例以本技术方案为前提，给出了详细的实施方式和具体的操作过程，但本发明的保护范围并不限于本实施例。

首先对本实施例中涉及到的术语作简单解释如下：

Nginx：Nginx是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。

OpenResty：OpenResty是一个基于Nginx与Lua的高性能Web平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。

ZooKeeper：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

Dubbo：Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合)。

Disconf：Disconf是百度开源的一款专注于各种分布式系统配置管理的通用组件和通用平台，提供统一的配置管理服务。

RocketMQ：RocketMQ是Alibaba开源的一款高性能、高吞吐量的分布式消息中间件。

Redis：Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

微服务架构：一项在云中部署应用和服务的新技术。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。

本实施例提供一种基于微服务技术的电商平台的实现系统，如图1所示，包括：

用户端：供用户根据所需要的服务向网关层发起对应的请求；

网关层：由Nginx和动态网关结合实现，与用户端、缓存服务器redis和应用层相关联，用于接收用户端的请求，根据用户的请求从缓存服务器redis调出相应的内容或向应用层中相应的应用发送请求；

应用层：与网关层、缓存服务器redis、服务层、注册中心、配置中心和信息中心相关联，设置有多个应用，每个应用根据网关层的请求向相应的服务发起请求并进行业务处理；

服务层：与应用层相关联，设置有多种服务，用于根据应用层的请求提供对应的服务；

缓存服务器redis：与所述服务层、应用层和网关层相关联，用于根据各个服务、应用和网关层的需要提供存入和取出功能；

注册中心：使用Zookeeper作为注册中心，与应用层和服务层相关联，用于统一管理服务层和应用层；

配置中心：使用Disconf作为配置中心，与应用层和服务层相关联，统一管理服务层和应用层的配置信息；

信息中心：使用RocketMQ作为信息中心，与应用层和服务层相关联，用于异步远程调用服务，作为Dubbo调用远程服务的补充。

进一步地，所述应用层中包括有商城端应用、商户端应用、运营端应用、收银台应用、客服中心应用、单点登陆应用和短信控制台应用。

更进一步地，所述商城端应用包括PC商城端应用、移动商城端应用、微商城端应用。

进一步地，所述服务层设置有商品详情服务、首页服务、订单服务、清算服务、短信服务和用户服务。在实际应用中还可以设置购物车服务、搜索服务、关注服务等。

进一步地，所述动态网关包括首页动态网关、商品动态网关、定位动态网关。

更进一步地，所述动态网关由OpenResty实现。

一种基于微服务技术的电商平台的实现方法，包括如下步骤：

当使用商品详情服务时：

1.1)商户在商户端应用向商品详情服务发起生成商品详情信息的请求，商品详情服务将生成的各个商品的商品详情信息在缓存服务器redis中分别生成两份缓存，其中一份为临时缓存(本实施例中缓存过期时间为10分钟)，另一份为永久缓存；

1.2)用户在用户端发起展示某商品的商品详情信息的请求，请求先经过Nginx，Nginx判断发起请求的是PC端浏览器、移动端APP还是移动端浏览器，然后请求被代理到商品动态网关；

1.3)商品动态网关根据请求从缓存服务器redis中获取对应的商品详情信息的临时缓存并返回；若是商品动态网关获取不到对应的商品详情信息的临时缓存，则商品动态网关向商城端应用(根据用户端是PC端浏览器、移动端APP还是移动端浏览器决定是向PC商城端应用、移动商城端应用还是微商城端应用发送请求)发送请求，商城端应用从缓存服务器Redis中获取该商品详情信息的永久缓存，同时通过信息中心RocketMQ请求所述商品详情服务更新该商品详情信息的临时缓存和永久缓存；若是商城端应用获取不到该商品详情信息的永久缓存，就直接通过Dubbo请求商品详情服务获取该商品的商品详情信息返回给用户，同时商品详情服务也会将生成的商品详情信息进行缓存。

需要说明的是，在商品详情服务中，当商户在商户端应用修改商品信息时，通过信息中心RocketMQ请求商品详情服务更新此商品的商品详情信息的临时缓存和永久缓存。

需要说明的是，所述商品详情信息可以为html页面或json对象。

当使用首页服务时：

2.1)各个地方的运营人员在运营端应用请求首页服务获取对应地方的首页信息，调整对应地方的首页内容后首页服务将首页信息缓存到缓存服务器redis，采用永久缓存的方式；

2.2)当用户在用户端请求访问首页时，请求通过Nginx，判断发起请求的是PC端浏览器、移动端APP还是移动端浏览器，然后该请求被Nginx代理到定位动态网关，定位动态网关通过用户的ip地址获取用户的地址，从而重定向到对应地方的首页；

2.3)此时用户再次发起请求，该请求被Nginx代理到首页动态网关，首页动态网关从缓存服务器redis中获取对应地方的首页信息的永久缓存返回给用户；若是没有找到对应地方的首页信息的缓存，首页动态网关就会访问商城端应用(根据用户端为PC端浏览器、移动端APP还是移动端浏览器确定访问PC商城端应用、移动商城端应用还是微商城端应用)，商城端应用访问首页服务获取对应地方的首页信息，返回给用户端，不缓存该首页信息。

需要说明的是，所述首页信息为html页面或json对象。

当下单支付时：

当用户通过用户端发起提交订单的请求后，跳转至收银台应用，用户支付后，收银台应用负责确认支付成功，同时通过清算服务进行对账以及和商户端应用进行清算。

需要说明的是，为了对金钱相关的业务逻辑统一管理，收银台应用拥有独立的定时任务机制。

当使用短信服务时：

各应用有需要发送短信时调用短信服务发送短信，运营人员可以在短信控制台应用进行短信服务监控和控制短信的发送。

当使用客服中心应用时：

商城端应用、商户端应用、运营端应用都在前端页面有对应逻辑，直接打开新窗口，向客服中心应用发起请求，通过客户中心应用与客服进行沟通。

当使用用户服务时：

通过单点登陆应用发起请求，用户登录时，单点登陆应用通过用户登录确认用户是否登陆，运营端应用通过调用用户服务管理用户信息。

对于本领域的技术人员来说，可以根据以上的技术方案和构思，给出各种相应的改变和变形，而所有的这些改变和变形，都应该包括在本发明权利要求的保护范围之内。

Claims (7)

1.一种基于微服务技术的电商平台的实现系统的实现方法，

该基于微服务技术的电商平台的实现系统包括：

用户端：供用户根据所需要的服务向网关层发起对应的请求；

网关层：由Nginx和动态网关结合实现，与用户端、缓存服务器redis和应用层相关联，用于接收用户端的请求，根据用户的请求从缓存服务器redis调出相应的内容或向应用层中相应的应用发送请求；所述动态网关包括首页动态网关、商品动态网关、定位动态网关；

应用层：与网关层、缓存服务器redis、服务层、注册中心、配置中心和信息中心相关联，设置有多个应用，每个应用根据网关层的请求向服务层中相应的服务发起请求并进行业务处理；应用层中包含有商城端应用、商户端应用、运营端应用，所述商城端应用包括PC商城端应用、移动商城端应用、微商城端应用；

服务层：与应用层相关联，设置有多种服务，用于根据应用层的请求提供对应的服务；所述服务层包括有商品详情服务和首页服务；

缓存服务器redis：与所述服务层、应用层和网关层相关联，用于根据各个服务、应用和网关层的需要提供存入和取出功能；

注册中心：使用Zookeeper作为注册中心，与应用层和服务层相关联，用于统一管理服务层和应用层；

配置中心：使用Disconf作为配置中心，与应用层和服务层相关联，统一管理服务层和应用层的配置信息；

信息中心：使用RocketMQ作为信息中心，与应用层和服务层相关联，用于异步远程调用服务，作为Dubbo调用远程服务的补充；

其特征在于，该实现方法包括：

当使用商品详情服务时：

1.1)商户在商户端应用向商品详情服务发起生成商品详情信息的请求，商品详情服务将生成的各个商品的商品详情信息在缓存服务器redis中分别生成两份缓存，其中一份为临时缓存，另一份为永久缓存；

1.2)用户在用户端发起展示某商品的商品详情信息的请求，请求先经过Nginx，Nginx判断发起请求的是PC端浏览器、移动端APP还是移动端浏览器，然后请求被代理到商品动态网关；

1.3)商品动态网关根据请求从缓存服务器redis中获取对应的商品详情信息的临时缓存并返回；若是商品动态网关获取不到对应的商品详情信息的临时缓存，则商品动态网关向对应的商城端应用发送请求，商城端应用从缓存服务器Redis中获取该商品详情信息的永久缓存，同时通过信息中心RocketMQ请求所述商品详情服务更新该商品详情信息的临时缓存和永久缓存；若是商城端应用获取不到该商品详情信息的永久缓存，就直接通过Dubbo请求商品详情服务获取该商品的商品详情信息返回给用户，同时商品详情服务也会将生成的商品详情信息进行缓存；

当使用首页服务时：

2.1)各个地方的运营人员在运营端应用请求首页服务获取对应地方的首页信息，调整对应地方的首页内容后首页服务将首页信息缓存到缓存服务器redis，采用永久缓存的方式；

2.2)当用户在用户端请求访问首页时，请求通过Nginx，判断发起请求的是PC端浏览器、移动端APP还是移动端浏览器，然后该请求被Nginx代理到定位动态网关，定位动态网关通过用户的ip地址获取用户的地址，从而重定向到对应地方的首页；

2.3)此时用户再次发起请求，该请求被Nginx代理到首页动态网关，首页动态网关从缓存服务器redis中获取对应地方的首页信息的永久缓存返回给用户；若是没有找到对应地方的首页信息的缓存，首页动态网关就会访问对应的商城端应用，商城端应用访问首页服务获取对应地方的首页信息，返回给用户端，不缓存该首页信息。

2.根据权利要求1所述的实现方法，其特征在于，在商品详情服务中，当商户在商户端应用修改商品信息时，通过信息中心RocketMQ请求商品详情服务更新此商品的商品详情信息的临时缓存和永久缓存。

3.根据权利要求1所述的实现方法，其特征在于，所述商品详情信息为html页面或json对象。

4.根据权利要求1所述的实现方法，其特征在于，所述首页信息为html页面或json对象。

5.根据权利要求1所述的实现方法，其特征在于，还包括：

当下单支付时：

当用户通过用户端发起提交订单的请求后，跳转至收银台应用，用户支付后，收银台应用负责确认支付成功，同时通过清算服务进行对账以及和商户端应用进行清算。

6.根据权利要求1所述的实现方法，其特征在于，还包括：

当需要发送短信时：

各应用有需要发送短信时调用短信服务发送短信，运营人员在短信控制台应用进行短信服务监控和控制短信的发送。

7.根据权利要求1所述的实现方法，其特征在于，还包括：

当需要和客服沟通时：

商城端应用、商户端应用、运营端应用都在前端页面有对应逻辑，直接打开新窗口，向客服中心应用发起请求，通过客户中心应用与客服进行沟通。

Images