Grigory Petrov: bekerja dengan jaringan di Ruby

Pada tanggal 28 September, di konferensi Evrone RubyRussia DevRel, Grigory Petrov akan berbicara tentang bagaimana komunikasi microservices. Dalam wawancara hari ini, Ivan Solovyov berbicara dengan Grigory tentang topik pidatonya yang akan datang dan tidak hanya tentang itu.



Ceritakan tentang diri Anda, apa yang Anda lakukan di Evrone?

Saya terlibat dalam hubungan pengembang - ini adalah sesuatu antara DevRel dan Technology Evangelist, seorang pengembang yang dapat berbicara di konferensi. Bekerja seperti Robin Hood: berkomunikasi dengan tim pengembangan di dalam perusahaan, mengumpulkan berbagai hal menarik dari apa yang mereka lakukan, dan membicarakannya di konferensi. Ruby Russia akan menjadi salah satu konferensi pertama di mana saya akan berbicara atas nama perusahaan.

Saya tahu Anda sebagai salah satu penyelenggara berbagai konferensi Python. Katakan bagaimana Anda datang ke dunia Ruby?

Saya tidak pernah meninggalkan dunia Ruby. Salah satu kuliah pertama saya adalah Python vs Ruby. Bertahun-tahun yang lalu, ketika saya menulis di C ++, saya membutuhkan mekanisme otomatisasi tingkat tinggi untuk setiap pengujian, pembuatan dokumentasi. Lalu saya menulis dengan Python dan Ruby, dan sedikit dalam PHP. Saya mencari cara terbaik untuk menyelesaikan masalah yang saya miliki.

Berapa banyak laporan Anda akan dipinjam dari tim pengembangan di dalam perusahaan? Saya tahu Anda menulis dalam banyak bahasa: Ruby, Python, PHP, TypeScript, JavaScript, C ++ dan tidak hanya.

Laporan ini akan membahas tentang komunikasi layanan mikro di antara mereka sendiri melalui jaringan, protokol yang digunakan untuk ini dan kesulitan yang muncul. Sebenarnya, saya memiliki hubungan yang panjang dengan grid. Saya lakukan Radmin, ini adalah alat jaringan untuk remote control. Proyek NPTV (di mana saya juga bekerja DevRel) adalah televisi interaktif yang secara aktif menggunakan grid dan dikendalikan oleh Ruby. Voximplant (tempat saya mempelajari DevRel lagi) adalah telepon yang dapat diprogram di mana saya bertemu VoIP. Grid sangat dekat dengan saya. Saya bisa membuat laporan berdasarkan pengalaman saya, tetapi dengan cara ini saya tidak akan membawa nilai maksimum kepada para tamu konferensi, tetapi saya ingin menanggung manfaat maksimal. Selama persiapan awal laporan, saya mewawancarai beberapa tim Evrone. Perusahaan ini bergerak dalam pengembangan kustom perangkat lunak yang kompleks dan berkualitas tinggi, banyak tim bekerja pada berbagai proyek. Kami menelepon di Zoom dan berbicara selama satu jam atau lebih. Mereka membahas apa dan bagaimana mereka melakukannya, kesulitan apa, tumpukan apa yang mereka gunakan. Laporan saya akan setengah tentang grid, protokol jaringan, kompleksitas dan aplikasi, dan setengah tentang bagaimana itu digunakan di Ruby oleh tim yang berbeda.

Anda memiliki banyak komunikasi dengan pengembang. Menurut Anda seberapa spesifik bekerja dengan jaringan di Ruby?

Jaringan terdiri dari beberapa bagian. Pertama-tama, karya bahasa pemrograman dan ekosistemnya secara langsung dengan byte yang dikirimkan melalui jaringan. Tumpukan jaringan level terendah. Misalnya, JS dan Node yang sama menggunakan libuv , model asinkron. Ada aliran utama, dan Anda akhirnya bekerja dengan jaringan. Anda memiliki coroutine untuk ini. Anda membuat banyak harapan, Anda menunggu untuk menerima data, Anda menunggu agar data dikirim. Utas tunggal ini menyediakan ribuan dan puluhan ribu kueri per detik.

Di atas fondasi ini, kerangka kerja dikembangkan, apa pun itu. Misalnya, JS tidak memiliki kerangka kerja yang serius untuk bekerja dengan kisi (yang Anda dapat memberi selamat padanya!). Dengan pengecualian express.js, yang hampir tidak merupakan kerangka kerja lengkap. Python beralih ke model yang serupa, dan kerangka kerja Django yang paling populer tetap pada model sebelumnya. Sekarang ada semacam perselisihan - kerangka kerja sinkron yang mencoba untuk diperbanyak dengan memblokir utas, proses dengan GIL menggantungnya, dan di samping ada beberapa hal baru yang mencoba untuk bekerja pada model asinkron, misalnya Saluran Django. Ruby masih dalam model sinkron dan diperbanyak dengan proses. Oleh karena itu, inilah ekosistem yang sesuai, pendekatan dan posisi yang sangat kuat dari Rails.

Apa kekuatan Ruby? Pertama-tama, dalam DSL, Bahasa khusus domain. Ketika kita berbicara tentang grid, Ruby memainkan yang terbaik di bidang yang paling kuat. Ketika kami menggunakan GraphQL, itu berarti bahwa perpustakaan untuk menggunakan GraphQL ada di mana-mana. Di Ruby, mereka akan menggunakan sintaks DSL yang sangat baik untuk mendefinisikan skema. Dan integrasi antara sintaks DSL ini dan sintaks DSL ORM dalam ActiveRecord. Inilah yang bisa kita harapkan dari Ruby. Pada saat yang sama, kami tidak akan memiliki operasi asinkron (menunggu), kami akan diskalakan oleh proses dan kami akan memiliki persyaratan server yang sesuai.

Laporan Anda menyatakan beberapa protokol interaksi. JSON yang sama: API dan sebagainya. Dari mana Anda melihat perkembangan selanjutnya, akankah kita semua meluncur ke GraphQL?

Pertanyaan yang sangat resonan. Menurut pendapat saya, itu dimulai dengan fakta bahwa grid lambat. Aplikasi pada awalnya sederhana. Sebagai aturan, semua aplikasi, baik Ruby, Python, dan Node, menggunakan titik akhir HTTP biasa untuk komunikasi. Di dalamnya mereka menggunakan semacam muatan. Sebelumnya XML, sekarang JSON. Mereka baik-baik saja selama beberapa bulan atau tahun pertama, seolah-olah mereka beruntung. Selanjutnya, bisnis mulai mengajukan pertanyaan kompleks. Misalnya, Anda perlu mendapatkan beberapa pengguna, dan untuk setiap pengguna untuk mendapatkan daftar perusahaan tempat ia bekerja. Di sini muncul masalah: jika Anda hanya menggunakan titik akhir, maka itu akan menjadi beberapa puluh atau ratusan permintaan, dan kisi-kisi itu santai: permintaan, respons, paket yang hilang. Ini akan menjadi sangat lambat dan banyak data yang perlu dikirim melalui jaringan. 100 kali lebih banyak dari data yang dibutuhkan. Sistem kami runtuh, karena sistem otomasi bisnis besar runtuh di bawah permintaan seperti itu, yang dalam 10 tahun tumbuh menjadi monster, di mana pertanyaan sulit dari antarmuka bisa memakan waktu beberapa menit, berjam-jam. Selama ini, basis data di backend akan mengerjakan banyak permintaan yang identik, dan banyak permintaan yang identik akan mengejar seluruh jaringan. Kami mencoba menyelesaikannya dengan berbagai cara.

Berikan contoh nyata dari masalah seperti itu?

Facebook sangat menonjol, mereka memiliki masalah ini sangat akut: ada banyak data yang mereka sukai untuk membuat kueri yang kompleks. Sebagai contoh: tunjukkan kepada saya orang-orang yang berkomentar di posting ini dan teman-teman mereka Agar tidak membuat jutaan permintaan, Facebook menggunakan opsi berbeda. Misalnya, FQL, Facebook Query Language. Setelah mengumpulkan semua keahlian mereka, mereka membuat GraphQL - suatu hal yang memungkinkan Anda untuk membuat query seperti SQL pada klien. Tapi ini bukan SQL, karena kita tidak bisa dilampirkan ke database, tetapi permintaan dalam hal API backend. Anda mengirim satu permintaan dan Anda mendapatkan satu (atau bagaimana kelanjutannya) menjawab.

Masalah besar kedua adalah apa yang harus dilakukan jika kita ingin mendapatkan banyak data dari backend. Misalnya, lima ribu pengguna atau log in 10mb. Sangat menakutkan untuk melakukan semuanya dengan satu permintaan http-respons. Karena jika jala runtuh, permintaan harus diulangi secara keseluruhan, dan ini bisa bertahan selamanya. Kembali ke Facebook: mereka membuat GraphQL, penopang di atas kisi. Dan kemudian orang lain melakukan HTTP / 2, yang memecahkan masalah kisi. HTTP / 2 membuat satu koneksi asinkron, di mana kita dapat membuat banyak permintaan kecil. HTTP / 2 melawan GraphQL jika server GraphQL tidak memiliki banyak keajaiban untuk mengoptimalkan jumlah permintaan ke database di backend. Dan dalam pembicaraan, kita akan berbicara tentang apa yang Ruby tawarkan untuk sihir ini. Dengan HTTP / 2, GraphQL mungkin tidak diperlukan. Kita dapat membuat 100 permintaan HTTP / 2 ke titik akhir kita, dan dari sudut pandang byte, ini tidak akan menjadi overhead yang lebih besar daripada jika kita menggunakan GraphQL. Google Protocol Buffer dan gRPC mendekati masalah ini dari ujung ketiga. Mereka menggunakan protokol transport biner, terutama HTTP / 2, mereka menawarkan skema tertentu untuk api. Di sini mereka bersaing dengan REST yang biasa.

Dalam praktiknya, di sebagian besar perusahaan yang menggunakan JSON, programmer Vasya duduk dan menulis JSON ini dengan tangannya. Enam bulan kemudian, Vasya mengetahui bahwa tanggal dan waktu dapat ditransmisikan dalam seratus cara berbeda. Horor dimulai! Tetapi jika pengembang yang baik duduk di perusahaan, mereka menulis tidak hanya JSON, tetapi menggunakan semacam standar. Menggunakan Skema OpenAPI atau JSON, semua hal menarik ini yang bersaing dengan gRPC. Seluruh kebun binatang modern ini memecahkan beberapa masalah yang disuarakan. Dan apa yang akan terjadi pada kebun binatang ini di masa depan, saya tidak dapat memprediksi sama sekali. Tapi saya mengundang pengembang untuk datang dan membahas masalah ini: apa yang menanti kita di tahun mendatang, 3, 5, 10 dan apa disposisi pasukan sekarang.

Mari kita bicara tentang masa depan Ruby sebagai bahasa pemrograman?

Sulit untuk memprediksi masa depan. Saya benar-benar ingin melihat tipe yang bagus di Ruby. Ruby 3 sekarang berada pada tahap awal implementasi tipe. Saya ingin sintaks ini menjadi cantik. Saya melihat proposal, titik botak saya berdiri di ujungnya. Sintaks yang mengerikan, sangat verbose yang tidak akan digunakan siapa pun.

Mengapa menurut Anda begitu?

Saya seorang ahli neurofisiologi amatir. Pemikiran intuitif bahwa setiap orang suka membuat segala macam keputusan aneh. Jika, misalnya, Anda perlu menulis banyak surat, maka ini buruk. Jenis ini bisa sangat keren, tetapi karena Anda harus menulis satu setengah kali lebih banyak kode, kita akan merasakan emosi "Saya tidak mau". Dan kami sangat sensitif terhadap emosi kami, jadi tidak ada yang akan menggunakannya. Saya sangat suka cara jenis disampaikan dengan Python dan TypeScript: melalui titik dua. Ini memberikan overhead minimal. Kami menulis pengidentifikasi - tampak. Saya tahu pasti bahwa akan ada nomor, Anda perlu menjebak. Pengembang menulis titik dua dan hanya itu, jebakan diinstal. Setelah beberapa minggu, ketika dia secara tidak sengaja melewati daftar atau baris di sana, jebakan akan bekerja dan menyelamatkan pengembang beberapa jam atau minggu dari debugging.

Apa lagi yang ingin Anda lihat di Ruby?

Selama beberapa tahun terakhir, saya telah melihat banyak async dengan coroutine. Saya sangat suka ini karena kode async dengan coroutine mudah dibaca. Dapat dimengerti, memungkinkan Anda untuk menjejalkan hal-hal kompleks menjadi sintaksis sederhana. Ini diimplementasikan dengan baik di Python terbaru dan diimplementasikan dengan baik dalam JavaScript. Saya benar-benar ingin Ruby membawa sesuatu seperti itu ... Sebenarnya, Ruby memiliki serat. Akan lebih baik untuk menambahkan sesuatu seperti Node sehingga Anda dapat menulis aplikasi Ruby asinkron menggunakan serat atau primitif lainnya. Dan di bawah tenda, itu sendiri akan menggunakan libuv atau sistem operasi primitif lainnya untuk bekerja dengan grid.

Atau akan meletakkan sesuatu di sungai. Akan menggunakan sesuatu untuk memenuhi semua permintaan jaringan, permintaan basis data, permintaan sistem file secara kompetitif. Dan saya hanya akan menulis coroutine pada tingkat potongan kecil kode yang dieksekusi pada permintaan atau timer yang masuk, kemudian memberikan perintah dan menunggu eksekusi mereka. Lebih lanjut di bawah tenda banyak keajaiban, semua ini dilakukan secara paralel, memakan mobil Amazon besar sebesar 100% dan memiliki puluhan ribu permintaan per detik. Dalam kasus Go, ratusan ribu permintaan per detik.

Kembali ke tipe. Ini mungkin akan menjadi pengenalan tipe secara bertahap, Mengetik Bertahap?

Pengetikan Bertahap adalah mega skyrocket yang pertama kali ditambahkan ke Python. Kami membuatnya sehingga jenis dapat ditambahkan sedikit. Menurut pendapat saya, seluruh paradigma pengembangan telah muncul ketika pada awalnya kode ditulis dengan sangat cepat tanpa tipe, dan kemudian ketika pengembang melihat bahwa beberapa bagian dari kode telah stabil, tipe mulai menambah bagian kode ini. Di sinilah stabil dan perlu mengatur jebakan sehingga di masa depan tidak ada yang rusak dengan yang stabil ini. Akan keren jika mereka melakukan sesuatu yang mirip dengan Ruby.

Pertanyaan apa yang ingin Anda tanyakan pada Yukihiro Matsumoto di konferensi?

Saya telah belajar bahasa Jepang selama 4 tahun, dan bahasa Jepang saya mungkin cukup untuk mengatakan "terima kasih" kepadanya. Saya akan berlatih!

Sampai jumpa di RubyRussia!

Daftarkan , kenaikan harga berikutnya diperkirakan setelah 15 September, sudah ada 700 peserta bersama kami.

Dan terima kasih tradisional kepada perusahaan yang mendukung kami:

Penyelenggara - Evrone
Mitra Umum - Toptal
Mitra Emas - Gett
Mitra Perak - JetBrains , Bookmate dan Cashwagon
Mitra Perunggu - InSales