🚐 👨🏾‍🔬 🧛🏽 Cara menggabungkan dua platform menjadi satu dan tidak menyinggung pengguna. Pengalaman Pengembang Yandex.Kew 📂 👨🏽‍🎨 🙌🏾

Tahun lalu, layanan TheQuestion bergabung dengan Yandex. Pada saat itu, sudah ada layanan pertanyaan dan jawaban yang serupa - Yandex.Znatoki. Para penikmat memiliki audiensi yang besar dan banyak pertanyaan menarik, tetapi tidak ada cukup ahli yang bisa memberikan jawaban berkualitas tinggi untuk pertanyaan-pertanyaan ini. TheQuestion, sebaliknya, memiliki komunitas ahli yang kuat, tetapi tidak memiliki pertanyaan menarik. Langkah logisnya adalah menggabungkan dua layanan untuk mengambil yang terbaik dari masing-masing layanan. Tetapi bagaimana melakukan ini jika setiap layanan memiliki basis teknologi, konten, dan pengguna sendiri?

Hari ini saya akan berbicara tentang bagaimana tim kami memecahkan masalah ini dari sudut pandang teknologi. Anda akan menemukan opsi untuk menggabungkan yang telah kami pertimbangkan dan yang pada akhirnya telah dipilih. Saya akan memberi tahu Anda tentang "swap API", migrasi basis data, profil gabungan dan pengujian backend. Namun - tentang malam bergerak tanpa hak untuk melakukan kesalahan. Anda akan melihat bahwa kami tidak harus bosan.

Tugas menggabungkan dua layanan menjadi satu bukanlah hal baru, tetapi ini tidak membuatnya lebih mudah. Sejarah tahu banyak contoh integrasi yang sukses (dan tidak begitu), tetapi, sayangnya, tidak ada "peluru perak" dan instruksi yang jelas "lakukan ini dan semuanya akan berhasil". Semuanya sangat tergantung pada spesifikasi layanan yang digabungkan dan hasil yang diinginkan.

Dalam kasus kami, tujuannya adalah ini: bahwa semua konten yang pernah ditulis pada masing-masing situs tersedia pada layanan terintegrasi, dan penulisnya dapat mengelolanya.

Jadi, bagaimana Anda menggabungkan dua layanan tanya jawab, yang tampaknya sangat mirip, tetapi pada dasarnya sangat berbeda? Mentransfer konten dan pengguna dari satu layanan ke layanan lainnya sangat mirip dengan pindah dari apartemen lama ke yang baru.

Hanya dalam kasus kami, pengguna dapat hidup secara bersamaan di dua apartemen (Penikmat dan TheQuestion), dan Anda perlu dengan hati-hati memindahkannya ke apartemen ketiga. Anda perlu memindahkan semua perabotan, tanaman, kucing, dan bahkan wallpaper ke apartemen baru (yaitu, pertanyaan, jawaban, komentar, suka), dan kemudian undang dia untuk pindah.

Bagaimana cara melakukannya? Beberapa opsi segera muncul di pikiran.

Opsi 1. Sangat buruk.
Mari kita ambil salah satu layanan, transfer semua konten ke yang lain (walaupun ini pun tidak lagi mudah) dan tutup layanan yang asli.

Opsi ini sangat buruk dari sudut pandang pengguna layanan pertama. Kami baru saja menghancurkan rumah lamanya dan memaksanya pindah ke yang baru. Siapa pun tidak akan menyukai sikap ini, dan alih-alih bergerak, ia bisa pergi ke matahari terbenam. Bagi kami, nilai utama adalah komunitas pengguna, jadi kami tidak berencana menyinggung siapa pun. Dan dengan berani beralih ke opsi lain.

Opsi 2. Buruk.
Mari kita tidak mengubah salah satu layanan, sebagai gantinya, meluncurkan yang baru, terintegrasi, dan kami akan secara berkala menambahkan konten dari dua lainnya untuk itu (misalnya, sekali sehari).

Dalam hal ini, kami sepertinya tidak membuat pengguna lebih buruk, tetapi kami juga tidak melakukan yang lebih baik. Apartemen lamanya tetap tidak berubah, tetapi tidak ada gunanya pindah ke yang baru. Semua tetangga juga tinggal di rumah tua, bunga yang baru dibeli akan diangkut ke apartemen baru hanya setelah sehari. Layanan terpadu seperti itu tidak memiliki peluang untuk menjadi rumah baru.

Opsi 3. Bagus, tetapi kompleks.
Jangan tutup salah satu layanan, kami akan segera menduplikasi konten dan profil pada layanan terintegrasi, dan orang-orang akan bergerak seiring waktu.

Semua tetangga pengguna (dan bahkan kucing) hidup serentak di rumah lama dan baru. Bunga yang baru saja Anda beli langsung muncul di apartemen baru. Persis apa yang dibutuhkan! Opsi ini adalah yang paling nyaman dari sudut pandang pengguna. Karena itu, kami memilihnya.

Mulai bergerak

Apa yang akhirnya kami lakukan dapat dijelaskan dalam beberapa kalimat. Kami sepenuhnya mengulangi seluruh backend TheQuestion API berdasarkan pada backend Connoisseurs, sehingga memperoleh backend tunggal yang dapat bekerja dengan dua (dan bahkan tiga) situs sekaligus. Frontend TheQuestion tetap hampir tidak berubah, yang berarti bahwa dari sudut pandang pengguna, situs itu sendiri tidak banyak berubah. Proyek ini telah menerima nama internal "swap API". Tetapi hal pertama yang pertama.

Apa yang kami miliki di pintu masuk: dua situs yang sepenuhnya independen. Penikmat tinggal di awan bagian dalam Yandex. Backend Connoisseurs ditulis dalam Python. TheQuestion hidup di awan Microsoft Azure, backend TheQuestion ditulis dalam Go. Layanan memiliki skema penyimpanan data yang sangat berbeda dalam database. Selain itu, TheQuestion memiliki dua aplikasi seluler (untuk Android dan iOS) yang juga perlu didukung. Secara umum, musuh tidak ingin menyatukan kebun binatang seperti itu.

Tahap 0. Berkendara ke awan Yandex

Sebenarnya, langkah ini tidak diperlukan untuk "plugin API", tetapi secara signifikan menyederhanakan langkah selanjutnya. Pada tahap ini, kami sepenuhnya meninggalkan penyimpanan dan fasilitas eksternal. TheQuestion mulai menggunakan server DNS Yandex. Layanan rentme dipindahkan ke Yandex.Cloud. Database dipindahkan ke Yandex Managed Database. Selama pindah, kami juga dapat menemukan dan memperbaiki beberapa kesalahan di TheQuestion, misalnya, koneksi tidak tertutup ke Redis dalam kode 2015. Sebagai bonus, kami juga menerima kekuatan tambahan untuk TheQuestion.

Tahap 1. Migrasi Data

Terlepas dari opsi mana yang Anda ingin gabungkan layanan, kami harus menggabungkan data dalam hal apa pun. Untuk satu basis data, mereka memutuskan untuk menggunakan PostgreSQL - DBMS ini telah digunakan di dalam Pakar dan TheQuestion. Agar tidak mempersulit proyek, mereka tidak mulai membuat basis ketiga untuk layanan terintegrasi, tetapi hanya mengambil basis data Znatokov dan memperluasnya sehingga bisa menerima semua data TheQuestion. Ini adalah tantangan teknologi besar pertama.

Setiap entri di setiap tabel dari database TheQuestion harus dikonversi dan dimasukkan ke dalam Database Pakar. Kemudian - mengkorelasikan setiap kolom dari satu dan basis lainnya. Banyak bidang harus dikonversi secara nontrivial dari satu format ke format lainnya. Jadi, subtugas besar yang terpisah adalah konversi format penyimpanan teks (format aktual penyimpanan pertanyaan atau jawaban) dari QML (TheQuestion) ke Markdown (Experts).

Kami menyiapkan proses reguler (beberapa kali sehari) untuk mentransfer data baru dari satu basis data ke basis data yang lain, tetapi pada saat yang sama memastikan bahwa data dari TheQuestion tidak ditampilkan di mana pun hingga penyelesaian tahap berikutnya. Karena "beberapa kali sehari" jauh dari yang dijanjikan "langsung", dan data bisa dalam keadaan tidak konsisten dengan data yang sama pada TheQuestion, yang akan menyesatkan pengguna. Jadi mengapa kita mulai dengan migrasi data jika backend belum siap?

Pertama, dengan cara ini kami menstabilkan proses. Kedua, mereka mengurangi jumlah data baru yang perlu ditransfer di masa depan, dan ini penting, karena semua konten yang diimpor harus didorong melalui peningkatan kualitas, konten yang tidak pantas, spam, penipuan.

Tahap 2. "Swapping API"

Jadi, kami memecahkan masalah pertama - kami belajar mengambil konten dari database TheQuestion dan bahkan menampilkannya jika Anda mau. Sekarang perlu untuk membuat konten ini masuk ke database terintegrasi secara instan, dan tidak beberapa kali sehari.

Untuk melakukan ini, perlu menulis ulang seluruh backend TheQuestion dengan semua logika yang diperlukan. Nama proyek, "Swap API," secara tegas, tidak sepenuhnya mencerminkan esensi. Akan lebih tepat menyebutnya "Tukar backend." Faktanya adalah, di samping implementasi langsung semua "pena" yang diperlukan untuk berfungsinya front-end TheQuestion, kemungkinan lain harus diwujudkan. Kami menghadapi beberapa tugas besar.

OtorisasiYandex memiliki sistem otorisasi pengguna terpusat - Yandex.Passport. Dan Penikmat, tentu saja, menggunakan Paspor. Untuk masuk, Anda harus memiliki akun di Yandex. Itu masalahnya. Tidak semua pengguna TheQuestion masuk ke situs melalui Yandex (meskipun ada peluang seperti itu). Banyak pengguna tidak memiliki login Yandex sama sekali dan pergi melalui jejaring sosial (VKontakte, Facebook ...). Secara alami, kami harus menjaga fungsi ini saat bergerak. Karena itu, kami menerapkan otorisasi "non-paspor".

Mencari situs.TheQuestion menerapkan pencarian pada pertanyaan, jawaban, pengguna, dan topik. Untuk pencarian, solusi Sphinx pihak ketiga digunakan. Jelas, jika kita berbicara tentang satu layanan, maka pencariannya harus sama, yaitu, ia tidak dapat bekerja pada dua sistem sekaligus. Dengan demikian, Sphinx ditinggalkan demi mesin pencari internal dengan dukungan untuk fungsionalitas yang diperlukan dan pengindeksan semua konten TheQuestion.

Pengiriman halaman dalam Zen dan Turbo . Pada saat bergabung, TheQuestion sudah menggunakan teknologi Yandex. Halaman Turbo didukung, konten menarik jatuh ke dalam umpan Zen. Semua ini juga harus didukung dalam "API pengganti".

Pemberitahuan dalam layanan dan aplikasi, milis.Segala sesuatu yang berkaitan dengan memberi tahu pengguna: langganan, buletin dengan konten yang menarik, dorong tentang suka dan komentar, lebih banyak lagi. Semua ini harus ditransfer dengan hati-hati dan tidak dilupakan.

Sistem Administrasi Situs . Paragraf ini mengacu pada segala sesuatu yang berkaitan dengan manajemen internal layanan: moderasi, analitik, dan sebagainya.

Sistem peringkat pengguna terpadu.Tugas ini agak tidak teknis, tetapi logis. Secara formal, tidak perlu mengembangkan sistem peringkat terpadu untuk "swap API", tetapi sistem ini masih diperlukan untuk layanan terintegrasi di masa depan. Di kedua situs, pengguna diberi peringkat untuk kuantitas dan kualitas konten yang dibuat. Rincian peringkat tidak diungkapkan, tetapi semakin sering dan semakin baik Anda menjawab pertanyaan, semakin tinggi peringkat Anda. Prinsip penilaian adalah sama pada kedua layanan, tetapi formula itu sendiri dan faktor-faktornya sangat berbeda. Itu diperlukan tidak hanya untuk secara benar dan jujur membandingkan pengguna Znatokov dan TheQuestion di antara mereka, tetapi juga untuk belajar mempertimbangkan peringkat tunggal untuk para ahli yang menulis pada dua layanan sekaligus.

Dan tulis ulang semua API.Suka atau tidak, tugas ini adalah yang paling penting dan sulit. Banyak proses pada layanan serupa, jadi kami mengambilnya dari para Penikmat dan tidak menulis dari awal. Tetapi ada juga banyak hal baru, misalnya, garis lurus pengguna atau konsep jawaban. Sebagai hasilnya, kami menulis ulang lebih dari 100 "pena" di "swap API" dan menerapkan lebih dari 50 sumber daya REST.

Setelah kami menerapkan semua fungsi yang dijelaskan di atas, dimungkinkan untuk mulai bergerak. Tetapi sebelum kita melakukan satu trik.

Jelas bahwa sebelum beralih dan meluncurkan "swap API" dalam produksi, itu harus diuji dengan sangat baik. Pertama-tama, perlu mengujinya secara fungsional, yaitu, langsung memeriksa kinerja seluruh situs di API baru. Kedua, sangat menegangkan. Kami ingin 100% yakin bahwa desain kami tidak akan "berbohong" di bawah beban. Secara alami, kami secara rutin melakukan “load firing”, yang menunjukkan bahwa kami memiliki pasokan kinerja yang baik. Namun dalam hal kinerja layanan, selalu lebih baik bermain aman. Setiap, bahkan yang terbaik, tes beban sintetis entah bagaimana berbeda dari beban produksi. Oleh karena itu, kami memutuskan, sebelum beralih API, untuk mengisi beban produksi di stand kami.

Untuk melakukan ini, di frontend TheQuestion, kami menerapkan duplikasi semua permintaan GET (yang berarti permintaan data, bukan modifikasi) menjadi dua API sekaligus: theQuestion "API lama", yang pada waktu itu adalah yang utama, dan yang kedua "swap API". Pada saat yang sama, frontend tidak menunggu respons API minor dan tidak menangani kesalahan, tetapi dengan cara ini kami dapat menguji backend pada pengguna nyata.

Tahap 3. Dan kemudian kita ingat tentang aplikasi

Tidak, tentu saja, kami ingat tentang mereka selama ini, tetapi menghadapi satu masalah. Mereka yang bekerja dengan aplikasi seluler tahu bahwa kerumitan dengan mereka lebih dari pada situs. Ini terutama disebabkan oleh distribusi versi baru.

Pertama, Anda harus bekerja dengan layanan eksternal dari App Store dan Google Play dan menunggu versi baru untuk lulus verifikasi (dan kadang-kadang verifikasi membutuhkan waktu yang cukup lama). Kedua, bahkan jika aplikasi Anda telah lulus tes dan muncul di toko, ini tidak berarti bahwa pengguna akan melakukan pembaruan.

Dalam kasus frontend situs web, pengembang sendiri mengontrol kapan versi baru dirilis, dan mereka tahu pasti bahwa setelah itu semua pengguna akan menerima versi situs yang diperbarui. Dalam hal aplikasi, tidak ada jaminan seperti itu. Untuk mendapatkan jaminan seperti itu, mereka sering menggunakan "pembaruan paksa" aplikasi. Hanya sedikit orang yang menyukai metode ini, dan, tentu saja, selalu, jika memungkinkan, Anda perlu mempertahankan kompatibilitas mundur antara aplikasi dan backend. Oleh karena itu, kami mengambil jalur untuk membuat perubahan tepat di sisi backend dengan perubahan minimal pada frontend dalam aplikasi. Tetapi, seperti yang sering terjadi, rencana tersebut dihadapkan dengan kenyataan pahit.

Beberapa perubahan lebih mudah dilakukan di sisi front-end daripada di back-end, oleh karena itu, dalam proses pengembangan "plug-in API", front-end sedikit, tetapi berubah. Secara khusus, database TheQuestion lama menggunakan ID 64-bit numerik. Database Penikmat dan, karenanya, database gabungan dan API baru untuk TheQuestion menggunakan string 128-bit ID. Secara umum, untuk frontend yang ditulis dalam Node.js, perbedaan ini tidak signifikan. Tetapi untuk aplikasi yang sangat diketik, ini berakibat fatal. Kami kehilangan kompatibilitas ke belakang, dan aplikasi yang lebih lama tidak dapat bekerja dengan "plugin API".

Pada titik tertentu, bahkan ada proyek yang disebut "plugin API untuk plugin API", yang intinya adalah untuk menulis lapisan kecil antara backend baru dan aplikasi yang akan mengubah semua data menjadi format lama. Namun, kami dengan cepat meninggalkan ide ini. Lapisan ini akan menjadi "penopang" yang sangat kaku, yang di masa depan pasti akan membawa kita banyak masalah. Misalnya, Anda tidak bisa hanya mengambil dan menerjemahkan ID 128-bit menjadi yang 64-bit. Saya harus menerjemahkan dengan kehilangan informasi dan, akibatnya, kemungkinan tabrakan dengan ID, atau mempertahankan tabel perantara dengan korespondensi ID lama dan baru (untuk semua elemen database). Baik itu, dan yang lain - bukan solusi arsitektur terbaik.

Selain ID, ada sejumlah perubahan lain yang juga lebih mudah untuk didukung di sisi front-end dan aplikasi. Akibatnya, kami memutuskan untuk menerapkan perubahan dalam aplikasi dan masih menggunakan pembaruan yang dipaksakan. Dalam waktu singkat kami mengembangkan versi aplikasi baru yang kompatibel dengan "swap API", karena tidak ada begitu banyak perubahan dari ujung depan dan itu tidak terlalu serius. Dikirim ke App Store dan Google Play, berhasil dimoderasi dan mulai menunggu.

Tahap X. Ayo pergi!

Jadi semua kode ditulis. Dudukan dengan "API pengganti" diuji dan dipecat. Versi baru aplikasi telah diuji di toko-toko dan siap untuk dipublikasikan. Sekarang semua ini harus diluncurkan ke produksi.

Karena fakta bahwa menyalin data baru dari database lama ke yang baru terjadi secara tidak sinkron dan memakan waktu, Anda tidak dapat mengganti backend (dan database di bawahnya) di situs yang berfungsi. Ini dapat menyebabkan hilangnya atau tidak konsistennya data pengguna. Oleh karena itu, kami memilih tanggal, memperingatkan pengguna dan menyiapkan piring "Pekerjaan teknis sedang berlangsung".

Dan kemudian jamnya tiba, atau lebih tepatnya malam X. Rencana peluncurannya terlihat seperti ini:

Di situs web TheQuestion, kami menutup tulisan rintisan "Pekerjaan sedang berlangsung".
Kami mentransfer aplikasi ke mode Readonly. Pengguna dapat membaca konten dari database lama, tetapi tidak dapat membuat yang baru.
TheQuestion Readonly. : . , , .
. , .
.
, , API.
API . — , API .
, , .
« », API.
.

Yah, itu tidak terlihat menakutkan. Pada kenyataannya, semuanya berjalan dengan lancar. Dari kejutan yang kami temui, mungkin terlalu lama untuk menerbitkan aplikasi di App Store (aplikasi diperiksa terlebih dahulu, itu hanya tentang muncul di toko). Pada akhirnya, butuh beberapa jam, itulah sebabnya mengapa seluruh operasi sedikit tertunda.

Selain itu, dalam proses switching, ada satu fitur utama yang merumitkan semuanya berkali-kali dan meningkatkan tanggung jawab. Faktanya adalah bahwa proses switching tidak dapat dibalik.

Meskipun proses menyalin dan mengonversi data dari database TheQuestion yang lama ke yang baru, yang terintegrasi telah disiapkan dan didebug untuk kami, tidak ada proses penyalinan terbalik (dari database baru ke yang lama). Ini berarti bahwa segera setelah kami membuka situs di "swap API" dan memulai lalu lintas pengguna, semua pertanyaan, jawaban, komentar, dan suka yang baru dibuat tidak dapat lagi dengan mudah masuk ke database TheQuestion yang lama. Jika terjadi kesalahan setelah membuka, misalnya, satu basis data tidak dapat mengatasi beban, maka tidak akan mungkin untuk dengan cepat memutar kembali semuanya.

Padahal, tentu saja, saya melebih-lebihkan. Bagaimanapun, kami tidak akan kehilangan data pengguna. Kami memiliki rencana B dan cara untuk membuat cadangan data secara manual dari database baru ke yang lama. Tapi itu masih akan memakan waktu, dan kemunduran tidak akan terjadi tanpa rasa sakit bagi pengguna.

Untungnya, Rencana A berhasil, dan tidak ada yang harus dibatalkan.

Babak final

Jadi, backend diubah, database digabungkan, aplikasi mobile tidak dilupakan. Untuk pengguna, tidak ada yang berubah, karena situs Yandex.Ku, yang seharusnya menggabungkan data dari kedua situs, belum diluncurkan pada waktu itu. Dan untuk peluncurannya kami harus menyelesaikan satu masalah lagi.

Pada awalnya, saya menulis bahwa kami harus menggabungkan tidak hanya pertanyaan dan jawaban dari dua layanan dalam satu yang baru, tetapi juga pengguna. Pengguna seharusnya tidak hanya dapat melihat konten mereka di Kew, tetapi juga mengelolanya di Kew. Secara teknis, menggabungkan data dan mentransfer hak manajemen tidaklah sulit. Adalah jauh lebih sulit untuk memastikan bahwa hak-hak tersebut dialihkan kepada orang yang kepadanya mereka harus dipindahkan.

Saat pindah dari Znatokov ke Kew, semuanya sederhana: dalam kedua kasus, akun Yandex yang sama digunakan. Tetapi TheQuestion memiliki akun sendiri, yang tidak dapat diotorisasi pada Kew. Untungnya, kami memikirkan hal ini sebelumnya. Jauh sebelum tindakan yang dijelaskan di atas, kami memungkinkan pengguna TheQuestion untuk menautkan profil Yandex mereka. Dan pada saat konsolidasi fisik layanan, lebih dari 90% pengguna aktif telah melakukan ini. Ini memungkinkan kami memulai migrasi konten dan pengguna tanpa rasa sakit.

Total

Ketika kami pindah, kami ingin menyelamatkan setiap pengguna, jadi kami dengan sadar pergi ke opsi yang paling memakan waktu dan berisiko menggabungkan platform. Kami menciptakan basis teknologi terpadu, belajar cara mengirim konten dan profil secara instan. Alih-alih penutupan yang tak terduga dan relokasi paksa, mereka mempertahankan fungsionalitas layanan lama, meluncurkan layanan baru dan menjelaskan kelebihannya.

Kami meluncurkan Yandex.Kew tahun lalu. Sekarang, lebih dari 80% penulis aktif TheQuestion dan Znatokov secara sukarela pindah ke rumah baru.

Cara menggabungkan dua platform menjadi satu dan tidak menyinggung pengguna. Pengalaman Pengembang Yandex.Kew