Cara komunikasi antara perkhidmatan dalam sistem Microservice

1. Komunikasi Segerak

Komunikasi segerak melibatkan interaksi masa nyata di mana satu perkhidmatan menghantar permintaan kepada yang lain dan menjeda operasinya sehingga respons diterima. REST API dan gRPC ialah protokol biasa yang digunakan untuk memudahkan jenis komunikasi ini.

1.1 API RESTful

API RESTful (Pemindahan Negeri Perwakilan) ialah salah satu kaedah paling biasa untuk perkhidmatan berkomunikasi antara satu sama lain dalam sistem perkhidmatan mikro. REST menggunakan format HTTP/HTTPS dan JSON atau XML untuk pertukaran data.

Biasanya, perkhidmatan berinteraksi antara satu sama lain dengan menggunakan API perkhidmatan lain secara langsung.

Contoh permintaan dan tindak balas:

GET /users/12345 HTTP/1.1 Host: api.userservice.com Accept: application/json Authorization: Bearer your-access-token { "userId": "12345", "name": "Michel J", "email": "MJ@example.com", "address": "Mountain View, Santa Clara, California" }

Contoh kod sumber

import org.springframework.web.client.RestTemplate; import org.springframework.http.ResponseEntity; public class OrderService { private final RestTemplate restTemplate = new RestTemplate(); private final String userServiceUrl = "https://api.userservice.com/users/"; public User getUserById(String userId) { String url = userServiceUrl + userId; ResponseEntity response = restTemplate.getForEntity(url, User.class); return response.getBody(); } }

Kelebihan:

Mudah digunakan dan disepadukan dengan pelbagai bahasa dan alatan.

Boleh menggunakan alat ujian dan pemantauan dengan mudah.

Keburukan:

Mungkin tidak cekap untuk keperluan kelajuan tinggi kerana sifatnya yang segerak.

Mungkin menghadapi kesukaran dalam mengendalikan ralat rangkaian atau terputus sambungan.

1.2 gRPC

gRPC, singkatan untuk Panggilan Prosedur Jauh Google, ialah rangka kerja RPC universal sumber terbuka berprestasi tinggi. Ia menggunakan HTTP/2 untuk pemindahan data yang cekap dan biasanya bergantung pada Penampan Protokol, mekanisme yang neutral bahasa, neutral platform, boleh diperluas untuk mensiri data berstruktur, untuk menentukan struktur data yang dihantar dan diterima.

Contoh, Definisi Penampan Protokol

syntax = "proto3"; package userservice; // Define message User message User { string userId = 1; string name = 2; string email = 3; string address = 4; } // Define service UserService service UserService { rpc GetUserById (UserIdRequest) returns (User); } // Define message UserIdRequest message UserIdRequest { string userId = 1; }

Untuk perkhidmatan Pengurusan Pengguna, anda harus melaksanakan pelayan gRPC yang mematuhi definisi perkhidmatan yang disediakan dalam fail .proto. Ini termasuk mencipta logik bahagian pelayan yang diperlukan untuk mengendalikan permintaan gRPC masuk dan menjana respons yang sesuai.

import io.grpc.stub.StreamObserver; import userservice.User; import userservice.UserIdRequest; import userservice.UserServiceGrpc; public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase { @Override public void getUserById(UserIdRequest request, StreamObserver responseObserver) { // Assuming you have a database to retrieve user information. User user = User.newBuilder() .setUserId(request.getUserId()) .setName("Michel J") .setEmail("MJ@example.com") .setAddress("Mountain View, Santa Clara, California") .build(); responseObserver.onNext(user); responseObserver.onCompleted(); } } import io.grpc.Server; import io.grpc.ServerBuilder; public class UserServer { public static void main(String[] args) throws Exception { Server server = ServerBuilder.forPort(9090) .addService(new UserServiceImpl()) .build() .start(); System.out.println("Server started on port 9090"); server.awaitTermination(); } }

Kelebihan:

Prestasi tinggi dan kecekapan lebar jalur kerana penggunaan HTTP/2 dan Penampan Protokol.

Menyokong berbilang bahasa pengaturcaraan dan mempunyai kebolehskalaan yang baik.

Keburukan:

Memerlukan lapisan terjemahan jika perkhidmatan tidak menyokong gRPC.

Boleh menjadi lebih kompleks untuk digunakan dan diurus.

2. Komunikasi Tak Segerak

Komunikasi tak segerak merujuk kepada proses perkhidmatan menghantar permintaan kepada perkhidmatan lain tanpa menyekat operasinya sendiri untuk menunggu balasan. Ini biasanya dicapai melalui baris gilir mesej atau sistem terbitkan/langganan.

1. Barisan Mesej

Sistem baris gilir mesej, seperti RabbitMQ dan Apache ActiveMQ, memudahkan komunikasi tak segerak antara perkhidmatan.

Kelebihan:

Kebolehskalaan dan toleransi kesalahan yang dipertingkatkan: Sistem boleh mengendalikan peningkatan beban kerja dengan lebih baik dan kurang terdedah kepada kegagalan.

Mengurangkan beban pada perkhidmatan: Dengan menyahganding permintaan menghantar dan menerima, perkhidmatan utama boleh menumpukan pada tugasan pemprosesan tanpa dibelenggu oleh permintaan yang berterusan.

Keburukan:

Mungkin memerlukan usaha tambahan untuk mengurus dan menyelenggara: Sistem berasaskan baris gilir boleh menjadi lebih kompleks dan memerlukan lebih banyak sumber untuk beroperasi.

Kesukaran mengendalikan pesanan dan memastikan penghantaran mesej: Memastikan permintaan diproses dalam susunan yang betul dan tiada mesej yang hilang boleh menjadi cabaran teknikal.

2.2. Sistem Pub/Sub

Sistem Pub/Sub (Terbitkan/Langgan), seperti Apache Kafka atau Google Pub/Sub, membenarkan perkhidmatan untuk menerbitkan mesej dan melanggan topik.

Kelebihan:

Menyokong strim data berskala besar dan daya pemprosesan tinggi.

Mengurangkan pergantungan antara perkhidmatan.

Keburukan:

Memerlukan lapisan yang lebih kompleks untuk mengurus dan memantau topik dan mesej.

Boleh mencabar untuk mengendalikan pesanan dan masalah kebolehpercayaan dengan mesej."

Jika anda berminat, anda boleh membaca artikel saya sebelum ini mengenai pub/sub topik.

Barisan Mati Surat dalam Broker Mesej bahagian 1

Baris Surat Mati dalam Broker Mesej bahagian 2

Kebimbangan konsistensi dan kebolehpercayaan dalam sistem Broker Mesej

3. Komunikasi Didorong Peristiwa

Komunikasi dipacu peristiwa ialah apabila perkhidmatan memancarkan peristiwa dan perkhidmatan lain bertindak balas atau mengambil tindakan berdasarkan peristiwa tersebut.

3.1. Peristiwa Segerak

Peristiwa segerak berlaku apabila perkhidmatan memancarkan acara dan menunggu respons daripada perkhidmatan lain.

Kelebihan:

Mudah untuk mengawal dan memantau proses pemprosesan acara.

Kelemahan:

Boleh menyebabkan kesesakan jika perkhidmatan bertindak balas lambat atau menghadapi ralat

3.2. Peristiwa Asynchronous

Peristiwa tak segerak berlaku apabila perkhidmatan memancarkan peristiwa dan tidak perlu menunggu respons segera.

Kelebihan:

Mengurangkan masa menunggu dan meningkatkan kebolehskalaan.

Membantu perkhidmatan beroperasi dengan lebih bebas dan mengurangkan pergantungan bersama.

Kelemahan:

Memerlukan mekanisme tambahan untuk memastikan acara diproses dengan betul dan tepat pada masanya.

Kesukaran dalam memastikan ketertiban dan mengendalikan acara pendua.

4. Kesimpulan

Pilihan kaedah komunikasi antara perkhidmatan dalam sistem perkhidmatan mikro bergantung pada faktor seperti keperluan prestasi, kebolehpercayaan dan kerumitan sistem. Setiap kaedah mempunyai kelebihan dan kekurangannya sendiri, dan memahami kaedah ini akan membantu anda membina sistem perkhidmatan mikro yang lebih cekap dan fleksibel. Pertimbangkan dengan teliti keperluan sistem anda untuk memilih kaedah komunikasi yang paling sesuai.

Atas ialah kandungan terperinci Cara komunikasi antara perkhidmatan dalam sistem Microservice. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!