CN110708372A - 点餐软件统一对接系统 - Google Patents

Abstract

本发明涉及互联网点餐领域，具体公开了点餐软件统一对接系统，包括第三方对接系统、中台管理系统、分别与第三方对接系统、中台管理系统连接的网关服务组件器集群、与网关服务组件器集群连接的业务数据微服务组件层、与业务数据微服务组件层连接的业务数据储存层以及分别与业务数据微服务组件层、业务数据储存层连接的大数据存储层。本发明的点餐软件统一对接系统，点餐请求组件中的各种点餐系统或点餐软件能够方便地对接业务数据微服务组件层中的各种服务组件，不仅节约了系统资源，而且方便了用户使用，减少了点餐系统崩溃、点餐菜品不齐全、点餐不方便等情况。网关服务组件器集群阻隔了其他程序或系统的干扰，提高了可靠性；构建一个弹性、可伸缩、可扩展性高的系统。

Description

点餐软件统一对接系统

技术领域

本发明涉及互联网点餐领域，具体地说，是一种能够适应多个点餐平台、节约资源、方便使用者使用的点餐软件统一对接系统。

背景技术

随着互联网的发展，很多行业都引入了大数据、物联网，以前打车要在路边等待出租车，即便是有出租车也不一定是空车，现在可以叫网约车，以前吃饭需要到门店去吃，现在吃饭可以网上订餐。由于大部分吃饭一般都是在饭点时间前后，因此网上订餐一般都会集中在一个时段，这会给餐饮企业制造出订餐的高峰时段，订餐者的需求在很多时候会得不到满足。

网上订餐有不少订餐的服务组件形式，其中包括线上订购、在线支付等等。想实现网上订购，这些网上订餐的形式应该很难，原因主要就是餐饮行业普遍存在的信息化程度不够，每个点餐平台中录入的餐饮信息都不够全面，比如客人喜欢吃的东西录入了另外的点菜平台，而正在使用的点餐平台没有录入，又或者午饭时间到了，某个餐饮产品受到大家热捧，大家都在点这款，此时造成线路繁忙，甚至服务组件系统崩溃，即便是成功点餐也会因为点餐人数过多而造成菜品质量降低、菜品配送延迟等问题。

发明内容

本发明的目的在于：提供一种能够适应多个点餐平台、构建一个弹性、可伸缩、可扩展性高的系统。

本发明通过下述技术方案实现：

点餐软件统一对接系统，包括第三方对接系统、中台管理系统、分别与第三方对接系统、中台管理系统连接的网关服务组件器集群、与网关服务组件器集群连接的业务数据微服务组件层、与业务数据微服务组件层连接的业务数据储存层以及分别与业务数据微服务组件层、业务数据储存层连接的大数据存储层；

所述的第三方对接系统和中台管理系统通过网关服务组件器集群向业务数据微服务组件层发送请求，并获得相应的请求响应；

所述的网关服务组件器集群，实现对点餐请求组件请求信息的认证、授权、安全检验以及流量监控，然后将请求信息发送到业务数据微服务组件层；

所述的业务数据微服务组件层，包括多个服务组件，根据第三方对接系统的请求对应调用相应的服务组件进行服务组件；

所述的大数据存储层，用于储存业务数据储存层、业务数据微服务组件层的数据信息；当业务数据微服务组件层需要调用时，提供数据支持；

所述的第三方对接系统包括外卖系统、财务系统、会员系统、供应链系统以及食堂系统。

进一步地，为了更好的实现本发明，所述的中台管理系统用于实现对整个点菜软件统一对接系统的管控协调。

进一步地，为了更好的实现本发明，所述的多个服务组件包括分别与网关服务组件集群连接的订单服务组件、商品服务组件、菜单服务组件、账号服务组件、分发服务组件、商家服务组件、会员服务组件、支付服务组件、库存服务组件、短信服务组件、权限服务组件、门店服务组件、搜索服务组件以及聚合服务组件。

进一步地，为了更好的实现本发明，所述网关服务组件器集群包括与第三方对接系统连接的API服务器集群和与中台管理系统连接的WEB服务器集群，所述API服务器集群的输入端与WEB服务器集群连接的输出端连接；所述API服务器集群与业务系统微服务层连接。

进一步地，为了更好的实现本发明，所述业务系统微服务层包括业务逻辑服务器集群和与业务逻辑服务器集群相互连接的日志/中间服务器集群；所述业务数据储存层与业务逻辑服务器集群连接。

进一步地，为了更好的实现本发明，所述大数据存储层包括Hive数据层、与业务系统微服务层连接的HBase数据层以及分别与Hive数据层、HBase数据层连接的Hadoop集群。

进一步地，为了更好的实现本发明，所述Hadoop集群包括多个HDFS服务器。

进一步地，为了更好的实现本发明，所述业务系统微服务层还包括网络通信组件、容器组件、基础服务组件；

容器组件采用Docker进行容器化；使用Kubernetes进行容器的管理、编排工作；

网络通信组件：同步通信使用Dubbo RPC进行调用，异步通信使用消息队列Kafka进行调用；

基础服务组件：包括分布式开源框架组件、流量管理框架组件、分布式任务调度框架组件、分布式配置管理框架组件、全链路日志服务组件、实时预警组件、大数据处理组件。

本发明与现有技术相比，具有以下优点及有益效果：本发明的点餐软件统一对接系统，通第三方对接系统、中台管理系统、网关服务组件器集群、业务数据微服务组件层以及大数据存储层等的配合，第三方对接系统、中台管理系统中的各种点餐系统或点餐软件能够方便地对接业务数据微服务组件层中的各种服务组件，不仅节约了系统资源，而且方便了用户使用，减少了点餐系统崩溃、点餐菜品不齐全、点餐不方便等情况。此外，API服务组件器集群的使用，阻隔了其他程序或系统的干扰，提高了可靠性。

附图说明

图1为本发明的连接关系示意图；

图2为本发明的点餐软件统一对接系统的一种逻辑框图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。

在下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例1：

本发明通过下述技术方案实现，如图1、图2所示，点餐软件统一对接系统，包括第三方对接系统、中台管理系统、分别与第三方对接系统、中台管理系统连接的网关服务组件器集群、与网关服务组件器集群连接的业务数据微服务组件层、与业务数据微服务组件层连接的业务数据储存层以及分别与业务数据微服务组件层、业务数据储存层连接的大数据存储层；

所述的第三方对接系统和中台管理系统通过网关服务组件器集群向业务数据微服务组件层发送请求，并获得相应的请求响应；

所述的网关服务组件器集群，实现对点餐请求组件请求信息的认证、授权、安全检验以及流量监控，然后将请求信息发送到业务数据微服务组件层；

所述的业务数据微服务组件层，包括多个服务组件，根据第三方对接系统的请求对应调用相应的服务组件进行服务组件；

所述的大数据存储层，用于储存业务数据储存层、业务数据微服务组件层的数据信息；当业务数据微服务组件层需要调用时，提供数据支持；

所述的第三方对接系统包括外卖系统、财务系统、会员系统、供应链系统以及食堂系统。

业务数据储存层：选用MongoDB进行业务数据的存储，采用副本集架构进行搭建，支持故障转移和读写分离，确保数据库的稳定和高可用。

在整个系统运行过程中，其各种数据如日志数据、业务数据以及大数据信息均通过统一的大数据存储层来实现存储。

实施例2：

本实施例在上述实施例的基础上做进一步优化，如图2所示，进一步地，为了更好的实现本发明，所述的中台管理系统用于实现对整个点菜软件统一对接系统的管控协调。

进一步地，为了更好的实现本发明，所述的多个服务组件包括分别与网关服务组件集群连接的订单服务组件、商品服务组件、菜单服务组件、账号服务组件、分发服务组件、商家服务组件、会员服务组件、支付服务组件、库存服务组件、短信服务组件、权限服务组件、门店服务组件、搜索服务组件以及聚合服务组件。

图2所示，以微服务的理念拆分出多个子系统，包括：订单服务、商品服务、菜单服务、账号服务、分发服务、商家服务、会员服务。业务数据微服务组件层中的每个微服务都利用Kubernetes & Docker进行容器化部署，很好的进行了系统间的资源隔离，并可根据不同系统的压力情况进行系统节点的动态伸缩。

本实施例的其他部分与上述实施例相同，故不再赘述。

实施例3：

本实施例在上述实施例的基础上做进一步优化，图2所示，进一步地，为了更好的实现，本发明所述网关服务组件器集群包括与第三方对接系统连接的API服务器集群和与中台管理系统连接的WEB服务器集群，所述API服务器集群的输入端与WEB服务器集群连接的输出端连接；所述API服务器集群与业务系统微服务层连接。

实施例4：

本实施例在上述实施例的基础上做进一步优化，进一步地，为了更好的实现本发明，所述业务系统微服务层包括业务逻辑服务器集群和与业务逻辑服务器集群相互连接的日志/中间服务器集群；所述业务数据储存层与业务逻辑服务器集群连接。

进一步地，为了更好的实现本发明，所述大数据存储层包括Hive数据层、与业务系统微服务层连接的HBase数据层以及分别与Hive数据层、HBase数据层连接的Hadoop集群。

采用HBase数据层解决实时数据查询问题，采用Hive数据层进行数据处理和计算，采用HDFS分布式文件系统。

HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。

进一步地，为了更好的实现本发明，所述Hadoop集群包括多个HDFS服务器。选用HDFS进行大数据的存储，采用集群方式部署，可快速扩展，确保数据的海里存储及分析。

进一步地，为了更好的实现本发明，所述业务系统微服务层还包括网络通信组件、容器组件、基础服务组件；

容器组件采用Docker进行容器化；使用Kubernetes进行容器的管理、编排工作；每个微服务都利用Kubernetes & Docker进行容器化部署，很好的进行了系统间的资源隔离，并可根据不同系统的压力情况进行系统节点的动态伸缩。

网络通信组件：同步通信使用Dubbo RPC进行调用，异步通信使用消息队列Kafka进行调用；服务器间通信：同步通信使用Dubbo RPC进行调用，异步通信使用消息队列Kafka进行调用。

基础服务组件：包括分布式开源框架组件、流量管理框架组件、分布式任务调度框架组件、分布式配置管理框架组件、全链路日志服务组件、实时预警组件、大数据处理组件。

分布式服务框架组件：使用成熟的分布式开源框架Dubbo；

流量管理框架组件：使用高可用防护的流量管理框架Sentinel，实现限流/熔断。

分布式任务调度组件：使用分布式任务调度框架XXL-JOB；

分布式配置中心组件：使用分布式配置管理框架Disconfig；

全链路日志组件：使用Candao Sleuth在代码中进行链路标记，通过Flume进行日志的收集，并发往Kafka消息队列进行缓冲，Logstash从Kafka中消费日志并且插入到Elasticsearch中，从而进行全链路的日志存储及查询。

实时预警组件：通过Spark Streaming实时流计算，根据配置的规则进行实时的短信+邮件方式的预警。

Spark Streaming：构建在Spark上处理Stream数据的框架，基本的原理是将Stream数据分成小的时间片段（几秒），以类似batch批量处理的方式来处理这小部分数据。Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+），虽然比不上专门的流式数据处理软件，也可以用于实时计算，另一方面相比基于Record的其它处理框架（如Storm），一部分窄依赖的RDD数据集可以从源数据重新计算达到容错处理目的。此外小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法。进行实时流计算，近实时的从海量数据里面分析出系统的当前运行状态，并进行监控和预警处理；

性能分析组件：通过Hadoop大数据处理，定时对每天的日志进行分析，统计出系统每天的性能情况。

大数据存储组件：选用HDFS进行大数据的存储，采用集群方式部署，可快速扩展，确保数据的海里存储及分析。

HDFS+Hadoop：所有日志进入分布式文件系统HDFS，定时分析的系统性能情况，以便对系统的整体性能趋势及性能优化做出参考。

全链路日志服务组件：选用Elasticsearch进行日志的存储，采用集群方式部署，可快速扩展，确保日志的高效存储及检索。使用Candao Sleuth在代码中进行链路标记，通过Flume进行日志的收集，并发往Kafka消息队列进行缓冲，Logstash从Kafka中消费日志并且插入到Elasticsearch中，从而进行全链路的日志存储及查询。

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。ElasticSearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。

在分布式的架构中，系统被拆分成了多个子系统，一个普通的请求可能需要经过多个子系统处理才能响应回去，并且每个子系统都是集群部署在N台服务器上，如果通过人工在服务器上查找日志文件的方式进行日志查询，效率会非常低效，这时就需要用到全链路的日志查询系统，可以在日志后台输入关键子，轻松的将所有相关的日志查询出来，并且可以根据日志ID进行整条链路日志的查看，极大地提高了效率。

本实施例的其他部分与上述实施例相同，故不再赘述。

实施例5：

本实施例在上述实施例的基础上做进一步优化，业务数据储存层、日志服务器集群、大数据存储层形成数据持久化组件，数据持久化组件主要是储存一些基础数据，能够供给系统长期重复使用，该基础数据包括各个服务组件需要用到的业务数据储、系统使用过程中的日志数据以及关联的大数据信息。所述的业务数据储存一般采用MongoDB数据库，所述的日志数据一般采用Elasticsearch搜索引擎。

MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。

本实施例的其他部分与上述实施例相同，故不再赘述。

实施例6：

本实施例在上述实施例的基础上做进一步优化，所述的第三方对接系统、与API服务器集群之间配合有负载均衡组件。中台管理系统与WEB服务器集群之间也配合有负载均衡组件；

负载均衡组件主要作用就是将执行任务分摊到多个操作单元上执行，共同完成任务，它构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务组件器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

本发明采用成熟的Dubbo分布式架构进行搭建，通过Kubernetes & Docker进行容器化部署，将整体系统拆分成多个子系统微服务，每个子系统都采用多节点方式部署，构建一个高性能、易扩展、可伸缩、高可用的系统。

本实施例的其他部分与上述实施例相同，故不再赘述。

以上所述，仅是本发明的较佳实施例，并非对本发明做任何形式上的限制，凡是依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化，均落入本发明的保护范围之内。

Claims (8)

1.点餐软件统一对接系统，其特征在于：包括第三方对接系统、中台管理系统、分别与第三方对接系统、中台管理系统连接的网关服务组件器集群、与网关服务组件器集群连接的业务数据微服务组件层、与业务数据微服务组件层连接的业务数据储存层以及分别与业务数据微服务组件层、业务数据储存层连接的大数据存储层；

所述的第三方对接系统和中台管理系统通过网关服务组件器集群向业务数据微服务组件层发送请求，并获得相应的请求响应；

所述的网关服务组件器集群，实现对点餐请求组件请求信息的认证、授权、安全检验以及流量监控，然后将请求信息发送到业务数据微服务组件层；

所述的业务数据微服务组件层，包括多个服务组件，根据第三方对接系统的请求对应调用相应的服务组件进行服务组件；

所述的大数据存储层，用于储存业务数据储存层、业务数据微服务组件层的数据信息；当业务数据微服务组件层需要调用时，提供数据支持；

所述的第三方对接系统包括外卖系统、财务系统、会员系统、供应链系统以及食堂系统。

2.根据权利要求1所述的点餐软件统一对接系统，其特征在于：所述的中台管理系统用于实现对整个点菜软件统一对接系统的管控协调。

3.根据权利要求1所述的点餐软件统一对接系统，其特征在于：所述的多个服务组件包括分别与网关服务组件集群连接的订单服务组件、商品服务组件、菜单服务组件、账号服务组件、分发服务组件、商家服务组件、会员服务组件、支付服务组件、库存服务组件、短信服务组件、权限服务组件、门店服务组件、搜索服务组件以及聚合服务组件。

4.根据权利要求1所述的点餐软件统一对接系统，其特征在于：所述网关服务组件器集群包括与第三方对接系统连接的API服务器集群和与中台管理系统连接的WEB服务器集群，所述API服务器集群的输入端与WEB服务器集群连接的输出端连接；所述API服务器集群与业务系统微服务层连接。

5.根据权利要求1所述的点餐软件统一对接系统，其特征在于：所述业务系统微服务层包括业务逻辑服务器集群和与业务逻辑服务器集群相互连接的日志/中间服务器集群；所述业务数据储存层与业务逻辑服务器集群连接。

6.根据权利要求5所述的点餐软件统一对接系统，其特征在于：所述大数据存储层包括Hive数据层、与业务系统微服务层连接的HBase数据层以及分别与Hive数据层、HBase数据层连接的Hadoop集群。

7.根据权利要求6所述的点餐软件统一对接系统，其特征在于：所述Hadoop集群包括多个HDFS服务器。

8.根据权利要求1-7任一项所述的点餐软件统一对接系统，其特征在于：所述业务系统微服务层还包括网络通信组件、容器组件、基础服务组件；

容器组件采用Docker进行容器化；使用Kubernetes进行容器的管理、编排工作；

网络通信组件：同步通信使用Dubbo RPC进行调用，异步通信使用消息队列Kafka进行调用；

基础服务组件：包括分布式开源框架组件、流量管理框架组件、分布式任务调度框架组件、分布式配置管理框架组件、全链路日志服务组件、实时预警组件、大数据处理组件。

Images