Hosting aplikasi lawan hosting statik: pilih ikut kerja yang perlu berjalan

Soalan yang menentukan pilihan hosting bukan "berapa harga sebulan", tetapi satu ayat: apabila pelawat membuka halaman, ada apa-apa yang perlu dikira di pelayan? Kalau jawapannya tiada, awak perlukan hosting statik. Kalau jawapannya ada. log masuk, pembayaran, carian dalam pangkalan data. awak perlukan hosting aplikasi, dan tiada CDN percuma boleh menggantikannya.

Perbezaan itu bukan soal jenama atau kelajuan. Ia soal apa yang berlaku selepas fail dihantar. Pos ini membandingkan had sebenar kedua-dua jenis menggunakan dokumentasi rasmi Cloudflare, GitHub, PHP dan nginx, kemudian menerangkan bila setiap satu berbaloi dan bila ia mula merugikan.

Fail yang menunggu lawan proses yang bekerja

Hosting statik menyimpan fail HTML, CSS, JavaScript dan gambar, kemudian menghantarnya bila diminta. Tiada kod dijalankan. Pelayan hanya menjawab dengan kandungan yang sudah siap sebelum pelawat tiba. Hosting aplikasi melakukan kerja tambahan: setiap permintaan masuk ke dalam proses yang hidup, membaca pangkalan data, menyemak sesi, kemudian membina halaman baharu sebelum menghantarnya.

Kerana itu had kedua-duanya berbeza sama sekali. Pada hosting aplikasi, memori setiap permintaan PHP dihadkan oleh tetapan memory_limit, dan nilai lalai dalam manual PHP ialah 128M. Di bahagian hadapan, nginx membuka sambungan serentak mengikut worker_connections, dengan nilai lalai 512 bagi setiap proses pekerja. Empat proses pekerja bermaksud kira-kira 2,048 sambungan serentak. dan setiap permintaan aplikasi yang mengambil masa 300 milisaat akan memegang satu daripadanya selama itu.

Pada hosting statik, dua angka itu tidak relevan. Tiada proses yang boleh kehabisan memori kerana tiada proses. Yang relevan ialah bilangan fail, saiz setiap fail, dan berapa kerap awak menerbitkan semula laman.

Had sebenar hosting statik: 20,000 fail dan 25 MiB

Dokumentasi Cloudflare Pages menyatakan pelan percuma membenarkan 500 binaan sebulan, sehingga 20,000 fail bagi setiap laman, dan maksimum 25 MiB bagi satu aset. Binaan yang melebihi 20 minit akan tamat masa. Satu projek pula boleh memegang sehingga 100 domain tersuai pada pelan percuma.

Siling teori kedua-dua angka itu besar: 20,000 aset pada 25 MiB setiap satu memberi ruang kira-kira 488 GB, jauh lebih banyak daripada yang pernah digunakan laman perniagaan kecil. Jadi had yang benar-benar mengejutkan dalam amalan bukan saiz fail, tetapi bilangan fail dan kekerapan binaan. GitHub Pages memberi had lain: saiz laman yang diterbitkan tidak boleh melebihi 1 GB, bandwidth bersifat lembut pada 100 GB sebulan, dan binaan dihadkan secara lembut kepada 10 kali sejam. Setiap penempatan yang mengambil masa lebih 10 minit akan tamat masa. Yang lebih penting, terma GitHub menyatakan Pages tidak boleh digunakan untuk laman yang menjalankan transaksi komersial atau jualan dalam talian.

Kira had fail sebelum ia menjadi masalah. Kalau setiap pos membawa tiga saiz gambar (hero 1280 piksel, kad 450 piksel, dan satu varian dalam isi), satu pos menggunakan kira-kira 9 fail. Pada 20,000 fail, itu bersamaan lebih kurang 2,200 pos sebelum had tercapai. cukup untuk blog 10 tahun pada kadar tiga pos sehari, tetapi tidak cukup untuk arkib 15 tahun dengan galeri gambar. Angka 500 binaan sebulan itu bersamaan kira-kira 16 binaan sehari. Kalau awak menolak perubahan tiga kali sehari, itu 90 binaan sebulan. masih jauh daripada had. Yang selalu mengejutkan bukan binaan, tetapi fail: blog lama dengan tiga saiz gambar bagi setiap pos mudah mencecah 20,000 fail selepas beberapa tahun, dan pada ketika itu awak perlu memangkas arkib atau berpindah.

Lima kerja yang memaksa awak pilih hosting aplikasi

Senarai ini bukan teori. Kalau mana-mana satu daripadanya ada dalam keperluan projek, hosting statik sahaja tidak akan cukup, walau dengan fungsi tambahan.

• ▸ Log masuk dan sesi. Kuki sesi mesti disemak pada setiap permintaan. Fail statik tidak boleh menyemak apa-apa; ia hanya boleh dihantar.
• ▸ Tulis ke pangkalan data. Borang tempahan, stok, atau rekod pelanggan memerlukan sambungan pangkalan data yang dibuka, digunakan dan ditutup dalam lingkungan satu permintaan.
• ▸ Kerja berjadual. Cron pada Linux berjalan mengikut jadual lima medan, dan selang paling rapat ialah 1 minit. Tiada cron pada hosting statik kerana tiada proses untuk dijadualkan.
• ▸ Muat naik fail. Gambar 3 MB daripada telefon pelanggan perlu disimpan ke cakera pelayan atau storan objek, bukan dimasukkan ke dalam repositori Git yang akan dibina semula setiap kali.
• ▸ Rahsia dan kunci API. Kalau kunci gerbang pembayaran ditulis dalam JavaScript, sesiapa yang membuka "view source" boleh membacanya. Pada hosting aplikasi, kunci itu tinggal di pelayan dan tidak pernah sampai ke pelayar.

Ujian 15 minit sebelum bayar hosting

Sebelum memilih, jalankan tiga semakan pada draf laman. Pertama, matikan JavaScript dalam pelayar: kalau halaman masih memaparkan kandungan utama, ia calon baik untuk hosting statik. Kedua, senaraikan semua borang dan tandakan mana yang menyimpan data. Ketiga, tanya sama ada laman perlu menghantar e-mel sendiri. e-mel keluar memerlukan proses dan rekod DNS yang berasingan.

Di peringkat pelayan, perbezaannya kelihatan dalam dua baris konfigurasi nginx. Yang pertama menghantar fail terus. Yang kedua menyerahkan setiap permintaan kepada aplikasi yang berjalan di port tempatan.

# statik: fail dihantar terus, tiada kod dijalankan
location / {
    try_files $uri $uri/ =404;
}

# aplikasi: setiap permintaan diserahkan kepada proses
location / {
    proxy_pass http://127.0.0.1:8888;
}

Ukur masa respons sebelum membuat keputusan. Jalankan arahan di bawah lima kali dan ambil nilai tengah, bukan nilai terbaik. Kalau laman statik memberi 80 milisaat dan laman aplikasi memberi 400 milisaat pada halaman yang sama, itu bukan masalah hosting. itu kos kerja yang memang perlu dibuat.

curl -o /dev/null -s -w '%{time_starttransfer}\n' https://contoh.com/

Selepas berpindah, semak semula angka yang sama. Kalau masa respons aplikasi naik dua kali ganda tanpa perubahan trafik, punca paling kerap ialah pertanyaan pangkalan data yang tidak berindeks, bukan pelayan yang kurang kuat.

Kos yang jarang dikira: tampalan dan sandaran

Hosting statik memindahkan kerja ke saluran binaan. Awak tidak menampal sistem pengendalian setiap bulan, tetapi awak perlu menjaga saluran binaan itu, menyemak bahawa 500 binaan sebulan tidak melebihi had, dan memastikan gambar tidak membesar melepasi 25 MiB. Kegagalan di sini kelihatan seperti laman yang tidak berubah selepas dihantar, bukan laman yang mati.

Hosting aplikasi memerlukan dua rutin yang tidak boleh dilangkau: tampalan keselamatan dan sandaran. Tampal PHP, nginx dan pangkalan data apabila keluar versi baharu. Sandarkan dua perkara berasingan. fail laman dan pangkalan data. kerana memulihkan fail sahaja akan meninggalkan awak dengan laman kosong yang berjalan dengan sempurna. Uji pemulihan sekurang-kurangnya sekali setahun pada pelayan berasingan, bukan pada pelayan produksi.

Tiga kesilapan yang mahal

• ▸ Meletakkan kedai dalam talian di GitHub Pages. Termanya jelas melarang penggunaan untuk transaksi komersial, dan penyedia boleh menghentikan laman tanpa notis panjang.
• ▸ Menyimpan kunci API dalam fail JavaScript yang dihantar kepada pelawat. Menyembunyikannya dalam pemboleh ubah atau menamakannya dengan kod tidak mengubah apa-apa; ia masih boleh dibaca.
• ▸ Menganggap had 100 GB sebulan itu besar tanpa mengira saiz halaman. Pada 3 MB satu halaman, 100 GB bersamaan kira-kira 33,000 lawatan halaman sebulan. Naikkan saiz kepada 6 MB dan had itu tiba pada separuh trafik.

Bila patut berpindah dari satu ke satu lagi

Pindah dari statik ke aplikasi apabila satu daripada ini berlaku: awak perlu log masuk pelanggan, perlu menerima bayaran, perlu menjadualkan kerja setiap jam, atau perlu menyimpan data yang berubah. Pindah dari aplikasi ke statik pula apabila laman itu sebenarnya tidak melakukan apa-apa selain memaparkan teks dan gambar. dan awak sedang menampal pelayan setiap bulan untuk kerja yang tidak wujud.

Pilihan ketiga yang selalu dilupakan ialah gabungan: laman utama statik di CDN, manakala aplikasi kecil berjalan di pelayan berasingan di belakang reverse proxy. Pendekatan ini mengekalkan kelajuan halaman awam tanpa memaksa seluruh laman bergantung pada satu proses yang perlu ditampal.