ASGI menjelaskan: Masa depan pembangunan web Python

​Penterjemah |. Li Rui

Penilai |. bagaimana mereka berkomunikasi dengan pelayan web. WSGI, pada asalnya diperkenalkan pada tahun 2003 dan dikemas kini pada tahun 2010, hanya bergantung pada ciri yang mudah dilaksanakan yang tersedia secara asli dalam Python 2.2. Hasilnya, WSGI telah disepadukan dengan cepat ke dalam semua rangka kerja web Python utama dan menjadi asas pembangunan web Python.

Maju cepat ke 2022. Python2 ditamatkan dan Python kini mempunyai sintaks asli untuk mengendalikan operasi tak segerak seperti panggilan rangkaian. WSGI dan piawaian lain yang menganggap tingkah laku segerak secara lalai gagal memanfaatkan prestasi dan keuntungan kecekapan tak segerak. Ini bermakna WSGI tidak dapat mengendalikan protokol peringkat tinggi seperti WebSocket dengan cekap.

Masukkan ASGI, Antara Muka Gerbang Pelayan Asynchronous. Sama seperti WSGI, ASGI menerangkan antara muka biasa antara aplikasi web Python dan pelayan web. Tidak seperti WSGI, ASGI membenarkan berbilang peristiwa tak segerak bagi setiap aplikasi. Selain itu, ASGI menyokong kedua-dua aplikasi segerak dan tak segerak. Pembangun boleh memindahkan aplikasi web WSGI segerak lama ke ASGI atau membina aplikasi web tak segerak baharu menggunakan ASGI.

1. Cara WSGI berfungsi

WSGI berfungsi dengan mendedahkan fungsi Python kepada pelayan web, biasanya dinamakan sebagai aplikasi atau aplikasi. Fungsi ini mengambil dua parameter:

persekitaran: Kamus yang mengandungi maklumat tentang permintaan semasa dan pembolehubah persekitaran yang disediakan oleh pelayan web.

start_response: Akan digunakan untuk memulakan fungsi yang menghantar semula respons HTTP kepada klien.

• Data yang dikembalikan oleh fungsi membentuk badan tindak balas.

Fungsi aplikasi mudah mungkin kelihatan seperti ini: ​

Jika anda menggunakan rangka kerja web yang serasi dengan WSGI ( Flask for contoh), maka rangka kerja itu sendiri akan menyediakan fungsi aplikasi dan semua komponennya akan disambungkan secara automatik.

def application(environ, start_response):

 start_response('200 OK', [('Content-Type', 'text/plain')])

 return [b'Greetings universe']

WSGI mempunyai dua kelemahan: Pertama, WSGI hanya mengendalikan satu permintaan dan respons pada satu masa, dan menganggap bahawa respons akan dikembalikan serta-merta. Tiada cara untuk mengendalikan sambungan yang dipegang lama, seperti WebSocket atau sambungan HTTP tinjauan panjang.

Kedua, WSGI hanya segerak. Walaupun dengan pengumpulan sambungan berbilang benang, setiap sambungan disekat sehingga ia mengembalikan respons. Banyak persediaan WSGI dapat mengendalikan kumpulan benang dan kumpulan proses, tetapi ini dihadkan oleh penyegerakan antara muka WSGI itu sendiri.

2. Cara ASGI berfungsi

ASGI mempunyai rupa yang serupa dengan WSGI. Seperti WSGI, pembangun boleh mentakrifkan objek fungsi aplikasi, tetapi ia adalah fungsi tak segerak dengan tiga parameter dan bukannya dua:

skop: Mengandungi maklumat tentang permintaan semasa Kamus maklumat, serupa untuk persekitaran di WSGI, tetapi butiran konvensyen penamaan adalah sedikit berbeza.

hantar: Fungsi boleh panggil tak segerak yang membolehkan aplikasi menghantar semula mesej kepada pelanggan.

terima: Fungsi boleh panggil tak segerak yang membolehkan aplikasi menerima mesej daripada pelanggan.

Fungsi aplikasi ASGI yang ringkas kelihatan seperti ini:

Seperti rangka kerja web WSGI, rangka kerja web ASGI akan menjana sendiri aplikasi () berfungsi dan menyambungkannya mengikut keperluan.

async def application(scope, receive, send):
 await send({
 'type': 'http.response.start',
 'status': 200,
 'headers': [
 [b'content-type', b'text/plain'],
 ],
 })
 await send({
 'type': 'http.response.body',
 'body': b'Hello, world!',
 })

Perbezaan paling ketara daripada ASGI ialah penggunaan metafora tak segerak di seluruh fungsi. Fungsi itu sendiri adalah tak segerak, di mana pengepala HTTP dan badan tindak balas dihantar melalui dua perintah tunggu hantar() berasingan. Dengan cara ini, fungsi itu sendiri dan arahan penghantarannya tidak menyekat apa-apa pun ia boleh dikaitkan dengan panggilan aplikasi dan dihantar dari banyak sambungan lain secara serentak.

Terima tidak digunakan dalam contoh ini, tetapi ia juga merupakan fungsi tak segerak. Ia membolehkan menerima badan permintaan tanpa menyekat operasi lain. Permintaan dan respons boleh dihantar secara berperingkat kepada atau dari pelayan dengan cara ini - sesuatu yang tidak boleh dilakukan dengan baik, atau mungkin sama sekali, dengan WSGI.

3. Menggunakan fungsi segerak dan tak segerak dalam ASGI ​

Apabila menggunakan ASGI, anda perlu menggunakan sebanyak mungkin fungsi tak segerak dan perpustakaan mesra tak segerak. Anda perlu membiasakan diri menggunakan async, kerana masalah menggunakan kod segerak sahaja boleh menjadi serius. Sebarang panggilan panjang ke fungsi segerak akan menyekat keseluruhan rantai panggilan, sekali gus menjadikan faedah menggunakan async hampir hilang.

Jika anda menghadapi masalah semasa menggunakan panggilan segerak yang berjalan lama, anda perlu menggunakan asyncio.run_in_executor untuk menyumber luar panggilan ke kumpulan benang atau kumpulan proses. Kumpulan benang harus digunakan setiap kali menunggu acara luaran atau tugas bukan intensif CPU. Kumpulan proses harus digunakan untuk tugas tempatan intensif CPU.

Sebagai contoh, jika terdapat laluan dalam aplikasi web yang boleh memanggil tapak web jauh, maka benang harus digunakan. Atau lebih baik lagi, gunakan perpustakaan aiohttp yang membuat permintaan HTTP tak segerak. Jika anda ingin memanggil pustaka imej Bantal untuk mengubah saiz imej, anda mungkin perlu menggunakan run_in_executor dengan kolam proses. Walaupun terdapat sedikit overhed dalam memindahkan data ke sana ke mari antara proses, menggunakan run_in_executor tidak menyekat acara lain.

4. Rangka kerja Web yang menyokong ASGI

Dengan melaksanakan objek application(), aplikasi Web ASGI boleh ditulis secara manual. Tetapi dalam kebanyakan kes, lebih mudah untuk menggunakan rangka kerja web Python asal tak segerak, ASGI-centric. Berikut ialah beberapa rangka kerja web biasa yang serasi dengan ASGI:

Starlette dan FastAPI: Rangka kerja baru muncul ini (FastAPI dibina di atas Starlette) adalah async-first, jadi semuanya menyokong ASGI Tidak hairanlah . Jika anda membangunkan aplikasi web dari awal, maka ia adalah rangka kerja web yang paling moden dan canggih untuk Python.

Suku: Walaupun rangka kerja web Python utama Flask menyokong ASGI, Flask tidak direka bentuk untuk memanfaatkan metafora async dari dalam ke luar. Quart daripada GitLab menggunakan sintaks dan metafora Flask tetapi membenarkan pengendali laluan tak segerak.

Django 3.0 dan lebih tinggi: Bermula daripada Django3.0, rangka kerja web Django yang berprestij menyokong ASGI. Sokongan untuk kod tak segerak dalam aplikasi Django telah ditambahkan dalam Django 3.1, dan bukannya hanya dapat melekapkan Django pada pengendali ASGI. Untuk rangka kerja yang tidak diketahui untuk kelajuan pelaksanaan, kehadiran async membawa prestasi yang lebih baik kepada mereka yang memilih untuk memanfaatkannya.

Pautan asal: https://www.infoworld.com/article/3658336/asgi-explained-the-future-of-python-Web-development.html​

Atas ialah kandungan terperinci ASGI menjelaskan: Masa depan pembangunan web Python. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!