Saya pasti bahawa tajuk itu menyebabkan reaksi yang sihat - "baik, ia bermula semula..." Tetapi izinkan saya menarik perhatian anda selama 5-10 minit, dan saya akan cuba untuk tidak mengecewakan jangkaan anda.
Struktur artikel adalah seperti berikut: pernyataan stereotaip diambil dan "sifat" kemunculan stereotaip ini didedahkan. Saya harap ini akan membolehkan anda melihat pilihan paradigma pertukaran data dalam projek anda dari sudut baharu.
Untuk lebih jelas tentang apa itu RPC, saya mencadangkan untuk mempertimbangkan piawaian . Dengan REST tiada kejelasan. Dan ia tidak sepatutnya. Semua yang anda perlu tahu tentang REST - ia tidak dapat dibezakan .
Permintaan RPC adalah lebih pantas dan lebih cekap kerana ia membolehkan anda membuat permintaan kelompok.
Intinya ialah dalam RPC anda boleh memanggil beberapa prosedur sekaligus dalam satu permintaan. Sebagai contoh, buat pengguna, tambahkan avatar kepadanya dan, dalam permintaan yang sama, langgan dia kepada beberapa topik. Hanya satu permintaan, dan berapa banyak manfaatnya!
Sesungguhnya, jika anda hanya mempunyai satu nod hujung belakang, ia akan kelihatan lebih pantas dengan permintaan kelompok. Kerana tiga permintaan REST akan memerlukan tiga kali lebih banyak sumber daripada satu nod untuk mewujudkan sambungan.
Ambil perhatian bahawa permintaan pertama dalam kes REST mesti mengembalikan ID pengguna agar permintaan seterusnya dibuat. Yang juga memberi kesan negatif kepada keputusan keseluruhan.
Tetapi infrastruktur sedemikian hanya boleh didapati dalam penyelesaian dalaman dan Perusahaan. Sebagai pilihan terakhir, dalam projek WEB kecil. Tetapi penyelesaian WEB yang lengkap, malah yang dipanggil HighLoad, tidak berbaloi untuk dibina. Infrastruktur mereka mesti memenuhi kriteria ketersediaan dan beban yang tinggi. Dan gambar itu berubah.
Saluran aktiviti infrastruktur di bawah senario yang sama ditandakan dengan warna hijau. Perhatikan bagaimana RPC berkelakuan sekarang. Permintaan menggunakan infrastruktur hanya pada satu kaki dari pengimbang ke bahagian belakang. Walaupun REST masih kalah dalam permintaan pertama, ia menggantikan masa yang hilang menggunakan keseluruhan infrastruktur.
Ia cukup untuk memasukkan ke dalam skrip bukan dua permintaan untuk pengayaan, tetapi, katakan, lima atau sepuluh... dan jawapan kepada soalan "siapa yang menang sekarang?" menjadi tidak jelas.
Saya bercadang untuk melihat masalah yang lebih luas. Rajah menunjukkan cara saluran infrastruktur digunakan, tetapi infrastruktur tidak terhad kepada saluran. Komponen penting dalam infrastruktur beban tinggi ialah cache. Sekarang mari dapatkan beberapa jenis artifak pengguna. Berulang kali. Katakan 32 kali.
Lihat bagaimana infrastruktur RPC telah bertambah baik dengan ketara untuk memenuhi permintaan beban tinggi. Masalahnya ialah REST menggunakan kuasa penuh protokol HTTP, tidak seperti RPC. Dalam rajah di atas, kuasa ini direalisasikan melalui kaedah permintaan - GET.
Kaedah HTTP, antara lain, mempunyai strategi caching. Anda boleh menemuinya dalam dokumentasi di . Untuk RPC, permintaan POST digunakan, yang tidak dianggap idempoten, iaitu, pengulangan berulang permintaan POST yang sama mungkin mengembalikan hasil yang berbeza (contohnya, selepas setiap ulasan dihantar, salinan lain ulasan ini akan muncul) ().
Akibatnya, RPC tidak dapat menggunakan cache infrastruktur dengan berkesan. Ini membawa kepada keperluan untuk "mengimport" cache perisian. Rajah menunjukkan Redis dalam peranan ini. Cache perisian pula memerlukan pembangun menambah lapisan tambahan kod dan perubahan ketara dalam seni bina.
Sekarang mari kita kira berapa banyak permintaan REST dan RPC yang "melahirkan" dalam infrastruktur yang sedang dipertimbangkan?
permintaan
peti masuk
ke belakang
kepada DBMS
kepada cache lembut (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Berbanding dengan skim pertama, perbezaannya sangat ketara. Kini manfaat REST menjadi jelas. Tetapi saya cadangkan jangan berhenti di situ. Infrastruktur yang dibangunkan termasuk CDN. Selalunya ia juga menyelesaikan isu menentang serangan DDoS dan DoS. Kita mendapatkan:
Di sinilah keadaan menjadi sangat buruk untuk RPC. RPC sememangnya tidak mampu mengagihkan beban kerja kepada CDN. Kami hanya boleh bergantung pada sistem untuk melawan serangan.
Adakah mungkin untuk berakhir di sini? Dan sekali lagi, tidak. Kaedah HTTP, seperti yang dinyatakan di atas, mempunyai "sihir" mereka sendiri. Dan bukan tanpa sebab bahawa kaedah GET digunakan secara meluas di Internet. Ambil perhatian bahawa kaedah ini dapat mengakses sekeping kandungan, dapat menetapkan syarat yang boleh ditafsirkan oleh elemen infrastruktur sebelum kawalan dipindahkan ke kod anda dan seterusnya. Semua ini membolehkan anda mencipta infrastruktur yang fleksibel dan boleh diurus yang boleh mengendalikan aliran permintaan yang sangat besar. Tetapi dalam RPC kaedah ini... diabaikan.
Jadi mengapa mitos bahawa permintaan kelompok (RPC) lebih pantas begitu berterusan? Secara peribadi, nampaknya kebanyakan projek tidak mencapai tahap pembangunan di mana REST dapat menunjukkan kekuatannya. Lebih-lebih lagi, dalam projek kecil, dia lebih bersedia untuk menunjukkan kelemahannya.
Pilihan REST atau RPC bukanlah pilihan kehendak individu dalam sesuatu projek. Pilihan ini mesti memenuhi keperluan projek. Jika projek dapat memerah semua yang benar-benar boleh keluar dari REST, dan ia benar-benar memerlukannya, maka REST akan menjadi pilihan yang sangat baik.
Tetapi jika, untuk mendapatkan semua faedah REST, anda perlu mengupah pakar devops untuk projek itu untuk skala infrastruktur dengan cepat, pentadbir untuk mengurus infrastruktur, arkitek untuk mereka bentuk semua lapisan perkhidmatan WEB... dan projek , pada masa yang sama, menjual tiga pek marjerin sehari... Saya akan tetap dengan RPC, kerana... protokol ini lebih utilitarian. Ia tidak memerlukan pengetahuan mendalam tentang cara cache dan infrastruktur berfungsi, tetapi akan memfokuskan pembangun pada panggilan mudah dan mudah difahami kepada prosedur yang dia perlukan. Perniagaan akan senang.
Permintaan RPC lebih dipercayai kerana ia boleh melaksanakan permintaan kelompok dalam satu transaksi
Sifat RPC ini adalah kelebihan yang pasti, kerana Mudah untuk memastikan pangkalan data konsisten. Tetapi dengan REST ia menjadi lebih rumit. Permintaan mungkin tiba secara tidak konsisten ke nod hujung belakang yang berbeza.
"Kelemahan" REST ini ialah sisi lain dari kelebihannya yang diterangkan di atas - keupayaan untuk menggunakan semua sumber infrastruktur dengan cekap. Jika infrastruktur direka dengan buruk, dan lebih-lebih lagi jika seni bina projek dan pangkalan data khususnya direka dengan buruk, maka ini benar-benar menyakitkan.
Tetapi adakah permintaan kelompok boleh dipercayai seperti yang kelihatan? Mari lihat satu kes: kami mencipta pengguna, memperkayakan profilnya dengan beberapa penerangan dan menghantar SMS kepadanya dengan rahsia untuk melengkapkan pendaftaran. Itu. tiga panggilan dalam satu permintaan kelompok.
Mari lihat gambar rajah. Ia membentangkan infrastruktur dengan elemen ketersediaan tinggi. Terdapat dua saluran komunikasi bebas dengan gerbang SMS. Tetapi... apa yang kita nampak? Apabila menghantar SMS, ralat 503 berlaku - perkhidmatan tidak tersedia buat sementara waktu. Kerana Penghantaran SMS dibungkus dalam permintaan kelompok, maka keseluruhan permintaan mesti ditarik balik. Tindakan dalam DBMS dibatalkan. Pelanggan menerima ralat.
Percubaan seterusnya ialah loteri. Sama ada permintaan akan memukul nod yang sama sekali lagi dan sekali lagi mengembalikan ralat, atau anda akan bernasib baik dan ia akan dilaksanakan. Tetapi perkara utama ialah sekurang-kurangnya sekali infrastruktur kita telah berfungsi dengan sia-sia. Terdapat beban, tetapi tiada keuntungan.
Okey, mari kita bayangkan bahawa kita telah membebankan diri (!) dan memikirkan pilihan apabila permintaan itu boleh diselesaikan sebahagiannya dengan jayanya. Dan kami akan cuba menyelesaikan selebihnya sekali lagi selepas selang masa tertentu (Yang mana? Adakah bahagian depan yang memutuskan?). Tetapi loteri tetap sama. Permintaan untuk menghantar SMS mempunyai peluang 50/50 untuk gagal lagi.
Setuju, dari sisi pelanggan, perkhidmatan itu nampaknya tidak boleh dipercayai seperti yang kami mahukan... bagaimana pula dengan REST?
REST menggunakan keajaiban HTTP sekali lagi, tetapi kini dengan kod respons. Apabila ralat 503 berlaku pada get laluan SMS, bahagian belakang menyiarkan ralat ini kepada pengimbang. Pengimbang menerima ralat ini dan tanpa memutuskan sambungan dengan klien, menghantar permintaan ke nod lain, yang berjaya memproses permintaan. Itu. pelanggan menerima hasil yang diharapkan, dan infrastruktur mengesahkan tajuk tingginya "sangat boleh diakses". Pengguna gembira.
Dan sekali lagi bukan itu sahaja. Pengimbang bukan sahaja menerima kod respons 503. Apabila membalas, mengikut piawaian, adalah dinasihatkan untuk memberikan kod ini dengan pengepala "Cuba Semula Selepas". Pengepala menjelaskan kepada pengimbang bahawa ia tidak berbaloi untuk mengganggu nod ini pada laluan ini untuk masa yang ditentukan. Dan permintaan seterusnya untuk menghantar SMS akan dihantar terus ke nod yang tidak mempunyai masalah dengan gerbang SMS.
Seperti yang kita dapat lihat, kebolehpercayaan JSON-RPC terlalu tinggi. Malah, lebih mudah untuk mengatur konsistensi dalam pangkalan data. Tetapi pengorbanan, dalam kes ini, akan menjadi kebolehpercayaan sistem secara keseluruhan.
Kesimpulannya hampir sama dengan yang sebelumnya. Apabila infrastrukturnya mudah, kejelasan JSON-RPC pastinya merupakan kelebihan. Jika projek itu melibatkan ketersediaan tinggi dengan beban yang tinggi, REST kelihatan seperti penyelesaian yang lebih betul, walaupun lebih kompleks.
Ambang kemasukan ke REST adalah lebih rendah
Saya berpendapat bahawa analisis di atas, membongkar stereotaip yang telah ditetapkan tentang RPC, jelas menunjukkan bahawa ambang untuk kemasukan ke REST sudah pasti lebih tinggi daripada ke dalam RPC. Ini disebabkan oleh keperluan untuk pemahaman yang mendalam tentang cara HTTP berfungsi, serta keperluan untuk mempunyai pengetahuan yang mencukupi tentang elemen infrastruktur sedia ada yang boleh dan harus digunakan dalam projek WEB.
Jadi mengapa ramai orang berfikir bahawa REST akan menjadi lebih mudah? Pendapat peribadi saya adalah bahawa kesederhanaan yang jelas ini datang dari REST yang nyata. Itu. REST bukan protokol tetapi konsep... REST tidak mempunyai standard, terdapat beberapa garis panduan... REST tidak lebih rumit daripada HTTP. Kebebasan dan anarki yang jelas menarik "artis bebas".
Sudah tentu, REST tidak lebih rumit daripada HTTP. Tetapi HTTP sendiri ialah protokol yang direka dengan baik yang telah membuktikan nilainya selama beberapa dekad. Jika tiada pemahaman mendalam tentang HTTP itu sendiri, maka REST tidak boleh dinilai.
Tetapi mengenai RPC - anda boleh. Ia cukup untuk mengambil spesifikasinya. Jadi adakah anda perlukan ? Atau adakah ia masih sukar REHAT? Awak tentukan.
Saya sangat berharap bahawa saya tidak membuang masa anda.
Sumber: www.habr.com