Dalam satu panggilan High-speed Service Framework (HSF), konsumen HSF mengirim permintaan ke penyedia HSF melalui jaringan, penyedia mengeksekusi metode target, dan hasilnya dikembalikan ke konsumen. Proses ini melibatkan beberapa thread serta sejumlah objek domain spesifik protokol HSF.
Memahami alur panggilan ini membantu Anda mendiagnosis masalah latensi, menginterpretasikan thread dump, serta mengidentifikasi lokasi kegagalan dalam aplikasi Enterprise Distributed Application Service (EDAS) Anda.
Ikhtisar alur panggilan
Panggilan HSF terdiri dari tiga fase:
Persiapan sisi client (langkah 1–3) — Thread client melakukan serialisasi permintaan dan menyerahkannya ke thread I/O untuk pengkodean dan transmisi.
Pemrosesan sisi server (langkah 4–8) — Thread I/O penyedia mendekode data yang masuk, thread server HSF mengeksekusi metode target melalui reflection, lalu melakukan serialisasi dan pengkodean respons.
Pengembalian respons (langkah 9–11) — Respons yang telah dikodekan dikirim kembali ke konsumen, thread I/O mendekodenya, dan thread client melakukan deserialisasi hasil tersebut.
Diagram berikut menunjukkan proses lengkap 11 langkah ini.
Model thread
Tiga jenis thread berpartisipasi dalam setiap panggilan HSF:
| Thread | Peran |
|---|---|
| Client thread | Menginisiasi panggilan di sisi konsumen. Melakukan serialisasi parameter permintaan, menunggu respons, dan melakukan deserialisasi hasil. |
| I/O thread | Menangani komunikasi jaringan di kedua sisi. Mengkodekan objek outbound menjadi konten biner dan mendekode konten biner inbound menjadi objek komunikasi. |
| HSF server thread | Memproses permintaan di sisi penyedia. Melakukan deserialisasi permintaan, memanggil metode target, dan melakukan serialisasi respons. |
Pemisahan ini mencegah eksekusi metode yang lambat menghambat I/O jaringan untuk panggilan konkuren lainnya, serta mencegah latensi atau kemacetan jaringan menghabiskan kapasitas kolam thread bisnis.
Objek domain
HSF menggunakan dua lapis objek untuk memisahkan data pengguna dari metadata protokol:
| Objek | Tujuan |
|---|---|
| Request object | Berisi parameter permintaan—argumen metode yang sebenarnya. |
| Request communication object | Pembungkus protokol HSF di sekitar request object. Berisi metadata tingkat protokol seperti ID permintaan. |
| Response object | Berisi nilai kembali metode. |
| Response communication object | Pembungkus protokol HSF di sekitar response object. Berisi metadata tingkat protokol untuk perjalanan balik. |
Desain dua lapis ini memungkinkan HSF menyertakan informasi routing, tracing, dan protokol tanpa mengubah data pengguna. Saat mendiagnosis masalah, perbedaan ini membantu Anda menentukan apakah masalah terletak pada logika bisnis (objek request/response) atau pada lapisan protokol (objek komunikasi).
Alur langkah demi langkah secara rinci
Fase 1: Persiapan sisi client (langkah 1–3)
| Langkah | Apa yang terjadi |
|---|---|
| 1 | Client thread melakukan serialisasi parameter permintaan menjadi request object, lalu membungkusnya dalam request communication object. Objek komunikasi ini mengikuti protokol HSF dan mencakup metadata seperti ID permintaan. |
| 2 | Thread client menyerahkan request communication object ke I/O thread, yang mengkodekannya menjadi konten biner. |
| 3 | Thread I/O mentransmisikan konten biner yang telah dikodekan ke penyedia HSF. Thread client diblokir dan menunggu respons. |
Fase 2: Pemrosesan sisi server (langkah 4–8)
| Langkah | Apa yang terjadi |
|---|---|
| 4 | I/O thread penyedia HSF menerima konten biner dan mendekodenya menjadi request communication object, lalu menyerahkan objek tersebut ke HSF server thread. |
| 5 | Thread server melakukan deserialisasi request communication object untuk memulihkan request object asli. |
| 6 | Thread server memanggil metode target melalui reflection call dan mendapatkan response object. |
| 7 | Thread server melakukan serialisasi response object dan membungkusnya dalam response communication object. |
| 8 | Thread server menyerahkan response communication object ke thread I/O, yang mengkodekannya menjadi konten biner. |
Fase 3: Pengembalian respons (langkah 9–11)
| Langkah | Apa yang terjadi |
|---|---|
| 9 | Thread I/O penyedia HSF mentransmisikan konten biner yang telah dikodekan kembali ke konsumen HSF. |
| 10 | I/O thread konsumen HSF menerima konten biner, mendekodenya menjadi response communication object, dan membangunkan thread client yang sedang diblokir. |
| 11 | Client thread melakukan deserialisasi response communication object untuk mengekstrak response object. Pemanggil menerima hasilnya, dan panggilan remote selesai. |
Dasar desain
Serialisasi vs. pengkodean
HSF menerapkan dua transformasi terpisah pada data outbound:
Serialisasi mengonversi objek (request atau response object) menjadi format aliran byte yang sesuai untuk dimasukkan ke dalam objek komunikasi.
Encoding mengonversi seluruh objek komunikasi—termasuk metadata protokol—menjadi konten biner untuk transmisi jaringan.
Di sisi penerima, decoding merekonstruksi objek komunikasi dari konten biner, dan deserialization mengekstrak objek asli dari objek komunikasi tersebut.
Pemisahan langkah-langkah ini memungkinkan HSF menukar format serialisasi secara independen dari pengkodean protokol wire.
Thread I/O dan bisnis yang terpisah
Thread I/O menangani pembacaan, penulisan, pengkodean, dan pendekodean jaringan. Thread server HSF menangani deserialisasi dan pemanggilan metode. Pemisahan ini memberikan dua keuntungan:
Metode bisnis yang lambat tidak menghambat I/O jaringan untuk panggilan konkuren lainnya.
Latensi atau kemacetan jaringan tidak menghabiskan kapasitas kolam thread bisnis.
Blokir sinkron di sisi konsumen
Selama panggilan HSF sinkron standar, thread client diblokir pada langkah 3 hingga thread I/O membangunkannya pada langkah 10. Waktu blokir total mencakup latensi round-trip jaringan, waktu pemrosesan di sisi server, serta overhead serialisasi/pengkodean di kedua sisi.