职业类 > 旅游 > OTA > 酒店项目重构方案
酒店项目重构方案
IT老兵    2016-04-27 14:54:11     浏览()   回复()    点赞(0)   收藏(
添加收藏

酒店重构方案.png


一、 项目现状
酒店核心运营系统自2011年5月份正式上线以来,已经运行了整一年。在此过程中我
们经历了订单从十到百, 从百到千的过程。 酒店项目从起步到现在, 已经获得了很多成就和突破,发展到现在也出现很多的不足和问题。


1.1 目前最受关注的问题
1. 数据库性能问题
关注源于去年 10月份数据库瘫痪事件 , 日常查询速度比较慢 ,数据库瓶颈问题,目前能承受的并发160左右, 将是一个制约业务发展的重要问题。


1.2 现有项目物理架苟

酒店项目重组方案1.png


1.3 现有项目软件架构

酒店项目重构方案2.png


1.4 目前业务压力分布


1.从供应商获取产品数据/ EBooking 压力非常小,cpu 平均 8%,内存平均 25% , 流
量平均不到300K, 但最近上升较快

酒店项目重构方案3.png


2. 数据库服务器
Cpu:

酒店项目重构方案4.png

内存:内存使用率60% ,有优化空间

酒店项目重构方案5.png


流量: 随着时间的增加,数据量的不断增加,流量没有太大的变化但数据压力却
上升,说明数据表结构和查询存在较大优化空间,这将是我们重构的重点。大量的
压力是在读上面。


酒店项目重构方案6.png

3. 对内服务,
Cpu: 峰值过后一直压力不大,资源处于空闲状态

酒店项目重构方案7.png

流量:

酒店项目重组方案8.png


4 . 对外服务,

CPU: 最近有上升趋势

酒店项目重组方案9.png

酒店项目重构方案10.png


5. 酒店管理平台

酒店项目重构方案11.png酒店项目重组方案12.png



6. 图片服务器 , 基本无压力 ,cpu 最大6%
(注: 红色表示压力非常大, 绿色表基本没什么压力


综合分析,主要的压力在数据库服务器上,而且随着时间的推移,数据量不断上升,这个压力还会持续增加,这里将是上线以来的第一个重大瓶颈 , 这一块将是重构的重点。 对内和对外的服务上这两台机子可以整合做高可用, 不让资源闲置提高资源利用率。然后可以服务的XML静态文件统一放到图片服务器, 都是静态资源更加好管理, 再者是XML文件有的比较大容易造成IIS堵塞。
此外,考虑业务上的一些策略和业务的季节性,需要为系统考虑一些处理突发大并发和大流量的能力


二、核心业务构成与未来趋势


酒店核心运营系统定位于产品提供商、订单处理中心。即所有的分销渠道通过酒店核心获取酒店数据,同时所有订单由分销渠道、代理商通过系统接口直接到酒店运营系统中。也就是说酒店核心运营系统定位于数据检索(产品提供)、数据处理(对发布产品进行控制),不直接面对酒店的最终客户,仅面对酒店的分销渠道与代理商。


2.1 主要业务构成

    1. 供应商产品获取, 目前已经有包括艺龙、航信等多家供应商
    2. 产品查询服务 , 查询基础信息、产品价格等数据
    3. 订单服务, 给分销商下单用的
    4. 酒店管理平台 ,包括对基础信息、订单管理、返现管理、等等
    5. EBooking, 自签酒店平台


2.2 未来的业务发展趋势
    1. 对接国际酒店 , 业务数据源增加 , 需要考虑:数据结构的兼容性等
    2. 国内预付酒店等业务 , 订单流程 , 需要考虑:结合订单流程重构加入新功能
    3. 团购业务
    4. 腾付通担保
    5. 业务量上升

业务上的多样性和业务量不断逐渐增加 ,对系统的支撑能力要求越来越高


三、重构解决方案


3.1 重构关注点

这次重构主要是技术上的重构 ,我们要努力去改善项目的方面:

  � 高可用性 , 确保业务正常运营,比什么都重要。
  �安全性 , 这个是必要,也是非常重要的 , 毕竟我们系统有交易在进行。

  �性能 , 对业务的发展至关重要 , 重构不但要解决目前的性能瓶颈,还要规划未来的方向 , 我们将逐步向分布式过渡。
  �可靠性 & 鲁棒性(健壮性) , 要求项目的质量过硬可靠,在异常情况下依然健壮。
  �可扩展性 & 伸缩性 & 成本 , 架构的扩展性, 程序的扩展性,争取最大限度的适应需求的变化 , 架构可以根据业务需求的量进行物理资源伸缩配置,做到合理利用资源不造成浪费。
  �可维护性 ,程序异常之后自动通知相关人员进行及时处理,主要面向运维降低运维成本。
  � 可重用性 , 程序一些公共方法、模块、子系统到业务系统的独立解耦,让其可重用降低公司开发成本。


3.2重构的方向

先调整和优化现有软件架构和数据结构, 合理布局和使用现有硬件资源, 发挥现有硬件资源的最大性能,然后向分布式可伸缩配置的架构过渡。 简单拿数据库举个例,优化程序和数据库结构,让单台Oracle数据发挥到极致,然后数据库层面引入 Rac 或者 Master/Slave机制,在然后对服务扩容。


3.3 重构架构设计

物理架构图

酒店项目重构方案13.png

3.4主要重构项

  1. 数据库表关系的梳理和结构修改,加入冗余字段,然后数据类型的明确,然后针
    对查询建立起有效的索引,大数据量的表独立表空间。查询这一块儿的优化方向:目前的多表复杂关联查询且只有部分索引=>少量表关联通过PK和索引查询=>单表复杂查询=>单表 PK查询。 这一块牵涉到的业务模块非常多, 比较耗时间, 也是重构中最重要最基础的一步。


  2.  整合供应商管理平台,供应商数据更新全部整合进行统一管理,在现有数据生产流程中加入数据预处理, 对供应商过来的数据先入临时库, 然后进行清洗和计算之后才放入生产数据库, 保证数据的质量, 通过预先的计算可以降低后期在数据使用时的计算量,从而提高查询的速度降低对数据库的压力 , 同时降低程序的复杂程度,从而提高性能和程序的可靠性。同时提供实时更新服务和计算服务, 以满足业务上的不同需求。但这一块比较耗时间。



酒店项目重组方案14.png


    3.产品查询重构,前期优化缓存设计
如产品查询可以先缓存竞价规则计算结果 30-60s,然后配合缓存主动过期机制(修
改竞价规则就过期缓存)。采用MemCached分布式缓存设计, 让所有集群服务器共享缓存, 降低对数据库的压力。


    4. 订单业务流程梳理 ,之前为了对业务的快速响应很多代码逻辑上需要再次审查,
需产品和客户人员参与,由开发人可以从技术角度引导,最终将业务流程合理化,
包括一些异常情况的处理, 同时数据源清理之后, 然后降低程序的复杂程度, 让增
加程序可靠性和健壮性。


    5. 酒店后台权限 , 充分考虑安全性是必须要的,也是迫切需要解决的问题


    6. 引入成熟的开源方案 MemCached和 QuartZ.Net, Memcached 分布式的缓存解决方案, 适合放在集群之间公用, 同时在我们优化中查询一直是最大的压力, 这一块也将采取MemCached来做缓存,3~5s内的同参数查询直接从缓存返回。QuartZ.NET是成熟的企业级的调度解决方案, 它非常适合我们的供应商管理平台, 这个地方会有很多任务通过调度去触发。


    7. 历史数据进行持续地按时间范围地转移 , 简单举个例来说就是每隔一段时间将不
用的历史产品、 订单、 日志等数据转移到另外的数据中, 以后还可以查询, 降低现有数据库中的数据量减少数据表查询是的扫描时间。如何去做?可以在数据库上做
定时任务,也可以通过程序去做。


    8. 数据库集群,面对业务上的需求,这个是事在必行的,这一块目前常见的有两种解
决方案:
a、使用Oracle自带的RAC, 优势对程序透明,不足不利于长期发展,主要是成本和性
能的投入产出可能不一致。
b、 自己做数据复制, 可以主库到从库、 主到主、 从到从比较灵活, 但是难度较大,这种做法可以和程序或者中间件配合起来实现读写分析,可以适应大流量大并发的场景, 目前主流电子商务网站都是该解决方案。 成本上基本可控, 可以将主库放在Oracle 上,然后将从库放在Mysql节点上。


    9. 服务集群与负载均衡,目前有两台服务应用服务器,这两台是相互独立的,一台给内
网一台给外网其它分销商用的。
将服务集群有什么好处? a、性能提升,减少等待时间,合理利用闲置资源, 让高峰时
间单台压力相对平均, b、 高可用, 如果其中一台不能服务另外一台还可以访问c、
为未来业务上的突破带来技术上的保障,流量大涨的时候可以让应用服务迅速扩
容,降低压力。
如何去做? 这首先要取出服务对 Session的依赖,同时引入分布式缓存 MemCached
保存分销商的服务认证票据。然后在服务前端加入反向代理 Nginx或者F5进行路
由。这个过程中繁琐的是将服务的其它依赖移除。


    10. XML 缓存数据的定时生成 与文件同步
将生成操作做成Windows服务通过调度去触发自动生成。 XML文件同步,目前是和
服务在一起, 可以将这类文件独立出去和静态图片文件放一台服务器。以后访问量
大了在考虑服务器之间的文件同步,解决办法可以采用Windows服务器自带的DFS
方案,也可以用cwRsync软件去做。


    11. 酒店管理平台的用户体验, 操作流程的优化,界面等。


    12. 异步订单解决方案(未来规划)


待上面的重构点都完成之后,就可以开始重构订单这一块,这个主要是为今后
的业务拓展做准备,让系统能够支撑更大的订单操作量。异步订单的目的是对大量
的订单处理请求进行队列化,然后让订单处理应用服务器有条不紊的进行处理,增
加系统可靠性, 同时也增加系统的扩容能力。 方案中采用RabbitMq,一套分布式跨
平台支持多种开发语言的队列解决方案,目前在 AWS上使用,可以作为公司级别
的解决方案。


    13. 数据库读写分离与数据访问中间件开发(未来的规划)

酒店项目重组方案15.png

这是基于 Oracle的方案 , 如果考虑成本问题,可以考虑 Mysql方案。数据量随着的时间不断的增加, 数据库这一块要考虑到一个成本问题, 建议公司可以慢慢引入Mysql解决方案 ,Mysql开源、 成熟的企业级解决方案、 对服务器的配置要求较低、 一般的DBA都可以应付日常问题,特殊情况可以购买技术支持服务,Mysql现在也是Oracle旗下的。


四、重构实施


具体时间需要看项目安排,目前重构这一块是将这些非功能性需求打散放到日常开发中去做。主要需要的资源开发人员、业务人员配合、测试人员和运维人员等。


4.1 优先级别与资源预算

提示: 蓝色的字是对资源的预算, 其中: dev:开发+单元测试时间, test:测试+开发修改BUG时间, mt:运维调试配置时间, d: 单位人天 。

  1. 产品查询优化,业务逻辑梳理,代码重构,缓存策略。目前这一块的压力最大
    人力资源: dev15~20d*2+test5d

  2. 订单流程梳理和优化, 做到下单的可靠性,下单失败后台有据可查知道该如何处
    理 ,以及下单异常时的自动报警通知相关人员处理等,尽量避免订单失败客服就大量的找开发人员查问题。人力资源: dev24d*3+test10d

  3.  服务拆分(订单、产品查询、认证)以及权限认证等
    人力资源: dev10d+test5d

  4. 一些和数据结构无关的技术重构可以提前与其它重构同时进行处理,
    � 数据库的历史数据转移,这里会有一个定时 windows服务运行,可以部署到
    供应商管理平台上 。
    硬件资源:一台Oracle历史数据服务器 ,硬盘需要大一些。
    人力资源: dev5d+test2d
    � 数据库的RAC集群
    硬件资源: 一台Oracle数据服务器(需要2台Oracle 服务器,目前已经有一台)
    人力资源: mt5~10d+dev3d+test3d
    � 服务的集群 , 如果走Nginx 需要一台Linux服务器,或者F5。
    硬件资源: F5或者一台Linux服务器
    人力资源: mt5~10d+dev5d+test3d
    � Quartz.Net的引入 , 集成进一些定时程序,原来的供应商管理平台 ,
    人力资源: dev10~15d
    � MemCached的集成 , 硬件资源:一台Linux服务器

  5.  酒店后台权限(包括权限机制、登陆认证和所有页面的权限验证)等,
    人力资源: dev15d+test5d

  6.  酒店后台用户体验等, 人力资源: dev24d*3+test15d

  7.  数据源的整合, 人力资源: dev20d*1+test5d

  8. 数据清洗和数据计算服务, 人力资源: dev24d*2+test5d

  9.  其它未来的规划,以后再具体估


4.2 注意事项

  1. 重构前必须分析清楚业务逻辑、依赖和关联项 。

  2. 重构过程中因为某种原因无法继续下去了, 要及时提出问题 , 没完成重构 , 不允许提交代码。

  3. 开发阶段引入单元测试和压力测试,让开发人员规范开发习惯和及时了解重构方案选择是否合理。单元测试使用Nunit框架,比VS自带的方便,以后还可以做dailybuild,压力测试工具使用ApacheBench,简单方便。 (具体实施的时候给大家演示)

  4. 文档相关文档的目的,记录核心最有价值内容,必须有业务流程图(之前的和重构之
    后的),数据库结构(之前的和重构之后的),以及相关的数据操作脚本,较大模块要有
    模块架构设计文档。

  5. 重要模块需要先出设计文档和业务流程图以及数据库设计图,而且需要评审后方可重构。


4.3 代码重构培训与交流

这个主要是面向开发人员, 后面会有一次开发人的重构培训与交流, 这里简要提一下大概的内容:

  1. 那些代码该重构 ? 比如 重复代码 , 一个方法几百上千行代码 , 逻辑不严谨

  2. 这些代码如何处理 ?

  3. 何时应该重构 ?

  4. 何时不应该重构 ?

  5. 重构与性能


一个好的产品是运营出来的。

在运营的过程中面对业务的不断扩展和业务量的上升而不断改进与创新,其实就是一个不断重构的过程, 不同阶段发展的瓶颈都会有所不同。要做好一个项目单靠某一个人的能力是很难的,很庆幸的我们有这么大的一个团队,重构道路肯定是很艰难的,而且是漫长的,但我坚信大家共同努力一定能运营出一个好的产品。让酒店业务成为票务中支柱业务。

关注微信公众号优麦网,定时推送,福利互动精彩多多!

发表评论

分享者

相关分享