智能餐厅项目方案建议书.docx

智能餐厅项目方案建议书.docx

《智能餐厅项目方案建议书.docx》由会员分享，可在线阅读，更多相关《智能餐厅项目方案建议书.docx（33页珍藏版）》请在冰点文库上搜索。

智能餐厅项目方案建议书

智能餐厅项目建设

方案建议书

2021年5月27日

XXXXIP专有信息声明

本文档中的所有信息均为XXXXIP机密信息。

未经版权限定以及XXXXIP公司明确作出的书面许可，不得为任何目的、以任何形式或手段（包括电子、机械、复印、录音或其他形式）对本文档的任何部分进行复制、存储、引入检索系统或者传播。

尽管XXXXIP已经尽力使本文档的内容全面准确，但仍可能有技术方面不够准确的地方或印刷错误。

此处的信息将被不定期修改；这些信息将包含在本文档的未来版本中。

XXXXIP是XXXX的注册商标。

本文档提及的其他公司、产品和服务的名称，可能是其他公司的商标或服务的标志。

Copyright©2018XXXXIPCoporation

Allrightsreserved

文档信息

文档名称

XXXX智能餐厅建设技术方案建议书

作者

研发支撑中心智能餐厅项目组

类别

方案建议书

编号

文件名称

XXXX智能餐厅建设技术方案建议书V1.0.doc

文件说明

修订历史（REVISIONHISTORY）

版本

日期

章节

类型

作者

摘要

V1.0

2018-02-07

所有

创建

内容范围

本文档的目的是为XXXX（以下简称“智能产品分公司”）智能餐厅建设技术方案建议书。

适用的对象

本文档仅适用于负责系统建设的相关人员。

1概述

1.1项目目标

智能餐厅由APP点餐、刷脸识别系统、员工信息营养成分显示、阳光食堂和智能分盘机等模块组成。

集成了一系列智能化、自助化的应用设备和软件，打造刷脸就餐、智能分盘的智能化、现代化的餐厅，保证了餐具的安全卫生，实现了厨房精准备餐和综合财务的高效管理，提升餐厅各环节的服务效率和响应速度，有效降低人工、管理成本，提升员工就餐体验，实现员工关爱，提高工作与生活质量。

为贯彻公司11236发展方向，落实30+1、60+1、90+1的生态共享的营销模式。

当前的智能餐厅功能模块，还不能满足不同的企业餐厅的需求。

拟定XXXX智能餐厅增加软件功能模块、打造硬件产品链、丰富营销套餐包。

1.1.1手机订餐精准备餐

员工可通过手机APP、微信端随时随地订餐，食堂根据订餐数量精准备餐，确保有量有节，可极大节省食堂经营成本。

  通过提前预订将选餐步骤前移，省去选餐排队时间，缩减领餐时间，大幅提升用餐体验，提升食堂服务能力。

1.1.2人脸识别无卡就餐

员工就餐时采用人脸识别，刷脸就餐的方式。

不用拥挤排队，随到随刷，无需刷卡监督，节省人力成本，提升就餐体验。

1.1.3健康饮食营养分析

人脸识别后，通过内外双屏幕终端显示就餐人信息，包括人员信息、余额、套餐内容及所选套餐的摄入能量和营养成分。

同时联动智能分盘机，进行餐盘分发。

1.1.4刷脸就餐智能分盘

  智能人脸识别分盘机，由公司自主原创组合发明。

目前在国内是首例。

已开始同时申请国家发明专利和实用新型两项专利。

  主要技术采用人脸识别仪刷脸后，上传到服务器。

再由服务器进行订餐逻辑判断后，推送给双屏终端机展示用户信息。

双屏终端下发指令给TCP网络开关量来控制分盘机，完成整个刷脸分盘的流程。

  采用智能分盘机可避免就餐人员的混乱、维护餐厅就餐秩序。

设备自带消毒杀菌系统，整个过程没有就餐者之外人员接触餐盘，保证餐盘的卫生。

并且可大幅节约人工的成本。

内部的器件也是完全使用食品、医疗级。

1.1.5阳光食堂透明厨房

 厨房设有直播摄像头，全过程动态视频监管。

员工通过微信、手机SRMS可随时观看食堂食品的加工和制作过程的直播，实现食堂透明化。

1.1.6数据分析高效管理

系统自动生成订餐明细、消费明细、财务结算、食堂就餐情况分析等数据报表，食堂管理者可通过后台管理系统实时查看食堂运营情况，为食堂经营决策提供重要依据，提高管理效率。

1.2业务需求

1.2.1系统功能

SRMS项目功能包括以下几个组成部分：

功能类别

子功能

描述

企业管理

企业管理

企业地点管理

企业联系人管理

企业银行帐号管理

餐厅管理

餐厅管理功能

餐补设置

订餐就餐时间设置

分时就餐时间设置

设备管理

设备管理

菜品管理

菜品管理

食物品类管理功能

食材管理功能

食材种类管理

套餐费用管理

菜品发布管理

菜品设备管理

菜品发布明细管理

订单管理

订单支付管理

订单管理

订单详情管理

用户管理

微信用户管理

微信用户绑定

来访人员管理

用户就餐配置管理

充值管理

我的帐号管理

用户明细账单管理

评价管理

评价管理

留言管理

留言管理

点赞管理

供应链管理

供应商管理

供应商地点管理

供应商联系人管理

供应商银行帐号管理

物料管理

物料类别管理

采购订单管理

采购订单行管理

采购订单发运信息管理

采购订单分配信息管理

采购订单支付管理

物料入库管理

物料出库管理

统计分析

就餐人数统计

菜品评价统计

营养动态

内容管理

系统框架内容管理

首页设置

1.2.2功能架构

SRMS系统功能架构图如下：

2总体方案设计

2.1方案设计原则

2.1.1架构设计原则

Ø可扩展性：

优良的体系结构设计对于系统是否能够适应将来新业务的发展至关重要。

在满足现有需求的基础上，XXXXIP还考虑到系统应当有充分的可扩展性，以满足未来的业务发展。

因此，在XXXXIP的方案设计中，所有推荐的产品均考虑到应用逐步丰富、系统不断扩展的要求，以形成一个易于管理、可持续发展的体系结构。

同时将应用系统进行完全模块化的设计，使系统具有良好的扩展性和高效性。

Ø先进性：

设计方案中采用市场领先并成熟的技术，使项目具备国内同业领先的地位。

Ø成熟性：

XXXXIP公司提供的产品都是经过了市场的考验。

也经过了大量的市场实践的检验。

Ø标准性和开放性：

在计算机领域内，有很多国际或行业标准是由XXXXIP公司首创和建立的，因此XXXXIP的产品始终严格遵守国际标准，在还没有形成标准的新领域内也积极倡导标准的形成。

在本项目建议书中建议的产品包括XXXXIP公司以及第三方厂商的产品，从网络协议到操作系统，全部遵循通用的国际或行业标准。

开放的系统平台便于将来增加新的功能及与第三方的接口

Ø系统集成性：

XXXXIP非常愿意为贵公司提供总包式的系统集成服务，使贵公司无需花费过多的精力从事于不同系统平台的集成，而将精力集中到整体的业务运动和新业务的开发和推广中，从时间和进度上促进本项目的成功。

XXXXIP公司的国际地位、综合整体实力、完善的培训、维修与服务等都将成为我们对客户的长期承诺的保证基础，XXXXIP公司非常愿意为客户智能餐厅系统项目的成功付出最大的努力。

Ø数据格式的统一和准确性：

应采用业界公认的数据交换标准，对系统中各种类型的数据和信息进行定义、封装、传送和解释。

应遵循信息平台的整体规划、整体建设、整体管理的原则，包括：

统一的系统功能规划；统一的数据展现规划；统一的界面设计等。

同时由于法律和财务对数据要求的严格，因此应保证数据处理和数据服务过程的准确率。

Ø安全性原则：

首先是数据传输的安全。

系统中采用IPSec传输确保安全性。

其次是数据的使用权限。

再次是病毒的防护和数据备份和恢复，系统也进行了充分考虑，给出了相应的解决方案。

2.2系统总体逻辑架构

我们采用分层的方法来设计本方案，将上节描述的功能规划到若干层面，以确定实现这些功能的实现方式。

2.2.1展现层

展现层层分析和归纳本项目的目标用户及他们对系统的访问特征。

主要的用户包括领导和员工等。

用户通过Internet浏览器访问系统。

展现层的建设重点是清晰的界面层次、直观便捷的操作和快速的操作响应，采用Web2.0设计思想和工具实现。

2.2.2应用服务层

业务功能层为系统各类用户实现各功能模块，包括采集输入、输出展现、数据操作、数据分析及各类业务规则。

该层主要使用应用服务器中间件实现，保证应用架构的完整、清晰，在实现功能的基础上还需充分考虑易用性、扩展性等非功能性需求。

2.2.3核心数据层

核心数据层定位于存储和访问各类业务数据和系统数据，为业务功能层服务。

主要的业务数据包括企业、餐厅、厨师、菜品等相关数据、操作日志等、报表等。

该层的首要设计目标是性能、稳定和可靠。

此外，在核心数据中还提供数据备份功能的实现。

2.2.4外围系统层

外围系统层包括本方案需要实现接口和交互的其他系统，分为应用端以及APP、微信端等。

该层建设应尽量减少本方案与外围系统的耦合度，减少对外围系统的改造量和改造风险，从而使本方案未来更容易适应移动的信息化建设进一步扩展和演化。

因此，该层的建设需要采用REST轻量级的设计方法，对餐厅系统与外部系统的相关服务进行服务识别、服务建模和服务实现。

对一些建设中或规划建设中的外围系统，智能餐厅系统可从多种接口方案中选择适当的技术方式，如数据库表、数据文件、HTTP协议等进行点对点交互。

2.2.5运维管理层

运维管理层包括系统监控、系统安全管理、及系统备份管理。

主要用户是IT管理人员。

该层的建设应力求本系统融入移动的网管体系。

3系统总体物理架构

根据上述的业务功能、架构设计原则、功能架构和逻辑架构，我们设计了本方案的物理架构参考图如下：

本方案的物理部署需考虑三个网络环境：

办公环境、开发测试环境和生产环境。

办公环境是用户使用本方案的主要环境，用户主要通过HTTP/HTTPS和远程桌面方式访问生产环境。

开发、测试人员使用开发测试环境建设、调试本方案，在系统上线后进行后继开发。

开发测试环境原则上无须连接生产环境。

办公环境和开发测试环境的建设暂不详叙。

生产环境是本方案的目标运行环境，主要包括以下设备节点：

设备节点

功能

应用服务器

应用服务器用于运行智能餐厅系统主要模块的业务逻辑，并提供前台展现页面的生成、采集用户输入、处理结果反馈的功能。

应用服务器和数据库服务器是互为备份的，一台服务器发生故障时由另一台服务器接管IP、共享存储和启动应用模块。

数据库服务器

应用服务器和数据库服务器是互为备份的，一台服务器发生故障时由另一台服务器接管IP、共享存储和启动应用模块。

以下资源使用集团私有云资源，不需要特别申请说明：

磁盘阵列

磁盘阵列为数据库服务器提供虚拟化、集中化的可靠数据存储。

磁带库

磁带库用于提供大容量、低成本且易于转移、存放的数据备份。

以太网交换机

以太网交换机用于连接应用服务器、数据库服务器。

光纤交换机

光纤交换机用于连接数据库服务器、磁盘阵列和磁带库。

防火墙

使用防火墙，分别隔离核心服务器和存储设备，并合理配置访问许可和阻止策略，来保护生产环境。

4应用解决方案

4.1应用总体架构框图

4.1.1应用架构分层设计说明

应用平台采用J2EE的标准5层架构实现，即客户端，表现层，业务层，集成层和资源层，并进行了一定拓展。

具体说明如下：

1、客户端：

提供Web应用给最终用户使用。

Web客户端采用Http/Https协议和表现层通信。

Web客户端采用AJAX技术组件，实现丰富的客户端操作控件、页面的局部刷新和后台同步，以加速用户操作响应，提升用户体验。

2、表现层：

提供和客户端的交互。

使用前端控制器和应用控制器进行统一应用接入和Action和View的选择与调度。

需要具备服务器端输入验证，提供协议无关的Context对象和JSP组件。

3、业务逻辑层：

业务逻辑层是整个统一信息管理系统的核心模块，实现所有的业务逻辑。

本层主要包括4种组件，即：

◆业务Facade提供统一的业务服务调用，包括提供给表现层和WebServices或者JMS的调用。

◆业务流程对象封装业务流程逻辑

◆业务组件对象封装一个业务功能

◆业务对象封装业务模型数据。

4、集成层：

封装和外部资源的通信。

主要提供4种类型的集成，即

◆数据集成，封装数据访问，例如数据库，文件和LDAP访问；

◆服务集成，封装对BPM引擎等其他服务组件的访问，将智能餐厅系统对外提供的服务暴露到企业接口平台；

◆消息集成，封装和中间件的通信，如Tomcat等；

5、资源层：

系统的外部资源。

对于集成层，同时具有4种类型的资源

◆数据源资源；

◆服务资源（WebService）；

◆消息资源（ESB引擎）；

◆应用资源。

6、基础服务：

对表现层，业务逻辑层，集成层提供公共的服务，主要包括缓存服务，传输对象，文件日志，数据库日志，权限管理，事务管理，任务调度模块等。

4.1.2智能餐厅系统功能架构

智能餐厅总体结构如下图所示：

4.1.2.1APP、微信端

智能餐厅APP、微信端功能如下图所示：

4.1.2.2中移智能餐厅云平台

4.1.2.3企业管理平台

4.1.2.4供应链管理

5安全解决方案

5.1系统安全性考虑

XXXXIP认为“安全”概念应该是一个从头至尾端到端的需求，它涵盖于任何信息技术项目的所谓的PACO周期，即“规划–设计-建设-运营”（Plan-Assess-Construct-Operate）周期中，既不仅仅是某时某刻的需求，更不仅仅是通常过分着重强调的防火墙或操作系统所能满足的。

下图为XXXXIP对安全的整体考虑的框架图：

举一个例子也许能更好地说明XXXXIP对于安全的观点，在此我们将安全比作是用一座水坝来防范洪水的入侵。

可想而知，水坝最弱的部分代表了整个水坝能抗御洪水的最强处，因为一旦洪水可以从此处冲垮水坝，其余再强的部分也形同虚设。

同样道理，如果我们将软件和硬件产品看作是安全水坝的组成一部分，保护系统安全最重要的组成部分其实是安全策略（SecurityPolicy）、安全标准（SecurityStandard）、安全处理过程（SecurityProcess）以及持续的安全审计（SecurityAudit）。

5.2安全管理

5.2.1网络安全

Ø接入安全：

在接入安全方面，我们采用防火墙的设置，保证所有经过不同网络接入方式的数据安全。

用户在接入智能餐厅平台时，需要通过防火墙才能对智能餐厅应用进行访问。

5.2.2应用安全

1.身份认证︰根据一般企业需求，服务平台可对用户进行登录认证。

登录认证后，才可具备在网上操作相应业务的功能。

本方案中对于智能餐厅平台的身份认证建议通过与客户公司现有的统一信息平台或OA系统的LDAP身份认证进行整合，确保与统一信息平台和OA系统的单点登录同时也可以保证身份认证的有效性。

2.权限控制︰作为企业业务应用的平台，本方案通过对用户、用户组、功能应用的权限控制，提供一完整的应用层面权限控制功能。

3.数据库日志：

对于数据库实施的操作应当记入日志。

可以利用关系型数据库提供的审计功能，用来监视各用户对数据库施加的动作。

有两种方式的审计，即用户审计和系统审计。

用户审计时，数据库审计系统记下所有对自己表或视图进行访问的企图（包括成功的和不成功的）及每次操作的用户名、时间、操作代码等信息。

这些信息一般都被记录在数据字典（系统表）之中，利用这些信息用户可以进行审计分析。

系统审计由系统管理员进行，其审计内容主要是系统一级命令以及数据库客体的使用情况。

此外，通过把数据库的日志送到安全日志收集中心，可进行统一的日志收集和审计。

5.2.3数据安全

随着信息化程度的提高，数据逐渐成为企业最有价值的资产，成为企业对市场动态准确把握的代表。

任何一个运行的应用都会和数据有关，例如：

数据的采集、存储、变更，以及从数据库管理系统中重新抽取数据。

因此，数据库在企业中作用日益重要。

特别是对于企业，业务流程已经完全实现信息化，所有的业务数据全部依赖于数据库。

一个稳定、高效、安全的数据库对企业意义重大。

数据库安全主要从数据库的管理上进行加强。

业界主流的数据库产品自身提供了许多安全功能，应当充分合理利用这些功能。

客户应制定完善的数据库安全计划来保障数据库的安全。

数据库安全主要从以下几方面进行考虑：

5.2.4数据库物理安全

在数据库物理存储上将按照移动制定的相应的安全政策，来管理报账平台数据库本身所依存的硬件、及其存放场所的物理安全。

5.2.5用户分类

对于移动报账平台系统数据库的用户或者应用，必须定义允许谁访问实例和数据库。

用户权限都应当按照业务需求进行分类，不同类型的用户授予不同的数据库访问权限。

可以将数据库用户分为三大类：

数据库查询权限类、资源管理权限类和数据库管理员权限类。

数据库查询权限：

具有这类权限的用户可以登录数据库，查询部分数据资源、创建视图等。

这类用户只能查阅部分数据库信息，不能修改数据库。

资源管理权限类：

除了拥有上一类的用户权限外，还有创建数据库表、索引等数据库客体的权限，可以在权限允许的范围内修改、查询数据库，还能将自己拥有的权限授予其他用户，可以申请审计。

数据库管理员：

有数据库管理员权限的用户将具有数据库管理的一切权限，包括访问任何用户的任何数据，授予（或回收）用户的各种权限，创建各种数据库客体，完成数据库的备份、装入重组以及进行全系统的审计等工作。

这类用户的工作是谨慎而带全局性的工作，应当只给专职的数据库管理员授予此权限，并且经过严格的审批程序。

5.2.6数据库日志

对于数据库实施的操作应当记入日志。

可以利用关系型数据库提供的审计功能，用来监视各用户对数据库施加的动作。

有两种方式的审计，即用户审计和系统审计。

用户审计时，数据库审计系统记下所有对自己表或视图进行访问的企图（包括成功的和不成功的）及每次操作的用户名、时间、操作代码等信息。

这些信息一般都被记录在数据字典（系统表）之中，利用这些信息用户可以进行审计分析。

系统审计由系统管理员进行，其审计内容主要是系统一级命令以及数据库客体的使用情况。

此外，通过把数据库的日志送到安全日志收集中心，可进行统一的日志收集和审计。

6平台配置建议

6.1平台配置概述

在本方案建议书中我们设计了智能餐厅系统的物理架构，在物理架构中我们根据服务的领域可以非常清晰的划分出服务领域。

根据上面的服务领域我们可以为每个服务领域进行产品选型，根据智能餐厅系统的特点进行评估。

我们认为主要包含以下几大服务领域：

◆负载均衡服务，提供智能餐厅系统负载均衡；

◆中间件应用服务，提供智能餐厅系统的业务逻辑处理；

◆数据库服务，提供数据库存储、查询和计算服务；

◆安全服务，提供系统级的安全防护，漏洞扫描和防病毒服务，集团私有云资源提供；

◆存储备份服务，提供信息的存储和备份服务，集团私有云资源提供；

◆网络服务，提供网络和防火墙服务，集团私有云资源提供。

根据物理架构的设计，对于智能餐厅系统需要具备以下设备：

名称

序号

设备名称

数量

单位

备注

核心应用设备

1

负载均衡服务器

1

套

2

应用服务器

1

套

3

数据库服务器

1

套

4

应用服务器平台软件

1

套

5

数据库软件

1

套

存储备份设备

1

SAN光纤交换机

2

台

私有云平台不需要

2

磁盘阵列

1

台

3

磁带库

1

台

4

备份软件

1

套

网络设备

1

3层网络交换机

2

台

私有云平台不需要

2

防火墙

2

台

开发测试

1

开发测试服务器

2

台

其他

1

机柜

1

台

具体资源配置信息如下表所示：

主机名

资源类型

操作系统信息

计算资源

网络需求

存储需求

系统类型及版本

CPU数

（小于16）

内存（G）

硬盘（G）

是否访问外网

网络域

存储类型

存储大小

srms-web1

虚拟机

CentOS-6.8-x86_64

8核

32

200

否

DMZ

NFS

2T

srms-web2

虚拟机

CentOS-6.8-x86_64

8核

32

200

否

DMZ

srms-app1

虚拟机

CentOS-6.8-x86_64

8核

32

200

否

核心区

srms-app2

虚拟机

CentOS-6.8-x86_64

8核

32

200

否

核心区

srms-app3

虚拟机

CentOS-6.8-x86_64x86-64

8核

32

200

否

核心区

srms-app4

虚拟机

CentOS-6.8-x86_64

8核

32

200

否

核心区

srms-db1

虚拟机

CentOS-6.8-x86_64

16核

64

200

否

核心区

srms-db2

虚拟机

CentOS-6.8-x86_64

16核

64

200

否

核心区

6.2主机配置评估

6.2.1主机设备估算

6.2.1.1主机设备估算依据

对于主机的配置主要是包括在以下服务领域的主机型号和主机软件配置建议

Ø负载均衡、静态资源服务领域：

Ø中间件服务领域；

Ø数据库服务领域；

因此，在智能餐厅需要作性能估算的有两个关键环节：

应用服务器，数据库服务器。

Ø中间件应用服务器

对于应用服务器，在典型的OLTP（联机交易处理）系统环境下，主要的负载是业务逻辑计算，所以其主要的性能估算指标是tpmC（每分钟处理的交易笔数）。

估算的前提输入参数

变量名

最大并发用户数（从…到…）

parUser

假设并发用户中同时操作的用户所占百分比

parPercent

最大响应时间（秒）

maxRespond

平均思考时间（秒）

avThink

假设每次访问包含的交易数（从…到…）

perTrans1,perTrans2

每个交易折算标准交易系数（从…到…）

tranQuo1,tranQuo2

系统要保持的高峰期利用率

utilRate

估算公式

tpmC=parUserxparPercentx（60/（maxRespond+avThink））x（（perTrans1+perTrans2）/2）x（（tranQuo1+tranQuo2）/2）/utilRate

Ø数据库服务器

对于数据库服务器，在典型的OLTP（联机交易处理）系统环境下，主要的负载是数据库计算，所以其主要的性能估算指标是tpmC（每分钟处理的交易笔数）。

估的前提输入参数

变量名

最大并发用户数（从…到…）

parUser

假设并发用户中同时操作的用户所占百分比

parPercent

最大响应时间（秒）

maxRespond

平均思考时间（秒）

avThink

假设应用服务器的并发用户数中需访问数据库的百分比

tranPercent

假设每次访问包含的交易数（从…到…）

perTrans1,perTrans2

每个交易折算标准交易系数（从…到…）

tranQuo1,tranQuo2

系统要保持的高峰期利用率

utilR