Saya yakin judulnya menimbulkan reaksi yang sehat - "ya, ini dimulai lagi..." Namun izinkan saya menarik perhatian Anda selama 5-10 menit, dan saya akan berusaha untuk tidak mengecewakan harapan Anda.
Struktur artikelnya adalah sebagai berikut: pernyataan stereotip diambil dan “sifat” munculnya stereotip tersebut terungkap. Saya harap ini memungkinkan Anda melihat pilihan paradigma pertukaran data dalam proyek Anda dari sudut pandang baru.
Untuk memperjelas apa itu RPC, saya mengusulkan untuk mempertimbangkan standarnya . Dengan REST tidak ada kejelasan. Dan itu tidak seharusnya terjadi. Segala sesuatu yang perlu Anda ketahui tentang REST - tidak dapat dibedakan .
Permintaan RPC lebih cepat dan efisien karena memungkinkan Anda membuat permintaan batch.
Intinya di RPC Anda bisa memanggil beberapa prosedur sekaligus dalam satu permintaan. Misalnya, buat pengguna, tambahkan avatar padanya dan, dalam permintaan yang sama, berlangganan dia ke beberapa topik. Hanya satu permintaan, dan betapa banyak manfaatnya!
Memang benar, jika Anda hanya memiliki satu node backend, permintaan batch akan terasa lebih cepat. Karena tiga permintaan REST akan memerlukan sumber daya tiga kali lebih banyak dari satu node untuk membuat koneksi.
Perhatikan bahwa permintaan pertama dalam kasus REST harus mengembalikan ID pengguna agar permintaan berikutnya dapat dibuat. Yang juga berdampak negatif pada hasil keseluruhan.
Namun infrastruktur seperti itu hanya dapat ditemukan di solusi internal dan Perusahaan. Sebagai upaya terakhir, dalam proyek WEB kecil. Namun solusi WEB yang lengkap, dan bahkan yang disebut HighLoad, tidak layak untuk dibangun. Infrastrukturnya harus memenuhi kriteria ketersediaan dan beban tinggi. Dan gambarannya berubah.
Saluran kegiatan infrastruktur dalam skenario yang sama ditandai dengan warna hijau. Perhatikan bagaimana perilaku RPC sekarang. Permintaan tersebut menggunakan infrastruktur hanya pada satu bagian dari penyeimbang hingga backend. Meskipun REST masih kalah dalam permintaan pertama, REST menggantikan waktu yang hilang dengan menggunakan seluruh infrastruktur.
Cukup dengan memasukkan ke dalam naskah bukan dua permintaan pengayaan, tetapi, katakanlah, lima atau sepuluh... dan jawaban atas pertanyaan “siapa yang menang sekarang?” menjadi tidak jelas.
Saya mengusulkan untuk melihat masalah ini lebih luas lagi. Diagram menunjukkan bagaimana saluran infrastruktur digunakan, namun infrastruktur tidak terbatas pada saluran. Komponen penting dari infrastruktur beban tinggi adalah cache. Sekarang mari kita dapatkan semacam artefak pengguna. Berkali-kali. Katakanlah 32 kali.
Lihat bagaimana infrastruktur RPC telah meningkat secara signifikan untuk memenuhi tuntutan beban tinggi. Masalahnya adalah REST menggunakan kekuatan penuh protokol HTTP, tidak seperti RPC. Pada diagram di atas, kekuatan ini diwujudkan melalui metode permintaan - GET.
Metode HTTP, antara lain, memiliki strategi caching. Anda dapat menemukannya di dokumentasi di . Untuk RPC, permintaan POST digunakan, yang tidak dianggap idempoten, yaitu pengulangan berulang dari permintaan POST yang sama dapat memberikan hasil yang berbeda (misalnya, setelah setiap komentar dikirim, salinan lain dari komentar ini akan muncul) ().
Akibatnya, RPC tidak dapat menggunakan cache infrastruktur secara efektif. Hal ini menyebabkan perlunya “mengimpor” cache perangkat lunak. Diagram menunjukkan Redis dalam peran ini. Cache perangkat lunak, pada gilirannya, mengharuskan pengembang untuk menambahkan lapisan kode tambahan dan perubahan nyata dalam arsitektur.
Sekarang mari kita hitung berapa banyak permintaan yang “dilahirkan” oleh REST dan RPC dalam infrastruktur yang sedang dipertimbangkan?
Pertanyaan
kotak masuk
ke bagian belakang
ke DBMS
ke cache lunak (Redis)
TOTAL
ISTIRAHAT
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Dibandingkan dengan skema pertama, perbedaannya sangat mencolok. Sekarang manfaat REST menjadi jelas. Tapi saya sarankan untuk tidak berhenti di situ. Infrastruktur yang dikembangkan meliputi CDN. Seringkali ini juga memecahkan masalah melawan serangan DDoS dan DoS. Kita mendapatkan:
Di sinilah segalanya menjadi sangat buruk bagi RPC. RPC tidak mampu mendelegasikan beban kerja ke CDN. Kami hanya bisa mengandalkan sistem untuk melawan serangan.
Mungkinkah berakhir di sini? Dan sekali lagi, tidak. Metode HTTP, seperti disebutkan di atas, memiliki “keajaiban” tersendiri. Dan bukan tanpa alasan metode GET banyak digunakan di Internet. Perhatikan bahwa metode ini dapat mengakses suatu konten, dapat mengatur kondisi yang dapat diinterpretasikan oleh elemen infrastruktur sebelum kontrol ditransfer ke kode Anda, dan seterusnya. Semua ini memungkinkan Anda membuat infrastruktur yang fleksibel dan mudah dikelola yang mampu menangani aliran permintaan yang sangat besar. Namun di RPC metode ini... diabaikan.
Jadi mengapa mitos bahwa permintaan batch (RPC) lebih cepat begitu bertahan? Secara pribadi, menurut saya sebagian besar proyek tidak mencapai tingkat perkembangan di mana REST mampu menunjukkan kekuatannya. Apalagi dalam proyek kecil, dia lebih rela menunjukkan kelemahannya.
Pilihan REST atau RPC bukanlah pilihan kemauan individu dalam suatu proyek. Pilihan ini harus memenuhi persyaratan proyek. Jika sebuah proyek mampu mengeluarkan semua yang dapat dihasilkannya dari REST, dan proyek tersebut benar-benar membutuhkannya, maka REST akan menjadi pilihan yang sangat baik.
Namun jika, untuk mendapatkan semua manfaat REST, Anda perlu mempekerjakan spesialis pengembang agar proyek dapat meningkatkan skala infrastruktur dengan cepat, administrator untuk mengelola infrastruktur, seorang arsitek untuk merancang semua lapisan layanan WEB... dan proyek , sekaligus menjual tiga bungkus margarin sehari... Saya akan tetap menggunakan RPC, karena... protokol ini lebih bermanfaat. Ini tidak memerlukan pengetahuan mendalam tentang cara kerja cache dan infrastruktur, tetapi akan memfokuskan pengembang pada panggilan yang sederhana dan mudah dipahami terhadap prosedur yang dia perlukan. Bisnis akan bahagia.
Permintaan RPC lebih dapat diandalkan karena dapat mengeksekusi permintaan batch dalam satu transaksi
Properti RPC ini merupakan keuntungan yang pasti, karena Sangat mudah untuk menjaga database tetap konsisten. Namun dengan REST, segalanya menjadi semakin rumit. Permintaan mungkin datang secara tidak konsisten ke node backend yang berbeda.
“Kerugian” REST ini adalah kebalikan dari kelebihannya yang dijelaskan di atas – kemampuan untuk menggunakan semua sumber daya infrastruktur secara efisien. Jika infrastruktur dirancang dengan buruk, dan terlebih lagi jika arsitektur proyek dan khususnya database dirancang dengan buruk, maka hal ini akan sangat merepotkan.
Namun apakah permintaan batch dapat diandalkan seperti kelihatannya? Mari kita lihat sebuah kasus: kita membuat pengguna, memperkaya profilnya dengan beberapa deskripsi dan mengiriminya SMS berisi rahasia untuk menyelesaikan pendaftaran. Itu. tiga panggilan dalam satu permintaan batch.
Mari kita lihat diagramnya. Ini menghadirkan infrastruktur dengan elemen ketersediaan tinggi. Ada dua saluran komunikasi independen dengan SMS gateway. Tapi... apa yang kita lihat? Saat mengirim SMS, terjadi kesalahan 503 - layanan untuk sementara tidak tersedia. Karena Pengiriman SMS dikemas dalam permintaan batch, kemudian seluruh permintaan harus dibatalkan. Tindakan di DBMS dibatalkan. Klien menerima kesalahan.
Percobaan berikutnya adalah lotere. Entah permintaan tersebut akan mengenai node yang sama berulang kali dan menghasilkan kesalahan lagi, atau Anda akan beruntung dan permintaan tersebut akan dieksekusi. Tapi yang terpenting adalah infrastruktur kita setidaknya pernah bekerja dengan sia-sia. Ada beban, tapi tidak ada untung.
Oke, mari kita bayangkan kita telah memaksakan diri (!) dan memikirkan opsi kapan permintaan tersebut dapat diselesaikan sebagian dengan sukses. Dan kami akan mencoba menyelesaikan sisanya lagi setelah interval waktu tertentu (Yang mana? Bagian depan yang memutuskan?). Tapi loterenya tetap sama. Permintaan pengiriman SMS memiliki peluang 50/50 untuk gagal lagi.
Setuju, dari sisi klien, layanan tampaknya tidak dapat diandalkan seperti yang kita inginkan... bagaimana dengan REST?
REST menggunakan keajaiban HTTP lagi, tetapi sekarang dengan kode respons. Ketika kesalahan 503 terjadi pada gateway SMS, backend menyiarkan kesalahan ini ke penyeimbang. Penyeimbang menerima kesalahan ini dan tanpa memutus koneksi dengan klien, mengirimkan permintaan ke node lain, yang berhasil memproses permintaan tersebut. Itu. klien menerima hasil yang diharapkan, dan infrastruktur menegaskan gelar tinggi “sangat mudah diakses”. Pengguna senang.
Dan sekali lagi itu belum semuanya. Penyeimbang tidak hanya menerima kode respons 503. Saat merespons, sesuai standar, disarankan untuk memberikan kode ini dengan header “Coba Lagi-Setelah”. Header memperjelas kepada penyeimbang bahwa ia tidak boleh mengganggu node pada rute ini untuk waktu tertentu. Dan selanjutnya permintaan pengiriman SMS akan dikirim langsung ke node yang tidak ada masalah dengan SMS gatewaynya.
Seperti yang bisa kita lihat, keandalan JSON-RPC dilebih-lebihkan. Memang lebih mudah mengatur konsistensi dalam database. Namun pengorbanannya, dalam hal ini, adalah keandalan sistem secara keseluruhan.
Kesimpulannya dalam banyak hal mirip dengan kesimpulan sebelumnya. Jika infrastrukturnya sederhana, kejelasan JSON-RPC jelas merupakan nilai tambah. Jika proyek melibatkan ketersediaan tinggi dengan beban tinggi, REST tampaknya merupakan solusi yang lebih tepat, meskipun lebih kompleks.
Ambang masuk ke REST lebih rendah
Saya pikir analisis di atas, yang menghilangkan prasangka stereotip yang ada tentang RPC, dengan jelas menunjukkan bahwa ambang batas untuk masuk ke REST tidak diragukan lagi lebih tinggi daripada ke RPC. Hal ini disebabkan perlunya pemahaman mendalam tentang cara kerja HTTP, serta kebutuhan untuk memiliki pengetahuan yang cukup tentang elemen infrastruktur yang ada yang dapat dan harus digunakan dalam proyek WEB.
Jadi mengapa banyak orang berpikir REST akan lebih sederhana? Pendapat pribadi saya adalah bahwa kesederhanaan yang tampak ini berasal dari wujud REST itu sendiri. Itu. REST bukanlah sebuah protokol tetapi sebuah konsep... REST tidak memiliki standar, ada beberapa pedoman... REST tidak lebih rumit dari HTTP. Kebebasan dan anarki yang nyata menarik “seniman bebas”.
Tentu saja, REST tidak lebih rumit dari HTTP. Namun HTTP sendiri adalah protokol yang dirancang dengan baik dan telah terbukti bermanfaat selama beberapa dekade. Jika tidak ada pemahaman mendalam tentang HTTP itu sendiri, maka REST tidak bisa dinilai.
Tapi tentang RPC - Anda bisa. Cukup dengan mengambil spesifikasinya. Jadi, apakah Anda membutuhkannya ? Atau masih REST yang rumit? Kamu putuskan.
Saya sangat berharap saya tidak menyia-nyiakan waktu Anda.
Sumber: www.habr.com