با بالغتر شدن معماریهای میکروسرویس، پیچیدگی مدیریت جریان ترافیک در سیستمهای توزیعشده بهطور نمایی افزایش یافته است. برای توسعهدهندگان و مهندسان DevOps با سطح متوسط تا پیشرفته، تعادلبارگذاری چرخشی سنتی دیگر کافی نیست. امروزه ما نیاز به کنترل دقیق بر توزیع ترافیک داریم تا در دسترس بودن بالا را تضمین کنیم، ریسک را در طول استقرار به حداقل برسانیم و تجربه کاربری بدون نقص را حفظ کنیم. در این پست، ما به عمق سه ستون حیاتی طراحی سیستمهای مدرن فرو خواهیم رفت: استقرار کاناری، انتشارات آبی-سبز و کشف سرویس.
گذار از مسیریابی ایستا به پویا
تعادلبارگذارهای سنتی اغلب به فایلهای پیکربندی ایستا یا بررسیهای سلامت ساده متکی هستند. با این حال، در محیطهای ابری بومی مدرن، زیرساخت زودگذر است. پادها میآیند و میروند، IPها به صورت پویا تغییر میکنند و سرویسها به صورت خودکار مقیاسبندی میشوند. این امر نیاز به تغییر به سمت استراتژیهای مسیریابی پویا دارد که بتوانند در زمان واقعی سازگار شوند. با بهرهگیری از قوانین مسیریابی هوشمند، میتوانیم ترافیک را بر اساس هدرها، بخشهای کاربر یا معیارهای تأخیر مسیریابی کنیم، نه فقط بر اساس ظرفیت سرور.
استقرار کاناری: شرط امن
استقرارهای کاناری به شما امکان میدهند نسخه جدیدی از برنامه خود را قبل از انتشار آن در کل ناوگان، در اختیار زیرمجموعهای کوچک از کاربران قرار دهید. این استراتژی شعاع انفجار یک استقرار ناموفق را به حداقل میرساند. اگر نسخه جدید خطاها را نشان دهد، تنها بخش کوچکی از کاربران تحت تأثیر قرار میگیرند که امکان بازگشت سریع را فراهم میکند.
پیادهسازی انتشار کاناری اغلب شامل پیکربندی کنترلکننده ingress یا مش سرویس برای تقسیم ترافیک است. به عنوان مثال، در یک پیکربندی ingress NGINX، ممکن است 90٪ ترافیک را به نسخه پایدار و 10٪ را به کاناری هدایت کنید:
# مثال پیکربندی NGINX Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-stable
port:
number: 80
برای مسیریابی ترافیک خاص به نمونه کاناری، معمولاً باید یک annotation اضافه کنید یا از یک مش سرویس مانند Istio برای تعریف یک VirtualService استفاده کنید که هدرها (به عنوان مثال، x-canary: true) را مطابقت دهد و آن ترافیک را به استقرار کاناری هدایت کند.
انتشارات آبی-سبز: بازگشت فوری
برخلاف استقرارهای کاناری، انتشارات آبی-سبز دو محیط تولید یکسان را حفظ میکنند. در هر زمان، فقط یکی از آنها فعال است («آبی») در حالی که دیگری («سبز») غیرفعال است. وقتی نسخه جدید آماده است، در محیط غیرفعال استقرار مییابد. پس از تکمیل آزمایشها، تعادلبارگذار ترافیک را به صورت آنی از آبی به سبز تغییر میدهد. مزیت اصلی در اینجا توانایی بازگشت فوری در صورت شکست نسخه جدید است، زیرا شما به سادگی ترافیک را به محیط قبلی برمیگردانید.
این استراتژی در طول فاز انتشار به دو برابر منابع زیرساخت نیاز دارد، اما قابلیت بازگشت بدون وقفه و تقریباً آنی را ارائه میدهد که آن را برای برنامههای حیاتی مالی یا بهداشتی ایدهآل میسازد.
کشف سرویس: چسب سیستمهای مدرن
صرفنظر از استراتژی استقرار که انتخاب میکنید، به یک مکانیزم قوی برای یافتن نمونههای در حال اجرای سرویسهای خود نیاز دارید. کشف سرویس ستون فقراتی است که به تعادلبارگذار شما اجازه میدهد ترافیک را به پادهای سالم و در دسترس مسیریابی کند. در محیطهای کانتینری مانند کوبرنیتیز، این کار توسط kube-proxy و CoreDNS انجام میشود که نقاط پایانی سرویس را به طور خودکار ثبت میکنند. برای تنظیمات سفارشی، ابزارهایی مانند Consul یا etcd به عنوان ثبتکننده عمل میکنند.
کشف سرویس مؤطمئن میشود که حتی اگر یک پاد خراب شود یا یک نود شکست بخورد، تعادلبارگذار بلافاصله پاسخهای DNS یا API بهروز شده را دریافت میکند و نقاط پایانی ناسالم را از چرخه خارج میکند. این بررسی سلامت پویا همان چیزی است که به استراتژیهای تقسیم ترافیک پیچیدهای که در بالا ذکر شد اجازه میدهد بدون مداخله انسانی به طور یکپارچه کار کنند.
نتیجهگیری
پیادهسازی استراتژیهای پیشرفته مسیریابی ترافیک فقط درباره استقرار سریعتر کد نیست؛ بلکه درباره استقرار ایمنتر آن است. با ترکیب استقرارهای کاناری برای قرارگیری تدریجی، انتشارات آبی-سبز برای بهروزرسانیهای حیاتی و کشف سرویس قوی برای قابلیت اطمینان، سیستمی میسازید که مقاوم، مقیاسپذیر و قادر به پاسخگویی به تقاضاهای ترافیک وب مدرن باشد. با پیادهسازی تقسیمبندیهای ساده ترافیک در محیط آزمایشی خود شروع کنید و به تدریج سیاستهای مسیریابی خود را با بالغتر شدن زیرساخت خود تکامل دهید.