Uzun zamandır RPC (yani Uzaktan İşlem Çağrısı) ile HTTP çağrıları arasındaki farkı çözemedim. Lütfen burada gülmeme izin ver~Naive! Bu makale, C/S mimarisinin iki biçimini kısaca tanıtıyor; öncelikle en temel farkları, yani RPC esas olarak TCP/IP protokolüne dayanırken, HTTP servisi ağırlıklı olarak HTTP protokolüne dayanırken, hepimiz biliyoruz ki HTTP protokolü taşıma katmanı protokolü TCP'nin üstünde yer alıyor, bu yüzden verimlilik açısından RPC elbette daha iyidir! RPC servisleri ve HTTP servisleri hakkında detaylıca konuşalım.
OSI ağ yedi katmanlı model
RPC ile HTTP arasındaki farktan bahsetmeden önce, OSI'nin yedi katmanlı ağ yapısı modelini (pratikte temelde beş katman olsa da) anlamanın gerekli olduğunu düşünüyorum; bu modeli aşağıdaki katmanlara ayırabilir: (yukarıdan aşağıya)
- İlk katman: uygulama katmanı. Ağda iletişim ve veri iletimi için arayüzler tanımlanır;
- İkinci katman: temsil katmanı. Farklı sistemlerde veri iletim formatını, kodlama ve çözme spesifikasyonlarını vb. tanımlamak;
- Üçüncü katman: konuşma katmanı. Kullanıcı oturumlarını yönetin ve kullanıcılar arasında mantıksal bağlantıların kurulmasını ve kesilmesini kontrol edin.
- Dördüncü katman: taşıma katmanı. Ağda uçtan uca veri iletimini yönetir;
- Katman 5: Ağ katmanı. Ağ cihazları arasında verinin nasıl aktarıldığını tanımlayın;
- Altıncı katman: bağlantı katmanı. Yukarıdaki ağ katmanının veri paketleri, fiziksel katmanın iletilini kolaylaştırmak için veri çerçevelerine kapsüllenmiştir.
- Katman 7: Fiziksel katman. Bu katman esas olarak bu ikili veriyi iletmektir.
Pratik uygulamada, beş katmanlı protokol yapısında sunum katmanı ve oturum katmanı yoktur. Uygulama katmanıyla birleştikleri söylenebilir. Uygulama katmanına ve taşıma katmanına odaklanmalıyız. Çünkü HTTP bir uygulama katmanı protokolüdür, TCP ise bir taşıma katmanı protokolüdür. Artık ağ katmanlama modelini bildiğimize göre, RPC servislerinin neden HTTP servislerinden daha güzel olduğunu daha iyi anlayabiliyoruz!
RPC hizmetleri
RPC servisleri üç açıdan tanıtılır: RPC mimarisi, senkron asenkron çağrılar ve popüler RPC çerçeveleri.
RPC mimarisi
RPC servislerinin temel mimarisinden bahsedelim. Utanç verici bir şekilde bir fotoğraf çalmama izin verin~ Tam bir RPC mimarisinin dört temel bileşen içerdiğini açıkça görebiliyoruz: Client, Server, Client Stub ve Server Stub, ki bu stub olarak anlaşılabilir. Bu bileşenleri ayrı ayrı konuşalım:
- Müşteri, hizmetin arayanı.
- Sunucu, gerçek hizmet sağlayıcı.
- İstemci stub, sunucunun adres mesajını saklar, ardından istemcinin istek parametrelerini ağ mesajına paketler ve ardından bunu ağ üzerinden uzaktan hizmet partisine gönderir.
- Sunucu tarafı stub, istemci tarafından gönderilen mesajları alır, mesajları açar ve yerel metodları çağırır.
RPC ağırlıklı olarak büyük işletmelerde kullanılır, çünkü büyük işletmelerin birçok sistemi, karmaşık iş hattı ve verimlilik avantajları çok önemlidir. Bu, gerçek geliştirme sürecinde yapılır ve projeler genellikle maven kullanılarak yönetilir. Örneğin, siparişleri işleyen bir sistem servisimiz var, önce tüm arayüzlerini (burada özellikle Java'daki arayüzü) ilan eder ve ardından tüm projeyi bir jar paketine paketler. Neden bunu yapıyorsun? Ana amaç, istemci tarafında jar paketinin boyutunu azaltmaktır; çünkü her paket serbest bırakıldığında, çok fazla jar paketi verimliliği her zaman etkiler. Ayrıca, kod taşınabilirliğini artırmak için istemci ve sunucuyu ayırıyor.
Senkron ve asenkron çağrılar
Senkron Çağrı nedir? Asenkron çağrı nedir? Senkron çağrı, istemcinin çağrının tamamlanmasını bekleyip sonucu döndürmesi anlamına gelir. Asenkron çağrılar, istemcinin çağrının yürütülüp sonucu geri döndürmesini beklememesi, ancak geri dönüş sonucunun bildirimini geri çağırma fonksiyonu aracılığıyla almaya devam edebileceği anlamına gelir. Müşteri sonucu umursamıyorsa, bu tek yönlü bir görüşmeye dönüşebilir. Bu süreç, Java'daki çağrılabilir ve çalıştırılabilir arayüzlere biraz benzer; asenkron çalıştırdığımızda, yürütme sonucunu bilmemiz gerekirse, çağrılanabilir arayüzü kullanabiliriz ve Future sınıfı aracılığıyla asenkron yürütme sonuç bilgilerini elde edebiliriz. Eğer yürütme sonucunu umursamıyorsan, sadece çalıştırılabilir arayüzü kullanabilirsin çünkü sonuç döndürmez, tabii ki çağrılabilen arayüz de mümkün, geleceği almamıza gerek yok.
Popüler RPC çerçevesi
Hâlâ birçok popüler açık kaynaklı RPC çerçevesi bulunmaktadır. İşte üç öne çıkan nokta:
- gRPC, Google tarafından yakın zamanda duyurulan açık kaynak yazılımıdır; en son HTTP 2.0 protokolüne dayanır ve birçok yaygın programlama dilini destekler. HTTP 2.0'ın, ikili tabanlı geliştirilmiş bir HTTP protokolü olduğunu biliyoruz ve büyük tarayıcılar şu anda bunu hızla destekliyor. Bu RPC çerçevesi HTTP protokolüne dayanır ve temel Netty çerçevesinin desteğini kullanır.
- Thrift, Facebook için açık kaynaklı bir projedir ve öncelikle diller arası hizmet geliştirme çerçevesidir. Tanımladığı IDL tanım dosyası için otomatik olarak bir hizmet kodu çerçevesi oluşturan bir kod oluşturucuya sahiptir. Kullanıcıların öncesinde sadece ikincil geliştirme yapması yeterlidir ve temel RPC iletişimi şeffaftır. Ancak, kullanıcılar için belirli bir alanın dilini öğrenmenin hâlâ belirli bir maliyeti vardır.
- Dubbo, Alibaba Group tarafından hazırlanmış ve birçok internet şirketi ile kurumsal uygulamada yaygın olarak kullanılan tanınmış bir RPC çerçevesi açık kaynaktır. Hem protokoller hem de serileştirme çerçeveleri takılabilir. Aynı uzaktan arayüz Java Arayüzü'ne dayanır ve kolay geliştirme için yay framework'e dayanır. Kolayca tek bir dosyaya paketlenip bağımsız olarak çalıştırılabilir; bu, mevcut mikroservis kavramıyla tutarlıdır.
Gizlice sana grubun artık dubbo kullanmadığını söyledim,Şu anda daha yaygın kullanılan yöntem HSF olarak adlandırılır, "çok rahat" olarak da bilinir. Sonrasında açık kaynak olabilir, o yüzden bekleyelim.
HTTP servisi
Aslında, çok uzun zaman önce, kurumsal geliştirme modelini her zaman HTTP arayüzü geliştirme olarak tanımladım; buna genellikle RESTful tarzı hizmet arayüzleri dediğimiz şey. Gerçekten de, az arayüz ve sistemler arasında daha az etkileşim durumunda bilgi adalarının erken aşamasında sıkça kullanılan bir iletişim yöntemidir; Avantajlar basit, doğrudan ve geliştirilmesi kolaydır. Hazır HTTP protokolünü iletim için kullanın. Daha önce şirkette arka plan geliştirme yaparken ağırlıklı olarak arayüzler geliştirirdik ve ayrıca girdi ve çıktıyı kesin olarak belirten büyük bir arayüz belgesi yazmak zorundaydık. Her arayüzün talep yöntemini ve istek parametrelerinde dikkat edilmesi gereken konuları açıklayın. Örneğin, aşağıdaki örnek:
YAYINLAhttp://www.httpexample.com/restful/buyer/info/share
Arayüz bir JSON dizisi veya bir XML belgesi döndürebilir. İstemci bu geri dönen bilgileri işleyerek geliştirmeyi hızlandırır. Ancak, büyük işletmeler için, birçok dahili alt sistem ve çok sayıda arayüz olduğunda, RPC çerçevesinin avantajları ortaya çıkar; öncelikle uzun bir bağlantıdır ve her seferinde http gibi üç kez el sıkışmaya gerek yoktur, böylece ağ yükü azalır; ikincisi, RPC çerçevesi genellikle bir kayıt merkezi ve zengin izleme ve yönetim içerir; Yayınlama, çevrimdışı arayüzler, dinamik genişletme vb. arayan için algısal olmayan ve birleşik işlemlerdir.
özet
Genel olarak, RPC hizmetleri ağırlıklı olarak büyük işletmeler içindirken, HTTP hizmetleri ise küçük işletmeler içindir; çünkü RPC daha verimlidir ve HTTP servis geliştirme yinelemeleri daha hızlı olur. Kısacası, hangi tür bir çerçevenin seçileceği piyasada popüler olanla değil, tüm projeyi tamamen değerlendirmek, böylece iki geliştirme çerçevesinin tüm proje üzerindeki etkisini dikkatlice karşılaştırmak ve sonunda proje için en uygun olanı belirlemek için belirlenir. RPC'yi her projede sadece RPC kullanmak için kullanmamalıyız, yerel koşullara uyum sağlamalı ve özel durumu analiz etmeliyiz.
|
Yayınlandı 1.04.2019 14:02:45
|
|
|
|
