Kuring yakin yén headline ngabalukarkeun réaksi séhat - "muhun, éta dimimitian deui ..." Tapi hayu atuh candak perhatian Anjeun pikeun 5-10 menit, sarta kuring bakal coba teu nguciwakeun ekspektasi Anjeun.
Struktur artikel bakal kieu: pernyataan stereotypical dicokot tur "sifat" mecenghulna stereotype ieu wangsit. Kuring miharep ieu bakal ngidinan Anjeun pikeun nempo pilihan paradigma bursa data dina proyék anjeun ti sudut anyar.
Dina raraga jadi jelas ngeunaan naon RPC, abdi ngajukeun mertimbangkeun standar . Kalayan REST teu aya kajelasan. Sareng henteu kedah. Sagalana nu peryogi kauninga ngeunaan REST - teu bisa dibédakeun tina .
Paménta RPC langkung gancang sareng langkung éfisién sabab ngamungkinkeun anjeun ngadamel pamundut bets.
Intina nyaéta dina RPC anjeun tiasa nelepon sababaraha prosedur sakaligus dina hiji pamundut. Salaku conto, jieun pangguna, tambahkeun avatar ka anjeunna sareng, dina pamundut anu sami, ngalanggan anjeunna kana sababaraha topik. Ngan hiji pamundut, sarta sabaraha kauntungan!
Mémang, upami anjeun ngan ukur gaduh hiji titik backend, éta bakal sigana langkung gancang kalayan pamundut bets. Kusabab tilu pamenta REST ngabutuhkeun sumber daya tilu kali langkung ti hiji titik pikeun ngadamel sambungan.
Catet yén pamundut anu munggaran dina kasus REST kedah ngabalikeun ID pangguna supados pamundut salajengna tiasa dilakukeun. Nu ogé négatip mangaruhan hasil sakabéh.
Tapi infrastruktur sapertos kitu ngan tiasa dipendakan dina solusi in-house sareng Perusahaan. Salaku Resort panungtungan, dina proyék WEB leutik. Tapi solusi WEB full-fledged, komo nu disebut HighLoad, teu patut ngawangun. Infrastrukturna kedah nyumponan kriteria kasadiaan sareng beban anu luhur. Sareng gambarna robih.
Saluran kagiatan prasarana dina skenario anu sami ditandaan héjo. Perhatikeun kumaha kalakuan RPC ayeuna. Paménta ngagunakeun infrastruktur dina ngan hiji leg ti balancer ka backend nu. Nalika REST masih kaleungitan dina pamundut anu munggaran, éta nyéépkeun waktos anu leungit nganggo sadayana infrastruktur.
Cukup asupkeun kana naskah sanés dua pamundut pikeun pengayaan, tapi, sebutkeun, lima atanapi sapuluh ... sareng jawaban kana patarosan "saha anu meunang ayeuna?" janten teu jelas.
Kuring ngajukeun pikeun nyandak hiji tampilan malah lega dina masalah. Diagram nunjukkeun kumaha saluran infrastruktur dianggo, tapi infrastruktur henteu dugi ka saluran. Komponén penting tina infrastruktur beban tinggi nyaéta caches. Hayu urang ayeuna meunang sababaraha jenis artefak pamaké. diulang-ulang. Sebutkeun 32 kali.
Tingali kumaha infrastruktur RPC parantos ningkat sacara signifikan pikeun nyumponan tungtutan beban anu luhur. Masalahna nyaéta REST ngagunakeun kakuatan pinuh ku protokol HTTP, teu sapertos RPC. Dina diagram di luhur, kakuatan ieu diwujudkeun ngaliwatan métode pamundut - GET.
métode HTTP, diantara hal séjén, boga strategi cache. Anjeun tiasa mendakanana dina dokuméntasi di . Pikeun RPC, requests POST dipaké, nu teu dianggap idempotent, nyaeta, pangulangan ulang tina requests POST sarua bisa balik hasil béda (contona, sanggeus unggal komentar dikirim, salinan sejen tina komentar ieu bakal muncul) ().
Akibatna, RPC henteu tiasa sacara efektif ngagunakeun cache infrastruktur. Ieu ngakibatkeun kabutuhan pikeun "impor" caches software. Diagram nunjukkeun Redis dina peran ieu. The cache software, kahareupna merlukeun pamekar pikeun nambahkeun hiji lapisan tambahan kode jeung parobahan noticeable dina arsitektur.
Hayu ayeuna urang ngitung sabaraha pamundut REST sareng RPC "ngalahirkeun" dina infrastruktur anu dipertimbangkeun?
Paménta
koropak
pikeun backend
kana DBMS
ka cache lemes (Redis)
total
ngaso
1/32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Dibandingkeun sareng skéma munggaran, bédana luar biasa. Ayeuna kauntungan REST janten jelas. Tapi kuring nyarankeun teu eureun di dinya. Infrastruktur anu dikembangkeun kalebet CDN. Seringna ogé ngarengsekeun masalah ngalawan serangan DDoS sareng DoS. Urang meunang:
Ieu dimana hal janten parah pisan pikeun RPC. RPC ngan saukur teu mampuh ngirimkeun beban kerja ka CDN. Urang ngan ukur tiasa ngandelkeun sistem pikeun ngalawan serangan.
Éta mungkin mungkas di dieu? Jeung deui, henteu. métode HTTP, sakumaha disebutkeun di luhur, boga sorangan "magic". Sareng sanés alesan yén metode GET seueur dianggo dina Internét. Catet yén metodeu ieu tiasa ngaksés sapotong eusi, tiasa nyetél kaayaan anu tiasa diinterpretasi ku elemen infrastruktur sateuacan kontrol ditransferkeun kana kode anjeun, sareng saterasna. Sadaya ieu ngamungkinkeun anjeun nyiptakeun infrastruktur anu fleksibel sareng tiasa diurus anu tiasa ngadamel aliran paménta anu ageung. Tapi dina RPC metoda ieu ... teu dipalire.
Janten naha mitos yén pamundut bets (RPC) langkung gancang janten pengkuh? Pribadi, sigana kuring yén kalolobaan proyék ngan saukur henteu ngahontal tingkat pangembangan dimana REST tiasa nunjukkeun kakuatanana. Sumawona, dina proyék-proyék leutik, anjeunna langkung daék nunjukkeun kalemahanana.
Pilihan REST atanapi RPC sanes pilihan volitional hiji individu dina proyék. Pilihan ieu kedah nyumponan sarat proyék. Lamun hiji proyék bisa squeeze sagalana bener bisa kaluar tina REST, sarta bener butuh eta, teras REST bakal pilihan alus teuing.
Tapi lamun, dina raraga neangan sagala mangpaat REST, Anjeun kudu nyewa devops spesialis pikeun proyék pikeun gancang skala infrastruktur, pangurus pikeun ngatur infrastruktur, hiji arsiték mendesain sakabéh lapisan layanan WEB ... , dina waktos anu sami, ngajual tilu bungkus margarin sadinten... Abdi bakal tetep nganggo RPC, sabab ... protokol ieu leuwih mangpaat. Éta moal meryogikeun pangaweruh anu jero ngeunaan cara cache sareng infrastruktur jalan, tapi bakal museurkeun pamekar kana telepon anu sederhana sareng kaharti kana prosedur anu diperyogikeun. Usaha bakal bagja.
Paménta RPC langkung dipercaya sabab tiasa ngalaksanakeun pamundut bets dina hiji transaksi
Ieu sipat RPC mangrupakeun kaunggulan definite, sabab Ieu gampang tetep database konsisten. Tapi kalayan REST janten langkung rumit. Paménta tiasa dugi ka teu konsisten ka titik backend anu béda.
"Kalemahan" REST ieu mangrupikeun sisi sabalikna tina kauntungan anu dijelaskeun di luhur - kamampuan pikeun éfisién ngagunakeun sadaya sumber daya infrastruktur. Upami infrastrukturna kirang dirancang, komo deui upami arsitéktur proyék sareng pangkalan data khususna kirang dirancang, maka ieu leres-leres nyeri.
Tapi naha pamundut bets tiasa dipercaya sakumaha sigana? Hayu urang nempo hiji pasualan: urang nyieun hiji pamaké, enrich profil na kalawan sababaraha pedaran tur ngirim anjeunna hiji SMS kalayan rusiah pikeun ngalengkepan pendaptaran. Jelema. tilu telepon dina hiji pamundut bets.
Hayu urang nempo diagram. Ieu presents hiji infrastruktur jeung elemen kasadiaan tinggi. Aya dua saluran komunikasi mandiri sareng gateway SMS. Tapi... naon anu urang tingali? Nalika ngirim SMS, kasalahan 503 lumangsung - jasa samentawis henteu sayogi. Sabab Ngirim SMS dibungkus dina pamundut bets, teras sadayana pamundut kedah digulung deui. Laku lampah dina DBMS dibatalkeun. Klién nampi kasalahan.
Cobaan salajengna nyaéta lotre. Boh pamundut bakal pencét titik sarua deui jeung deui balik kasalahan, atawa anjeun bakal untung na eta bakal dieksekusi. Tapi anu utama nyaéta sahenteuna sakali infrastruktur urang parantos damel sia-sia. Aya beban, tapi euweuh kauntungan.
Oké, hayu urang ngabayangkeun yén urang tapis sorangan (!) Jeung mikir ngaliwatan pilihan lamun pamundut bisa sawaréh réngsé junun. Sarta kami bakal nyoba ngalengkepan sésana deui sanggeus sababaraha interval waktu (Nu hiji? Naha hareup mutuskeun?). Tapi lotre tetep sarua. Paménta pikeun ngirim SMS ngagaduhan kasempetan 50/50 gagal deui.
Satuju, ti sisi klien, palayanan sigana henteu dipercaya sapertos anu urang pikahoyong ... kumaha upami REST?
REST nganggo sihir HTTP deui, tapi ayeuna nganggo kode réspon. Nalika kasalahan 503 lumangsung dina gateway SMS, backend nu disiarkeun kasalahan ieu balancer nu. Balancer nampi kasalahan ieu sareng tanpa megatkeun sambungan sareng klien, ngirim pamundut ka titik sejen, nu hasil ngolah pamundut teh. Jelema. klien nu narima hasil ekspektasi, sarta infrastruktur confirms judul luhur na "kacida diaksés". pamaké éta senang.
Sareng deui éta sanés sadayana. Balancer henteu ngan ukur nampi kodeu réspon 503. Nalika ngaréspon, dumasar kana standar, disarankeun pikeun nyayogikeun kode ieu sareng lulugu "Coba-Sanggeus". Lulugu ngajelaskeun ka balancer yén éta henteu kedah ngaganggu titik ieu dina jalur ieu pikeun waktos anu ditangtukeun. Sareng pamundut salajengna pikeun ngirim SMS bakal dikirim langsung ka titik anu teu aya masalah sareng gateway SMS.
Sakumaha anu urang tingali, reliabiliti JSON-RPC overrated. Mémang, langkung gampang pikeun ngatur konsistensi dina pangkalan data. Tapi kurban, dina hal ieu, bakal reliabiliti sistem sakabéhna.
Kacindekan umumna sami sareng anu sateuacana. Nalika infrastrukturna saderhana, jelasna JSON-RPC pasti tambah. Lamun proyek ngalibatkeun kasadiaan tinggi kalawan beban tinggi, REST Sigana leuwih bener, sanajan leuwih kompleks, solusi.
Ambang asup ka REST leuwih handap
Jigana éta analisis di luhur, debunking stereotypes ngadegkeun ngeunaan RPC, jelas némbongkeun yén bangbarung pikeun asupna kana REST nyaeta undoubtedly leuwih luhur ti kana RPC. Ieu alatan kabutuhan pikeun pamahaman jero kumaha HTTP jalan, kitu ogé kudu boga pangaweruh cukup ngeunaan elemen infrastruktur aya nu bisa jeung kudu dipaké dina proyék WEB.
Janten naha seueur jalma mikir yén REST bakal langkung saderhana? Pamadegan pribadi kuring nyaéta yén kesederhanaan anu katingali ieu asalna tina REST manifests sorangan. Jelema. REST sanes protokol tapi konsep... REST teu gaduh standar, aya sababaraha pedoman... REST teu langkung rumit tibatan HTTP. Kabébasan semu jeung anarki narik "seniman bébas".
Tangtosna, REST henteu langkung rumit tibatan HTTP. Tapi HTTP sorangan mangrupikeun protokol anu dirarancang saé anu parantos kabuktian nilaina salami sababaraha dekade. Lamun teu aya pamahaman jero ngeunaan HTTP sorangan, teras REST teu bisa judged.
Tapi ngeunaan RPC - anjeun tiasa. Ieu cukup pikeun nyandak spésifikasi na. Janten anjeun peryogi ? Atawa éta masih tricky REST? Anjeun mutuskeun.
Abdi ngarep pisan yén kuring henteu nyéépkeun waktos anjeun.
sumber: www.habr.com