Anda dapat memigrasikan instans API Gateway asli ke Cloud-native API Gateway untuk memastikan kelangsungan layanan selama masa transisi.
1. Ikhtisar
Cloud-native API Gateway adalah produk gerbang utama yang sedang aktif dikembangkan. Jika Anda menggunakan API Gateway asli, Anda dapat memigrasikan layanan Anda ke Cloud-native API Gateway. Setelah mengonfigurasi metadata API di Cloud-native API Gateway, Anda dapat secara bertahap mengalihkan lalu lintas layanan dengan mengubah pengaturan resolusi nama domain Anda.
Perbedaan konseptual antara kedua gerbang
Untuk menyelaraskan dengan standar OpenAPI Specification (OAS), API Gateway asli dan Cloud-native API Gateway memiliki perbedaan konseptual penting. Pahami perbedaan ini sebelum memulai migrasi:
Grup API di API Gateway asli bersesuaian dengan API di Cloud-native API Gateway.
API di API Gateway asli bersesuaian dengan operasi di Cloud-native API Gateway.
Skenario di mana migrasi tidak disarankan
Migrasi tidak disarankan dalam skenario berikut:
Pengguna Alibaba Cloud Marketplace: Cloud-native API Gateway belum terintegrasi dengan Alibaba Cloud Marketplace. Migrasi tidak disarankan untuk pengguna ini saat ini.
2. Prosedur migrasi
2.1. Beli instans cloud-native
Saat membeli instans Cloud-native API Gateway, perhatikan dua poin berikut:
Batas tipe instans berbeda antara API Gateway asli dan Cloud-native API Gateway. Evaluasi ulang kapasitas layanan Anda berdasarkan spesifikasi instans Cloud-native API Gateway. Untuk informasi lebih lanjut tentang kapasitas, lihat Deskripsi kapasitas.
Saat membuat instans, pilih virtual private cloud (VPC) tempat layanan backend Anda berada. Jika tidak, akses layanan akan gagal karena VPC tidak dapat berkomunikasi.
2.2. Konfigurasikan metadata API
2.2.1. Konfigurasikan nama domain dan sertifikat
Setelah membuat instans Cloud-native API Gateway, konfigurasikan nama domain layanan dan sertifikat yang sesuai pada instans tersebut. Untuk informasi lebih lanjut, lihat dokumen berikut:
Ubah protokol domain dan sertifikat
Cloud-native API Gateway menyediakan konfigurasi enkripsi Secure Sockets Layer (SSL) yang lebih fleksibel. Anda dapat mengonfigurasi pengaturan setara berdasarkan Versi TLS dan paket sandi dalam kebijakan keamanan HTTPS grup API Gateway asli:
Login ke Konsol API Gateway asli.
Di panel navigasi kiri, klik API Management > Group Management. Klik nama grup untuk membuka halaman detail grup dan temukan tipe kebijakan keamanan HTTPS.
Untuk detail versi TLS dan paket sandi yang sesuai, lihat Kebijakan keamanan HTTPS.
Konfigurasikan pengaturan setara di Cloud-native API Gateway. Untuk informasi lebih lanjut, lihat Atur paket sandi HTTPS tertentu.
Catatan:
Cloud-native API Gateway tidak memiliki konsep lingkungan. Nama domain hanya dapat disambungkan ke instans. Fitur penempelan lingkungan dari API Gateway asli tidak memiliki padanan di Cloud-native API Gateway.
Cloud-native API Gateway saat ini tidak mendukung OCSP atau transmisi langsung ssl_client_s_dn. Jika Anda menggunakan fitur-fitur ini, migrasi tidak disarankan saat ini.
Cloud-native API Gateway saat ini tidak mendukung parameter nama domain berbasis Nama domain wildcard. Jika Anda menggunakan parameter nama domain, migrasi tidak disarankan saat ini.
2.2.2. Impor definisi API
Baik API Gateway asli maupun Cloud-native API Gateway mendukung protokol OAS standar. Anda dapat mengekspor definisi API dari API Gateway asli sebagai file yang sesuai dengan OAS, lalu mengimpor file tersebut ke Cloud-native API Gateway.
Ekspor definisi API seluruh grup dari API Gateway asli. Untuk informasi lebih lanjut, lihat Ekspor definisi OAS standar.
Login ke Konsol API Gateway.
Di panel navigasi kiri, pilih API Management > Group Management.
Di halaman Group List, pilih grup API target. Di kolom Actions, klik Export API Definition.
Di kotak dialog Export API Definition, tentukan format data untuk ekspor.
Anda harus mengekspor definisi API dalam protokol OAS 3.0. Jangan pilih definisi ekstensi API Gateway. Ekspor langsung definisi API online.
Impor file definisi API yang telah diekspor dari API Gateway asli ke Cloud-native API Gateway.
Login ke Konsol Cloud-native API Gateway. Di panel navigasi kiri, pilih APIs, dan pilih wilayah di bilah menu atas.
Klik Create API. Di bagian REST API, klik Import dan unggah file definisi API yang diekspor pada langkah sebelumnya.
Poin penting:
Cloud-native API Gateway memerlukan plugin transformasi request/response untuk menerapkan pemetaan parameter.
Cloud-native API Gateway saat ini tidak memiliki fitur anti-replay. Jika Anda memerlukan fitur ini, migrasi tidak disarankan saat ini.
2.2.3. Konfigurasikan layanan backend
Selanjutnya, konfigurasikan layanan backend pada instans tersebut. Layanan backend yang didukung oleh API Gateway asli dan Cloud-native API Gateway sedikit berbeda:
Original API Gateway | Cloud-native API Gateway |
Otorisasi VPC (HTTP/HTTPS) | Didukung (Alamat tetap/Nama domain DNS) |
Alamat Internet (HTTP/HTTPS) | Didukung (Alamat tetap/Nama domain DNS, memerlukan NAT) |
Function Compute | Dukungan |
EventBridge | Tidak didukung |
Nacos/Zookeeper | Didukung |
Mock | Didukung |
DataWorks | Didukung, buka Konsol DataWorks untuk mengoperasikannya |
Dataphin/DMS | Tidak didukung |
OSS | Tidak didukung |
Untuk layanan backend umum seperti ECS dan CLB, buat layanan alamat tetap di Cloud-native API Gateway:
Login ke Konsol Cloud-native API Gateway.
Di panel navigasi kiri, pilih Instances, dan pilih wilayah di bilah menu atas.
Di halaman Instances, klik ID instans gerbang target.
Di panel navigasi kiri, pilih Services, dan klik Create Service. Di panel Create Service, atur Service Source ke Fixed Address, konfigurasikan parameter terkait, lalu klik OK.
Catatan:
Cloud-native API Gateway berkomunikasi dengan layanan backend melalui Elastic Network Interface (ENI) Anda. Saat menambahkan alamat ke daftar putih, gunakan Blok CIDR vSwitch instans. Untuk menemukan Blok CIDR, buka halaman detail instans, temukan koneksi vSwitch, lalu klik untuk melihat Blok CIDR yang sesuai.
Jika layanan backend berada di Internet, VPC yang digunakan oleh instans Cloud-native API Gateway harus memiliki Gateway NAT Internet. Uji hal ini secara menyeluruh sebelum migrasi.
Jika layanan backend Anda ditempatkan di beberapa VPC, Anda harus menggunakan CEN atau PrivateLink untuk membangun konektivitas jaringan sebelum dapat melakukan migrasi.
2.2.4. Publikasikan API
Setelah menyelesaikan konfigurasi di atas, publikasikan API ke instans yang telah dibeli untuk pengujian. Logika publikasi Cloud-native API Gateway sangat berbeda dari API Gateway asli.
Publikasi di API Gateway asli:
Grup API diikat ke instans tertentu. Anda tidak dapat memilih instans saat publikasi. API dipublikasikan ke instans grupnya secara default.
Layanan backend untuk API telah dikonfigurasi sebelumnya. Anda tidak perlu menentukannya setiap kali mempublikasikan.
Nama domain permintaan dikonfigurasi pada grup dan tidak dapat diubah saat publikasi.
Anda harus menentukan lingkungan untuk setiap publikasi. Anda hanya dapat mempublikasikan ke satu lingkungan dalam satu waktu.
Anda hanya dapat mempublikasikan satu API dari grup dalam satu waktu.
Publikasi di Cloud-native API Gateway:
Saat mempublikasikan API, Anda harus memilih instans hosting. Konten yang dipublikasikan hanya berlaku pada instans yang dipilih. API dapat dipublikasikan ke beberapa instans.
Anda harus menentukan layanan backend setiap kali mempublikasikan. Anda dapat mengubah layanan backend saat publikasi.
Anda harus memilih nama domain permintaan setiap kali mempublikasikan. Jika beberapa nama domain menyediakan layanan, Anda harus memilih semuanya saat publikasi.
Tidak ada konsep lingkungan. Instans umumnya digunakan untuk membedakan lingkungan.
Semua operasi di bawah API dipublikasikan sekaligus. Anda tidak dapat mempublikasikan satu operasi saja.
2.2.5. Konfigurasikan plugin
Setelah API dipublikasikan ke instans, Anda dapat mengonfigurasi kebijakan untuk API atau operasinya. Kebijakan yang didukung oleh Cloud-native API Gateway dan plugin yang didukung oleh API Gateway asli sangat berbeda. Tabel berikut mencantumkan perbedaan utamanya.
API Gateway asli | Kebijakan/plugin Cloud-native API Gateway yang sesuai |
Plugin otorisasi pihak ketiga | Plugin autentikasi eksternal Catatan tentang plugin autentikasi eksternal Cloud-native API Gateway:
|
Plugin JWT | Plugin JWT Catatan tentang plugin autentikasi JWT Cloud-native API Gateway:
|
Plugin BasicAuth | Autentikasi dasar |
Plugin penandatanganan backend | Saat ini tidak didukung oleh Cloud-native API Gateway |
Plugin pembatasan kecepatan - Pembatasan dasar | Kebijakan pembatasan kecepatan
|
Plugin pembatasan kecepatan - Pembatasan berbasis parameter | Pembatasan kluster berbasis kunci |
Plugin kontrol akses IP | Pembatasan IP |
Plugin kontrol akses parameter | Kontrol akses parameter |
Plugin akses sumber daya lintas domain | Berbagi sumber daya lintas origin |
Plugin caching | Caching respons umum |
Plugin routing backend | Layanan di Cloud-native API Gateway secara native mendukung routing berdasarkan kondisi pencocokan dan juga mendukung routing grayscale. |
Plugin pemetaan kode error | Plugin respons kustom: |
Plugin pemutusan sirkuit | Kebijakan pemutusan sirkuit: |
Plugin desensitisasi log | Saat ini tidak didukung oleh Cloud-native API Gateway |
Plugin penulisan ulang request/response | Transformasi request/response |
Untuk informasi lebih lanjut tentang plugin API Gateway asli, lihat Ikhtisar plugin.
Untuk informasi lebih lanjut tentang plugin Cloud-native API Gateway, lihat Pasar plugin.
2.2.6. Konfigurasikan informasi otorisasi aplikasi
Migrasi aplikasi (APP)
Konsep "aplikasi" di API Gateway asli disebut "konsumen" di Cloud-native API Gateway. Kemampuannya setara, dan Anda dapat memigrasikan fitur ini dengan lancar. Untuk informasi lebih lanjut tentang mengelola konsumen di Cloud-native API Gateway, lihat Kelola konsumen.
Penting:
Kunci API konsumen di Cloud-native API Gateway sama dengan AppCode aplikasi di API Gateway asli. Anda dapat menghasilkan kunci API khusus untuk memigrasikan AppCode dari aplikasi asli.
AccessKey (AK) dalam Hash-based Message Authentication Code (HMAC) konsumen di Cloud-native API Gateway sama dengan AK aplikasi di API Gateway asli. Anda dapat menghasilkan AK khusus untuk memigrasikan AK dari aplikasi asli.
Migrasi hubungan otorisasi
Otorisasi konsumen di Cloud-native API Gateway berbasis operasi, yang konsisten dengan API Gateway asli. Anda dapat mengonfigurasi hubungan otorisasi untuk operasi API tertentu di halaman operasi API. Anda juga dapat memberikan otorisasi batch untuk operasi API kepada konsumen di halaman konsumen.
3. Verifikasi fungsi
Setelah mengonfigurasi semua metadata API, mulailah verifikasi fungsi. Karena nama domain resmi saat ini sedang digunakan di produksi pada API Gateway asli, Anda memiliki dua opsi untuk pengujian:
Konfigurasikan nama domain pengujian di Cloud-native API Gateway dan buat Rekaman CNAME yang memetakan nama domain pengujian ke titik akhir instans untuk pengujian.
Ubah konfigurasi host mesin pengujian Anda untuk menggunakan nama domain produksi asli dalam pengujian.
Setelah menyelesaikan masalah titik akhir, lakukan integrasi sistem. Cloud-native API Gateway menyediakan SDK untuk diunduh. Anda dapat mengunduh kode contoh untuk memanggil semua operasi di bawah API langsung dari halaman detail API.
4. Migrasi grayscale layanan produksi
Setelah verifikasi fungsi menyeluruh, Anda dapat secara bertahap memigrasikan layanan Anda dari API Gateway asli ke Cloud-native API Gateway. Gunakan rencana grayscale selama proses migrasi. Migrasikan secara perlahan sehingga Anda dapat mengembalikan semua layanan ke API Gateway asli kapan saja jika mengalami masalah. Kami menyarankan agar Anda secara bertahap memigrasikan layanan produksi dengan mengubah bobot resolusi nama domain produksi Anda. Untuk informasi lebih lanjut, lihat Konfigurasikan bobot.
Di halaman Informasi Dasar instans, temukan titik akhir instans Cloud-native API Gateway.
Buat Rekaman CNAME yang memetakan nama domain produksi Anda ke titik akhir instans Cloud-native API Gateway. Mulailah dengan bobot 1, lalu tingkatkan secara bertahap.
Anda harus mengontrol bobot awal Rekaman CNAME baru. Kami sangat menyarankan agar Anda menjaga bobot di bawah 1% dan memantau setidaknya selama 24 jam sebelum meningkatkan bobot trafik.
Pemantauan layanan
Anda dapat melihat status operasional layanan Anda di modul Observation & Analysis instans. Untuk informasi lebih lanjut, lihat Lihat data pemantauan gerbang. Jika tidak ada anomali selama pemantauan layanan, Anda dapat terus meningkatkan bobot trafik secara bertahap.
Rollback
Jika Anda menemukan anomali selama migrasi grayscale, segera hapus Rekaman CNAME untuk titik akhir Cloud-native API Gateway dari nama domain produksi Anda. Hal ini akan mengembalikan layanan Anda. Setelah menyelesaikan masalah, Anda dapat melanjutkan migrasi.