Təsəvvür edin ki, onlayn mağaza açırsınız. Alıcı Leyla 87 AZN-lik sifariş verir və bundan dərhal sonra bir neçə şey baş verməlidir: sifariş verilənlər bazasında saxlanır, anbar malı rezerv edir, Leyla isə təsdiq məktubu alır. Sual budur ki, servislər baş verənlər haqqında bir-birinə necə xəbər verir. Mağazanın «qara cümə»ni və tək bir servisin çökməsini sağ-salamat keçib-keçməyəcəyi cavabdan asılıdır. Bu dərsdə ünsiyyətin iki üsulunu — sinxron və asinxron — müqayisə edəcək, mesaj brokerləri ilə tanış olacaq və onların hansı çatdırılma zəmanətləri verdiyini öyrənəcəyik.

Sinxron ünsiyyət: HTTP çağırışları zənciri

Ən aydın üsul sinxrondur: bir servis digərini HTTP ilə çağırır və telefon zəngi kimi cavab gözləyir. Qarşı tərəf cavab verməyincə dəstəyi asmaq olmur. Sifariş servisində (orders, Express 5) anbarı və məktub servisini ardıcıl çağıran handler belə görünür:

javascript
app.post('/orders', async (req, res) => {
  const order = await saveOrder(req.body);

  await fetch('http://inventory/reserve', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ orderId: order.id }),
  });
  await fetch('http://notifications/send-email', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ orderId: order.id }),
  });

  res.status(201).json(order);
});

Kod qısa və aydındır, amma onda üç problem gizlənib.

Çağırış zəncirinin üç problemi

  1. Kaskad nasazlıqlar. Sifariş yalnız bütün servislər cavab verəndə bitir. Əlçatanlıq vurulur: hər biri 99,9 % olan (ildə təxminən 9 saat dayanma) üç servis birlikdə 0,999³ ≈ 99,7 % verir — bu, artıq təxminən 26 saat deməkdir. Məktub servisi çökdü — sifarişlər də qəbul olunmur, halbuki məktub əsas məsələ deyil.
  2. Gecikmələr toplanır. Müştəri bütün çağırışların cəmini gözləyir: 200 ms-lik üç çağırış 600 ms edir, bir servis 5 saniyə «fikirləşəndə» alıcı da o qədər gözləyir.
  3. Sərt bağlılıq. Sifariş servisi inventory və notifications ünvanlarını və hər sorğunun formatını bilir. Analitika əlavə etmək istəyirsiniz — sifariş servisini dəyişib yenidən deploy etmək lazım gələcək.

Dördüncüsü də var, ən xoşagəlməzi: qismən uğur. Anbar malı artıq rezerv edib, məktub servisinə çağırış isə uğursuz olub. Alıcı 500 xətasını görür, «Ödə» düyməsini yenidən basır, dublikat yaradır, rezervi isə əl ilə geri qaytarmaq lazım gəlir.

⚠️ Belə zəncirdə avtomatik təkrarlar (retry) vəziyyəti daha da pisləşdirir: onsuz da yüklənmiş servis daha çox sorğu alır.

Asinxron ünsiyyət: mesajlar və broker

Çıxış yolu — zəng etmək yox, mesaj qoymaqdır. Restoran mətbəxini təsəvvür edin: ofisiant aşpazın başı üstündə dayanmır, sifariş vərəqini piştaxtaya sancıb növbəti masaya gedir. Aşpazlar vərəqləri boş olanda götürür. Aşpaz fasiləyə çıxıbsa, vərəqlər piştaxtada gözləyir və itmir.

Proqramlaşdırmada eyni şey beş termin ilə təsvir olunur: