Microservices Engine:Strategi rilis layanan

Blue-green deployment

Blue-green deployment adalah teknik penyebaran redundan untuk merilis layanan. Sebelum rilis, layanan diterapkan dalam dua versi dengan tipe instans dan jumlah instans yang sama. Versi asli menyediakan layanan sementara versi baru berada dalam mode hot standby. Saat versi layanan ditingkatkan, lalu lintas dapat dialihkan ke versi baru, dan versi asli dipindahkan ke mode hot standby. Metode ini memastikan ketersediaan sumber daya yang cukup untuk versi baru. Jika terjadi masalah pada versi baru setelah dirilis, lalu lintas dapat dialihkan kembali ke versi asli, mengurangi waktu pemulihan kesalahan. Setelah versi baru diperbaiki dan diterapkan ulang, lalu lintas dapat dialihkan kembali ke versi tersebut.

Blue-green deployment menggunakan sumber daya instans tambahan untuk memastikan ketersediaan selama rilis layanan.

Gambar berikut menunjukkan bahwa versi asli v1 dari layanan menangani lalu lintas, sementara versi baru v2 diterapkan dalam mode hot standby. Jika Anda ingin meningkatkan versi layanan, Anda dapat mengalihkan lalu lintas ke v2.

Jika v2 mengalami masalah, rollback cepat ke v1 dilakukan, seperti yang ditunjukkan pada gambar berikut.

• Manfaat:

  • Mudah diimplementasikan dan mudah dalam O&M.

  • Sederhana dan cepat untuk melakukan peningkatan layanan.

• Kekurangan:

  • Membutuhkan sumber daya redundan. Dua lingkungan produksi identik harus diterapkan.

  • Mempengaruhi lebih banyak layanan jika versi baru mengalami masalah.

A/B testing

A/B testing mengarahkan lalu lintas ke versi baru layanan berdasarkan metadata permintaan pengguna. A/B testing merupakan strategi rilis canary yang mengontrol routing berdasarkan konten permintaan. Hanya permintaan yang memenuhi aturan tertentu yang diarahkan ke versi baru. Metode routing umum mencakup header HTTP dan cookie. Misalnya, Anda dapat menentukan bahwa versi baru hanya dapat diakses oleh permintaan dengan nilai User-Agent Android. Pengguna non-Android tetap mengakses versi asli. Anda juga dapat mengonfigurasi aturan routing berbasis cookie, yang berisi data pengguna dengan semantik bisnis. Contohnya, Anda dapat mengizinkan versi baru diakses oleh pengguna reguler, sementara versi asli diakses oleh pengguna VIP.

Gambar berikut menunjukkan bahwa layanan memiliki v1 sebagai versi saat ini dan v2 sebagai versi baru yang akan dirilis. Dalam hal ini, pengguna Android mengakses v2, sedangkan pengguna non-Android tetap mengakses v1.

Anda dapat memantau tingkat keberhasilan akses dan waktu respons (RT) dari v1 dan v2. Jika v2 bekerja sesuai harapan, semua permintaan dapat dialihkan ke v2. Pada titik ini, Anda dapat menghentikan v1 untuk mengurangi biaya.

• Manfaat:

  • Mempengaruhi lebih sedikit layanan jika versi baru mengalami masalah karena hanya memberikan versi baru kepada permintaan dan pengguna tertentu.

  • Membutuhkan platform pemantauan lengkap untuk membandingkan permintaan antar versi.

• Kekurangan:

  • Membutuhkan redundansi sumber daya karena ketidakmampuan memperkirakan kapasitas permintaan.

  • Mengakibatkan siklus rilis yang panjang.

Rilis canary

Rilis canary mengarahkan sejumlah kecil lalu lintas ke versi baru layanan. Instans yang lebih sedikit diperlukan untuk menerapkan versi baru. Setelah Anda memastikan bahwa versi baru bekerja sesuai harapan, Anda dapat secara bertahap memigrasikan lalu lintas dari versi asli ke versi baru dengan menyesuaikan bobot lalu lintas yang ditetapkan untuk kedua versi tersebut. Selama proses ini, Anda dapat meningkatkan kapasitas versi baru dan mengurangi kapasitas versi asli untuk memaksimalkan pemanfaatan sumber daya dasar.

Gambar berikut menunjukkan bahwa layanan memiliki v1 sebagai versi saat ini dan v2 sebagai versi baru yang akan dirilis. Untuk memastikan peningkatan versi yang lancar tanpa kehilangan layanan, Anda dapat menggunakan rilis canary untuk secara bertahap memigrasikan lalu lintas dari versi asli ke versi baru.

• Manfaat:

  • Mempengaruhi lebih sedikit layanan jika versi baru mengalami masalah karena lalu lintas diarahkan ke versi baru berdasarkan bobot.

  • Memungkinkan pemanfaatan sumber daya yang lebih tinggi karena Anda dapat secara bertahap menambah kapasitas versi baru dan mengurangi kapasitas versi asli selama rilis canary.

• Kekurangan:

  • Dapat mempengaruhi pengalaman pengguna VIP karena semua lalu lintas diarahkan secara tidak pandang bulu ke versi baru.

  • Mengakibatkan siklus rilis yang panjang.