Still worrying about system migration? Master these "Basic Laws" to unlock more possibilities

Posted May 25, 20208 min read

Introduction: After completing the basic function construction, the community comment system began to gradually migrate the old system business to the new system to achieve a unified overall structure, the new system function empowers the old business, and saves system maintenance costs; although the migration process itself It is boring and odorless, but it does not hinder the precipitation of common solutions. In this article, I will review the migration of new and old systems as a background and talk about the basic methods of system migration.

Author | Wang Xiang(Blade Wing)
Produce | Alibaba New Retail Amoy Technology Department


After completing the basic function construction, the community comment system began to gradually migrate the old system business to the new system to achieve a unified overall structure, the new system function empowers the old business, and saves system maintenance costs; although the migration process itself is boring, it does not hinder With the precipitation of common solutions, this article takes the review of old and new system migration as the background and talks about the basic method of system migration. At the same time, I hope to be able to use it to explore more possibilities for migration.

Overview of system migration solutions

Main steps

As far as the general system is concerned, it mainly involves the following steps. Among them, the migration order of the read-write interface can be adjusted according to the actual situation:

Basic data inventory/incremental migration
Goal:The data of the old system is migrated to the new system, and the incremental data is synchronized to the new system in real time

Main problems to be solved:

  1. Ensure that the data is not lost, and the new system data is accurate after synchronization
  2. New and old system id mapping:When the new and old system id systems are different, you need to do a good job of id mapping. For example, the extension field in the new db stores the old system id, and at the same time saves the new system id corresponding to the old system id to ldb, which is convenient for anti-check ; Comment on the new system design at the beginning to facilitate the migration of the old system, using the same sequenceId generation system as the old system, so no need to consider the problem of id mapping

Read interface migration:read the new system first
Objective:Directly check the new system at the interface layer
The main problem to be solved:the new and old interface data structure is compatible, reducing the cost of front desk migration

Write interface migration
Goal:New data first write new system

Main problems to be solved:

  1. The early stage needs to support reverse synchronization to the old system(the reason why this step requires two-way synchronization back to the old system is mainly to be compatible with the old business interface and odps data, which is difficult to clean in one step), and it is necessary to ensure that there is no dead loop during two-way synchronization

  2. Each write port of the old system needs to be adapted for routing. The workload of this step of transformation is relatively large, and it is relatively related to the specific system characteristics. This article will not discuss

    Critical stage

Correspondingly, there are several key stages in the system migration process:

Phase one: Data unidirectional synchronization phase(old system-> new system)
Phase 2: Read/write interface migration is completed, the ingress traffic goes to the new system first, incremental data is written to the new system first, and then synchronized back to the old system(two-way synchronization phase)
Phase 3: All downstream business traffic and mtop inlet traffic are migrated to the new system, and the old system traffic is gradually cleared to 0 until offline; this step is also the final perfect state

Generally speaking, after all the adaptation transformations that need to be done on the platform side are completed, you can enter phase two. Phase three mainly relies on gradually promoting the migration of downstream business parties. The platform itself does not need to make additional changes. Solve the problems faced in the first two stages.

In addition, according to different system characteristics, in addition to basic data migration, there may be one more step of index construction, such as a comment system. The index layer is a very important part of the system, which supports almost all query scenarios in the foreground, and index construction strategies will also affect To the selection of migration solutions.

Comment on several options for system migration

Solution 1:Rely on Jingwei for data migration and index construction

Data inventory migration/incremental synchronization

  1. Jingwei stock/incremental tasks
  2. The Jingwei client/sar package task creates an index synchronously(currently the client mode is offline, you can only use the sar package method)


  1. If the system can receive a part of the incremental data that is inconsistent, you can start the incremental task first, and then start the full amount task(the same record will be overwritten); if the system has high consistency requirements, you need to use the backtracking of the Jingwei incremental task. Function to ensure that all changes that occur during the full data migration can be synchronized to the new library. If the full task migration time is longer, you need to contact Jingwei on duty to reserve a longer position(the online default position is only reserved for 1 day))

  2. Index construction relies on the simultaneous completion of Jingwei tasks. The overall diagram is as follows:

Read interface migration
Since the index has been created synchronously, you can directly do read interface routing migration at the interface layer

Write interface migration

  1. Support reverse synchronization channel(new system-> old system)
  2. The source system tag prevents endless loops
  3. Write interface layer routing, write new system first

Note:Prevent the bidirectional synchronous dead loop by marking the data that is written to the new system first(the eagle eye marking method can also be used here, but personally think that it is not as safe as storing the source system label directly, and it is easy to trace the source based on the source data), The old system-> the incremental channel of the new system checks whether the data carries the new system label, and decides whether to process or discard it. After the write interface is migrated, the schematic diagram of the two-way synchronization status of the new and old systems is as follows:


Solution 2:Index construction does not depend on Jingwei

Data inventory migration/incremental synchronization

  1. Jingwei stock/incremental tasks

Note:The stock/incremental data plan is the same as plan one

Write interface migration
(Bidirectional synchronization phase)

  1. Reverse synchronization channel(to ensure that data can flow back to the old system, compatible with old services) New-> Old
  2. The source system tag(to ensure that there is no cycle when bidirectional synchronization)
  3. The write interface routing is enabled(switch from writing the old library first to writing the new library first)

Note:The index reconstruction needs to be completed before the read interface is switched. The index reconstruction includes two parts:incremental and stock. The incremental part relies on the system to asynchronously consume comments. The metaq message sent after the successful writing interface is completed, so you need to migrate the writing interface first Incremental data can be indexed:


Other steps are the same as scheme one

Building of stock data index

  1. The dts task reads the inventory offline table to complete the construction of a new index of the inventory data. Here, multi-machine concurrent tasks can be used.
    Note:Incremental data index construction relies on the switch of the write interface. The index construction of the stock data requires a special write task to read the offline table.

Read interface migration

  1. After the index stock/incremental data construction is completed, you can open the read interface switch

    Solution 3:No dependence on Jingwei

Data inventory migration/incremental synchronization

  1. The dts task reads the inventory offline table and migrates the inventory data in the interface mode
  2. Incremental synchronization relies on double write at the interface layer

Note:The Jingwei solution is generally applicable to scenarios where new and old system storage uses mysql. When the storage solution is inconsistent, the migration of inventory data can only be completed by writing dts migration tasks. Since the interface layer is used to write data, the metaq method The built index can be rebuilt synchronously.

Read interface migration

  1. The first step will complete the index construction synchronously, so you can move the read interface first

Write interface migration

  1. Reverse synchronization channel
  2. The write interface routing is turned on. After the routing is turned on, the double write at the interface layer is automatically turned off, and the data begins to write to the new system-> then to the old system

Note:There is no problem of two-way synchronization. The synchronization link of the old system-> new system is double-written at the interface layer. After the write interface routing is turned on, the double-write logic will be turned off at the same time as the new system is written first. The reverse channel can synchronize the data back to the old system

to sum up

Three sets of solutions solve the problems of different scenarios, each has its own advantages and disadvantages. The following points can be used as the basis for judging the selection of solutions:

1, basic data migration: When new and old systems use mysql storage, try to use Jingwei to do full/incremental migration. Jingwei itself is a professional data synchronization tool with comprehensive functions that can maximize data protection Consistency and accuracy after the migration, at the same time, you can also use the Jingwei console to adjust the migration speed at any time to ensure the stability of the migration process.
2. Migration sequence of read-write interface: The sequence of read-write migration is determined according to the specific scheme of index construction. The migration of read interface strongly depends on the completion of index construction:

Advantages of Option 1: Basic data and indexes can be migrated synchronously, and cutting the interface first is also less risky than writing the interface first.

Advantage of solution two: Although not relying on Jingwei to build an index makes it necessary to write a task to rebuild the index, but the index construction scheme that does not rely on Jingwei is more convenient for logical modification and iteration in the actual project. Jingwei depends on binlog The original determines the untestability of pre-launch, inconvenient rapid iteration of functions and stable online.

One More Thing

We are the Taobao content social interaction team, which mainly carries the user's important experience upgrade from "buy in Taobao" to "consumer life in Taobao". Based on the new product model and operation model, it is promoted by content, gamification and social community. Users are active in Taobao. Along with the vast business space opportunities, there are sufficiently challenging technical scenarios:we have tens of billions of user relationships and user interaction data assets to be discovered, millions of QPS, high traffic, high availability, strong consistency, multi-tenant technology scenarios , Covering engineering development, recommendation algorithms, big data analysis platforms, etc., provides career growth space and diverse job options:data-driven operations, large-capacity and high-concurrency systems, recommended search service platforms, deep learning engineering systems, etc.
Please submit your resume to the email: