智慧旅游公共服务平台运营支持中心方案.docx

智慧旅游公共服务平台运营支持中心方案.docx

《智慧旅游公共服务平台运营支持中心方案.docx》由会员分享，可在线阅读，更多相关《智慧旅游公共服务平台运营支持中心方案.docx（14页珍藏版）》请在冰豆网上搜索。

智慧旅游公共服务平台运营支持中心方案

智慧旅游公共服务平台

运营支持中心方案

目录

1.项目建设背景3

2.智慧旅游运营支撑中心方案4

2.1.智慧旅游公共服务平台运营支撑基础架构的需求分析4

2.2.智慧旅游公共服务平台的运营支撑中心4

2.3.智慧旅游公共服务平台的核心基础架构整体设计5

2.4.数据中心站点内的部署结构7

2.5.数据中心外的部署结构132

2.6.整体运维方案133

2.7.安全架构设计135

2.8.业务连续性的设计136

2.8.1.业务连续性的需求138

2.8.2.业务连续性的模式设计138

1.项目建设背景

智慧旅游来源于“智慧地球（SmarterPlanet）”及其在中国实践的“智慧城市（SmarterCities）”。

2008年国际商用机器公司（InternationalBusinessMachine，IBM）首先提出了“智慧地球”概念，指出智慧地球的核心是以一种更智慧的方法通过利用新一代信息技术来改变政府、公司和人们相互交互的方式，以便提高交互的明确性、效率、灵活性和响应速度。

由此，“智慧的城市”、“智慧的企业”与“智慧的行业”等概念应运而生。

全世界的企业和政府都对“智慧”产生了自己的认识和理解。

旅游业是高关联度、高综合拉动性的产业。

它是集交通、旅行社、景区景点、饭店宾馆、餐饮、商业、娱乐、金融投资、房地产等产业为一体的产业群。

考虑智慧的旅游公共服务平台的建设，就必须对满足当前及未来游客，经营者，市场管理者的综合需求，从引导和打造更加智慧的的产业链角度，以创新的国家级智慧旅游公共服务平台这种形式为整个生态体系进行服务。

获得国内领域的良好实践后，未来可以考虑向全球提供服务和体系的输出。

本项目旨在建立旅游行业的一体化信息服务平台，通过构建游客服务网站平台、智慧旅游景区（点）信息亭及智慧旅游智能终端应用等工具，实现针对游客的旅游信息服务和旅游体验表达，服务游客结伴出行、紧急救助等业务需求。

系统按照SoLoCoMo（Social-Local-Communication-Mobile，社交-本地-沟通-移动）模式构建，全面提升游客旅游体验与旅行品质。

通过游客服务网站平台（So），实现游客出行前信息检索、结伴出游、辅助游客完成票务预订等；通过智慧旅游信息亭（Lo）和智能终端（Mo）的交互应用，实现智能导览、紧急求助、旅游感受发布等，并通过位置服务等功能，实现同伴位置检索及网上互动；利用Wiki方式，发动游客参与，严格审核，维护针对景区（点）的唯一、权威的旅行攻略信息，满足游客行程规划及旅行过程中的旅游辅助需要。

最后，构建涵盖旅游政府主管部门、旅游景区、旅游服务机构和游客的沟通（Co）体系让游客与管理者、经营者可以随时互动，并实现与目前广泛使用的通用微薄平台的互连与同步，为旅游活动相关主体提供网上信息发布与在线交互的实时联动平台。

2.智慧旅游运营支撑中心方案

2.1.智慧旅游公共服务平台运营支撑基础架构的需求分析

为了快速构建以上各种平台以满足业务功能的建设，运营和扩张，更好的支撑智慧旅游业务的经营，需要高等级基础架构平台进行支撑。

根据旅游行业的特点，我们建议采用云化的基础架构进行支撑。

同时，采用双活/多活架构来满足业务连续性和客户体验的要求。

旅游产业自身是综合性服务产业，同时旅游产业与其他产业的正在不断的深度融合，这就要求要求智慧旅游的基础架构平台要能与未来城市与社会服务的对接能力要能够支撑未来20年的发展需求，根据最佳实践，按需建设的业务需要云化的基础架构。

旅游行业具有季节性、周期性，作为行业平台，需要按需扩展的计算能力进行支撑，这就必须采用先进的云化建设模式来满足业务高峰期的处理能力。

旅游行业的客户体验具有跨地域特点，同时考虑途体验和地域体验，需要平台能够为整个过程提供一致的漫游体验。

因此，需要考虑在全国进行业务能

力的建设，初期计划使用双活的运营支撑中心设计来满足南北大区客户的需求。

后期采用多活的运营支撑中心及本地计算节点来进行扩展。

同时，我们也应充分考虑未来旅游业务模式的不断创新的必然性。

考虑平台必须具有扩展性。

体现在采用主流的技术平台，建设之初即具备良好的横向和纵向的扩展能力。

2.2.智慧旅游公共服务平台的运营支撑中心

根据国家智慧旅游公共服务平台的总体建设规划，对运营支撑中心进行阶段性设计。

在北京和上海运营支撑的功能架构设计：

对应北京和上海两个站点，根据大型运营支撑中心的最佳实践，除了基础架构的建设外，对运营支撑的功能进行设计。

2.3.智慧旅游公共服务平台的核心基础架构整体设计

智慧旅游基础架构平台的整体架构设计：

在初期建设中，采用南-北双活的运营支撑中心结构来满足整个中国的业务需求，具体的来说，根据项目建设方案，按照北京-上海的顺序建设基础架构平台，运营支撑的组织和相关制度流程，完成总控平台的建设。

在北京-上海的的支撑中心投产后，根据业务扩展的要求，在全国建立分布式的运营中心。

在大型景区和信息聚集区，建立网关式的信息节点，来满足近端计算和数据交换的要求。

•集中监控模块将各数据中心的运行状态进行汇总并实现部分自动化操作

•负载均衡模块将交易、浏览请求发送至正确的处理节点并将结果送回客户端

•数据复制模块在数据中心间维持数据的一致性

•数据中心间软硬件、网络配置一致，同时通过软件分发机制及工具维持版本管理

•跨中心的变更管理、问题管理流程和工具支持

技术构架模式上，采用以POD为建设单位的标准化建设机制，每个POD是一个标准的交付单元，便于建设，管理和运营：

2.4.数据中心站点内的部署结构

多活数据中心的整体网络架构实现：

在数据中心的内部，根据业务要求，需要划分如下逻辑区域：

1）测试区

2）核心生产区域

3）DMZ区域

4）管理区域

5）存储区域

合理的逻辑分区保证了业务的有序开展。

2.5.数据中心外的部署结构

CDN内容加速网络的建设也是保证海量客户体验的基础，拟在初期建设阶段完成后，在后续阶段完成国内CDN节点的部署。

CDN服务以多媒体视频为例：

考虑国外访问的需求，在国内CDN网络建成后，将前端业务平台扩展到国外。

同时完成与国际平台（B2B对接，O2O平台对接，支付平台与渠道对接，其他行业应用平台对接）的整合。

拟采用IBMSoftlayer平台完成国外的平台承载能力：

2.6.整体运维方案

初期拟在在北京运营中心设立集中的运维管理中心，同时，在上海中心设立现场运维管理团队。

通过7*24*365的不间断运维，满足业务的安全稳定运行。

运维保障体系是运维工作是否能够满足未来业务快速扩张的必要建设内容，根据行业最佳实践，主要应该考虑四个方面：

●人员组织

●管理制度和流程

●技术平台和技术环境

●信息与管理

职能团队包括云管理平台管理岗、生产运行支持岗、服务台管理岗、值班经理岗、生产运行监控岗、运维体系管理岗、景点运行支持管理岗、流程管理岗、数据库管理岗、操

作系统管理岗、备份与存储管理岗、中间件维护岗、硬件设备与配置管理岗、机房值班岗、网络规划岗、网络运维管理岗、运维平台开发维护岗、前端技术维护岗、基础设施管理岗、异地灾备运维岗、灾备演练管理岗

流程制度方面，完成业务交付支撑，应用管理，IT基础设施管理和产品支撑方面的建。

根据ISO20000标准的要求，建设13个标准的运维管理流程和职能：

技术平台和环境部分，建设包括“监，管，控，分析”的技术平台，建设控制中心的运营环境：

2.7.安全架构设计

在云环境下，安全管控将发生如下变化：

在本解决方案中，将基于ISF（IBMSecurityFramework）进行安全架构设计：

其中，“基于云的服务与管理”指智慧旅游公共云提供的公共云安全服务。

本项目将进行适当评估这些云服务的必要性，并进行整合分析。

具体而言，将在如下层面实现安全：

✓终端网络

✓业务接口

✓资源池：

✓云计算管理平台：

✓数据中心：

2.8.业务连续性的设计

可以预见，智慧旅游公共服务平台将在未来融入中国社会的重要信息化支撑体系，其信息系统的安全将会直接影响到国民经济的正常运行，直接关系到社会稳定和群众生活。

我国信息安全的防护能力较弱，安全保障水平不高，就信息化平台来说，建立统一的灾难恢复和业务连续性管理机制，信息安全和灾难恢复工作是必须考虑的需求。

智慧旅游公共服务平台采用双活/多活的基础架构设计，在建设时，充分考虑了业务连续性的设计。

在业务连续和容灾备份建设中，以下几个概念非常重要，它们也是衡量业务持续以及容灾备份需求的指标。

恢复时间目标（RTO）

恢复时间目标（RecoveryTimeObjective，简称RTO）是指信息系统突发事件发生后，从信息系统故障导致业务停顿时刻开始，到信息系统恢复至可支持各部门运作、业务恢复运营之时，此两点之间的时间段称为RTO。

一般而言，RTO时间越短，即意味要求在更短的时间内恢复业务至可使用状态。

虽然从管理的角度而言，RTO时间越短越好，但是，这同时也意味着更多成本的投入。

RTO目标的确定可以用下图来说明：

图RTO指标

恢复点目标（RPO）

恢复点目标（RecoveryPointObjective，简称RPO）是指对系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。

这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。

与RTO目标不同，RPO目标的确定不是依赖于企业业务规模，而是取决于企业业务的性质和业务操作对数据的依赖程度。

因此，RPO目标对相同行业的企业而言会有些接近，而对于不同行业的企业来说仍可能会有较大差距。

2.8.1.业务连续性的需求

业务连续性有如下的建设需求

Ø考虑资源整合和架构优化，逐步按照生产、查询、公共服务、交换等多种专业分区管理，形成南北中心一体化基础架构和运维支持专业体系；

Ø防范可能的不同级别的灾难的发生（设备、机房、区域性等）成为目前风险防范的重点；

Ø需要制定成体系的、规范的灾难恢复制度和计划；

Ø需要建设规范的、有清晰责任定义的灾难恢复管理组织；

Ø灾备机制需要针对核心生产进行有计划的演练，以确保灾备中心的真实可用。

2.8.2.业务连续性的模式设计

1、灾备工作模式

常见的灾备工作模式主要有两种，即主备模式和双活模式；主备模式是灾备中心处于备份接管状态，不对外提供服务；双活模式是灾备中心承担对外服务功能，通常需要远程集群处理技术支持。

本次项目建设的模式的双活模式。

该模式在系统建设开始时同步考虑灾备的实现，即北方生产中心对客户提供服务的同时，南方生产中心同时为客户提供服务。

系统具有如下特点：

▪高可用性最佳实践

▪所有数据中心均为生产中心

▪无需计划停机维护窗口

▪完全杜绝数据中心灾难、网络故障对生产的停顿影响，无需通常意义上的灾难切换过程

▪所有数据中心完全配置一致

▪全局动态负载均衡

▪绝大部分非计划性停机故障可由双中心架构自行屏蔽对应用影响

▪与网银类似的B/S类型应用架构，三层模型在计划内维护的场景下：

▪“滚动式计划停机”

▪对数据中心的重大计划内维护可以在正常工作时间完成-由最好的技术资源支持

▪广播通知计划停机信息

▪将计划维护的数据中心从生产处理候选列表摘除

▪停止应用、数据库等运行

▪实施所需的任何维护操作

▪应用重新启动