携程亿级高并发架构改造实践

本次分享内容

1. 业务背景描述
2. 存储重构(SQLServer 转到 MySQL、核心和非核心隔离、消息替代轮询)
3. 架构升级(系统合并、前后端分离)
4. 总结

一、前言

本次分享将介绍在业务持续发展环境中，复杂系统的改造过程以及实施的一些经验，希望能给面对同样问题的同学提供一些借鉴思路。

1.1 背景

度假产品系统，作为携程度假部门自营业务人员与供应商的上货平台，为旅游产品的预订以及订单处理流程提供产品信息的数据支持。作为业务系统的底层数据，有如下特点：

1）业务复杂度高

到 2020 年，系统经历了 8 年的业务逻辑积累，支持多种产品形态，包括：跟团游，自由行，周边游，签证，以及当地向导等，30 多种产品和资源类型，包括：保险，火车票，一日游，接送机等等。还与交通和住宿部门对接，支持多种大交通资源的匹配规则，包括机票，酒店，火车票等。

2）系统架构陈旧

改造前，系统架构基于. NET 平台开发，使用 SQLServser 数据库。随着时间和业务逻辑的积累，系统中存在大量陈旧的代码逻辑，数据库中也有很多废弃的表和字段，使用 SQLServer 的复制分发功能实现读写分离，不同系统之间依赖数据同步，这些陈旧的架构导致系统扩展性差，数据实时性低。

1.2 问题

业务复杂度高和系统架构的落后，带来的问题是系统问题多，开发效率低。

1）复制分发延迟，影响产品售卖

数据库 800 多张表，包括核心表和非核心表，划分不清晰相互影响。非核心业务往往存在大量的数据更新和读取，影响数据库性能，从而影响核心业务。表的结构设计不合理，不同领域的数据结构划分不清晰混在相同的数据表中，产品主表有 200 多个字段，其中包括很多废弃的字段。SQLServser 的复制分发在写库大量数据更新时，分发库存在延迟影响正常业务。

2）开发效率低，问题频发

自营与供应商使用两套独立的产品系统，而预订和订单处理流程只使用一套数据，数据通过臃肿的 WCF 架构同步，存在数据不同步的风险。系统重复开发，浪费研发资源。后台站点直接读写 DB，多模块写入点分散。这些架构的复杂度带来涉及人员多，排障流程长等问题，效率低下。

1.3 措施

针对系统现状，通过对系统重构，解决复制分发延迟问题，降低系统整体复杂度，避免重复开发，提高开发效率。

系统的改造是伴随着业务需求压力并持续优化改造的过程，重点有两方面：

1）存储重构

数据库从 SQLServser 迁移到 MySQL，包括消除数据库的复制分发，重新按领域模型拆分表，将核心数据与非核心数据隔离，通过消息系统替代轮询数据等。

2）架构升级

减少重复建设，去掉臃肿的数据同步过程，将分离的两套系统合并。从. NET 站点转变为前后端分离的系统架构。

二、存储重构

2.1 SQLServer 转到 MySQL

数据库从 SQLServer 向 MYSQL 迁移，主要有三个难点：

1）数据源切换，写入点分散，改造成本高，周期长。

首先是成本高，写入点分散的问题。产品系统的应用有多个，同一个模块的数据在不同的功能中都有修改的场景，漏改会引发数据不一致问题。

由于产品系统作为度假整体系统的一部分并且作为基础数据的支持，改造过程有上下游的依赖，大量的应用直接读取 DB，数据读取点多。如果逐个表逐个字段迁移再与相关依赖系统协调切换数据源，整个改造周期会非常长。

2）下游切换，依赖多，逻辑复杂。在大量下游系统直接依赖数据的情况下，每个下游系统都有各自的业务逻辑，使用的数据字段和方法各有不同，逻辑分散在各处。

3）数据一致性。基础数据的数据源切换，一旦发生问题，对业务影响大。

为了解决这些难点，我们把数据的迁移分成三个阶段，如下图所示：

数据库迁移的三个步骤

1）建立数据同步机制，提供 API 规范数据访问，下游快速切换到 MySQL 数据源。

这一步的目的是避免按表分步切换拉长改造周期。首先是需要提供产品数据查询统一的 API 给下游系统，API 中直接读取 MySQL 的数据，在数据切换时保证数据的完整性，在 MySQL 中建立数据，通过数据同步机制保证的一致性。这样下游系统不需要逐个字段或逐个表进行迁移，可以基于功能模块对接 API。

2）数据源双写，逐步断开数据同步。

这个步骤是逐步对原来功能模块写数据的场景进行改造，在新老 DB 共存上下游逐步切换的场景中，保证业务的稳定性。在写原 SQLServser 数据的同时，将数据再对 MySQL 数据库写一份，以便于下一个阶段彻底解除对 SQLServser 数据的依赖。

数据表有三类：

第一类是业务需求功能改动相关表，这类表随着业务需求中涉及到的改动点，把依赖的数据表整理出来重新开发功能。

第二类是没有新需求功能的相关表，这类表需要研发人员主动梳理并作为技术改造的日常任务进行切换，经常伴随着业务需求的压力以及需要协调各方资源推进完成改造。