معماری ترکیبی زیرساخت: مدیریت پایداری شبکه و سئو در پروژه‌های بومی با توجه با اختلالات گسترده اینترنت در ایران

معماری ترکیبی زیرساخت: مدیریت پایداری شبکه و سئو در پروژه‌های بومی

در مهندسی نرم‌افزار مدرن، پلتفرم‌های ابری مانند Vercel، Netlify یا Render به دلیل ارائه تجربه توسعه (DX) ایده‌آل و شبکه‌های Edge توزیع‌شده، انتخاب‌های اول بسیاری از تیم‌های فنی هستند. با این حال، در اکوسیستم فناوری ایران، تکیه ۱۰۰ درصدی بر این ابزارها با دو چالش عمده همراه است: اختلالات مداوم در گیت‌وی‌های بین‌المللی و ریسک قطع دسترسی کاربران داخلی.

جداسازی فیزیکی پروژه‌ها به دو نسخه داخلی و خارجی، ساده‌ترین راهکار است؛ اما این رویکرد به معنای چندپارگی کد (Code Splitting)، افزایش هزینه‌های DevOps و ناهماهنگی در دیپلوی‌هاست. از سوی دیگر، انتقال کامل زیرساخت به دیتاسنترهای داخلی نیز به دلیل ناپایداری‌های دسترسی خزنده‌های گوگل (Googlebots) به سرورهای ایران، آسیب شدیدی به سئو (SEO) و بودجه خزش (Crawl Budget) پلتفرم می‌زند.

ما در تیم فنی Wishwork برای حل این پارادوکس، پشته زیرساختی خود را به یک معماری هیبریدیِ انعطاف‌پذیر (Hybrid Geo-Aware Architecture) ارتقا دادیم. در ادامه، مستندات و مراحل فنی این پیاده‌سازی را به صورت آبجکتیو بررسی می‌کنیم.

مرحله اول: خروج از Vendor Lock-in با داکرایزیشن چندمرحله‌ای

برای اینکه فرآیند دیپلوی مستقل از پلتفرم میزبان باشد، نیاز بود وابستگی مستقیم به محیط اجرایی Vercel یا سرویس‌های مشابه حذف شود. برای این منظور، کل فرآیند بیلد در قالب Multi-stage Dockerfile بازنویسی شد.

به عنوان نمونه در پروژه‌های Next.js، با فعال‌سازی قابلیت output: ‘standalone’، خروجی بیلد به بهینه‌ترین شکل ممکن و بدون وابستگی‌های اضافی محیط توسعه (DevDependencies) پکیج می‌شود. این کار حجم Image نهایی را تا نزدیک به ۸۰ درصد کاهش می‌دهد. نتیجه این لایه، ساخت یک Artifact استاندارد است که از طریق متغیرهای محیطی (Environment Variables) سوییچ می‌شود؛ به طوری که یک ایمیج واحد، هم روی سرورهای بین‌المللی (مانند Render) و هم روی پلتفرم‌های ابری بومی (مانند هم‌روش) بدون کوچکترین تغییر در کدهای اصلی اجرا می‌شود.

FROM node:18-alpine AS base

FROM base AS builder
WORKDIR /app
COPY . .
RUN npm run build

FROM base AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
EXPOSE 3000
CMD ["node", "server.js"]

مرحله دوم: مدیریت تفکیک ترافیک در لایه DNS و شبکه

چالش بعدی، مسیریابی درست ترافیک بدون ایجاد نقطه شکست (Single Point of Failure) در لایه DNS بود. اگر DNS سرورها فقط در خارج از کشور باشند، در صورت بروز وضعیت اینترانت، دامنه لود نمی‌شود. اگر فقط در داخل باشند، بات‌های گوگل با Timeout مواجه می‌شوند.

راه‌حل، استفاده از شبکه‌های توزیع محتوا (CDN) با قابلیت Anycast و Geo-DNS است (مانند شبکه‌های ترکیبی کلودفلر یا ابرهای بومی مثل ابر آروان).

منطق مسیریابی به این صورت پیکربندی شده است:

• ترافیک داخلی (Iran ASNs): درخواست‌های کاربران از داخل کشور، در نزدیک‌ترین نودِ بومیِ CDN مهار شده و مستقیماً به کلاستر ما در هم‌روش منتقل می‌شوند. این کار لیتنسی را به حداقل می‌رساند.

• ترافیک خارجی (Global/Googlebot): درخواست‌هایی که از IPهای بین‌المللی (به ویژه خزنده‌های موتورهای جستجو) می‌آیند، به سمت Edge Networkهای جهانی (مانند Vercel یا Render) هدایت می‌شوند تا پایداری ایندکس و سئوی سایت تضمین شود.

مرحله سوم: بهینه‌سازی ترافیک سمت کلاینت (حل تداخل VPN)

یکی از پیچیده‌ترین رفتارهای شبکه در ایران، استفاده مداوم کاربران از فیلترشکن (VPN) است. کاربری که با VPN روشن به سایت متصل می‌شود، از دید لایه DNS یک کاربر خارجی است و سیستم او را به Vercel هدایت می‌کند؛ در حالی که به دلیل محدودیت‌های پهنای باند روی پروتکل‌های تونلینگ، با افت شدید سرعت مواجه خواهد شد.

برای حل این مسئله، سیستم مسیریابی را صرفاً به لایه DNS محدود نکردیم و یک مکانیزم هوشمند سنجش تاخیر (Latency Live Sniffer) در لایه فرانت‌اَند پیاده‌سازی کردیم. هنگام لود اولیه اپلیکیشن، کلاینت دو درخواست پینگ بسیار سبک به هردو Endpoint داخلی و خارجی ارسال می‌کند:

const routes = {
  internal: 'https://ir-api.wishwork.org/health',
  external: 'https://global-api.wishwork.org/health'
};

async function setOptimalRoute() {
  try {
    // رقابت لیتنسی بین دیتاسنتر داخلی و خارجی
    const fastestProvider = await Promise.race(
      Object.entries(routes).map(([key, url]) => 
        fetch(url, { method: 'HEAD' }).then(() => key)
      )
    );
    localStorage.setItem('network_route', fastestProvider);
  } catch (error) {
    localStorage.setItem('network_route', 'internal'); // هماهنگی با وضعیت سناریوی امن
  }
}

از طریق این مکانیزم، مرورگر کاربر (حتی با وجود فعال بودن VPN) به محض تشخیص اینکه مسیر کلاستر داخلی پایدارتر و سریع‌تر است، ترافیک APIها را به صورت داینامیک مدیریت می‌کند.

مرحله چهارم: پیاده‌سازی مکانیزم قطع‌کننده اضطراری (Circuit Breaker)

در شرایط بحرانی که دسترسی به اینترنت بین‌الملل به طور کامل قطع می‌شود، سیستم نباید در چرخه جستجوی سرورهای خارجی معطل بماند.

کلاستر کوبرنتیز پلتفرم در دیتاسنتر داخلی به صورت کاملاً مستقل (Self-Sustaining) پیکربندی شده است. لایه مانیتورینگ بیرونی با رصد مداوم پکت‌لاستِ گیت‌وی‌های بین‌المللی، به محض تشخیص قطعیِ شبکه، یک فرمان Circuit Breaker صادر می‌کند. در این وضعیت، لایه Geo-Routing به طور موقت بای‌پاس شده و ۱۰۰ درصد ترافیک دامنه‌ها روی نودهای هم‌روش قفل می‌شود تا پایداری بیزنس برای کاربران داخل کشور حفظ شود. پس از پایداری مجدد شبکه، سیستم به طور خودکار به حالت ترکیبی (Hybrid) بازمی‌گردد.

جمع‌بندی

طراحی زیرساخت در شرایط خاص شبکه، نیازمند عبور از الگوهای استاندارد و یکپارچه جهانی است. ما در Wishwork با تلفیق داکرایزیشن ماژولار، مدیریت Geo-DNS و هوشمندسازی لایه کلاینت، توانسته‌ایم پایداری بیزنس و سئو را به طور همزمان حفظ کنیم.