Aku yakin manawa judhul kasebut nyebabake reaksi sing sehat - "ya, wis diwiwiti maneh ..." Nanging supaya aku narik perhatian sampeyan sajrone 5-10 menit, lan aku bakal nyoba ora nguciwani pangarepan sampeyan.
Struktur artikel bakal kaya mangkene: statement stereotypical dijupuk lan "alam" munculé stereotype iki dicethakaké. Muga-muga iki bakal ngidini sampeyan ndeleng pilihan paradigma ijol-ijolan data ing proyek sampeyan saka sudut anyar.
Supaya luwih jelas babagan apa RPC, aku ngusulake nimbang standar kasebut . Kanthi REST ora ana kajelasan. Lan mesthine ora. Kabeh sing sampeyan kudu ngerti babagan REST - ora bisa dibedakake .
Panjaluk RPC luwih cepet lan luwih efisien amarga ngidini sampeyan nggawe panjaluk batch.
Intine yaiku ing RPC sampeyan bisa nelpon sawetara prosedur sekaligus ing siji panyuwunan. Contone, nggawe pangguna, nambah avatar lan, ing panjalukan sing padha, langganan sawetara topik. Mung siji panjalukan, lan pinten keuntungan!
Pancen, yen sampeyan duwe mung siji simpul backend, bakal katon luwih cepet karo panjalukan kumpulan. Amarga telung panjaluk REST mbutuhake sumber daya kaping telu luwih saka siji simpul kanggo nggawe sambungan.
Elinga yen panjalukan pisanan ing kasus REST kudu ngasilake ID pangguna supaya panjaluk sabanjure bisa ditindakake. Sing uga mengaruhi asil sakabèhé.
Nanging infrastruktur kasebut mung bisa ditemokake ing solusi internal lan Enterprise. Minangka pilihan pungkasan, ing proyek WEB cilik. Nanging solusi WEB lengkap, lan malah sing disebut HighLoad, ora worth mbangun. Infrastruktur kasebut kudu memenuhi kritéria kasedhiyan lan beban sing dhuwur. Lan gambar ganti.
Saluran kegiatan infrastruktur ing skenario sing padha ditandhani kanthi warna ijo. Delengen kepiye tumindak RPC saiki. Panjaluk nggunakake infrastruktur mung siji sikil saka balancer menyang backend. Nalika REST isih kalah ing panjalukan pisanan, iku nggawe wektu sing ilang nggunakake kabeh infrastruktur.
Cukup kanggo ngetik script ora loro panjalukan kanggo pengayaan, nanging, ngomong, lima utawa sepuluh ... lan jawaban kanggo pitakonan "sing menang saiki?" dadi ora jelas.
Aku propose kanggo njupuk dipikir malah luwih jembar ing masalah. Diagram nuduhake carane saluran infrastruktur digunakake, nanging infrastruktur ora winates kanggo saluran. Komponen penting saka infrastruktur dhuwur-munggah yaiku cache. Ayo saiki entuk sawetara artefak pangguna. bola-bali. Ayo ngomong 32 kaping.
Delengen kepiye infrastruktur RPC saya tambah akeh kanggo nyukupi kabutuhan beban sing dhuwur. Bab kasebut yaiku REST nggunakake kekuwatan lengkap protokol HTTP, ora kaya RPC. Ing diagram ing ndhuwur, kekuwatan iki diwujudake liwat metode panyuwunan - GET.
Cara HTTP, antara liya, duwe strategi caching. Sampeyan bisa nemokake ing dokumentasi ing . Kanggo RPC, panjalukan POST digunakake, sing ora dianggep idempoten, yaiku, pengulangan bola-bali saka panjalukan POST sing padha bisa ngasilake asil sing beda (contone, sawise saben komentar dikirim, salinan komentar liyane bakal katon) ().
Akibate, RPC ora bisa nggunakake cache infrastruktur kanthi efektif. Iki ndadékaké kanggo perlu kanggo "ngimpor" caches lunak. Diagram nuduhake Redis ing peran iki. Cache piranti lunak, uga mbutuhake pangembang kanggo nambah lapisan kode tambahan lan owah-owahan sing katon ing arsitektur.
Ayo saiki ngetung pira panjaluk REST lan RPC sing "lair" ing infrastruktur sing dianggep?
Njaluk
kothak mlebu
kanggo backend
menyang DBMS
kanggo soft cache (Redis)
TOTAL
REST
1/32 *
1
1
0
3 / 35
CPR
32
32
1
31
96
Dibandhingake karo skema pisanan, prabédan banget. Saiki entuk manfaat saka REST dadi jelas. Nanging aku menehi saran supaya ora mandheg. Infrastruktur sing dikembangake kalebu CDN. Asring uga ngrampungake masalah nglawan serangan DDoS lan DoS. Kita entuk:
Iki minangka kedadeyan sing ala banget kanggo RPC. RPC mung ora bisa ngirimake beban kerja menyang CDN. Kita mung bisa ngandelake sistem kanggo nglawan serangan.
Apa bisa rampung ing kene? Lan maneh, ora. Cara HTTP, kaya sing kasebut ing ndhuwur, duwe "sihir" dhewe. Lan ora ana alesan manawa metode GET digunakake ing Internet. Elinga yen cara iki bisa ngakses potongan konten, bisa nyetel kahanan sing bisa diinterpretasikake unsur infrastruktur sadurunge kontrol ditransfer menyang kode sampeyan, lan liya-liyane. Kabeh iki ngidini sampeyan nggawe infrastruktur sing fleksibel lan bisa diatur sing bisa nangani panjaluk sing akeh banget. Nanging ing RPC cara iki ... diabaikan.
Dadi kenapa mitos manawa panjaluk batch (RPC) luwih cepet dadi terus-terusan? Secara pribadi, misale jek umume proyek mung ora tekan tingkat pangembangan ing ngendi REST bisa nuduhake kekuwatane. Kajaba iku, ing proyek cilik, dheweke luwih seneng nuduhake kelemahane.
Pilihan REST utawa RPC ora dadi pilihan saka individu ing sawijining proyek. Pilihan iki kudu nyukupi syarat proyek kasebut. Yen proyek bisa ngempet kabeh sing bisa ditindakake saka REST, lan pancen butuh, REST bakal dadi pilihan sing apik.
Nanging yen, kanggo entuk kabeh mupangat saka REST, sampeyan kudu nyewa spesialis devops kanggo proyek kanthi cepet skala infrastruktur, pangurus kanggo ngatur infrastruktur, arsitek kanggo ngrancang kabeh lapisan layanan WEB ... lan proyek kasebut. , ing wektu sing padha, adol margarin telung bungkus saben dina ... Aku bakal tetep nganggo RPC, amarga ... protokol iki luwih utilitarian. Ora mbutuhake kawruh jero babagan cara kerja cache lan infrastruktur, nanging bakal fokus pangembang ing telpon sing gampang lan dingerteni kanggo prosedur sing dibutuhake. Bisnis bakal seneng.
Panjaluk RPC luwih dipercaya amarga bisa nglakokake panjaluk batch sajrone transaksi siji
Properti RPC iki minangka kauntungan sing mesthi, amarga Iku gampang kanggo njaga database konsisten. Nanging kanthi REST dadi luwih rumit. Panyuwunan bisa uga ora konsisten menyang simpul mburi sing beda.
"Kekurangan" REST iki minangka sisih flip saka kauntungan sing diterangake ing ndhuwur - kemampuan kanggo nggunakake kabeh sumber daya infrastruktur kanthi efisien. Yen prasarana dirancang kanthi ora apik, lan luwih-luwih yen arsitektur proyek lan basis data utamane ora dirancang, mula iki pancen nyeri banget.
Nanging panjaluk batch bisa dipercaya kaya sing katon? Ayo goleki kasus: nggawe pangguna, nambahake profil karo sawetara deskripsi lan ngirim SMS kanthi rahasia kanggo ngrampungake registrasi. Sing. telung telpon ing request kumpulan siji.
Ayo katon ing diagram. Iki nyedhiyakake infrastruktur kanthi unsur kasedhiyan dhuwur. Ana rong saluran komunikasi independen kanthi gateway SMS. Nanging ... apa sing kita deleng? Nalika ngirim SMS, ana kesalahan 503 - layanan sementara ora kasedhiya. Amarga Pangiriman SMS dikemas kanthi panjaluk batch, banjur kabeh panjaluk kudu digulung maneh. Tumindak ing DBMS dibatalake. Klien nampa kesalahan.
Coba sabanjure yaiku lotre. Salah siji panjalukan bakal mencet simpul padha maneh lan maneh kesalahan, utawa sampeyan bakal begja lan bakal kaleksanan. Nanging sing paling penting yaiku paling ora yen infrastruktur kita wis muspra. Ana beban, nanging ora ana bathi.
Oke, ayo mbayangno yen awake dhewe wis nyenyet (!) Lan mikir babagan pilihan nalika panjaluk bisa rampung kanthi sukses. Lan kita bakal nyoba kanggo ngrampungake liyane maneh sawise sawetara interval wektu (Sing siji? Apa ngarep arep?). Nanging lotre tetep padha. Panjaluk ngirim SMS duwe 50/50 kemungkinan gagal maneh.
Setuju, saka sisih klien, layanan kasebut ora bisa dipercaya kaya sing dikarepake ... kepiye REST?
REST nggunakake sihir HTTP maneh, nanging saiki nganggo kode respon. Nalika kesalahan 503 ana ing gateway SMS, backend ngirim kesalahan iki menyang balancer. Balancer nampa kesalahan iki lan tanpa ngilangi sambungan karo klien, ngirim panjalukan menyang simpul liyane, sing kasil ngolah panjaluk kasebut. Sing. klien nampa asil samesthine, lan infrastruktur nandheske judhul dhuwur "bisa diakses". Pangguna seneng.
Lan maneh ora kabeh. Balance ora mung nampa kode respon 503. Nalika nanggapi, miturut standar, disaranake nyedhiyakake kode iki kanthi header "Coba maneh-Sawise". Header kasebut nggawe pangimbang manawa ora ana gunane ngganggu simpul iki ing rute iki kanggo wektu sing ditemtokake. Lan panjalukan sabanjure kanggo ngirim SMS bakal dikirim langsung menyang simpul sing ora ana masalah karo gateway SMS.
Minangka kita bisa ndeleng, linuwih saka JSON-RPC overrated. Pancen, luwih gampang ngatur konsistensi ing basis data. Nanging pengorbanan, ing kasus iki, bakal dadi linuwih sistem kanthi sakabehe.
Kesimpulane meh padha karo sing sadurunge. Nalika prasarana prasaja, jelas JSON-RPC mesthi dadi plus. Yen proyek kasebut kalebu kasedhiyan dhuwur kanthi beban sing dhuwur, REST katon minangka solusi sing luwih bener, sanajan luwih rumit.
Ambang entri menyang REST luwih murah
Aku mikir yen analisis ndhuwur, debunking stereotypes mantep babagan RPC, cetha nuduhake yen batesan kanggo mlebu menyang REST temtunipun luwih dhuwur tinimbang menyang RPC. Iki amarga perlu kanggo pangerten jero babagan cara HTTP bisa digunakake, uga kudu duwe kawruh sing cukup babagan unsur infrastruktur sing ana sing bisa lan kudu digunakake ing proyek WEB.
Dadi kenapa akeh wong mikir yen REST bakal luwih gampang? Pendapat pribadiku yaiku kesederhanaan sing katon saka REST sing diwujudake. Sing. REST dudu protokol nanging konsep ... REST ora duwe standar, ana sawetara pedoman ... REST ora luwih rumit tinimbang HTTP. Kebebasan lan anarki sing katon narik "seniman gratis".
Mesthi, REST ora luwih rumit tinimbang HTTP. Nanging HTTP dhewe minangka protokol sing dirancang kanthi apik sing wis mbuktekake regane sajrone pirang-pirang dekade. Yen ora ana pangerten jero babagan HTTP dhewe, banjur REST ora bisa diadili.
Nanging babagan RPC - sampeyan bisa. Iku cukup kanggo njupuk specification sawijining. Dadi sampeyan butuh ? Utawa isih angel REST? Sampeyan mutusake.
Aku ngarep-arep banget yen aku ora mbuwang wektu sampeyan.
Source: www.habr.com