8feea123bb
* feat(docs): mirror every docs/ page in all 65 locales Extends the documentation mirrors from the 22-page core set (#13940) to every Markdown page under docs/: 152 sources x 65 locales = 9,880 mirrors (6,208 new), language bars rewritten for the full locale list, state adopted so the blocking drift gate now covers all 152 pages. run-translation.mjs: an oversized block made only of table rows or list items (PROVIDER_REFERENCE.md 244-row table, FREE_TIERS.md 71-item list) is cut at item boundaries and rejoined without a blank line — the single 16-40 KB request outlived the backend socket for verbose scripts. 48 older mirrors whose tables had lost rows were retranslated with --force. * docs(i18n): refresh mirrors for the sources the base changed since the branch cut Section-level retranslation of the 29 docs (and README.md) whose source or mirrors moved on release/v3.8.51 during the run, then state adoption; the drift gate is green again on the merged tree.
18 KiB
Relay Backend Strategy (မြန်မာ)
🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW
အကျဉ်းချုပ်
OmniRoute သည် ယခုအခါ /api/v1/relay/chat/completions အတွက် relay mode သုံးမျိုးကို ပံ့ပိုးထားသည်-
ts: TypeScript relay ကို process အတွင်း အသုံးပြုသည်။bifrost: Bifrost gateway ကို မဖြစ်မနေ အသုံးပြုသည်။auto: Bifrost ကို အသုံးပြုနိုင်သည့်အခါ ဦးစားပေးပြီး၊ မအောင်မြင်ပါက TypeScript သို့ ပြန်လည်အသုံးပြုသည်။
Request rate မြင့်မားစွာဖြင့် လည်ပတ်နေချိန်တွင် (တစ်ရက်လျှင် token အရေအတွက်များပြားပြီး throughput သည် အဆက်မပြတ်နီးပါးဖြစ်သည့်အခါ) အကောင်းဆုံးနည်းဗျူဟာမှာ fallback လမ်းကြောင်းကို ရှင်းလင်းတိကျပြီး မြန်ဆန်စွာထားရှိရန်ဖြစ်သည်။ ထိုသို့ထားခြင်းဖြင့် hot path သည် အလုပ်မလုပ်တော့သည့် sidecar ကို စောင့်ဆိုင်းရင်း မည်သည့်အခါမျှ ပိတ်ဆို့မနေစေပါ။
Mode တစ်ခုချင်းစီ၏ လုပ်ဆောင်ပုံ
ts- လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ ရှုပ်ထွေးမှု အနည်းဆုံးဖြစ်သည်။
- Routing နှင့် validation အားလုံးသည် Node တွင် လုပ်ဆောင်သည်။
- အသုံးပြုနိုင်မှုအတွက် sidecar အပေါ် မှီခိုစရာမလိုပါ။
bifrost- Request အားလုံးကို sidecar gateway မှတစ်ဆင့် မဖြစ်မနေ ဖြတ်သန်းစေသည်။
- အလိုအလျောက် fallback မရှိပါ။
- Sidecar ၏ health နှင့် latency ကို အာမခံနိုင်သည့်အခါမှသာ အသုံးဝင်သည်။
auto- Sidecar ကို ဆက်သွယ်ရယူနိုင်ပြီး ဖွင့်ထားသည့်အခါ အသုံးပြုသည်။
- မအောင်မြင်သော ကြိုးပမ်းမှုများသည် fallback header များကို ဖြစ်ပေါ်စေပြီး request အောင်မြင်မှုကို ကန့်သတ်ထားနိုင်ရန် traffic ကို TS သို့ ပြန်ပို့သည်။
- Uptime သည် sidecar တစ်ခုတည်းမှတစ်ဆင့်သာ တင်းကျပ်စွာ routing လုပ်ခြင်းထက် ပိုအရေးကြီးသည့် production ပတ်ဝန်းကျင်အတွက် ဤ mode သည် အလုံခြုံဆုံး ရွေးချယ်မှုဖြစ်သည်။
ယနေ့ 9router နှင့် CLIPROXYAPI နှိုင်းယှဉ်ချက်
9router နှင့် CLIPROXYAPI နှစ်ခုစလုံးသည် ယခင်က upstream provider များအတွက် compatibility path များကို ဖော်ထုတ်ပေးခဲ့သည့် integration များဖြစ်သည်။
- 9router သည် upstream orchestration နှင့် compatibility behavior အတွက် ထည့်သွင်းမြှုပ်နှံထားသော လမ်းကြောင်းတစ်ခုဖြစ်သည်။
- CLIPROXYAPI သည် CLI / SDK ပုံစံ traffic အတွက် proxy API bridge တစ်ခုဖြစ်သည်။
- သီးခြား sidecar ပုံစံ hop နှင့် latency နည်းသော local dispatch လိုအပ်သည့်အခါ အသုံးပြုရန် Bifrost ကို ပြင်ပလမ်းကြောင်းအဖြစ် တည်ငြိမ်အောင် လုပ်ဆောင်နေသည်။
လက်ရှိတွင် 9router/CLIPROXYAPI ကို နှိုင်းယှဉ်သုံးသပ်နေပါက-
- လွှဲပြောင်းမပေးမီ request signing၊ allowlist စစ်ဆေးမှုများနှင့် DB policy gate များကို API route ထဲတွင် ထားရှိပါ။
- Workflow တစ်ခုသည် တင်းကျပ်သော sidecar လုပ်ဆောင်ပုံနှင့် request တစ်ခုချင်းအလိုက် ကွဲပြားမှု နည်းပါးခြင်းကို လိုအပ်ပါက
OMNIROUTE_RELAY_BACKEND=bifrostကို အသုံးပြုပါ။ - Incident ဖြစ်ပွားချိန်တွင် လုပ်ဆောင်နိုင်စွမ်းကို တဖြည်းဖြည်းလျှော့ချသည့် graceful degradation နှင့်အတူ sidecar ခံနိုင်ရည်ရှိမှုကို လိုအပ်ပါက
OMNIROUTE_RELAY_BACKEND=autoကို အသုံးပြုပါ။
Backend နယ်နိမိတ်ဆိုင်ရာ သဘောတူညီချက်
တည်ငြိမ်သော product boundary သည် dashboard implementation မဟုတ်ဘဲ OmniRoute relay API ဖြစ်သည်။ Next.js dashboard သည် local service များကို ထည့်သွင်းခြင်း၊ စီစဉ်သတ်မှတ်ခြင်းနှင့် ကြီးကြပ်ခြင်းတို့ ပြုလုပ်နိုင်သော်လည်း request routing သည် relay API မှတစ်ဆင့် ဝင်ရောက်ပြီး ထို boundary နောက်ကွယ်သို့ လွှဲပြောင်းပေးသင့်သည်။
ရေရှည် backend ရွေးချယ်မှုများ-
- TypeScript relay ကို in-process policy နှင့် fallback path အဖြစ် ဆက်လက်ထားရှိပါ။ Backend တစ်ခုခုသို့ မလွှဲပြောင်းမီ Auth၊ allowlist များ၊ request normalization၊ accounting နှင့် safety check များကို ဤနေရာတွင် ဆက်လက်ထားရှိပါ။
- Deployment သည် routing ကွဲပြားမှု နည်းပါးခြင်း၊ ဗဟိုမှ စီမံသည့် provider အလှည့်ကျအသုံးပြုမှု သို့မဟုတ် OmniRoute replica အများအပြားသို့ scale-out လုပ်ခြင်းကို လိုအပ်သည့်အခါ Bifrost ကို ဦးစားပေး high-throughput Tier-1 sidecar အဖြစ် အသုံးပြုပါ။
- 9router နှင့် CLIPROXYAPI ကို ထည့်သွင်းမြှုပ်နှံထားသော compatibility service များအဖြစ် ဆက်လက်ထားရှိပါ။ ၎င်းတို့သည် ကြီးကြပ်ထားသော local process များအဖြစ် လည်ပတ်ပြီး ၎င်းတို့၏ provider/CLI လုပ်ဆောင်ပုံကို လိုချင်သော adapter အဖြစ် အသုံးပြုသည့်အခါ အသုံးဝင်သော်လည်း ပုံသေ Tier-1 routing engine မဖြစ်သင့်ပါ။
- Dashboard မှ မည်သည့် service URL ကိုမဆို hot path သို့ တိုက်ရိုက်ပေးပို့ခွင့် မပြုပါနှင့်။ UI မှ ပေးသော URL များသည် configuration input များသာဖြစ်သည်။ Routing code သည် server-side setting များနှင့် supervisor state တို့မှ မှတ်ပုံတင်ထားပြီး health check ပြုလုပ်ထားသော backend များကို ရှာဖွေအသုံးပြုသင့်သည်။
- စီမံကြီးကြပ်ထားသော process များသည် HTTP-compatible API များကို အသင့်ဖော်ထုတ်ထားပြီး၊ route guard က boundary ကို audit လုပ်နိုင်ကာ failure/fallback လုပ်ဆောင်ပုံကို request log များတွင် မြင်နိုင်သောကြောင့် လက်ရှိတွင် supervised service များအတွက် loopback HTTP ကို ဦးစားပေးပါ။ အနာဂတ် SDK သို့မဟုတ် socket transport တစ်ခုသည် isolation သို့မဟုတ် fallback semantics ကို မအားနည်းစေဘဲ p99 routing latency ကို တိုင်းတာနိုင်လောက်အောင် လျှော့ချပေးနိုင်မှသာ ထည့်သွင်းရန် ထိုက်တန်သည်။
ထို့ကြောင့် အလွန်မြင့်မားသော throughput ရှိသည့် deployment အတွက် ပုံသေအဖြေမှာ Bifrost ကို ဖွင့်ထားသည့် auto ဖြစ်သည်။ အောင်မြင်မှုနှုန်းကို ထိန်းသိမ်းရန် TypeScript fallback ကို ဆက်လက်ထားရှိရင်း hot path တွင် Go sidecar ကို အသုံးပြုပါ။ တင်းကျပ်သော sidecar-only လုပ်ဆောင်ပုံသည် graceful degradation ထက် ပိုအရေးကြီးသည့်အခါမှသာ bifrost ကို အသုံးပြုပါ။
High-throughput အတွက် လမ်းညွှန်ချက်
မြင့်မားသော RPM/RPS ကို ရေရှည်ထိန်းသိမ်းပြီး တင်းကျပ်သော success SLO ကို ရရှိရန်-
- လက်တွေ့ကျသော cooldown နှင့် failure telemetry တို့နှင့်အတူ
autoကို အသုံးပြုပါ။ - Upstream validation နှင့် API-key စစ်ဆေးမှုများကို TypeScript route boundary တွင် ထားရှိပါ။
- သင့် alerting စနစ်က fallback ဖြစ်ပွားသည့် အကြိမ်ရေနှင့် အကြောင်းရင်းများကို မြင်နိုင်ရန် တိကျသော header/counter များကို ဖွင့်ထားပါ။
- အကန့်အသတ်မရှိ စောင့်ဆိုင်းမည့်အစား မြန်ဆန်စွာ failure ဖြစ်စေရန် sidecar timeout များကို ချိန်ညှိပါ။
- Fallback သည် အမှန်တကယ် ခြွင်းချက်အခြေအနေတစ်ခုသာ ဖြစ်နေစေရန် service auto-restart နှင့် health telemetry loop ကို ကောင်းမွန်စွာ လည်ပတ်နေအောင် ထိန်းသိမ်းပါ။
အကြံပြုထားသော အခြေခံသတ်မှတ်ချက်
OMNIROUTE_RELAY_BACKEND=autoBIFROST_ENABLED=1- API key များ၊ allowlist၊ sanitizer နှင့် rate-limit စစ်ဆေးမှုများကို route handler များတွင် ဖွင့်ထားပါ။ ၎င်းတို့သည် downstream သို့ မပို့မီ အမြဲတမ်း လုပ်ဆောင်သည်။
- Sidecar ပြတ်တောက်မှုများကို တစ်မိနစ်အတွင်း မြင်နိုင်စေရန် သင့် reverse proxy နှင့် request log များမှ fallback metric များကို export လုပ်ပါ။
Provider plugin ဆိုင်ရာ သဘောတူညီချက်
Sidecar များသည် TypeScript executor အတွင်းပိုင်း implementation များအပေါ် မှီခိုမည့်အစား JSON-safe provider plugin manifest မှတစ်ဆင့် provider metadata ကို import လုပ်သင့်သည်။ Sidecar အသုံးပြုခွင့်ဆိုင်ရာ သဘောတူညီချက်နှင့် migration အဆင့်များအတွက် Provider Plugin Manifest ကို ကြည့်ပါ။