تکنولوژی و زیرساخت → استراتژی چند ابر و هماهنگ سازی

استراتژی چند ابر و هماهنگ سازی

1) چرا چند ابر

• انعطاف پذیری و DR: کاهش خطرات خاص ابر (شکست منطقه ای/پلت فرم).
• جغرافیا و انطباق: ذخیره سازی و پردازش در حوزه های قضایی مناسب (اقامت داده ها).
• عملکرد و هزینه: مسیر نزدیک به POP، آربیتراژ بازار در قیمت/سهمیه.
• استقلال از فروشنده: آزادی تکنولوژی و قدرت چانه زنی
• قیمت این مسئله پیچیدگی همگام سازی داده ها، شبکه ها، هویت ها و فرآیندهای تغییر است.

2) مدل های استقرار پایه

2. 1 دارایی-مسئولیت (چند ابر DR)

Prod در Cloud-A زندگی می کند ؛ در Cloud-B - آماده به کار گرم/گرم.
RTO/RPO به عمق تکرار، از دقیقه (روزنامه نگاری) تا ساعت (پشتیبان گیری/بازیابی) بستگی دارد.

مزایا: ساده تر و ارزان تر. منفی: RTO بالاتر, خطر ابتلا به پیکربندی «رانش»

2. ۲ دارایی (دو هواپیمای جنگی)

ترافیک بین Cloud-A/Cloud-B (GeoDNS/Anycast، GSLB، سطح کشور/ASN) توزیع می شود.
نیاز به سازگاری داده های متفکر و «شعاع انفجار» انزوا.
مزایا: RTO/RPO پایین، نزدیک به کاربر. معایب: پیچیدگی سازگاری و تست.

2. 3 تقسیم بر اساس دامنه (تقسیم بندی عملکردی)

هسته پرداخت در ابر با بهترین اتصالات خصوصی به PSP ؛ محتوا/دایرکتوری - در دیگری.
به حداقل رساندن متقابل ابر داغ آهنگ همگام سازی.

3) هماهنگ سازی داده ها: استراتژی ها و الگوهای

3. 1 انواع سازگاری

تکرار همزمان قوی-تراکنش (به طور معمول در همان ابر/منطقه).
نهایی (احتمالی): تکرار ناهمزمان ؛ مناسب برای کاتالوگ ها، پروفایل ها، تجزیه و تحلیل.
staleness محدود معتبر تاخیر (ثانیه/دقیقه) برای خواندن در خارج از عمودی داغ.

3. 2 تکنیک های تکرار

CDC (Change Data Capture): مجله → رویدادها → برنامه در ابر دیگر ؛ خوب برای DWH/گزارش/کش.
منبع یابی رویداد: منبع حقیقت - جریان رویدادهای دامنه ؛ از این پیش بینی های جمع آوری شده در هر ابر است.
CRDT/ساختارهای بدون درگیری: برای ورودی ها/شمارنده های قابل ویرایش (به عنوان مثال امتیازات/مدیران).
نوشتن دوگانه با idemotency: ضبط و انتشار توسط رویداد ؛ گیرنده dedupe (صندوق خروجی/صندوق ورودی) را فراهم می کند.
Object stores: versioning + cross-region/cross-cloud replication (با سربار خروج).

3. 3 حل تعارض (مثال)

قوانین دامنه: «آخرین عملیات برنده» تنها اگر دستورات idempoint از همان نوع.
سفارش با توجه به منبع حقیقت: وضعیت پرداخت کیف پول را نهایی می کند و نه برعکس.

ساعتهای برداری/برچسبهای منطقی: برای برخوردهای نادر در سوابق دارایی-دارایی

جبران (sagas): در صورت اختلاف - جبران دامنه (باز کردن تعادل، معکوس معامله).

3. 4 طرح عملی (کیف پول و پرداخت)

دستورات (بدهی/اعتباری) رفتن به ورود به سیستم محلی در ابر-A/ابر-B.
کیف پول رویدادها changed "از طریق یک اتوبوس بین ابر به هر دو ابر منتشر می شود.
نهایی شدن وضعیت - فقط تایید PSP ؛ deduplication توسط 'operation _ id'.
گزارش های نهایی جمع آوری می شوند CDC → DWH در هر ابر ؛ زمینه های وابسته به فروشنده عادی می شوند.

4) لایه شبکه و ترافیک جهانی

GSLB (Global Server Load Balancing): GeoDNS/Anycast، نمونه های بهداشتی در هر ابر، چسبندگی در هر جلسه.
Mesh-over-internet/private links: IPsec/Cloud-to-Cloud interconnect/private peerings.

کنترل خروج: ثابت NAT-IP توسط اجازه لیست به PSP/KYC ؛ QoS و محدودیت ها

تقسیم بندی: زیر شبکه های جداگانه برای تولید/مرحله ؛ کنترل ترافیک شرق و غرب بین ابر است.

[Users] → [GSLB/Anycast] → (Cloud-A: Edge/API) ↔ (Cloud-B: Edge/API)

[Services / Data A] ↔↔↔ [Services / Data B]
^   Inter-cloud Mesh   ^
[DWH/CDC A]        [DWH/CDC B]

5) هویت، اسرار و انطباق

فدراسیون IAM: تک IdP (OIDC/SAML)، مدل نقش پیش بینی شده در هر دو ابر ؛ حذف «دانه های برف»

اسرار و KMS: کلید در کنار هر ابر (BYOK/HYOK در صورت لزوم)، چرخش توافق ؛ کلیدهای اصلی را مستقیما تکرار نکنید.
mTLS/امضا: خدمات TLS متقابل بین ابر ؛ رویدادها و وب سایت ها توسط HMAC با کلید های ابر امضا شده است.
اقامت داده ها: برچسب ها/کلاس های داده، سیاست های مسیریابی/ذخیره سازی (PII/PCI در کشور باقی می ماند).
حسابرسی: ورود به سیستم WORM، ردیابی متقابل ابر، ورود به سیستم تغییر یکپارچه.

6) پلت فرم و انتزاع

Kubernetes چند خوشه: خوشه در هر ابر ؛ اتحاد از طریق GitOps (Argo/Flux)، پروفایل های خوشه ای و سیاست به عنوان کد (OPA/Gatekeeper).
سرویس مش (چند خوشه): mTLS، retry/breakers، مسیریابی محلی آگاه ؛ به وضوح تماس های متقابل ابر را محدود کنید.
ذخیره سازی (CSI) و حافظه پنهان: اجتناب از تنظیم stateful با نوشتن اجباری همزمان بین ابر ؛ کش/خواندن - به صورت محلی، گرم شدن ناهمزمان.
IaC: Terraform/Crossplane برای مصنوعات ابر ؛ ماژول های تک با «درج» خاص فروشنده.
DevPortal/Service Catalog: هر مکان ابر و ابرداده وابستگی.

7) CI/CD و مدیریت تغییر

تک repo/تک مشخصات با پارامتر هر ابر (ویژگی ها، سهمیه ها، انواع متعادل کننده ها).
Canary/Blue-Green per-cloud: انتشار جداگانه در مقایسه متریک Cloud-A/Cloud-B +.
ماتریس تست: تست ادغام «oblako↔oblako»، پخش حوادث، geo synthetics.
نسخه قرارداد: طرح کلی رجیستری، قوانین MINOR سازگار با عقب.
تغییر یخ در مهاجرت EOL: زمانی که شما سوئیچ ترافیک بین ابرها.

8) قابلیت مشاهده و مدیریت SLO

End-to-end trace_id: اندازه گیری از طریق یک دروازه → سرویس → کارگزار → مصرف کننده در ابر دیگر ؛ лейблы «ابر»، «منطقه»، «api _ version»، «شریک».
SLO در هر ابر/در هر منطقه: داشبورد در دسترس بودن/تاخیر/خطا و تاخیر بین ابر (تاخیر تکرار).
ناهنجاری هماهنگ سازی بین ابر: هشدار به رشد DLQ، افزایش در «نرخ درگیری»، تاخیر CDC.
صفحه وضعیت: وضعیت عمومی توسط ابر و منطقه.

9) FinOps: هزینه چند ابر

خروج و کانال های بین ابر: مورد اصلی هزینه ؛ به حداقل رساندن پچ پچ، حوادث جمع، استفاده از پیش بینی های محلی.
منابع تکراری: استخرهای گرم، موارد رزرو شده/نظرات در هر ابر → تعادل.
پروفایل های بار: جابجایی پس زمینه غیر بحرانی به ابر با بهترین قیمت/سهمیه.
«هزینه سازگاری» شمارنده: $/ثانیه تاخیر، تکرار $/GB، $/درگیری - شفافیت برای کسب و کار.

10) موارد برای iGaming/fintech

پرداخت/کیف پول (سطح سازگاری دقیق): دارایی-مسئولیت با شکست سریع ؛ رویدادهای نهایی سازی وضعیت تنها منبع حقیقت هستند ؛ تکرار ورود به سیستم.
کاتالوگ بازی/تبلیغی/رتبه بندی: دارایی با نهایی، CRDT-شمارنده برای آمار ؛ کش TTL در هر خواندن.

گزارش به تنظیم کننده ها: فروشگاه های محلی DWH، جمع آوری ابر متقابل به صورت ناهمزمان ؛ ضمانت تازگی (SLO)

بازاریابی/اطلاعیه ها: هماهنگی جغرافیایی/ابر، محدودیت تماس متقابل ابر ؛ deduplication از ارسال.
KYC/AML: ارائه دهندگان موازی در ابرهای مختلف، عادی سازی پاسخ ها و یک سیاست تصمیم گیری واحد.

11) راه حل های نمونه (قطعات)

11. 1 صندوق پستی → CDC (idempotency)

BEGIN TX apply(domain_command)
insert into outbox(event_id, aggregate_id, type, payload, hash)
COMMIT
//Replicator reads outbox, publishes to inter-cloud bus;
//receiver executes inbox-dedupe on event_id/hash.

11. 2 سیاست تعارض (شبه)

if operation. type in {CAPTURE, REFUND}:
source = PSP_EVENT elif operation. type in {LIMIT_SET, LIMIT_REMOVE}:
source = RG_SERVICE apply_if_newer(source, aggregate_version)

11. 3 سیاست شبکه

تماس های بین ابر فقط برای «رویدادها»، «idp»، «همگام سازی کاتالوگ» مجاز است. یک راست رفت. write "- مجاز نیست (به صورت محلی).

12) ایمنی و خطر

شعاع انفجار: محدودیت در پهنای باند بین ابر و صف به طوری که خطا/حلقه «سیل» هر دو ابر نیست.
Gardrails اتوماسیون: AI-Ops/ranbooks نمی تواند پیکربندی دو ابر را در همان زمان بدون چند سیگنال تغییر دهد.
تست های شکست ارتباطی: رفتار تقسیم مغز، رشد صف، وقفه ها و تخریب خودکار.

13) چک لیست پیاده سازی

1. دامنه های سازگاری دقیق/نهایی و هدف RPO/RTO در هر دامنه تعریف شده است.
2. مدل انتخاب شده (دارایی-بدهی/دارایی-دارایی/تقسیم بندی دامنه).
3. شبکه بین ابر: GSLB، لینک مش/خصوصی، خروجی IP ثابت، حفاظت WAF/ربات.
4. طرح داده ها در رجیستری، قوانین سازگاری ؛ outbox/inbox در همه جا حاضر است.
5. Idempotence و deduplication (کلید، ذخیره سازی TTL، هش).
6. CI/CD: پارامتری در هر ابر، قناری به طور جداگانه، مرکز انتشار مشترک.
7. مشاهده: 'trace _ id'، ورود به سیستم تکرار، نرخ درگیری، نظارت DLQ.
8. فدراسیون IAM، اسرار KMS/ابر، ممیزی دسترسی.
9. FinOps: بودجه ها را بیرون بکشید، هشدار برای هزینه های بین ابر.
10. دریل DR به طور منظم: feiler ابر، شبیه سازی تقسیم مغز.

14) ضد الگوهای

معاملات مسیر داغ ابر همزمان (کیف پول/نوشتن) → شکنندگی و دم P99.
یک «خوشه اصلی» از پایگاه داده برای دو ابر → SPOF بر روی شبکه.
تکرار «همه در یک بار» بدون دسته بندی داده ها → انفجار هزینه ها و درگیری ها.
فقدان صندوق خروجی/صندوق ورودی و idempotency → پرداخت های تکراری/اعتبار.
اسرار «در حال حرکت» از طریق S3-buckets/pipes در فرم باز است.
خروج حساب نشده و پنهان چت خدمات بین ابر → حساب های غیر قابل پیش بینی.

15) خط پایین

چند ابر «دو تیک در کنسول» نیست، بلکه نظم و انضباط طراحی داده ها، شبکه ها و فرآیندهای تغییر است. واضح است که دامنه ها را با الزامات سازگاری جدا کنید، مسیر داغ متقابل ابر را محدود کنید، از CDC/event sourcing و idempotency استفاده کنید، تاخیرها و درگیری ها را اندازه گیری کنید و هزینه ها را کنترل کنید. چند ابر پس از آن تبدیل به یک ابزار برای انعطاف پذیری و سرعت، به جای منبع حوادث اواخر شب و خروج از صورتحساب.