Untuk waktu yang lama, saya belum menemukan perbedaan antara RPC (yaitu Remote Procedure Call) dan panggilan HTTP. Tolong izinkan saya tertawa di sini ~ Naif! Artikel ini secara singkat memperkenalkan dua bentuk arsitektur C/S, pertama-tama, perbedaannya yang paling penting, yaitu RPC terutama didasarkan pada protokol TCP/IP, sedangkan layanan HTTP terutama didasarkan pada protokol HTTP, kita semua tahu bahwa protokol HTTP berada di atas protokol lapisan transportasi TCP, jadi dalam hal efisiensi, RPC tentu saja lebih baik! Mari kita bicara tentang layanan RPC dan layanan HTTP secara rinci.
Model tujuh lapis jaringan OSI
Sebelum berbicara tentang perbedaan antara RPC dan HTTP, saya merasa perlu untuk memahami model struktur jaringan tujuh lapis OSI (meskipun pada dasarnya lima lapisan dalam praktiknya), yang dapat dibagi menjadi lapisan berikut: (dari atas ke bawah)
- Lapisan pertama: lapisan aplikasi. Antarmuka untuk komunikasi dan transmisi data dalam jaringan ditentukan;
- Lapisan kedua: lapisan representasi. Tentukan format transmisi, spesifikasi pengkodean dan decoding data dalam sistem yang berbeda, dll.;
- Lapisan ketiga: lapisan percakapan. Kelola sesi pengguna dan kontrol pembentukan dan gangguan koneksi logis antar pengguna.
- Lapisan keempat: lapisan transportasi. Ini mengelola transmisi data end-to-end di jaringan;
- Lapisan 5: Lapisan jaringan. Tentukan bagaimana data ditransfer antar perangkat jaringan;
- Lapisan keenam: lapisan tautan. Paket data dari lapisan jaringan di atas dienkapsulasi ke dalam bingkai data untuk memfasilitasi transmisi lapisan fisik.
- Lapisan 7: Lapisan fisik. Lapisan ini terutama tentang mentransmisikan data biner ini.
Dalam aplikasi praktis, tidak ada lapisan presentasi dan lapisan sesi dalam struktur protokol lima lapis. Harus dikatakan bahwa mereka bergabung dengan lapisan aplikasi. Kita harus fokus pada lapisan aplikasi dan lapisan transportasi. Karena HTTP adalah protokol lapisan aplikasi, sedangkan TCP adalah protokol lapisan transportasi. Nah, sekarang setelah kita mengetahui model pelapisan jaringan, kita dapat lebih memahami mengapa layanan RPC lebih bagus daripada layanan HTTP!
Layanan RPC
Layanan RPC diperkenalkan dari tiga perspektif: arsitektur RPC, panggilan asinkron sinkron, dan kerangka kerja RPC populer.
Arsitektur RPC
Mari kita bicara tentang arsitektur dasar layanan RPC. Izinkan saya mencuri gambar dengan malu-malu~ Kita dapat dengan jelas melihat bahwa arsitektur RPC yang lengkap berisi empat komponen inti, yaitu Client, Server, Client Stub dan Server Stub, yang dapat dipahami sebagai rintisan. Mari kita bicara tentang komponen ini secara terpisah:
- Klien, penelepon layanan.
- Server, penyedia layanan yang sebenarnya.
- Rintisan klien menyimpan pesan alamat server, lalu mengemas parameter permintaan klien ke dalam pesan jaringan, lalu mengirimkannya ke pihak layanan dari jarak jauh melalui jaringan.
- Rintisan sisi server menerima pesan yang dikirim oleh klien, membongkar pesan, dan memanggil metode lokal.
RPC terutama digunakan pada perusahaan besar, karena perusahaan besar memiliki banyak sistem, lini bisnis yang kompleks, dan keunggulan efisiensi sangat penting. Ini dilakukan dalam pengembangan aktual, dan proyek umumnya dikelola menggunakan maven. Misalnya, kita memiliki layanan sistem yang memproses pesanan, pertama-tama mendeklarasikan semua antarmukanya (di sini khususnya antarmuka di Java), dan kemudian mengemas seluruh proyek ke dalam paket jar. Mengapa melakukan ini? Tujuan utamanya adalah untuk mengurangi ukuran paket jar di sisi klien, karena setiap kali paket dirilis, terlalu banyak paket jar akan selalu mempengaruhi efisiensi. Ini juga memisahkan klien dan server untuk meningkatkan portabilitas kode.
Panggilan sinkron dan asinkron
Apa itu Panggilan Sinkron? Apa itu panggilan asinkron? Panggilan sinkron adalah ketika klien menunggu panggilan menyelesaikan eksekusi dan mengembalikan hasilnya. Panggilan asinkron berarti bahwa klien tidak menunggu panggilan dijalankan dan mengembalikan hasilnya, tetapi masih dapat menerima pemberitahuan hasil pengembalian melalui fungsi panggilan balik. Jika klien tidak peduli dengan hasilnya, itu bisa berubah menjadi panggilan satu arah. Proses ini agak mirip dengan antarmuka yang dapat dipanggil dan dijalankan di Java, ketika kita mengeksekusi secara asinkron, jika kita perlu mengetahui hasil eksekusi, kita dapat menggunakan antarmuka yang dapat dipanggil, dan kita dapat memperoleh informasi hasil eksekusi asinkron melalui kelas Future. Jika Anda tidak peduli dengan hasil eksekusi, Anda bisa saja menggunakan antarmuka yang dapat dijalankan karena tidak mengembalikan hasilnya, tentunya dapat dipanggil juga dimungkinkan, kita tidak perlu mendapatkan masa depan.
Kerangka kerja RPC populer
Masih banyak kerangka kerja RPC open source yang populer. Berikut adalah tiga sorotan:
- gRPC adalah perangkat lunak sumber terbuka yang baru-baru ini diumumkan oleh Google, berdasarkan protokol HTTP 2.0 terbaru, dan mendukung banyak bahasa pemrograman umum. Kita tahu bahwa HTTP 2.0 adalah versi yang ditingkatkan dari protokol HTTP berdasarkan biner, dan browser utama saat ini mendukungnya dengan cepat. Kerangka kerja RPC ini didasarkan pada protokol HTTP, dan yang mendasarinya menggunakan dukungan kerangka kerja Netty.
- Thrift adalah proyek sumber terbuka untuk Facebook, terutama kerangka kerja pengembangan layanan lintas bahasa. Ini memiliki pembuat kode untuk secara otomatis menghasilkan kerangka kerja kode layanan untuk file definisi IDL yang ditentukannya. Pengguna hanya perlu melakukan pengembangan sekunder sebelumnya, dan komunikasi RPC yang mendasarinya transparan. Namun, bagi pengguna, masih ada biaya tertentu untuk mempelajari bahasa bidang tertentu.
- Dubbo adalah open source kerangka kerja RPC terkenal oleh Alibaba Group, yang banyak digunakan di banyak perusahaan Internet dan aplikasi perusahaan. Baik protokol maupun kerangka kerja serialisasi dapat dicolokkan. Antarmuka jarak jauh yang sama didasarkan pada Java Interface dan mengandalkan kerangka kerja pegas untuk pengembangan yang mudah. Ini dapat dengan mudah dikemas menjadi satu file dan dijalankan secara independen, yang konsisten dengan konsep layanan mikro saat ini.
Diam-diam memberi tahu Anda bahwa grup tidak banyak menggunakan dubbo lagi,Yang lebih umum digunakan sekarang disebut HSF, juga dikenal sebagai "sangat nyaman". Mungkin ada open source nanti, jadi mari kita tunggu dan lihat.
Layanan HTTP
Faktanya, sejak lama, saya selalu mencirikan model pengembangan perusahaan sebagai pengembangan antarmuka HTTP, yang sering kita sebut antarmuka layanan gaya RESTful. Memang, ini adalah metode komunikasi yang sering digunakan pada tahap awal pemecahan pulau informasi dalam kasus beberapa antarmuka dan lebih sedikit interaksi antar sistem; Keuntungannya sederhana, langsung dan mudah dikembangkan. Manfaatkan protokol HTTP siap pakai untuk transmisi. Kami ingat bahwa ketika kami melakukan pengembangan latar belakang di perusahaan sebelumnya, kami terutama mengembangkan antarmuka, dan kami juga harus menulis dokumen antarmuka yang besar, dengan ketat menunjukkan apa input dan outputnya. Jelaskan metode permintaan dari setiap antarmuka dan hal-hal yang perlu diperhatikan dalam parameter permintaan. Misalnya, contoh berikut:
TIANGhttp://www.httpexample.com/restful/buyer/info/share
Antarmuka dapat mengembalikan string JSON atau dokumen XML. Klien kemudian memproses informasi yang dikembalikan ini, memungkinkan pengembangan yang lebih cepat. Namun, untuk perusahaan besar, ketika ada banyak subsistem internal dan banyak antarmuka, keunggulan kerangka kerja RPC ditunjukkan, pertama-tama, ini adalah tautan yang panjang, dan tidak perlu berjabat tangan 3 kali seperti http setiap saat, mengurangi overhead jaringan; kedua, kerangka kerja RPC umumnya memiliki pusat pendaftaran dan pemantauan dan manajemen yang kaya; Penerbitan, antarmuka offline, ekspansi dinamis, dll., adalah operasi non-perseptif dan terpadu untuk penelepon.
ringkasan
Secara umum, layanan RPC terutama untuk perusahaan besar, sedangkan layanan HTTP terutama untuk perusahaan kecil, karena RPC lebih efisien, dan iterasi pengembangan layanan HTTP akan lebih cepat. Singkatnya, kerangka kerja seperti apa yang harus dipilih tidak ditentukan oleh apa yang populer di pasar, tetapi untuk mengevaluasi seluruh proyek sepenuhnya, sehingga dapat dengan hati-hati membandingkan dampak dari dua kerangka kerja pengembangan pada keseluruhan proyek, dan akhirnya memutuskan apa yang paling cocok untuk proyek tersebut. Kita tidak boleh menggunakan RPC untuk setiap proyek demi penggunaan RPC, tetapi beradaptasi dengan kondisi lokal dan menganalisis situasi spesifik.
|
Diposting pada 01/04/2019 14.02.45
|
|
|
|
