როგორ ურთიერთობენ მიკროსერვისები ერთმანეთში?

Question

Accepted Answer

სერვისები ურთიერთობენ **სინქრონულად** (მოთხოვნა/პასუხი REST-ით ან gRPC-ით) ან **ასინქრონულად** (შეტყობინებები/მოვლენები ბროკერის მეშვეობით, როგორიცაა Kafka ან RabbitMQ).

## სინქრონული (მოთხოვნა/პასუხი)

მომწოდებელი ელის პასუხის დაბრუნებას. მარტივი და ინტუიტიური, მაგრამ ამას აკავშირებს ხელმისაწვდომობა — თუ გამოძახებული სერვისი ქვემოთ არის, მომწოდებელი დაზიანებული იქნება.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## ასინქრონული (შეტყობინებები/მოვლენები)

გამაგზავნელი ქვეყნდება შეტყობინება და მიდის; მომხმარებლები მას გვიან ამუშავებენ. ეს სერვისებს დროის მიხედვით განცალკევებს.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## რომელი რა დროს გამოიყენო

| საჭიროება | აირჩიე |
|---|---|
| esman პასუხი მომხმარებლისთვის | სინქრონული |
| განცალკევება, ბაფერირება, fan-out | ასინქრონული |
| ძლიერი დროითი მიბაძვა OK | სინქრონული |
| დაქვემდებარებული წარუმატებლობის წინააღმდეგ სტაბილურობა | ასინქრონული |

## პაწი

ხანგრძლივი **სინქრონული ჯაჭვები** (A → B → C → D) მრავლდებს დაყოვნება და წარუმატებლობის ალბათობა. სასურველია async ან გაერთიანება სადაც შესაძლებელია.

## რატომ არის მნიშვნელოვანი

კომუნიკაციის სტილი ზეწოვებს სისტემის სტაბილურობას: სინქრონული ზოგები მარტივი გასაგებია მაგრამ ქმნის მჭიდრო დროს სქემის შეკრებას, ხოლო ასინქრონული შეტყობინებები იძენენ განცალკევებას საბოლოო თანმიმდევრობის ხარჯზე.

მეტი რეალური სისტემები შერეულია ორივე — sync მომხმარებელი-ზედმიწევი კითხვებისთვის, async ფონის სამუშაოთი.

საჭიროება	აირჩიე
esman პასუხი მომხმარებლისთვის	სინქრონული
განცალკევება, ბაფერირება, fan-out	ასინქრონული
ძლიერი დროითი მიბაძვა OK	სინქრონული
დაქვემდებარებული წარუმატებლობის წინააღმდეგ სტაბილურობა	ასინქრონული