用于食品监管的微服务系统

摘要

本公开提供一种用于食品监管的微服务系统，涉及互联网技术领域，能够解决数据交换时需要各个业务系统独自开发接口，通过接口调用的方式，难以维护和管理的问题。具体技术方案为：该系统包括微服务核心平台和多个微服务业务子系统，其中，所述微服务核心平台包括注册中心和远程服务调度中心，所述多个微服务业务子系统通过注册中心注册到微服务核心平台，所述多个微服务业务子系统之间通过远程服务调度中心进行数据交互；其中，多个微服务业务子系统包括：监管档案微服务、行政许可微服务、工作流微服务、日常监管微服务、稽查办案微服务以及检验检测微服务。

说明书

技术领域

本公开涉及互联网技术领域，尤其涉及用于食品监管的微服务系统。

背景技术

食品监管信息化系统是一个综合性业务系统。根据现行食品监管的相关法规制度以及实际监管过程中的部门职能划分。食品监管信息化可分为行政许可，日常监管，稽查办案，检验检测等几个相互独立的业务系统。

在传统的食品监管信息化建设过程中。一般都是以独立建设的方式分别建设行政许可，日常监管，稽查办案，检验检测等业务系统。这些业务系统负责不同的监管功能，都是围绕被监管对象进行监管。以同一个被监管对象为中心，这些不同业务系统的监管数据需要被关联和共享。因此多个独立的业务系统需要实现数据互通和服务共享。

但传统“烟囱式”的业务系统建设方式，当前的食品监管信息化建设。一般都是以独立建设的方式分别建设行政许可，日常监管，稽查办案，检验检测等业务系统。这些业务系统负责不同的监管功能。

这种建设方式的缺点是，各业务系统独立运行，数据各自维护，导致数据孤岛问题严重，数据不能互通共享。难以实现综合性监管。数据交换时需要各个业务系统独自开发接口，通过接口调用的方式，难以维护和管理。

发明内容

本公开实施例提供一种用于食品监管的微服务系统，能够解决各业务系统独立运行，数据各自维护，导致数据孤岛问题严重，数据不能互通共享的问题。所述技术方案如下：

根据本公开实施例的第一方面，提供一种用于食品监管的微服务系统，该系统包括微服务核心平台和多个微服务业务子系统，其中，所述微服务核心平台包括注册中心和远程服务调度中心，所述多个微服务业务子系统通过注册中心注册到微服务核心平台，所述多个微服务业务子系统之间通过远程服务调度中心进行数据交互；其中，多个微服务业务子系统包括：监管档案微服务、行政许可微服务、工作流微服务、日常监管微服务、稽查办案微服务以及检验检测微服务。

在一个实施例中，监管档案微服务存储有监管对象基本信息和监管数据，行政许可微服务通过工作流微服务获取许可办理流程，并通过远程服务调度中心将经由所述许可办理流程经办后的许可信息推送到监管档案微服务。

在一个实施例中，日常监管微服务，从监管档案微服务中获取被监管对象基本信息，根据所述被监管对象主体信息创建对应的日常检查任务，并将被监管对象基本信息中检查合格的部分推送到监管档案微服务，将被监管对象基本信息中检查不合格的部分推送到稽查办案微服务。

在一个实施例中，稽查办案微服务，从日常监管微服务获取被监管对象基本信息中检查不合格的部分并进行稽查办案，将稽查办案后的被监管对象基本信息推送到监管档案微服务。

在一个实施例中，从监管档案微服务中获取被监管对象基本信息，根据所述被监管对象基本信息创建对应的检验检测任务，并将检验检测结果推送到监管档案微服务。

在一个实施例中，微服务核心平台还包括链路跟踪中心，用于检测所述多个微服务业务子系统进行数据交互过程中网络性能参数。

在一个实施例中，微服务核心平台还包括熔断保护中心，用于监控所述多个微服务业务子系统之间的调用响应状态，并在调用响应状态满足预设条件时，启动熔断机制。

在一个实施例中，微服务核心平台还包括API网关，所述API网关提供和所述多个微服务业务子系统进行交互的接口。

在一个实施例中，网络性能参数包括以下至少之一：请求耗费时间、网络延迟、业务逻辑耗费时间。

在一个实施例中，熔断保护中心具体用于监控所述多个微服务业务子系统之间的调用响应状态，并在调用响应状态指示调用失败次数达到预设阈值时，启动熔断机制。

微服务框架系统是构成应用系统的“小而自治的服务”。随着系统业务需求日益增加、业务数据快速增长、服务规模不断扩展，软件功能须频繁变化，微服务框架(MSA，Microservice Architecture)作为一种新型软件系统，逐渐成为用于解决构建细粒度、松耦合复杂系统的分布式系统架构，它将应用程序分割为多个独立、协同工作的微小服务，每个服务专注于单一业务功能并拥有独立运行的进程，服务之间界限清晰，通过轻量级通信实现完整的应用，满足用户业务扩展变化的需求。

微服务框架能够按照业务拆分服务粒度，通过可伸缩接口控制服务边界，适应实际业务需求变化，使用微服务组合完成具体功能，使应用程序可自由扩展。服务发生变更时可实现自动化按需部署，无需修改、重新部署整个应用程序。微服务框架能够利用去中心化、轻量级交互、敏捷迭代、解耦、故障隔离、容器等机制，满足复杂系统结构变化需要，能够优化IT复杂系统效率，同时也不失弹性、平稳和健壮性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是本公开实施例提供的用于食品监管的微服务系统结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

本公开实施例提供一种用于食品监管业务的微服务系统，如图1所示，该食品监管业务的微服务系统包括微服务核心平台101和多个微服务业务子系统102，其中，所述微服务核心平台101包括注册中心和远程服务调度中心，所述多个微服务业务子系统102通过注册中心注册到微服务核心平台101，所述多个微服务业务子系统102之间通过远程服务调度中心进行数据交互；其中，多个微服务业务子系统102包括：监管档案微服务、行政许可微服务、工作流微服务、日常监管微服务、稽查办案微服务以及检验检测微服务。

多个微服务业务子系统都是一个个独立的项目，可以独立运行。如果微服务业务子系统之间有依赖关系，那么通过远程过程调用(Remote Procedure Call，RPC)方式调用。

这样的好处有很多：

多个微服务业务子系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。

多个微服务业务子系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促，下单量可能会大大提升，因此我们可以针对性地提升订单系统、产品系统的节点数量，而对于后台管理系统、数据分析系统而言，节点数量维持原有水平即可。

多个微服务业务子系统的复用性更高。比如，当我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。

然后当这些多个微服务业务子系统服务初始化的时候，将当前微服务业务子系统需要发布的服务、以及微服务业务子系统的IP和端口号发送给注册中心，注册中心便会将其记录下来。这就是服务发布的过程。与此同时，也是在系统初始化的时候，扫描一下当前微服务业务子系统所需要引用的服务，然后向注册中心请求需要引用的服务所在的IP和端口号。接下来系统就可以正常运行了。当系统A需要调用系统B的服务的时候，A就会与B建立起一条RPC信道，然后再调用B系统上相应的服务。

该实施例中，监管档案微服务存储有监管对象基本信息和监管数据，行政许可微服务通过工作流微服务获取许可办理流程，并通过远程服务调度中心将经由所述许可办理流程经办后的许可信息推送到监管档案微服务。

该实施例中，日常监管微服务，从监管档案微服务中获取被监管对象基本信息，根据所述被监管对象主体信息创建对应的日常检查任务，并将被监管对象基本信息中检查合格的部分推送到监管档案微服务，将被监管对象基本信息中检查不合格的部分推送到稽查办案微服务。

该实施例中，稽查办案微服务，从日常监管微服务获取被监管对象基本信息中检查不合格的部分并进行稽查办案，将稽查办案后的被监管对象基本信息推送到监管档案微服务。

该实施例中，从监管档案微服务中获取被监管对象基本信息，根据所述被监管对象基本信息创建对应的检验检测任务，并将检验检测结果推送到监管档案微服务。

该实施例中，微服务核心平台还包括熔断保护中心，用于监控所述多个微服务业务子系统之间的调用失败次数，并在所述调用失败次数达到预设阈值时，启动熔断机制。

比如，我们的应用是微服务A调用微服务B和微服务C来完成的，而微服务B又需要调用微服务D，微服务D又需要调用微服务E。如果在调用的链路上对微服务E的调用，响应时间过长或者服务不可用，那么对微服务D的调用就会占用越来越多的系统资源，进而引起微服务D的系统崩溃，微服务D的不可用，又会连锁反应的引起微服务B崩溃，进而微服务A崩溃，最终导致整个应用不可用。这也就是所谓的“雪崩效应”。启动熔断机制可以有效预防“雪崩效应”。

熔断机制一般可以分为熔断和熔断降级两种方式。熔断的方式一般用于当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。服务降级则是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能(业务场景)出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback(退路)错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

当检测到微服务业务子系统之间的调用响应状态正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。在dubbo中也可利用nio超时+失败次数做熔断。

该实施例中，微服务核心平台还包括API网关，所述API网关提供和所述多个微服务业务子系统进行交互的接口。

该实施例中，网络性能参数包括以下至少之一：请求耗费时间、网络延迟、业务逻辑耗费时间。

该实施例中，熔断保护中心，具体用于监控所述多个微服务业务子系统之间的调用响应状态，并在调用响应状态指示调用失败次数达到预设阈值时，启动熔断机制。

微服务框架系统是构成应用系统的“小而自治的服务”。随着系统业务需求日益增加、业务数据快速增长、服务规模不断扩展，软件功能须频繁变化，微服务框架(MSA，Microservice Architecture)作为一种新型软件系统，逐渐成为用于解决构建细粒度、松耦合复杂系统的分布式系统架构，它将应用程序分割为多个独立、协同工作的微小服务，每个服务专注于单一业务功能并拥有独立运行的进程，服务之间界限清晰，通过轻量级通信实现完整的应用，满足用户业务扩展变化的需求。

微服务框架能够按照业务拆分服务粒度，通过可伸缩接口控制服务边界，适应实际业务需求变化，使用微服务组合完成具体功能，使应用程序可自由扩展。服务发生变更时可实现自动化按需部署，无需修改、重新部署整个应用程序。微服务框架能够利用去中心化、轻量级交互、敏捷迭代、解耦、故障隔离、容器等机制，满足复杂系统结构变化需要，能够优化IT复杂系统效率，同时也不失弹性、平稳和健壮性。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。