[0001] 本发明涉及智慧景区技术领域，特别涉及智慧景区操作系统。

[0002] 市场目前已存在了各种成熟的智慧景区系统，但他们各自都有一套自己的标准，因此导致系统与系统之间都形成了数据孤岛，界面风格、功能操作、产品形态等也千差万别没有一套统一的标准。正由于这些原因导致景区办公无法做到真正线上化、协同化。各系统留下来的数据孤岛不能为景区经营管理提供全方位的、精准有效的数据分析。

[0003] 在国内阿里巴巴提供的一些产品（如钉钉）有着统一入口、统一的用户、部分数据可以在各系统之间存在协同性。钉钉能虽然能打通各系统用户但是旅游景区各系统之间的业务数据无法一一互联，虽然有统一的入口但是系统功能与功能之间的协同性不够，另外接入方式的也存在居多的局限性。

[0004] 现有景区智慧系统中，多个智慧系统无通用接入标准、各系统之间数据难以衔接、用户操作入口多、不同规格的系统带来学习成本增加且系统操作复杂。

[0005] 且现有景区系统中，不具有数据处理的功能，不能给景区提供数据参考，使用价值有限。

[0021] 为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

[0022] 本发明针对现有的问题，提供了一种智慧景区操作系统，为基于智慧景区基础数据领域模型构建的操作系统，所述智慧景区基础数据领域模型包括具有相互依赖关系，且细分到具体实体的景区模型、景区运营管理人员模型及游客模型，为不同景区、不同景区运营管理人员及不同游客提供统一的景区系统，并提供参考数据。

[0023] 所述提供参考数据包括预测未来的时间段的景区运营情况，具体包括如下步骤：步骤S11、收集基础业务数据，选取影响预测数据结果的参考因素；
步骤S12、分析处理以获取历年年度业务数据报表及景区热度趋势；
步骤S13、计算获得预测时段景区运营情况。

[0024] 所述步骤S11中的影响预测数据结果的参考因素包括历史用户信息、数据发生时的天气信息，所述步骤S13中采用加权平均法，对参考因素加权计算，获得预测时段景区运营情况。

[0025] 所述预测时段景区运营情况具体包括入园人数预测、财务收入预测、餐饮食材量预测、酒店客房预订数量预测、景区服务工作人员数量预测。

[0026] 所述步骤S13中计算方法具体为：入园人数预测=上年度实际入园人数统计结果*（正增长率+天气因素增长率+社会因素增长率）；
财务收入预测=预测入园人数*客单价；
酒店客房预订预测=预测入园人数*最近5年平均单位人数入住率；
餐饮主材预测=预测入园人数*最近5年平均单位人数用餐率*平均消耗量+酒店客房预订预测人数*平均消耗量。

[0027] 如图1所示，为基于智慧景区基础数据领域模型构建的操作系统包括操作基础信息管理设置、系统用户登录、用户权限、系统基础日志、各领域模型统一终端api（Application Programming Interface，应用程序接口）、基础模型数据存储与检索、操作系统运行环境，所述智慧景区基础数据领域模型包括具有相互依赖关系，且细分到具体实体的景区模型、景区运营管理人员模型及游客模型，为不同景区、不同景区运营管理人员及不同游客提供模型，所述操作系统运行环境包括WEB UI(网络产品界面设计，Website User Interface）和后台，所述WEB UI为景区、景区运营管理人员及游客提供景区前端运行环境。

[0028] 所述WEB UI采用vue框架（一个JavaScriptMVVM库,是一套构建用户界面的渐进式框架）为基础搭建前端运环境。前端具有模块化、组件化、框架化的特征，所述WEB UI为风格统一的UI（User Interface，用户界面）界面，可供二次开发的平台和快速集成的接入点。

[0029] 所述后台以微服务框架spring cloud（一系列框架的有序集合）为基础搭建后台运行环境，所述后台采用docker（应用容器引擎）容器结合k8s（kubernetes，容器编排引擎）服务、多节的点部署结合负载均衡系统、redis（一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key‑Value数据库）缓存与rabbitmq（消息队列）队列异步处理服务、nginx（一个高性能的HTTP和反向代理web服务器）反向代理服务、日志ELK（Elasticsearch,Logstash  和 Kibana，集中式日志系统）存储与检索及RESTful（Representational State Transfer，一种网络应用程序的设计风格和开发方式）服务接口的后台运行环境。

[0030] 所述操作系统运行环境采用前后端分离的运行环境方式，具有分布式、模块化、微服务化、saas(Software‑as‑a‑Service，网络软件服务）化的后台环境特征。

[0031] 后台运行环境采用docker容器结合k8s服务，可智能伸缩、调整、故障转移；采用多节点部署结合负载均衡系统，承载能力强；采用redis缓存与rabbitmq队列异步处理服务，抗压力强；采用nginx反向代理服务，吞吐量高；采用日志ELK存储与检索，可随时随地排查分析系统缺陷；采用RESTful服务接口，对接简单。

[0032] 所述基础模型数据存储与检索包括数据存储及数据检索；所述数据存储包括基础模型数据存储、计算结果及中间结果数据存储、游客行为数据存储，所述基础模型数据存储按具体划分的表结构存放于mysql（一个关系型数据库管理系统）数据库，所述计算结果及中间结果数据存储存放于redis内存数据库，所述游客行为数据存储存放于hbase（一个分布式的、面向列的开源数据库）列式大数据存储方案数据库；
所述数据检索按照优先redis内存数据库检索为原则，其次是mysql数据库，hbase列式大数据存储方案数据库不直接检索结果数据，hbase列式大数据存储方案数据库为数据分析的源，其分析计算结果存放于mysql数据库中。

[0033] 所述景区模型包括景区基础信息、景点信息、景区设备、酒店及景区联营店铺的细分组合；所述景区运营管理人员模型包括景区管理人员、职位基础员工、外包临时人员的细分组合，所述景区管理人员为总经理以及各职能部门主管；所述职位基础员工包括导游、设备操作员、拓展教练、演员、游览车司机、卫生清洁员、财务人员、保安；
所述游客模型包括游客基本信息、游客行为信息的细分组合。所述游客基本信息包括姓名、手机号、身份证、年龄、性别、职业、常住地址，所述游客行为信息包括购票渠道来源、来源地、团队或散客的游客性质、景区游玩轨迹。

[0034] 所述智慧景区基础数据领域模型的相互依赖关系包括景区与景区运营人员依赖、游客与景区关联依赖、景区运营人员与游客间接依赖，所述景区与景区运营人员依赖包括特定岗位的运营人员与景区设备关联依赖，设施设备与景点信息依赖，所述游客与景区关联依赖包括游客到访的景区关联、游客与景区景点关联依赖信息、游客与景区设备信息关联依赖，所述景区运营人员与游客间接依赖为通过景区建立的景区运营人员和游客之间的依赖。

[0035] 景区、景区运营管理人员及游客可以通过系统用户登录进入所述WEB UI，所述WEB UI默认显示常用云应用、帮助文档、控制中心、常用应用功能快捷，所述控制中心为用户与操作系统界面交互的主要部件，其功能涵盖应用管理、组织管理、人员管理、系统资源管理、菜单管理、权限管理、景区基础信息管理。

[0036] 如图2所示，所述智慧景区操作系统具有包括组织部门管理、应用管理、用户管理、角色定义、角色权限定义、用户授权与认证、统一鉴权、共享对象api功能模块、服务注册与发现模块、统一配置中心、统一部署运维方案、缓存/消息中间件/文件系统通用组件、前后端应用研发脚手架框架的功能。

[0037] 如图3所示，组织（各个景区）操作系统集成应用所述智慧景区操作系统的方法包括如下步骤：步骤S1、可视化操作创建应用；
步骤S2、创建应用功能菜单；
步骤S3、创建用户角色模板和权限定义；
步骤S4、判断组织用户是否第一次接入应用，如果是，为组织批量实施化应用，如果否，在组织原有系统上更新添加应用。

[0038] 采用本发明能达到的技术效果有：本发明采用企业中后台概念，为各系统提供一个稳定的后台服务，打通景区各智慧系统，使系统的数据上游和下游各服务之间能够互联互通，相互响应。其次为后续研发的系统接入提供一个统一的接入方式，包含前端和后台系统的接入方式。产品设计理念一致、风格统一用户界面，减少用户学习成本，提高用户的工作效率。能够在互联互通的数据基础上为景区提供全方位的经营分析指标。全方位打造智慧景区操作系统，后续研发的系统可以完美的对接安装在此操作系统上方便接入，减少工作量，提升系统整体稳定性。

[0039] 基于此智慧景区操作系统开发应用可以减少30%的工作量，可以有效的把整个景区体系的数据有效结合的形式一套完整的数据池；基于此智慧景区操作系统研发的应用具有一致的UI组件、UI风格，能够享受用户、权限、共享对象等开箱即用API的便利性。

[0040] 此智慧景区操作系统具有数据处理的功能，能给景区提供数据参考，能准确的预测未来的时间段的景区运营情况，包括入园人数预测、财务收入预测、餐饮食材量预测、酒店客房预订数量预测、景区服务工作人员数量预测，为景区及景区工作人员的工作提供便利。

[0041] 以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。