1. तुल्यकालिक संचार

सिंक्रोनस संचार में वास्तविक समय की बातचीत शामिल होती है जहां एक सेवा दूसरे को अनुरोध भेजती है और प्रतिक्रिया प्राप्त होने तक अपना संचालन रोक देती है। REST API और gRPC सामान्य प्रोटोकॉल हैं जिनका उपयोग इस प्रकार के संचार को सुविधाजनक बनाने के लिए किया जाता है।

1.1 रेस्टफुल एपीआई

एक रेस्टफुल एपीआई (प्रतिनिधि राज्य स्थानांतरण) एक माइक्रोसर्विसेज सिस्टम में सेवाओं के लिए एक दूसरे के साथ संचार करने के सबसे आम तरीकों में से एक है। REST डेटा विनिमय के लिए HTTP/HTTPS और JSON या XML स्वरूपों का उपयोग करता है।

आमतौर पर, सेवाएँ किसी अन्य सेवा के एपीआई को सीधे लागू करके एक-दूसरे के साथ बातचीत करती हैं।

उदाहरण अनुरोध और प्रतिक्रिया:

GET /users/12345 HTTP/1.1
Host: api.userservice.com
Accept: application/json
Authorization: Bearer your-access-token

{
  "userId": "12345",
  "name": "Michel J",
  "email": "[email protected]",
  "address": "Mountain View, Santa Clara, California"
}

स्रोत कोड उदाहरण

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();
    }
}

फायदे:

विभिन्न भाषाओं और उपकरणों के साथ तैनात करना और एकीकृत करना आसान है।

परीक्षण और निगरानी उपकरणों का आसानी से उपयोग कर सकते हैं।

नुकसान:

अपनी तुल्यकालिक प्रकृति के कारण उच्च गति आवश्यकताओं के लिए कुशल नहीं हो सकता है।

नेटवर्क त्रुटियों या डिस्कनेक्ट से निपटने में कठिनाइयों का सामना करना पड़ सकता है।

1.2 जीआरपीसी

gRPC, जिसका पूरा नाम Google रिमोट प्रोसीजर कॉल है, एक उच्च-प्रदर्शन, ओपन-सोर्स यूनिवर्सल RPC फ्रेमवर्क है। यह कुशल डेटा ट्रांसफर के लिए HTTP/2 का उपयोग करता है और आम तौर पर भेजे और प्राप्त किए जा रहे डेटा की संरचना को परिभाषित करने के लिए प्रोटोकॉल बफ़र्स, एक भाषा-तटस्थ, प्लेटफ़ॉर्म-तटस्थ, संरचित डेटा को क्रमबद्ध करने के लिए एक्स्टेंसिबल तंत्र पर निर्भर करता है।

उदाहरण, प्रोटोकॉल बफ़र्स की परिभाषा

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;
}

उपयोगकर्ता प्रबंधन सेवा के लिए, आपको एक जीआरपीसी सर्वर लागू करना चाहिए जो .proto फ़ाइल में प्रदान की गई सेवा परिभाषा का पालन करता है। इसमें आने वाले जीआरपीसी अनुरोधों को संभालने और उचित प्रतिक्रियाएं उत्पन्न करने के लिए आवश्यक सर्वर-साइड लॉजिक बनाना शामिल है।

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("[email protected]")
                .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();
    }
}

फायदे:

HTTP/2 और प्रोटोकॉल बफ़र्स के उपयोग के कारण उच्च प्रदर्शन और बैंडविड्थ दक्षता।

कई प्रोग्रामिंग भाषाओं का समर्थन करता है और इसमें अच्छी स्केलेबिलिटी है।

नुकसान:

यदि सेवाएँ gRPC का समर्थन नहीं करती हैं तो अनुवाद परत की आवश्यकता होती है।

तैनात करना और प्रबंधित करना अधिक जटिल हो सकता है।

2. अतुल्यकालिक संचार

एसिंक्रोनस संचार एक सेवा द्वारा उत्तर की प्रतीक्षा करने के लिए अपने स्वयं के संचालन को अवरुद्ध किए बिना किसी अन्य सेवा को अनुरोध भेजने की प्रक्रिया को संदर्भित करता है। यह आमतौर पर संदेश कतारों या प्रकाशन/सदस्यता प्रणाली के माध्यम से प्राप्त किया जाता है।

1. संदेश कतारें

संदेश कतार प्रणाली, जैसे RabbitMQ और Apache ActiveMQ, सेवाओं के बीच अतुल्यकालिक संचार की सुविधा प्रदान करती हैं।

फायदे:

बेहतर स्केलेबिलिटी और दोष सहनशीलता: सिस्टम बढ़े हुए कार्यभार को बेहतर ढंग से संभाल सकता है और विफलताओं के प्रति कम संवेदनशील है।

सेवाओं पर भार कम करना: अनुरोध भेजने और प्राप्त करने को अलग करके, मुख्य सेवाएँ निरंतर अनुरोधों से अभिभूत हुए बिना प्रसंस्करण कार्यों पर ध्यान केंद्रित कर सकती हैं।

नुकसान:

प्रबंधन और रखरखाव के लिए अतिरिक्त प्रयास की आवश्यकता हो सकती है: कतार-आधारित सिस्टम अधिक जटिल हो सकते हैं और संचालित करने के लिए अधिक संसाधनों की आवश्यकता होती है।

ऑर्डर को संभालने और संदेश वितरण सुनिश्चित करने में कठिनाई: यह सुनिश्चित करना कि अनुरोधों को सही क्रम में संसाधित किया गया है और कोई भी संदेश खो न जाए, एक तकनीकी चुनौती हो सकती है।

2.2. पब/उप सिस्टम

अपाचे काफ्का या गूगल पब/सब जैसी एक पब/सब (प्रकाशित/सदस्यता लें) प्रणाली, सेवाओं को संदेश प्रकाशित करने और विषयों की सदस्यता लेने की अनुमति देती है।

फायदे:

बड़े पैमाने पर और उच्च थ्रूपुट डेटा स्ट्रीम का समर्थन करता है।

सेवाओं के बीच निर्भरता कम करता है.

नुकसान:

विषयों और संदेशों को प्रबंधित और मॉनिटर करने के लिए अधिक जटिल परत की आवश्यकता होती है।

संदेशों के साथ ऑर्डर और विश्वसनीयता के मुद्दों को संभालना चुनौतीपूर्ण हो सकता है।"

यदि आप रुचि रखते हैं, तो आप पब/उपविषय पर मेरे पिछले लेख पढ़ सकते हैं।

संदेश ब्रोकर भाग 1 में मृत पत्र कतार

एक संदेश ब्रोकर भाग 2 में मृत पत्र कतार

संदेश ब्रोकर प्रणाली के भीतर संगति और विश्वसनीयता संबंधी चिंताएं

3. घटना-संचालित संचार

इवेंट-संचालित संचार तब होता है जब कोई सेवा किसी इवेंट का उत्सर्जन करती है और अन्य सेवाएं उन घटनाओं के आधार पर प्रतिक्रिया देती हैं या कार्रवाई करती हैं।

3.1. समकालिक घटनाएँ

सिंक्रोनस इवेंट तब घटित होते हैं जब कोई सेवा एक इवेंट उत्सर्जित करती है और अन्य सेवाओं से प्रतिक्रिया की प्रतीक्षा करती है।

लाभ:

इवेंट प्रोसेसिंग प्रक्रिया को नियंत्रित और मॉनिटर करना आसान है।

नुकसान:

यदि प्रतिक्रिया देने वाली सेवाएँ धीमी हैं या त्रुटियों का सामना करना पड़ता है तो बाधाएँ उत्पन्न हो सकती हैं

3.2. अतुल्यकालिक घटनाएँ

अतुल्यकालिक घटनाएँ तब घटित होती हैं जब कोई सेवा एक घटना उत्सर्जित करती है और उसे तत्काल प्रतिक्रिया की प्रतीक्षा करने की आवश्यकता नहीं होती है।

फायदे:

प्रतीक्षा समय कम करता है और स्केलेबिलिटी में सुधार करता है।

सेवाओं को अधिक स्वतंत्र रूप से संचालित करने में मदद करता है और पारस्परिक निर्भरता को कम करता है।

नुकसान:

घटनाओं को सही ढंग से और समय पर संसाधित किया जाए यह सुनिश्चित करने के लिए अतिरिक्त तंत्र की आवश्यकता है।

आदेश सुनिश्चित करने और डुप्लिकेट घटनाओं को संभालने में कठिनाई।

4. निष्कर्ष

माइक्रोसर्विसेज सिस्टम में सेवाओं के बीच संचार पद्धति का चुनाव प्रदर्शन आवश्यकताओं, विश्वसनीयता और सिस्टम जटिलता जैसे कारकों पर निर्भर करता है। प्रत्येक विधि के अपने फायदे और नुकसान हैं, और इन विधियों को समझने से आपको अधिक कुशल और लचीली माइक्रोसर्विसेज प्रणाली बनाने में मदद मिलेगी। सबसे उपयुक्त संचार विधि चुनने के लिए अपने सिस्टम की आवश्यकताओं पर सावधानीपूर्वक विचार करें।