Bagaimana gRPC mengetahui alamat IP perkhidmatan bagi perkhidmatan mikro

gRPC ialah rangka kerja panggilan prosedur jauh sumber terbuka berprestasi tinggi untuk membina perkhidmatan mikro dalam sistem teragih. Apabila menggunakan gRPC, soalan biasa ialah bagaimana untuk memberitahu pelanggan alamat IP perkhidmatan perkhidmatan mikro. Pertama, editor PHP Shinichi menerangkan cara gRPC berfungsi Ia menggunakan Protocol Buffers sebagai bahasa definisi antara muka dan HTTP/2 sebagai protokol pengangkutan. Kemudian, editor memperkenalkan dua kaedah yang biasa digunakan untuk menyelesaikan masalah alamat IP perkhidmatan: konfigurasi statik dan penemuan perkhidmatan. Kod keras konfigurasi statik alamat IP perkhidmatan dalam kod klien Kaedah ini mudah dan mudah, tetapi memerlukan kemas kini konfigurasi secara manual. Penemuan perkhidmatan adalah untuk mendapatkan alamat IP perkhidmatan secara dinamik dengan menggunakan alat pendaftaran dan penemuan perkhidmatan, seperti Konsul atau Etcd. Pendekatan ini lebih fleksibel dan automatik, tetapi memerlukan penggunaan dan penyelenggaraan tambahan. Tidak kira kaedah yang anda pilih, anda perlu melaksanakan logik yang sepadan dalam kod klien untuk mendapatkan alamat IP perkhidmatan bagi memastikan operasi normal gRPC.

Kandungan soalan

Saya bermula dengan demo perkhidmatan mikro platform awan google. Saya ingin tahu bagaimana stub grpc berfungsi apabila perkhidmatan itu digunakan dalam bekas.

Daripada apa yang saya faham, bekas untuk perkhidmatan tertentu ditangani oleh ip perkhidmatan yang dinyatakan dalam fail konfigurasi yaml. Jadi adakah pelayan grpc perkhidmatan perlu mendengar pada ip perkhidmatan? Tetapi saya terjumpa coretan kod berikut:

l, err := net.Listen("tcp", fmt.Sprintf(":%s", port))
if err != nil {
    log.Fatal(err)
}

Saya ingin tahu bagaimana pelayan mendengar alamat tanpa IP?

Penyelesaian

:{port} bukanlah "alamat tanpa IP".

Dokumentasi untuk

Listen termasuk "Jika hos dalam parameter alamat kosong atau alamat IP literal yang tidak ditentukan, Listen mendengar pada semua alamat IP unicast dan anycast yang tersedia pada sistem setempat."

Jadi dalam kes ini, tanpa alamat hos, alamat berkesan ialah 0.0.0.0 ，它对应于所有接口。由此推论，人们在使用容器时常犯的一个错误是将其代码绑定到 localhost (127.0.0.1) dan kod itu tidak boleh diakses dari luar bekas.

Menggunakan 0.0.0.0 ialah amalan biasa (baik), terutamanya apabila bekerja dengan bekas, kerana ia secara berkesan mewakilkan pengikatan alamat kepada masa jalan kontena.

Jadi aplikasi anda berjalan pada {port} pada semua antara muka di dalam bekas. Masa jalan kontena kemudiannya mengikat satu atau lebih antara muka ini ke antara muka hos dan cth anda. Kod klien bersambung ke alamat IP hos.

Apabila bekas anda diurus oleh Kubernetes, Kubernetes memberikan alamat IP kepada bekas yang menjalankan aplikasi anda, dan bekas ini biasanya terdedah kepada perkhidmatan lain menggunakan sumber perkhidmatan Kubernetes, yang bukan sahaja mempunyai alamat IP, tetapi juga DNS kelompok .

1. Kubernetes YAML boleh menentukan DNS perkhidmatan.
2. Kubernetes menyelesaikan permintaan nama DNS ke bekas yang dipilih (IP dan port)
3. Waktu jalan kontena mengarahkan permintaan masuk pada port hos ke port kontena
4. Pelayan gRPC anda akan menerima trafik daripada masa jalan kontena pada net.Listen 的 {port} antara muka yang telah anda takrifkan sebagai net.Listen.

Atas ialah kandungan terperinci Bagaimana gRPC mengetahui alamat IP perkhidmatan bagi perkhidmatan mikro. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!