Eminim manşet sağlıklı bir tepki uyandırmıştır – “eee, yeniden başladı…” Ama 5-10 dakika dikkatinizi çekeyim, beklentilerinizi boşa çıkarmamaya çalışacağım.
Makalenin yapısı şu şekilde olacaktır: Kalıplaşmış bir ifade alınır ve bu kalıplaşmış yargının ortaya çıkışının “doğası” ortaya çıkarılır. Umarım bu, projelerinizde veri alışverişi paradigması seçimine yeni bir açıdan bakmanıza olanak tanır.
RPC'nin ne olduğu konusunda net olmak için standardı dikkate almayı öneriyorum . REST ile netlik yoktur. Ve öyle olmamalı. REST hakkında bilmeniz gereken her şey; .
RPC istekleri, toplu istekler yapmanıza olanak tanıdığı için daha hızlı ve daha verimlidir.
Mesele şu ki, RPC'de tek bir istekte birden fazla prosedürü aynı anda arayabilirsiniz. Örneğin bir kullanıcı oluşturun, ona bir avatar ekleyin ve aynı istekte onu bazı konulara abone olun. Sadece bir istek ve ne kadar fayda!
Aslında, yalnızca bir arka uç düğümünüz varsa toplu istekle daha hızlı görünecektir. Çünkü üç REST isteği, bağlantı kurmak için bir düğümden üç kat daha fazla kaynak gerektirecektir.
REST durumunda ilk isteğin, sonraki isteklerin yapılabilmesi için kullanıcı kimliğini döndürmesi gerektiğini unutmayın. Bu da genel sonucu olumsuz etkiler.
Ancak bu tür altyapılar ancak kurum içi çözümlerde ve Enterprise'da bulunabilir. Küçük WEB projelerinde son çare olarak. Ancak tam teşekküllü WEB çözümleri ve hatta HighLoad adı verilenler bile oluşturmaya değmez. Altyapılarının yüksek kullanılabilirlik ve yük kriterlerini karşılaması gerekir. Ve resim değişiyor.
Aynı senaryo kapsamındaki altyapı faaliyet kanalları yeşil renkle işaretlenmiştir. RPC'nin şimdi nasıl davrandığına dikkat edin. İstek, altyapıyı dengeleyiciden arka uca kadar yalnızca tek ayak üzerinde kullanır. REST ilk istekte hala kayıp yaşarken, tüm altyapıyı kullanarak kaybedilen zamanı telafi ediyor.
Senaryoya zenginleştirme için iki değil, beş veya on talep girmek yeterlidir... ve "şimdi kim kazanır?" sorusunun cevabını girin. belirsiz hale gelir.
Soruna daha geniş bir açıdan bakmayı öneriyorum. Diyagramda altyapı kanallarının nasıl kullanıldığı gösterilmektedir ancak altyapı kanallarla sınırlı değildir. Yüksek yüklü bir altyapının önemli bir bileşeni önbelleklerdir. Şimdi bir tür kullanıcı eseri elde edelim. Defalarca. 32 kere diyelim.
Yüksek yük taleplerini karşılamak için RPC altyapısının nasıl önemli ölçüde geliştiğini görün. Mesele şu ki REST, RPC'den farklı olarak HTTP protokolünün tüm gücünü kullanıyor. Yukarıdaki diyagramda bu güç, istek yöntemi - GET aracılığıyla gerçekleştirilir.
HTTP yöntemleri, diğer şeylerin yanı sıra, önbellekleme stratejilerine sahiptir. Bunları adresindeki belgelerde bulabilirsiniz. . RPC için, bağımsız olarak kabul edilmeyen POST istekleri kullanılır, yani aynı POST isteklerinin tekrar tekrar tekrarlanması farklı sonuçlar verebilir (örneğin, her yorum gönderildikten sonra bu yorumun başka bir kopyası görünecektir) ().
Sonuç olarak RPC, altyapı önbelleklerini etkin bir şekilde kullanamıyor. Bu, yazılım önbelleklerini “içe aktarma” ihtiyacına yol açar. Diyagramda Redis bu rolde gösterilmektedir. Yazılım önbelleği, geliştiricinin ek bir kod katmanı eklemesini ve mimaride gözle görülür değişiklikler yapmasını gerektirir.
Şimdi söz konusu altyapıda REST ve RPC'nin kaç istek "doğurduğunu" sayalım?
istekler
Gelen Kutusu
arka uca
DBMS'ye
yazılım önbelleğine (Redis)
TOPLAM
DİNLENME
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
İlk şemayla karşılaştırıldığında fark dikkat çekicidir. Artık REST'in faydası netleşiyor. Ama orada durmamanızı öneririm. Geliştirilen altyapı bir CDN içermektedir. Çoğu zaman DDoS ve DoS saldırılarına karşı koyma sorununu da çözer. Şunu elde ederiz:
RPC için işlerin gerçekten kötüye gittiği yer burası. RPC, iş yükünü bir CDN'ye devretme yeteneğine sahip değildir. Saldırılara karşı koymak için yalnızca sistemlere güvenebiliriz.
Burada bitirmek mümkün mü? Ve yine hayır. Yukarıda da belirtildiği gibi HTTP yöntemlerinin kendi “sihri” vardır. Ve GET yönteminin internette yaygın olarak kullanılması sebepsiz değildir. Bu yöntemin bir içeriğe erişebildiğini, kontrol kodunuza aktarılmadan önce altyapı öğelerinin yorumlayabileceği koşulları ayarlayabildiğini vb. unutmayın. Tüm bunlar, gerçekten büyük talep akışlarını karşılayabilecek esnek, yönetilebilir altyapılar oluşturmanıza olanak tanır. Ancak RPC'de bu yöntem... göz ardı edilir.
Peki toplu isteklerin (RPC) daha hızlı olduğu efsanesi neden bu kadar kalıcı? Şahsen bana öyle geliyor ki çoğu proje REST'in gücünü gösterebileceği bir gelişme düzeyine ulaşmıyor. Üstelik küçük projelerde zayıf yönlerini göstermeye daha istekli oluyor.
REST veya RPC seçimi, bir projedeki bireyin iradi bir seçimi değildir. Bu seçim projenin gereksinimlerini karşılamalıdır. Bir proje REST'ten gerçekten alabileceği her şeyi çıkarabiliyorsa ve buna gerçekten ihtiyacı varsa, o zaman REST mükemmel bir seçim olacaktır.
Ancak, REST'in tüm avantajlarından yararlanmak amacıyla, proje için altyapıyı hızlı bir şekilde ölçeklendirmek üzere devops uzmanları, altyapıyı yönetmek için yöneticiler, WEB hizmetinin tüm katmanlarını ve projeyi tasarlayacak bir mimar tutmanız gerekiyorsa... , aynı zamanda günde üç paket margarin satıyor... Ben RPC'ye sadık kalırdım çünkü... bu protokol daha faydacıdır. Önbelleklerin ve altyapının nasıl çalıştığına dair derin bilgi gerektirmeyecek, ancak geliştiricinin ihtiyaç duyduğu prosedürlere yönelik basit ve anlaşılır çağrılara odaklanmasını sağlayacak. İş mutlu olacak.
RPC istekleri, toplu istekleri tek bir işlemde yürütebildikleri için daha güvenilirdir
RPC'nin bu özelliği kesin bir avantajdır çünkü Veritabanını tutarlı tutmak kolaydır. Ancak REST ile her şey giderek daha karmaşık hale geliyor. İstekler farklı arka uç düğümlerine tutarsız bir şekilde ulaşabilir.
REST'in bu "dezavantajı", yukarıda açıklanan avantajının diğer yüzüdür: tüm altyapı kaynaklarını verimli bir şekilde kullanma yeteneği. Altyapı kötü tasarlanmışsa ve özellikle projenin mimarisi ve veritabanı kötü tasarlanmışsa, bu gerçekten büyük bir acıdır.
Peki toplu istekler göründüğü kadar güvenilir mi? Bir duruma bakalım: Bir kullanıcı oluşturuyoruz, profilini bazı açıklamalarla zenginleştiriyoruz ve kaydı tamamlaması için ona bir sır içeren bir SMS gönderiyoruz. Onlar. bir toplu istekte üç çağrı.
Diyagrama bakalım. Yüksek kullanılabilirlik unsurlarına sahip bir altyapı sunar. SMS ağ geçitlerine sahip iki bağımsız iletişim kanalı vardır. Ama... ne görüyoruz? SMS gönderirken 503 hatası oluşuyor - hizmet geçici olarak kullanılamıyor. Çünkü SMS gönderme toplu istekte paketlenir, bu durumda isteğin tamamının geri alınması gerekir. DBMS'deki eylemler iptal edilir. İstemci bir hata alır.
Bir sonraki deneme piyango. Ya istek aynı düğüme tekrar tekrar ulaşacak ve hata döndürecektir ya da şanslısınız ve istek yerine getirilecektir. Ancak asıl önemli olan, altyapımızın en azından bir kez boşuna çalışmış olmasıdır. Yük vardı ama kâr yoktu.
Tamam, kendimizi zorladığımızı (!) ve isteğin kısmen başarıyla tamamlanabileceği seçeneği düşündüğümüzü hayal edelim. Gerisini de bir süre sonra tamamlamaya çalışacağız (Hangisi? Cephe karar veriyor mu?). Ancak piyango aynı kaldı. SMS gönderme isteğinin tekrar başarısız olma ihtimali 50/50'dir.
Müşteri tarafında hizmetin istediğimiz kadar güvenilir görünmediğini kabul ediyorum... peki ya REST?
REST, HTTP'nin büyüsünü yeniden kullanıyor, ancak şimdi yanıt kodlarıyla birlikte. SMS ağ geçidinde 503 hatası oluştuğunda, arka uç bu hatayı dengeleyiciye yayınlar. Dengeleyici bu hatayı alır ve istemciyle olan bağlantıyı kesmeden isteği başka bir düğüme gönderir ve o da isteği başarıyla işler. Onlar. müşteri beklenen sonucu alır ve altyapı, "yüksek düzeyde erişilebilir" unvanını doğrular. Kullanıcı mutlu.
Ve yine hepsi bu değil. Dengeleyici yalnızca 503 yanıt kodunu almadı. Standarda göre yanıt verirken bu kodun "Retry-After" başlığıyla birlikte sağlanması tavsiye edilir. Başlık, dengeleyiciye bu rotadaki bu düğümü belirli bir süre rahatsız etmeye değmeyeceğini açıkça belirtir. Ve bir sonraki SMS gönderme istekleri doğrudan SMS ağ geçidiyle sorunu olmayan bir düğüme gönderilecektir.
Gördüğümüz gibi JSON-RPC'nin güvenilirliğine gereğinden fazla önem veriliyor. Aslında veritabanındaki tutarlılığı düzenlemek daha kolaydır. Ancak bu durumda fedakarlık, bir bütün olarak sistemin güvenilirliği olacaktır.
Sonuç büyük ölçüde öncekine benzer. Altyapı basit olduğunda JSON-RPC'nin belirginliği kesinlikle bir artıdır. Proje yüksek yük ile yüksek kullanılabilirlik içeriyorsa, REST daha karmaşık olmasına rağmen daha doğru bir çözüm gibi görünüyor.
REST'e giriş eşiği daha düşük
RPC ile ilgili yerleşik stereotipleri çürüten yukarıdaki analizin, REST'e giriş eşiğinin şüphesiz RPC'den daha yüksek olduğunu açıkça gösterdiğini düşünüyorum. Bunun nedeni, HTTP'nin nasıl çalıştığına dair derinlemesine bir anlayış ihtiyacının yanı sıra, WEB projelerinde kullanılabilecek ve kullanılması gereken mevcut altyapı unsurları hakkında yeterli bilgiye sahip olma ihtiyacıdır.
Peki neden birçok kişi REST'in daha basit olacağını düşünüyor? Benim kişisel görüşüm, bu görünen sadeliğin REST'in kendini göstermesinden kaynaklandığı yönünde. Onlar. REST bir protokol değil kavramdır... REST'in standardı yoktur, bazı yönergeleri vardır... REST, HTTP'den daha karmaşık değildir. Görünen özgürlük ve anarşi “özgür sanatçıları” cezbeder.
Elbette REST HTTP'den daha karmaşık değil. Ancak HTTP'nin kendisi, değerini onlarca yıldır kanıtlamış, iyi tasarlanmış bir protokoldür. HTTP'nin kendisi hakkında derinlemesine bir anlayış yoksa REST değerlendirilemez.
Ancak RPC hakkında - yapabilirsiniz. Şartnamesini almak yeterlidir. Peki ihtiyacın var mı ? Yoksa hala zor REST mi? Sen karar ver.
Umarım zamanınızı boşa harcamamışımdır.
Kaynak: habr.com