原因: 预定站点可售房型比供应商提供的房型少了80%。 预定站点可售房型重复，同一个酒店同一个房间不同供应商的可售房型重复展示，导致用 户看上去页面信息重复且混乱 现象: 系统缺乏平台化酒店的结构，导致数据结构存储不合理 系统缺乏酒店和房型的聚合逻辑，导致同一房型不同渠道的售卖信息重复展示 解决方案: 搭建平台化酒店结构，建立子母酒店、子母房型的结构，支持多供应商的数据无缝接入。 新增数据聚合逻辑，根据特定字段，将相同的酒店和房型进行聚合展示，方便用户挑选。 效果 酒店可售sku增加了70%。 酒店聚合重复渠道的可售房型，提高转化率1%。 难点: 老系统的业务逻辑梳理，并在此上面优化。 将近20亿的历史数据迁移 接口的改造，为了让兄弟团队无缝接入，需要新增一整套酒店接口的同时，把老接口也全 部做兼容。

现象: 乐享住原来是一个公司自有公寓使用的业财一体化系统，主要针对长租公寓进行成本、营 收、财务、智能设备等模块的管理。随着行业的成熟，有越来越多的企业来咨询购买系统 的需求，所以2020年开始，针对这套系统做saas商业化，针对整个市场做售卖。但是在售 卖过程中，客户需求过于定制且过多，导致技术团队的效率跟不上节奏。质量以及系统稳 定性都出现了问题。 原因: 由于系统原来仅仅针对公司内部，所以在系统架构上和数据结构上都是针对单一公司进行 设计的，接入外部客户需要的开发量比较大，作为单个项目来说，ROI极低。 功能缺失:由于系统的功能是基于原来公司内部的，所以还有很多行业标准功能缺失，也 是需要额外工作量的原因。 解决方案: 针对系统做saas化升级: 引入租户模块:针对不同客户，建立共享服务和独立数据库的架构，在每一张数据表里 都增加租户ID，利用mycat，基于租户ID分库分表，一个租户一个schema。满足不同 租户的需求，并且数据做到绝对的隔离。PC端注册默认是新建组织，为每个组织生成租 户。移动端默认注册是用户。用户可以被邀请到组织。形成账号和租户的关联。 一个用 户+一个租户可以生成一个系统账号。 引入网关+前台+中台模式:有利于不同租户对交互界面、流程引擎的个性化需求 引入可配置概念: 1、数据可配置:根据租户把字段设计成键值对的结构，方便扩展和配置。但查询性 能不高，为了增加查询性能，把真正的数据缓存在redis中。 2、功能可配置:梳理出系统的原子功能和依赖关系，保证每个功能是可单独使用、 可测试的。基于原子功能设计出功能包:把强关联的原子功能打包成功能包，使功能 具有闭环。基于销售包:把功能包按照商业意图打包成销售包。比如CRM相关模 块，打包成CRM销售包，给到售前单独售卖。 3、界面可配置:实现一个租户一个菜单，一个菜单关联多个原子功能。 4、流程可配置:引入Activity6，实现状态机和审批流的可配置。支持集团性质公司 和单体公司的审批流。支持导入公司组织架构，在系统中完成审批流的设计。 效果: 针对客户的个性化需求，提升开发效率，降低单个客户的接入时间50%。 系统稳定性达到99.99%。客户报issue数量下降了73.4%。 难点: 在saas的通用性和个性化中做好取舍 需要做好模块的划分，重点降低业务之间的耦合性 运维难度增加，需要引入一些自动化运维的组件 系统还可以设计一个paas开放平台，与飞书、钉钉、企业*或者三方组件进行集成，捆 包销售，形成一个生态平台。

现象:预定站点因为价格不一致导致预定转化率较低，仅有2.5%，低于行业平均水平。 原因: 消息积压:三方渠道的产品在推送数据量太大，每天接近一亿的时间价格数据，5分钟的 峰值达到两百万，但负责消费时间价格数据的服务器集群仅有4台服务器，消息队列服务 器仅有一套主备服务器，导致消息队列积压，无法实时消费。 解决方案: Ov9v0DQ8202207272055 针对消息积压: 整体:将消息中间件替换成kafka，提高吞吐率。并且kafka可以方便地建立分布式集 群，动态扩容。 发送端: 发送消息时，根据时间价格地时效性分级，让消费端优先消费高优先级消息。低优先 级队列可以不用实时消费，降低服务器的峰值消息量。 消费端: 扩容consumer的实例数量与主题中的分区数量一致，并且在接收消息后，把消息放 到内存队列，然后启动多业务线程，真正处理消息的业务逻辑。虽然会有丢失消息的 风险，只要不是大范围的宕机，是在业务允许的前提下可以容忍， 效果: 消息队列已经无明显积压，积压一段时间就可以被完全消费掉。 前端预定转化率上升了100%，达到了5%。 难点: 需要切换消息中间件，在前期需要做大量的吞吐率测试，来评估哪个消息中间件更适合现 有团队和业务模型。