Kruhová kontrola a přepínání rozhraní API, aby průtok překlady

[vBET]

Chápu vaše popis a své místo. Nyní musíme zjistit, jak to asi fungovat technicky.

Jeden problém vidím tady je, jak poznají, že již máme k dispozici od hranice těch, kde předtím.

Můžeme jednoduše pokaždé zeptat upřednostňovaného zprostředkovatele a pak přejít na další stránku. Výkon - to bude stát, protože pro každý požadavek na stránku, která vyžaduje překlad zvládli neúspěšné volání na upřednostňovaného zprostředkovatele, pak na další jeden (takže když vBET bude podporovat více API může být několik neúspěšných volání).

Jiné řešení by bylo pro ukládání informací, že preferovaným dodavatelem není k dispozici, a přejít přímo k další. To by bylo mnohem rychlejší, protože kontrola lokálních proměnných je mnohem rychlejší, než čekat na odpověď z externího serveru. Tentokrát jsme se další problém - nevíme, kdy preferovaným dodavatelem je k dispozici. Můžeme samozřejmě udělal některé naplánované úlohy, které by požádat o jednoduchý (krátký), překlad například jednou za hodinu / den, podívat se na to. Takže v této strategii se musíme rozhodnout, jak často implicitně jako úkol Předpokládám, že se do práce. Samozřejmě, že bychom zkontrolovat pouze v případě některých služeb je označen jako není k dispozici.
Také v případě, označíme poskytovatelé nedostupné - Co dělat, když víme, že všichni poskytovatelé nejsou k dispozici - přidat nějaké informace pro koncové uživatele, nebo jen přeložit, co je v cache a zbytek je původní, a to bez jakékoli další informace o dočasný nedostatek překlady .

Bez ohledu na to, jakým způsobem to bude hotovo, bude Google bude považován za jedno API (V1 a V2 v závislosti na konfiguraci) - Nemá smysl dělit, protože Google V1 bude uzavřena v nejbližší době.

Další věc je umožnit Konfigurovat zprostředkovatele fronty pro každý jazyk pár odděleně. V tomto okamžiku vBET již umožňuje konfigurovat poskytovatel překladů pro každou dvojici jazyk. Myslím, že můžeme změnit ji od jednoho do hodnoty oddělené čárkou (CSV). Tímto způsobem budeme vědět pro každý jazyk pár který zprostředkovatelé podporují tento překlad a co jsou pořadí preferencí (jen pořadí na seznam CSV).

UPOZORNĚNÍ: To bude mít nějaký dopad na výkon tak jako tak. Namísto vytvoření jednoho objektu pro překlad, budeme muset vytvořit pole takových objektů a další balení objekt (aby bylo transparentní pro jiné části kódu a méně náchylné chyby). Samozřejmě nebudeme vytvářet objekty pro poskytovatele víme, že nejsou k dispozici v tuto chvíli.
Řešení by to bylo na konfiguraci pro lepší výkon a odstranit poskytovatelů fronta - stejně jako je to teď - jednoho poskytovatele za jazykový pár.
To by nemělo být drahé výkony, ale stále ještě některé další logiky a paměti.

Prosím, řekněte, které řešení je lepší.