自成立以来，途家供应链系统业务经历了多次跨越式发展，这对系统的整体架构和基础设施提出了更高要求，同时也不断驱动着技术团队深刻理解民宿业务，准确定位非标住宿行业领域模型以及高效支撑系统扩展。在这个过程中，技术团队不断思考如何在业务高速增长、可用性越来越高的背景下实现系统架构的快速有效升级？如何保证复杂业务下的研发效率与质量？本文将为大家介绍途家供应链系统的思考与实践。
民宿业务
从标准酒店到非标民宿
在线酒旅行业的发展离不开商业进步。近些年，商业变革和人们出游需求的增长为在线酒旅行业发展创造了新的机会。在线旅游的兴起也有效带动了在线酒旅行业的飞速发展，造就了携程、去哪儿网、同城艺龙、美团酒旅这样的 QTA 平台。近年来，共享商业模式的兴起，尤其是共享出行、分享住宿等场景的出现促进了共享经济的快速发展。
与传统酒旅的 QTA 平台不同，途家非标民宿具有如下特点:
库存分散：百万级 SPU 对应百万 SKU、可售库存位置均不一致。
房屋标准多样化、个性化： 房屋大小、装修风格各异。
共享民宿的发展契机
行业流程再造一般离不开两个因素：
技术方面，智能硬件与大数据应用逐步普及，人脸识别和公安系统校验提高了民宿的安全性。GPS 的快速发展与 GIS 厂商能力的不断开放，使得基于 LBS 应用的开发成本大大降低。基础设施方面，得益于国家的持续投入，移动网络质量地不断提升，成本逐年下降，间接促使智能手机几乎实现全民覆盖。
市场方面，随着消费升级和对个性化住宿及出游方式的不同诉求。
这两大因素共同促成了民宿行业的发展。对民宿行业而言，入住安全与民宿标准化是研发团队要重点解决的两大问题：
技术挑战
途家供应链系统的本质是为房客提供个性化民宿房屋，为房东提供便捷的房屋经营平台，服务于全球用户和房东的大规模民宿平台系统。技术的挑战本质上源于业务痛点，具体体现为强安全保障要求与民宿标准化要求，也同样来源如下于两个方面：
系统架构演进
途家供应链系统架构的演进过程可以分为三个阶段：
1.平台搭建阶段：业务模式探索，快速试错，如何具备快速迭代能力。
2.规模化阶段：业务成指数级增长，如何既保证业务发展，又解决系统可用性、扩展性、研发效率等问题。
3.精细化阶段：业务模式逐步成熟，运营逐步精细化，如何通过产品技术创新驱动业务发展。
平台搭建阶段
试错阶段，需要快速探索业务模式到底是不是一个方向，这个阶段不要期望很多事情都想得很清楚，用户和市场会快速反馈结果。所以，对于技术团队而言，这个阶段最主要的能力是快。抢夺市场，唯快不破。
从系统架构角度，平台搭建阶段只需要做粗粒拆解，我们按照人、物两大领域将系统做了初步服务划分，以保证后续业务领域可从这两个主领域中分离、继承。
顺便提一下当时团队的组织形式，研发团队按项目制组织，大家共同维护一套系统。由 PM、RD 共同保证开发质量，一天发布二十几次是常态。
规模化阶段
进入这个阶段，业务和产品已经得到市场的初步验证，的确找到了正确的方向。同时，业务发展增速也对研发团队的能力提出了更高要求，因为这个阶段会有大量紧急且重要的事情涌现，且系统可用性、扩展性方面的问题会逐步凸显。处理不当，就会导致系统故障频发、研发效率低下等问题，使研发疲于奔命。
这个阶段从架构层面，我们重点思考三个方面的问题：
整体架构应该如何演化？交易系统与运营系统的边界在哪里？
交易系统的可用性如何保证？系统容量如何规划？
运营系统如何解决业务的真正痛点？如何在大量“琐碎需求”下提升研发效率？
解决以上问题的整体思路是化繁为简（理清逻辑关系）、逐步演进（考虑 ROI）。
整体架构设计
在整体架构上，我们将供应链系统拆解为交易系统、运营系统、中台系统和主数据平台。
交易系统（下图左上侧）的设计上，首先按照用户侧与商户侧做了初步划分，这样拆分兼顾双端角色 。例如：用户侧更关注下单的成功率与订单状态的一致性，商户侧更关注房屋的搜索排名等，整体上解耦搜索排名、房屋报价、营销系统、订单系统等模块。
运营系统（下图左中侧）方面，需求长期多而杂，架构设计上需要先想清楚民宿的运营系统应该管什么、不应该管什么。在长期的项目开发中，我们从业务战略与组织架构出发，在明确业务战略目标和阶段策略下，梳理每个业务团队或者岗位的核心职责、考核目标、组织之间的协作流程，最终整理出现阶段民宿运营管理的中心为五个领域：
除了交易、运营两个系统的架构设计外，架构设计层面还有一个非常关键的问题，即交易、运营系统的边界与职责如何划分的问题。个人理解这个问题可能是 C2C 类业务在规模化阶段最关键的架构设计问题，如果不能有效解决将为系统的可用性、扩展性埋下巨大隐患。交易、运营两个方向的业务需求和技术职责有较大差异，且多数数据的生产都在运营系统，最核心最关键的应用在交易系统。虽然各自的领域职责是清晰的，但对于具体的需求边界上不见得简单明了。对此，我们借鉴了 MDM（主数据管理）思路，提出了主数据平台（下图底部）的概念，重点解决交易系统与运营系统的合作与边界问题。
主数据平台
主数据是企业信息系统中最基础的业务单位数据，对于民宿而言是商家、用户、城市等数据。与之对应的是业务数据，例如：订单、考勤等。主数据有两个最关键的特征：
主数据管理并非一蹴而就，是伴随业务发展逐步迭代的。早期系统较简单，上游系统直接从 DB 中读取数据并应用。这种方案在系统逐步复杂后，容易出现多个团队开发互相影响，不利于系统扩展，并且在可用性上有很大风险。为此，我们专门成立了主数据团队，独立拆分了主数据服务，并把所有对数据的访问收回到服务上。在此基础上，经过不断的迭代和演进，最终我们吸收了 CQRS（Command Query Responsibility Segregation ）和 MDM（Master Data Management）的思想，将整个主数据平台逐步划分成四个部分：
房屋系统：负责对数据生产的建模，隔离数据生产对核心模型的影响。例如：商户上房 、门店分配流程等。
核心模型：挖掘数据实体关系，提升模型能力。例如：商户多门店、房屋聚合等。
基础数据中心：面向交易系统的应用场景支持，将房屋基础数据模型化。适应交易系统的不同需求。
管理数据中心：面向运营系统提供标准化框架，提供信息检索、流程审批、权限控制等场景的统一解决方案。
系统可用性
业务的快速增长对系统可用性提出越来越高的要求。在方法论层面，我们按照事故发生的时间序列（事前、事中、事后）提出了四大能力建设，即：预防能力、诊断能力、解决能力、规避能力。同时，在具体工作上，我们划分为流程和系统两个方面。
可用性建设是一个长期项目。考虑到 ROI，起步阶段重点完成事前的流程建设，即上线规范等一系列线上操作流程，这个工作在早期能够规避 80% 的线上故障。在流程规范跑通并证实有效之后，再逐步通过系统建设提升人效。
容灾能力
容灾能力建设上，首先思考的问题是系统最大的风险点是什么。从管理角度来看，职责的“灰色地带”通常是系统质量容易出现风险的地方。因此，早期最先做的容灾处理是核心依赖、第三方依赖降级，优先保证一旦依赖的服务、中间件出现问题，系统自身具备最基本的降级能力。
第二阶段，我们提出端到端的容灾能力。首先，我们建设业务大盘，定义实时监控核心业务指标（单量、在线房屋数量等），通过这些指标快速判断系统是不是出了问题。其次，我们在核心指标上扩展了关键维度（城市、App 版本、运营商等），以快速评估问题有多大影响。最后，我们通过 Trace 系统，将服务间的调用关系与链路级成功率可视化展现，具备了快速定位问题根因在哪的能力。
第三阶段，我们期望将容灾预案集成到系统中，基于各类事故场景打造定制化、一体化的容灾工具，这样可以进一步缩短故障的响应、处理时间以及研发学习成本。
系统容量
对于一个规模快速增长的业务，系统容量规划是一个长期命题。容量规划的关键点是评估与扩容。
评估方面，在业务发展早期，一个架构师就能够完全掌控整个系统，采用静态评估的方式基本可以衡量系统容量。随着系统复杂度逐渐提升，我们逐步引入了 Trace、中间件容量监控等工具辅助评估容量，由架构师团队定义容量评估主框架，由各团队细化评估每个子系统的容量。
当业务已经变得非常复杂时，没有任何一个人或团队能够保证精确完成容量评估，这时，我们启动了场景压测、引流压测、全链路压测等项目，通过流量标记 + 影子表 + 流量偏移 + 场景回放等手段，实现了通过线上流量按比例回放压测的能力，通过系统报告精确评估容量与瓶颈点。
扩容方面，我们分阶段依次实施了冗余备份（主从分离）、垂直拆分（拆分核心属性与非核心属性）、水平拆分（分库分表）、自动归档。
运营系统迭代效率
运营系统涉及一个业务运营管理的方方面面，我们在业务领域上除了明确目标、过程、房屋三个领域外，打造了一套运营系统集成解决方案集合。研发通过持续投入精力在平台化服务或组件的长期建设上，使每个垂直的运营系统扩展性得到保证，从而不断提升研发效率。以运营后台为例，通过动态表单 的方式， 方便快捷搭建后端系统。
精细化阶段
业务发展不断成熟之后，业务的各类运营管理动作会趋于精细化。这个阶段，业务对产品技术有更高要求，期望通过产品技术创新不断打造技术壁垒，保持领先优势。为此，我们重点提升了几方面能力：
结语
在途家供应链系统架构的演进过程中，架构师团队长期关注技术驱动业务、明确领域职责与边界等关键问题，同时架构演进过程也是不断考虑 ROI 权衡取舍的过程。技术的持续发展让用户体验、业务规模不断提升，并降低运营成本，而架构在里面解决的问题是化繁为简，将复杂问题拆解为简单问题，并通过领域专家逐级各个击破。随着规模的持续增长，业务的持续创新给系统架构提出越来越大的挑战，系统架构设计将是值得我们长期研究的一个课题。
| 留言与评论（共有 0 条评论） |
