Əminəm ki, başlıq sağlam reaksiyaya səbəb oldu - "yaxşı, yenidən başladı ..." Ancaq icazə verin, 5-10 dəqiqə diqqətinizi çəkim və gözləntilərinizi puç etməməyə çalışacağam.
Məqalənin strukturu belə olacaq: stereotipik ifadə alınır və bu stereotipin yaranmasının “təbiəti” üzə çıxarılır. Ümid edirəm ki, bu, layihələrinizdə məlumat mübadiləsi paradiqmasının seçiminə yeni bucaqdan baxmağa imkan verəcək.
RPC-nin nə olduğunu aydınlaşdırmaq üçün standartı nəzərdən keçirməyi təklif edirəm . REST ilə heç bir aydınlıq yoxdur. Və olmamalıdır. REST haqqında bilmək lazım olan hər şey - ondan fərqləndirmək mümkün deyil .
RPC sorğuları daha sürətli və daha səmərəlidir, çünki onlar toplu sorğular etməyə imkan verir.
Məsələ ondadır ki, RPC-də bir sorğuda bir neçə proseduru eyni anda çağıra bilərsiniz. Məsələn, istifadəçi yaradın, ona avatar əlavə edin və eyni sorğuda onu bəzi mövzulara abunə olun. Yalnız bir xahiş və nə qədər fayda!
Həqiqətən, yalnız bir backend nodeunuz varsa, toplu sorğu ilə daha sürətli görünəcək. Çünki üç REST sorğusu əlaqə yaratmaq üçün bir qovşaqdan üç dəfə çox resurs tələb edəcək.
Nəzərə alın ki, REST vəziyyətində ilk sorğu sonrakı sorğuların edilməsi üçün istifadəçi ID-ni qaytarmalıdır. Bu da ümumi nəticəyə mənfi təsir göstərir.
Lakin bu cür infrastrukturlar yalnız daxili həllərdə və Enterprise-də tapıla bilər. Son çarə olaraq, kiçik WEB layihələrində. Ancaq tam hüquqlu WEB həlləri və hətta HighLoad adlanan həllər qurmağa dəyməz. Onların infrastrukturu yüksək əlçatanlıq və yüklənmə meyarlarına cavab verməlidir. Və şəkil dəyişir.
Eyni ssenari üzrə infrastruktur fəaliyyət kanalları yaşıl rənglə qeyd olunub. RPC-nin indi necə davrandığına diqqət yetirin. Sorğu balanslaşdırıcıdan arxa tərəfə qədər yalnız bir ayaqda infrastrukturdan istifadə edir. REST hələ də ilk sorğuda itirsə də, bütün infrastrukturdan istifadə edərək itirilmiş vaxtı tamamlayır.
Ssenariyə zənginləşmə üçün iki sorğu yox, deyək ki, beş və ya on... və “indi kim qalib gəlir?” sualının cavabını daxil etmək kifayətdir. qeyri-müəyyən olur.
Problemə daha geniş nəzər salmağı təklif edirəm. Diaqram infrastruktur kanallarının necə istifadə edildiyini göstərir, lakin infrastruktur yalnız kanallarla məhdudlaşmır. Yüksək yüklü infrastrukturun mühüm komponenti keşlərdir. İndi bir növ istifadəçi artefaktını əldə edək. Dəfələrlə. 32 dəfə deyək.
RPC infrastrukturunun yüksək yük tələblərinə cavab vermək üçün necə əhəmiyyətli dərəcədə yaxşılaşdığına baxın. İş ondadır ki, REST RPC-dən fərqli olaraq HTTP protokolunun tam gücündən istifadə edir. Yuxarıdakı diaqramda bu güc sorğu metodu - GET vasitəsilə həyata keçirilir.
HTTP metodları, digər şeylər arasında, keşləmə strategiyalarına malikdir. Onları sənədlərdə tapa bilərsiniz . RPC üçün idempotent sayılmayan POST sorğularından istifadə olunur, yəni eyni POST sorğularının təkrar təkrarlanması fərqli nəticələr verə bilər (məsələn, hər şərh göndərildikdən sonra bu şərhin başqa bir nüsxəsi görünəcək) ().
Nəticədə, RPC infrastruktur keşlərindən səmərəli istifadə edə bilmir. Bu, proqram keşlərinin "import" ehtiyacına səbəb olur. Diaqram Redisi bu rolda göstərir. Proqram keşi, öz növbəsində, tərtibatçıdan əlavə kod qatını və arxitekturada nəzərəçarpacaq dəyişiklikləri əlavə etməyi tələb edir.
İndi hesablayaq ki, baxılan infrastrukturda REST və RPC neçə sorğu “doğurdu”?
İstək
Gələnlər qutusu
arxa uç üçün
DBMS-ə
yumşaq önbelleğe (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Birinci sxemlə müqayisədə fərq təəccüblüdür. İndi REST-in faydası aydın olur. Ancaq orada dayanmamağı təklif edirəm. İnkişaf etmiş infrastruktura CDN daxildir. Çox vaxt DDoS və DoS hücumlarına qarşı mübarizə məsələsini də həll edir. Biz əldə edirik:
RPC üçün işlərin həqiqətən pis olduğu yer budur. RPC sadəcə olaraq iş yükünü CDN-ə həvalə edə bilmir. Hücumlara qarşı yalnız sistemlərə etibar edə bilərik.
Burada bitmək mümkündürmü? Və yenə yox. Yuxarıda qeyd edildiyi kimi, HTTP metodlarının öz “sehrləri” var. GET metodunun internetdə geniş istifadə olunması da səbəbsiz deyil. Nəzərə alın ki, bu üsul məzmuna daxil ola bilir, nəzarət kodunuza ötürülməzdən əvvəl infrastruktur elementlərinin şərh edə biləcəyi şərtləri təyin edə bilir və s. Bütün bunlar sizə həqiqətən böyük sorğu axınını idarə edə bilən çevik, idarə oluna bilən infrastrukturlar yaratmağa imkan verir. Lakin RPC-də bu üsul... nəzərə alınmır.
Bəs niyə toplu sorğuların (RPC) daha sürətli olması barədə mif bu qədər davamlıdır? Şəxsən mənə elə gəlir ki, əksər layihələr sadəcə olaraq REST-in gücünü göstərə bildiyi inkişaf səviyyəsinə çatmır. Üstəlik, kiçik layihələrdə zəif tərəflərini göstərməyə daha çox meyllidir.
REST və ya RPC seçimi layihədə fərdin könüllü seçimi deyil. Bu seçim layihənin tələblərinə cavab verməlidir. Əgər layihə həqiqətən REST-dən edə biləcəyi hər şeyi sıxışdıra bilirsə və ona həqiqətən ehtiyacı varsa, REST əla seçim olacaq.
Ancaq REST-in bütün üstünlüklərini əldə etmək üçün, infrastrukturu tez bir zamanda genişləndirmək üçün layihə üçün devops mütəxəssislərini, infrastrukturu idarə etmək üçün inzibatçıları, WEB xidmətinin bütün təbəqələrini dizayn etmək üçün bir memar işə götürməlisiniz ... və layihə , eyni zamanda gündə üç paket marqarin satır... Mən RPC-dən yapışardım, çünki... bu protokol daha faydalıdır. Bu, keşlərin və infrastrukturun necə işlədiyinə dair dərin bilik tələb etməyəcək, lakin tərtibatçını ehtiyac duyduğu prosedurlara sadə və başa düşülən zənglərə yönəldəcək. Biznes xoşbəxt olacaq.
RPC sorğuları daha etibarlıdır, çünki onlar toplu sorğuları bir əməliyyat çərçivəsində yerinə yetirə bilirlər
RPC-nin bu xüsusiyyəti müəyyən bir üstünlükdür, çünki Verilənlər bazasını ardıcıl saxlamaq asandır. Ancaq REST ilə bu getdikcə mürəkkəbləşir. Sorğular fərqli arxa qovşaqlara uyğunsuz gələ bilər.
REST-in bu "dezavantajı" yuxarıda təsvir edilən üstünlüyünün əks tərəfidir - bütün infrastruktur resurslarından səmərəli istifadə etmək imkanı. Əgər infrastruktur zəif layihələndirilibsə və daha çox layihənin arxitekturası və xüsusən də verilənlər bazası zəif dizayn edilibsə, bu, həqiqətən də böyük ağrıdır.
Bəs toplu sorğular göründüyü qədər etibarlıdırmı? Bir işə baxaq: biz istifadəçi yaradırıq, onun profilini bəzi təsvirlərlə zənginləşdiririk və qeydiyyatı tamamlamaq üçün ona sirrlə SMS göndəririk. Bunlar. bir toplu sorğuda üç zəng.
Diaqrama baxaq. O, yüksək əlçatanlıq elementləri olan bir infrastruktur təqdim edir. SMS şlüzləri olan iki müstəqil rabitə kanalı var. Amma... biz nə görürük? SMS göndərərkən 503 səhvi baş verir - xidmət müvəqqəti olaraq mövcud deyil. Çünki SMS göndərilməsi toplu sorğuda paketlənir, sonra bütün sorğu geri qaytarılmalıdır. DBMS-də hərəkətlər ləğv edilir. Müştəri xəta alır.
Növbəti sınaq lotereyadır. Ya sorğu təkrar-təkrar eyni node vuracaq və təkrar xəta qaytaracaq, ya da şanslı olacaqsınız və o, yerinə yetiriləcək. Amma əsas odur ki, heç olmasa bir dəfə infrastrukturumuz artıq əbəs işləyib. Yük var idi, amma qazanc yox idi.
Yaxşı, təsəvvür edək ki, biz özümüzü gərginləşdirmişik (!) və sorğunun qismən uğurla tamamlana biləcəyi variantı düşünmüşük. Qalanını isə müəyyən vaxt intervalından sonra yenidən tamamlamağa çalışacağıq (hansı? Cəbhə qərar verir?). Amma lotereya eyni qaldı. SMS göndərmə sorğusunun təkrar uğursuzluq şansı 50/50-dir.
Razılaşın, müştəri tərəfdən xidmət bizim istədiyimiz qədər etibarlı görünmür... Bəs REST?
REST yenidən HTTP sehrindən istifadə edir, lakin indi cavab kodları ilə. SMS şlüzində 503 xətası baş verdikdə, arxa uç bu xətanı balanslaşdırıcıya ötürür. Balanslaşdırıcı bu xətanı alır və müştəri ilə əlaqəni kəsmədən sorğunu müvəffəqiyyətlə emal edən başqa node-a göndərir. Bunlar. müştəri gözlənilən nəticəni alır və infrastruktur özünün yüksək “yüksək əlçatan” adını təsdiqləyir. İstifadəçi xoşbəxtdir.
Və yenə də hamısı deyil. Balanslaşdırıcı sadəcə 503 cavab kodunu almadı. Cavab verərkən, standarta uyğun olaraq, bu kodu “Yenidən cəhd et” başlığı ilə təmin etmək məsləhətdir. Başlıq balanslaşdırıcıya aydın edir ki, müəyyən bir müddət ərzində bu marşrutda bu nodu narahat etməyə dəyməz. Və SMS göndərmək üçün növbəti sorğular birbaşa SMS şlüzü ilə heç bir problemi olmayan bir node göndəriləcək.
Gördüyümüz kimi, JSON-RPC-nin etibarlılığı həddən artıq qiymətləndirilib. Həqiqətən, verilənlər bazasında ardıcıllığı təşkil etmək daha asandır. Ancaq qurban, bu halda, bütövlükdə sistemin etibarlılığı olacaq.
Nəticə əsasən əvvəlkinə bənzəyir. İnfrastruktur sadə olduqda, JSON-RPC-nin aşkarlığı mütləq bir artıdır. Layihə yüksək yüklə yüksək əlçatanlığı nəzərdə tutursa, REST daha düzgün, baxmayaraq ki, daha mürəkkəb bir həll kimi görünür.
REST üçün giriş həddi daha aşağıdır
Düşünürəm ki, yuxarıdakı təhlil, RPC haqqında qurulmuş stereotipləri pozaraq, REST-ə giriş həddinin, şübhəsiz ki, RPC-dən daha yüksək olduğunu açıq şəkildə göstərdi. Bu, HTTP-nin necə işlədiyini dərindən başa düşmək ehtiyacı, həmçinin WEB layihələrində istifadə oluna bilən və istifadə edilməli olan mövcud infrastruktur elementləri haqqında kifayət qədər biliyə malik olmaq ehtiyacı ilə bağlıdır.
Bəs niyə bir çox insan REST-in daha sadə olacağını düşünür? Mənim şəxsi fikrim budur ki, bu zahiri sadəlik REST-dən qaynaqlanır. Bunlar. REST protokol deyil, konseptdir... REST-in standartı yoxdur, bəzi qaydalar var... REST HTTP-dən mürəkkəb deyil. Görünən azadlıq və anarxiya “azad sənətkarları” cəlb edir.
Əlbəttə ki, REST HTTP-dən daha mürəkkəb deyil. Lakin HTTP özü onilliklər ərzində öz dəyərini sübut edən yaxşı işlənmiş protokoldur. HTTP-nin özü haqqında dərin bir anlayış yoxdursa, REST-i mühakimə etmək olmaz.
Ancaq RPC haqqında - edə bilərsiniz. Onun spesifikasiyasını götürmək kifayətdir. Deməli, ehtiyacınız var ? Yoxsa hələ də çətin REST? Siz qərar verin.
Ümid edirəm ki, vaxtınızı boşa keçirməmişəm.
Mənbə: www.habr.com