Upravit

Model Agregace pomocí brány

Traffic Manager

Používá bránu k agregaci několika jednotlivých požadavků do jednoho. Tento model se hodí, když klient musí k provedení operace volat více různých systémů back-end.

Kontext a problém

Je možné, že klient k provedení jednoho úkolu musí provést několik volání různých služeb back-end. Aplikace, která je kvůli provedení úkolu závislá na mnoha službách, musí na každý požadavek vynaložit prostředky. Když se do aplikace přidá nová funkce nebo služba, jsou potřeba další požadavky. Tím se nároky na prostředky a počet síťových volání ještě zvýší. Tato častá komunikace mezi klientem a back-endem může nepříznivě ovlivnit výkon a škálování aplikace. Kvůli architekturám mikroslužeb je tento problém častější, protože aplikace sestavené kolem mnoha menších služeb mají přirozeně větší počet volání mezi službami.

V následujícím diagramu klient odesílá požadavky do každé služby (1, 2, 3). Každá služba požadavek zpracuje a odešle odpověď zpět do aplikace (4, 5, 6). Přes mobilní síť s obvykle vysokou latencí je používání jednotlivých požadavků tímto způsobem neefektivní a může mít za následek přerušené připojení nebo neúplné požadavky. I když se dá každý požadavek provést paralelně, musí aplikace pro každý požadavek odeslat, čekat a zpracovat data, a to vždy v samostatných připojeních. Tím se zvyšuje riziko selhání.

Diagram problému pro model agregace brány

Řešení

Použijte bránu ke snížení nadměrné komunikace mezi klientem a službami. Brána přijme požadavky klienta, odešle je různým systémům back-end a pak agreguje výsledky a zašle je zpět klientovi.

Tento model může snížit počet požadavků, které aplikace zasílá službám back-end, a zlepšit výkon aplikace v sítích s vysokou latencí.

V následujícím diagramu aplikace odesílá požadavek do brány (1). Požadavek obsahuje balíček dalších požadavků. Brána je rozloží a zpracuje každý požadavek jeho odesláním do příslušné služby (2). Každá služba vrátí odpověď bráně (3). Brána odpovědi z každé služby zkombinuje a odešle odpověď aplikaci (4). Aplikace vytvoří jeden požadavek a z brány obdrží jenom jednu odpověď.

Diagram řešení pro model agregace brány

Problémy a důležité informace

  • Brány nesmí zavést párování služeb napříč službami back-end.
  • Brána se musí nacházet blízko služeb back-end, aby se co nejvíce snížila latence.
  • Služba brány může představovat kritický prvek způsobující selhání. Zajistěte, aby byla brána správně navržená a splňovala požadavky aplikace na dostupnost.
  • Brána může představovat kritický bod. Zkontrolujte, jestli má brána odpovídající výkon pro zpracování zátěže a je možné ji škálovat, aby zvládala váš předpokládaný růst.
  • Proveďte testování s bránou, abyste se ujistili, že nezpůsobíte kaskádová selhání služeb.
  • Implementujte odolný návrh s využitím technik jako pažení, jistič, opakovánía časové limity.
  • Pokud jedno nebo více volání služby trvá příliš dlouho, může být přijatelné uplatnit časový limit a vrátit částečnou sadu data. Zvažte, jak vaše aplikace tento scénář zvládne.
  • Používejte asynchronní vstup a výstup, aby zpoždění v back-endu nezpůsobovalo problémy s výkonem v aplikaci.
  • Implementujte distribuované trasování pomocí ID korelace ke sledování každého jednotlivého volání.
  • Monitorujte metriky požadavků a velikosti odpovědí.
  • Zvažte vracení dat uložených v mezipaměti jako strategii pro převzetí služeb při selhání.
  • Místo zabudování agregace do brány zvažte umístění agregační služby za bránou. Agregace požadavků bude mít pravděpodobně jiné nároky na prostředky než jiné služby v bráně a může mít vliv na funkce brány týkající se směrování a snižování zátěže.

Kdy se má tento model použít

Tento model použijte v těchto případech:

  • Klient musí kvůli provedení operace komunikovat s více službami back-end.
  • Klient může používat sítě s výraznou latencí, třeba mobilní sítě.

Tento model nebude pravděpodobně vhodný v následujících případech:

  • Chcete snížit počet volání mezi klientem a jednou službou napříč více operacemi. V takovém scénáři může být lepší přidat do služby dávkovou operaci.
  • Klient nebo aplikace se nachází blízko služeb back-end a latence není významným faktorem.

Příklad

Následující příklad ukazuje, jak vytvořit jednoduchou službu NGINX agregace pomocí brány s využitím Lua.

worker_processes  4;

events {
  worker_connections 1024;
}

http {
  server {
    listen 80;

    location = /batch {
      content_by_lua '
        ngx.req.read_body()

        -- read json body content
        local cjson = require "cjson"
        local batch = cjson.decode(ngx.req.get_body_data())["batch"]

        -- create capture_multi table
        local requests = {}
        for i, item in ipairs(batch) do
          table.insert(requests, {item.relative_url, { method = ngx.HTTP_GET}})
        end

        -- execute batch requests in parallel
        local results = {}
        local resps = { ngx.location.capture_multi(requests) }
        for i, res in ipairs(resps) do
          table.insert(results, {status = res.status, body = cjson.decode(res.body), header = res.header})
        end

        ngx.say(cjson.encode({results = results}))
      ';
    }

    location = /service1 {
      default_type application/json;
      echo '{"attr1":"val1"}';
    }

    location = /service2 {
      default_type application/json;
      echo '{"attr2":"val2"}';
    }
  }
}