Pembelian akaun Google Cloud: Prinsip pecutan GoogleCloudCDN dan tutorial konfigurasi

Dalam kalangan laut dan pasukan SaaS multinasional, ketika berbicara mengenai percepatan rangkaian, reaksi pertama banyak orang adalah membeli pelbagai CDN pihak ketiga. Tetapi jika perniagaan, pelayan, atau penyimpanan anda sendiri telah diletakkan di Google Cloud (GCP), maka tinggalkan yang asli

Google Cloud CDN

Ia hanyalah perkara yang ganas.

Ramai saudara tidak tahu apa-apa tentang kuasa Google. Hari ini kita akan merobek dokumen rasmi yang tidak jelas dan bercakap dalam bahasa biasa: Mengapa CDN Google Cloud membolehkan pengguna di seluruh dunia mengakses anda secepat rangkaian tempatan? Dan bagaimana kita mengelakkan lubang caj tersembunyi dalam konfigurasi sebenar.

Bahagian pertama: Serangan pengurangan dimensi untuk Google Cloud CDN: seni bina Anycast

Bagaimana CDN biasa berfungsi? Setelah anda melengkapkan nama domain, pengeluar CDN akan memberi anda alamat CNAME. Semasa pengguna mengakses, permintaan pengguna "dialihkan" ke simpul yang paling dekat dengannya melalui resolusi DNS. Kaedah ini sangat tradisional, tetapi mempunyai kekurangan:

Resolusi DNS memerlukan masa, dan sering diselesaikan di tempat yang salah ketika melintasi operator.

Dan Google telah mengambil jalan yang sama sekali berbeza, ia menggunakan teknologi hitam utama di Internet --

Global Single IP Anycast (Global Anycast IP)

。

Anda boleh melihat rajah seni bina di atas, ini adalah kekejaman Google Cloud Network:

Dunia berkongsi IP: Sama ada pengguna anda berada di Los Angeles (LAX) atau New York (NYC), apabila mereka melayari laman web anda, IP rangkaian awam yang diselesaikan adalah sama.

Pemintasan langsung simpul tepi: Seperti yang ditunjukkan dalam gambar, pengguna di Los Angeles mengajukan permintaan, dan lalu lintas langsung dipintas oleh simpul tepi tempatan Google di Los Angeles (Edge POP LAX) di lapisan penghalaan rangkaian.

Transanet yang mengerikan kembali ke sumber: Bagaimana jika tidak ada data yang diminta oleh pengguna di Edge Caches? Sekiranya anda beralih ke CDN biasa, anda harus menggunakan rangkaian awam yang sesak di seberang lautan. Setelah simpul tepi Google memintas lalu lintas, ia akan langsung dimasukkan ke dalam rangkaian tulang belakang serat optik peribadi global (Google Network) yang ditarik oleh Google sendiri, dan lampu hijau menyala kembali ke stesen sumber anda sepanjang jalan.

Vernakular veteran: Dengan Google Cloud CDN, pengguna bahkan belum memulakan pencarian jalan DNS multinasional yang panjang, dan mereka telah memuat turun laman web di simpul Google beberapa kilometer darinya.

Bahagian 2: Ajar anda cara mengkonfigurasi CDN Google Cloud

Dalam GCP,

Cloud CDN tidak boleh dibuat secara bebas

。 Ia secara langsung "parasit" di

Beban global GCP

Keseimbangan (Cloud Load Balancing, disebut sebagai HtpClient/HTTPS LB)

Suis pada.

Mari kita mempercepat laman web yang dihoskan di Compute Engine sebagai contoh, dan melalui proses konfigurasi standard:

Langkah 1: Buat pengimbangan beban dan hidupkan suis CDN

Log masuk ke konsol GCP, cari perkhidmatan rangkaian $ \ right arrow $ Load Balancing (Load Balancing), dan klik Buat.

Pilih pengimbangan beban HTTPS (mod penyebaran global) "Dari Internet ke mesin maya saya".

Semasa mengkonfigurasi Perkhidmatan Backend, pilih Kumpulan Instance di mana anda meletakkan laman web.

[Langkah Teras]: Di bahagian bawah konfigurasi perkhidmatan back-end, anda akan melihat kotak centang yang tidak jelas: "Enable Cloud CDN" (Aktifkan Cloud CDN). Tanpa ragu-ragu, tandakannya!

Langkah 2: Pilih "Mod Cache" anda (Mod Cache)

Setelah memeriksa CDN, sistem akan membiarkan anda memilih

Mod cache

, Berikut adalah pilihan utama yang menentukan prestasi dan dompet anda:

Mod 1: Gunakan tajuk tindak balas stesen sumber (Default). Hanya apabila kod belakang anda (seperti Nginx atau Node.js) dengan jelas mengembalikan Cache-Control: awam, max-age = 3600, GCP akan cache. Sekiranya kod belakang anda tidak dilengkapi, CDN tidak berguna, dan lalu lintas menembusi setiap hari.

Mod 2: Cache semua kandungan statik (RECOMMENDED). Sangat disyorkan untuk memilih ini untuk stesen atau aplikasi bebas laut. Google akan mengenali gambar, video, CSS, dan JS secara automatik untuk cache.

Mod 3: Memaksa cache semua kandungan (Force Cache). Tidak kira apa yang dikatakan oleh bahagian belakang, ia akan menjadi cache. [Dakeng] Kecuali laman web anda adalah semua laman web yang statik, jangan pilih ini! Setelah dipilih, status log masuk pengguna, keranjang belanja, dan API sensitif latar belakang juga akan disimpan di seluruh rangkaian, yang secara langsung menyebabkan kemalangan nombor siri penyangak yang serius.

Bahagian 3: Panduan Mengelakkan Lubang "Jimat Wang dan Kehidupan" Veteran Operasi dan Penyelenggaraan

Perkara Google mudah digunakan, tetapi "mahal" juga benar. Sekiranya konfigurasi tidak betul, bil lalu lintas bulanan boleh membuat anda sakit. Tiga perkara berikut adalah pelajaran yang diambil oleh burung tua dengan wang sebenar:

1. Berhati-hati dengan penagihan berganda yang disebabkan oleh "pengembalian API dinamik"

Sekiranya nama domain anda (seperti

Api.yourdomain.com

) Semua disambungkan ke load balancing CDN, walaupun anda meletakkan

/Api/

Laluan ditetapkan untuk tidak menyimpan cache, tetapi lalu lintas dinamik ini masih akan melalui rangkaian nod CDN.

Google menyasarkan

Mengikut

Lalu lintas dinamik melalui nod CDN tetapi tidak terpukul (CDN Cache Misses)

, Bayaran lalu lintas rangkaian yang dikenakan selalunya sedikit lebih mahal daripada lawatan rangkaian awam pengimbangan beban biasa.

Pendekatan yang betul: sumber statik (gambar, fail front-end) mengambil subdomain bebas (seperti static.yourdomain.com) dan membuka CDN; API dinamik murni mengambil subdomain lain, tidak membuka CDN, dan secara langsung mengambil pengimbangan beban, sehingga tagihan akan jauh lebih baik.

2. Gunakan "liputan TTL" dengan baik untuk mengelakkan stesen sumber dihanyutkan

Dalam konfigurasi, disarankan untuk menetapkannya secara manual

"Masa kegagalan cache maksimum (Maximum TTL)"

。 Contohnya, tetapkan hingga 7 hari.

Dengan cara ini, walaupun Nginx di bahagian belakang anda secara tidak sengaja menulis fail konfigurasi yang salah, menyebabkan beberapa gambar statik tidak mempunyai tajuk cache, Google akan memaksa anda untuk menahan lalu lintas selama 7 hari di simpul tepi, dan tidak akan membiarkan permintaan pengguna yang bergolak secara langsung Hancurkan pelayan belakang anda yang rapuh.

3. Cara membersihkan cache ralat dalam beberapa saat (Cache Invalidation)

Kod tersebut dalam talian dan bug keluar, dan JS yang salah telah disimpan di seluruh dunia oleh Google. Apa yang harus saya lakukan?

Jangan panik, pergi ke halaman pengimbangan beban anda, klik untuk memasukkan tab CDN, cari

"Cache Invaldate" (untuk membatalkan cache)

。

Masukkan jalan

/*

(Bersihkan keseluruhan laman web) atau

/Static/js/main.js

(Bersihkan fail individu). Terima kasih kepada rangkaian tulang belakang Anycast global Google, ia menyegarkan dengan sangat cepat, biasanya

Dalam 1 hingga 2 minit

Semua cache ralat nod global dapat dihapuskan.

Ringkasan

Google Cloud CDN bukanlah "alat penjimatan lebar jalur" semata-mata, ia memperbaiki pelaburan trilion dolar Google dalam dua dekad yang lalu

Lebuh raya rangkaian swasta teratas di dunia

, Disewa terus kepada anda.

Selagi anda menjelaskan hubungan simbiotik antara ia dan pengimbangan beban, melengkapkan peraturan cache pemisahan dinamik dan statik, dan dengan berhati-hati mengelakkan perangkap penagihan lalu lintas dinamik kembali ke sumber, ia dapat menggunakan IP tunggal sederhana untuk membantu anda menyelesaikannya dengan mudah Akses serentak dan pantas yang tinggi kepada ratusan juta pengguna di seluruh dunia.