Gambar di atas adalah rilis skala abu-abu Tencent, pengguna biasa dapat mengaksesnya, server Alibaba Cloud tidak dapat diakses, ping normal, dan IP resolusi juga normal
Hanya saja tidak dapat diakses, dapat dilihat bahwa Tencent juga suka bermain dengan rilis skala abu-abu ...
1. Mengapa Rilis Skala Abu-abu
- Layanan internet sering berubah dan siklus rilis singkat. Kecepatan dan kualitas selalu sulit dikombinasikan.
- Penerbitan skala abu-abu dapat mengurangi risiko penerbitan dan mengurangi cakupan dampak.
- Kurangi ketergantungan pada pengujian dan kurangi biaya konstruksi data untuk pengujian mandiri offline.
- Lebih mudah untuk memantau log secara terpusat dan menerbitkannya secara penuh Karena peran penyeimbangan beban di setiap lapisan, sulit untuk melacak tautan panggilan lengkap.
- Anda dapat menggunakan akun pengujian Grayscale, lalu akun pengguna nyata skala abu-abu setelah akun pengujian lulus untuk lebih mengurangi risiko dan dampak penerbitan.
- Rollback mudah.
Masalah yang tidak dapat diselesaikan dengan rilis skala abu-abu
Perlu ditekankan bahwa "dampak yang dapat ditoleransi" yang disebutkan di atas harus dapat dipulihkan, misalnya, API tidak dapat dipanggil untuk jangka waktu tertentu, tetapi setelah diperbaiki, dapat berhasil dipanggil. Kehilangan atau penghancuran permanen data pengguna (seperti informasi produk, informasi pesanan, dll.) tidak dapat ditoleransi. Oleh karena itu, adalah tanggung jawab arsitek perusahaan Internet untuk memperbaiki data pengguna yang hilang ke keadaan terbaru (seperti satu jam yang lalu hingga seminggu yang lalu) melalui intervensi manual jika terjadi hilangnya data pengguna karena gangguan sistem produksi (seperti pencadangan data pengguna secara teratur, menulis log operasi, dll.).
TIPS Uji kebijakan skala abu-abu akun Anda terlebih dahulu untuk mengurangi risiko kerusakan atau kehilangan data pengguna nyata.
2. Efek apa yang diharapkan?
Terlepas dari perubahannya, kami ingin permintaan tertentu dirutekan ke versi perubahan kami (versi skala abu-abu) untuk pengamatan dan validasi.
3. Strategi skala abu-abu
Faktanya, permintaan apa yang harus dirutekan ke versi skala abu-abu kita (mesin skala abu-abu). Ini seringkali sangat terkait dengan bisnis. Misalnya, untuk API, umumnya ada persyaratan berikut:
Pengguna tertentu (misalnya, akun pengujian)
Aplikasi tertentu (misalnya, aplikasi uji atau aplikasi partner)
Modul dan antarmuka tertentu (hanya beberapa antarmuka yang memerlukan skala abu-abu, yang umumnya merupakan modifikasi dari kontainer API, dan beberapa API yang tidak terlalu penting digunakan untuk pengujian skala abu-abu.) ）
Mesin tertentu (beberapa IP permintaan diteruskan ke mesin skala abu-abu)
4. Diskusi tentang skema skala abu-abu
Solusi 1: Tingkat kode dinilai dengan bendera yang disepakati, dan yang lama dan baru dialihkan secara dinamis - pendekatan Amazon
Implementasi:
Kubur sakelar dalam kode, buat penilaian jika-lain, dan atur sakelar ke aktif untuk mesin yang memerlukan skala abu-abu, jika tidak, akan mati. Ada dua versi untuk setiap rilis.
Merit
Rollback cepat, tidak perlu menerbitkan ulang dan me-reboot sistem.
Kekurangan
Cenderung membuat kode.
Logika percabangan membawa kompleksitas.
Metode ini digunakan oleh penulis ketika saya berada di Alibaba, mengalihkan database barang dari Oracle ke MySql, dan menggunakan variabel status untuk kontrol. Dengan demikian mencapai efek migrasi yang lancar.
Opsi 2: Mesin pra-rilis - Praktik Alibaba
Faktanya, ini bukan skala abu-abu dalam arti sebenarnya. Karena mesin pra-rilis ini adalah IP internal dan tidak memiliki layanan eksternal. Pengikatan domain diperlukan untuk verifikasi. Tetapi datanya sepenuhnya online. Jadi ini pada dasarnya adalah pendekatan sederhana untuk beberapa pengguna Grayscale tertentu (pengguna yang memiliki akses ke mesin grayscale, pengguna pengujian internal). Faktanya, ada pendekatan serupa di sisi API, yaitu lingkungan Gamma kami, dan kami juga menyediakan nama domain mesin Gamma untuk memfasilitasi pengguna koperasi eksternal untuk bekerja sama dengan pengujian.
Merit
Sederhana
Kekurangan
Buang mesin (ini dapat dimasukkan ke dalam lingkungan produksi setelah pra-rilis selesai, dan dihapus dari nginx selama pra-rilis, tetapi dukungan O&M diperlukan.) ）
Tidak cukup fleksibel
Layanan IDL hanya dapat digunakan untuk mesin lapisan akses, dan layanan IDL perlu dipertimbangkan secara terpisah.
Opsi 3: Penerapan SET
1. Terapkan secara terpisah sesuai dengan layanan
Misalnya, dalam praktik kontainer API saat ini, granularitas penyebaran dapat dicapai ke tingkat API, dan front-end ke depan sesuai dengan nginx. Seperti apa:
Kontainer API Belanja Mikro: api.weigou.qq.com
Pat API Container:api.paipai.com
Kontainer API Yixun: api.yixun.com
API belanja online Container:api.buy.qq.com
Di atas adalah penyebaran terisolasi di tingkat bisnis besar. Ini juga dapat disempurnakan lebih lanjut ke tingkat modul, seperti API e-commerce layanan virtual, yang merupakan modul sub-bisnis yang tergantung di bawah Paipai, tetapi karena terhubung ke WeChat, jumlah kunjungan telah meningkat secara signifikan, untuk menghindari mempengaruhi bisnis Paipai lainnya, dan untuk menghindari terpengaruh oleh bisnis lain, API di sini adalah untuk menyebarkan dua mesin secara terpisah untuk mereka, nginx dapat dikonfigurasi untuk menguras akses API virtual:
Kontainer API Virtual: http://api.paipai.com/v2/virbiz
Dengan cara ini, ketika kami merilis versi, pertama-tama kami dapat memilih Yixun dengan volume bisnis terkecil untuk diterbitkan, dan kemudian mengamati bahwa tidak ada masalah sebelum menggunakan semua platform lain.
2. Terapkan dengan isolasi pengguna
Ini tidak terlalu cocok untuk platform terbuka, tetapi sangat cocok untuk skenario aplikasi seperti SNS. Misalnya, sistem QQ dibagi menjadi beberapa set sesuai dengan segmen nomor pengguna, dan setiap set berisi 100 juta angka berturut-turut. Dengan asumsi bahwa angka QQ terbaru mendekati 1 miliar, ada total 10 set (Set 1 hingga Set 10). Dengan cara ini, Anda dapat memilih salah satu SET untuk dipublikasikan setiap kali, dan QQ tingkat tinggi seringkali bukan pengguna yang sangat penting, jadi SET10 akan dirilis terlebih dahulu.
Merit
Penerapan terisolasi dengan dampak minimal di seluruh lini bisnis. Secara otomatis mendukung penerbitan skala abu-abu.
Kekurangan
Granularitas skala abu-abu tergantung pada granularitas penyebaran terisolasi, yang umumnya besar.
Pemborosan mesin dibandingkan dengan penyebaran terpusat.
Versi setiap lini bisnis mungkin tidak konsisten, yang tidak kondusif untuk manajemen terpadu.
Ada biaya implementasi dan penerapan tertentu
Skema 4: Perutean dinamis
Metode: Gunakan kebijakan skala abu-abu yang dapat dikonfigurasi secara fleksibel untuk memengaruhi perilaku keseimbangan beban dan memungkinkannya mengembalikan IP dan port layanan skala abu-abu sesuai dengan kebijakan skala abu-abu.
Cocok untuk layanan skala abu-abu dengan IDL back-office.
Merit
Fleksibel, dapat dikendalikan.
Kekurangan
Pusat konfigurasi saat ini dan L5 sendiri tidak mempertimbangkan kebijakan perutean yang ditentukan, dan tidak dapat diskalakan, sehingga perlu dikembangkan di luarnya.
Sumber metadata API relatif tersebar, dan saat ini metadata API dan IDL, tingkat API, dan batas frekuensi didistribusikan di berbagai sumber data, dan sekarang perlu menambahkan sumber data perutean skala abu-abu.
Umumnya ada tiga cara untuk mempublikasikan skala abu-abu nginx+lua, nginx didistribusikan sesuai dengan cookie, dan nginx ditetapkan sesuai dengan berat:
nginx+lua membedakan sesuai dengan alamat IP pengunjung, karena perusahaan mengekspor alamat IP, dan situs web akan diakses baik versi lama atau versi baru, yang tidak cocok untuk metode ini
nginx menetapkan bobot berdasarkan bobot, yang mudah diterapkan dan dapat dicoba
nginx membagi berdasarkan cookie, dan skala abu-abu menerbitkan berdasarkan pengguna
|
Diposting pada 09/03/2017 15.48.27
|
|
|
|
