Ada beberapa masalah dalam posting silang karena dialek penurunan harga di posting asli. Terutama diagram tidak ditampilkan yang ada di posting asli. Jadi silakan periksa yang asli juga jika Anda tertarik. Saya pikir yang asli lebih bisa dimengerti

Upgrade HBase di atas Sumber Acara dan arsitektur CQRS dalam 3 minggu

TL;DR

• Kami menggunakan strategi penerapan biru-hijau untuk pemutakhiran versi HBase di atas Sistem Sumber Acara dan arsitektur CQRS.
• Pendekatan penerapan bekerja cukup baik dan hanya membutuhkan total 3 minggu untuk mencapai tujuan proyek. Pengalaman ini baru dan menarik bagi kami. Jadi saya ingin membagikannya :)

Tentang peningkatan basis data

Pembaruan basis data selalu merepotkan dan setiap kali Anda menghadapi keadaan seperti itu dalam skenario produksi, Anda akan sangat gugup (Saya akan mengatakan 100 kali dibandingkan dengan operasi produksi lain yang Anda hadapi) .

Perasaan ini sulit untuk dibagikan dengan orang-orang yang tidak memiliki pengalaman atau paparan dalam mengoperasikan lingkungan Database. Dan saya pikir 99,9% orang akan setuju jika Anda memiliki pengalaman dan telah melalui masa-masa sulit dalam menangani operasi terkait database. Ini berisiko dan membutuhkan banyak biaya, tetapi peningkatan itu sendiri tidak berarti memberikan nilai baru pada produk dan meskipun tidak diprioritaskan dalam banyak kasus kecuali ada alasan mendesak.

Pada saat yang sama, ini adalah risiko tersembunyi yang sangat besar jika database menjadi "tak tersentuh" ​​dan bagaimana menangani masalah ini telah menjadi topik, banyak pengembang dan operator telah berjuang dengan situasi seperti itu

Pendekatan peningkatan

Secara umum, Anda memiliki dua pilihan.

peningkatan versi bergulir

Salah satunya adalah upgrade bergulir. Upgrade versi database satu per satu secara berurutan.
Saya menemukan penjelasan yang bagus di sini. Silakan baca ini jika Anda tidak terbiasa dengan kata tersebut.

Apa yang dimaksud dengan peningkatan berkelanjutan dalam pengembangan perangkat lunak?

• Pro

  • Data ada di satu tempat. Jadi, Anda tidak perlu memikirkan cara menyinkronkan data antar kluster yang berbeda dan bagaimana memastikan sinkronisasi bekerja dengan sempurna.

• Kontra

  • Setelah upgrade selesai, tidak ada cara mudah untuk mengembalikannya. Jadi, jika pemutakhiran memicu masalah kinerja, Anda akan berada dalam masalah besar.
  • Basis data yang berjalan lama memiliki beberapa keadaan tak terduga yang tidak dapat Anda reproduksi di lingkungan pengujian. Terkadang Anda perlu mengatasi masalah terkait produksi. Dan kemungkinan itu membuatmu sangat gugup.

penerapan biru-hijau

Yang lainnya adalah penyebaran biru-hijau. Dalam hal ini, Anda harus menyediakan cluster database yang ditingkatkan secara terpisah dan mengganti aplikasi untuk menggunakan yang baru di beberapa titik.
Silakan periksa posting blog ini jika Anda tidak terbiasa dengan kata "penempatan biru-hijau".

BlueGreenDeployment

Saya pikir pendekatan ini tersebar luas dalam penerapan aplikasi web, tetapi jika Anda mengganti kata "router" menjadi "aplikasi", dan "server web" menjadi "database", pendekatan yang sama dapat diterapkan pada peningkatan database.

• Pro

  • Anda tidak menyentuh database produksi yang sedang berjalan saat meningkatkan versi. Itu membuat hidup Anda jauh lebih mudah dibandingkan dengan pendekatan peningkatan versi bergulir.
  • Anda dapat dengan mudah kembali ke cluster lama ketika beberapa masalah tak terduga terjadi. Dan Anda juga dapat mendistribusikan permintaan secara bertahap sehingga Anda dapat meminimalkan cakupan jika Anda memiliki beberapa masalah (Untuk melakukan ini, seperti dalam "Kontra", Anda perlu menyinkronkan data dari cluster baru ke cluster lama)
  • Karena faktor di atas, Anda dapat mempersingkat pengujian beban pada lingkungan pengujian dan dapat melanjutkan proyek dengan cepat.

• Kontra

  • Anda perlu memastikan data disinkronkan antara kedua cluster database. Tidak hanya dari cluster lama ke cluster baru, tetapi juga dari cluster baru ke cluster lama jika Anda ingin memiliki cara mudah untuk kembali setelah upgrade. Tetapi replikasi data timbal balik cukup sulit dalam banyak kasus. Dimungkinkan untuk menulis ke dua klaster pada setiap operasi, tetapi Anda perlu bersiap ketika hanya satu klaster yang down dan operasi ke klaster itu saja yang gagal. Penanganan itu akan sangat rumit.
  • Anda harus memiliki server berukuran ganda saat menjalankan kedua cluster. Itu akan memakan biaya dan bisa jadi sulit jika sistem Anda tidak menggunakan infrastruktur cloud.

Pendekatan kami

Pada dasarnya, pendekatan kami adalah penerapan biru-hijau. Dan karena kami memiliki Kafka di depan sebagai bus sumber acara, jauh lebih mudah untuk menangani masalah sinkronisasi data di "Kontra" yang tercantum di atas.

Arsitektur saat ini

Pertama, izinkan saya memperkenalkan arsitektur dasar. Btw, kami menyebut seluruh sub-sistem pesan obrolan "Falcon". Itulah mengapa ikon elang ada di diagram.

1. ketika pengguna akhir memposting pesan obrolan, write-api memasukkan data pesan ke Kafka
2. read-model-updater (singkatnya "rmu") mengambil data dari Kafka, mengubahnya menjadi read-model dan memasukkannya ke dalam HBase
3. ketika pengguna akhir membaca pesan chat, read-api menarik data pesan dari HBase

Saya tidak menjelaskan mengapa kami memilih CQRS dalam posting ini. Jadi, silahkan cek slide-slide di bawah ini jika Anda ingin mengetahui secara detail atau jika Anda belum familiar dengan konsep CQRS.
Kafka Summit SF 2017 - Layanan Pesan Terukur dan Tangguh di Seluruh Dunia dengan Kafka dan Kafka Streams
Layanan Pesan Tangguh dan Skalabel Seluruh Dunia oleh CQRS dan Sumber Acara menggunakan Akka, Kafka Streams, dan HBase

Alur peningkatan basis data

Sekarang, saya akan menjelaskan bagaimana kita melakukan upgrade database di atas arsitektur ini

Langkah1: Siapkan cluster baru dan lakukan pemulihan awal dari pencadangan.

Langkah2: Siapkan konsumen lain (rmu2 dalam diagram ini) untuk menyinkronkan data dari Kafka ke cluster database baru. Anda akan memutar ulang acara Kafka lama mulai dari sebelum pemulihan awal. Pastikan Anda menerapkan idempotensi pada konsumen Anda. Maksud saya, sistem harus bekerja dengan baik meskipun kejadian yang sama dikonsumsi lebih dari sekali.

Langkah3: Ketika konsumen baru(rmu2) telah mengikuti pesan Kafka terbaru, siapkan data read-api yang menarik dari cluster database baru. Dan kirim permintaan ke read-api baru secara bertahap.

Akan ada beberapa perbedaan status antara cluster lama dan cluster baru meskipun sinkronisasi data selesai dalam beberapa milidetik. Kami memiliki masalah kecil karena perbedaan ini, jadi Anda perlu mengonfirmasi dan menjalankan pemeriksaan penilaian untuk melihat masalah seperti apa yang dapat dipicu melalui perbedaan antara cluster dan logika aplikasi Anda sebelumnya. Atau jika Anda memiliki beberapa lapisan yang baik di depan read-api untuk mendistribusikan permintaan sesuai dengan atribut pengguna atau sesuatu (misalnya perutean melalui Nginx atau Envoy seperti proxy), Anda dapat menetapkan aturan yang tepat di sana dan perbedaannya dapat ditangani secara efisien dan itu tidak akan menjadi masalah.

Dan dalam retrospeksi proyek ini, kami melihat bahwa jika Anda dapat mencerminkan permintaan dari api yang ada ke api baru, Anda dapat melakukan pengujian beban menggunakan lalu lintas produksi tanpa memengaruhi pengguna akhir.

Langkah4: Beralih ke read-api baru 100% dan matikan cluster dan aplikasi lama saat Anda yakin semuanya bekerja dengan sempurna.

Mengapa menurut saya pendekatan ini lebih baik

Mari saya jelaskan perbedaannya dengan pendekatan biru-hijau normal. Satu masalah dalam biru-hijau normal adalah Anda perlu memastikan bahwa data disinkronkan di kedua cluster, idealnya tidak hanya sebelum peningkatan tetapi juga setelah peningkatan. Dalam pendekatan ini, alih-alih menggunakan fungsionalitas replikasi yang disediakan database, pembaruan database diterapkan secara terpisah melalui aplikasi yang kami tulis dan siapkan. Pendekatan ini memberi kita banyak manfaat.

Pertama, karena mereka bekerja secara terpisah, Anda tidak perlu peduli bagaimana data disinkronkan pada setiap fase. Terutama, Anda akan memerlukan beberapa upaya ekstra (dan cukup sulit dalam banyak kasus) dalam menyinkronkan data dari cluster baru ke cluster lama jika Anda ingin memiliki cara mudah untuk kembali setelah upgrade. Namun dalam pendekatan ini, mereka hanya bekerja secara mandiri. Jadi Anda bisa kembali menggunakan yang lama jika beberapa masalah tak terduga mulai terjadi setelah pemutakhiran.

Kedua, Anda tidak perlu pusing memikirkan kompatibilitas versi antara cluster lama dan cluster baru. Jika Anda menggunakan fungsionalitas sinkronisasi data cluster yang disediakan database, akan ada beberapa pembatasan versi dan masalah kompatibilitas yang dapat terjadi dalam beberapa kasus tepi. Namun dalam pendekatan ini, yang perlu Anda lakukan adalah menyiapkan aplikasi independen yang memasukkan data ke dalam setiap database. Saya pikir itu adalah masalah yang dapat Anda selesaikan dengan lebih mudah dalam banyak kasus. Dan secara teori, tidak hanya memperbarui versi database tetapi Anda juga dapat mengalihkan cluster baru ke cluster yang sama sekali berbeda (mis. DynamoDB) menggunakan pendekatan yang sama. Dalam hal ini, Anda tidak dapat menggunakan data cadangan untuk penyiapan awal dan perlu menyiapkan program migrasi data awal. Itu akan memakan waktu, tapi saya pikir itu hal yang masuk akal untuk dihadapi.

Kesimpulan

CQRS dan mata pelajaran sumber acara sering dibahas dalam arsitektur perangkat lunak. Dari sudut pandang operasional, memiliki satu lapisan lagi sebagai bus acara meningkatkan kompleksitas infrastruktur dan biaya operasi. Sejujurnya, saya tidak terlalu menyukai pendekatan ini dari pandangan itu sebelumnya. Tetapi kami memperhatikan bahwa hal itu juga mengubah cara kami mengoperasikan infrastruktur dan memberi kami ketenangan dalam pengoperasian basis data. Dan ya, saya sangat senang dengan CQRS dan sumber acara sekarang :)

Tantangan berikutnya

Anda mungkin bertanya-tanya apa yang akan kami perbarui Kafka (bus sumber acara)? Ya, itu akan menjadi tantangan kami berikutnya. Saya harap ada pendekatan yang lebih baik daripada peningkatan bergulir normal dan penyebaran biru-hijau. Kehidupan insinyur terus berjalan!