نتفلیکس خط لولهٔ Service Topology را بازطراحی کرد تا در مقیاس تولید پایدار بماند: پردازش شبکه در سه مرحلهٔ مجزا، هدایت فشار برگشتی به Kafka به‌جای حذف رکوردها، و جایگزینی gRPC با Server-Sent Events (SSE) برای انتقال‌های داخلی پرحجم.

منابع داده و هدف

Service Topology داده‌ها را از چند منبع ترکیب می‌کند: جریان‌های سطح شبکه حاصل از eBPF، معیارهای ارتباط بین‌فرآیندی (IPC) و ترِیس‌های توزیع‌شده. هر لایه را می‌توان مستقل پرس‌وجو کرد یا برای دست‌یابی به دیدی جامع‌تر ادغام نمود؛ کارکردهای رایج شامل بررسی حادثه، تحلیل دامنهٔ تأثیر و مدیریت تغییر در تولید است.

معماری سه‌مرحله‌ای پردازش شبکه

رکوردهای خام جریان شبکه نشان‌دهندهٔ هاپ‌های شبکه‌اند و لزوماً وابستگی منطقی برنامه‌ها را منعکس نمی‌کنند؛ ترافیک ممکن است از لودبالانسر، درگاه NAT یا پراکسی عبور کند. برای رفع این ناسازگاری، پردازش به سه مرحلهٔ مجزا تقسیم شده است:

  1. مرحلهٔ اول — مصرف و تجمیع اولیه: مصرف جریان‌های Kafka در چند منطقه، پالایش رکوردهای نامعتبر، دسته‌بندی در پنجره‌های پنج‌دقیقه‌ای و ساخت تجمیع‌گرهای اولیه.
  2. مرحلهٔ دوم — حل واسطه‌ها: حذف واسطه‌های شبکه‌ای و تبدیل هاپ‌ها به یال‌های مستقیم برنامه‌به‌برنامه؛ سپس توزیع مجدد نتایج به گره‌های مسئول ادامهٔ پردازش.
  3. مرحلهٔ سوم — غنی‌سازی و ماندگاری: افزودن اطلاعات سلامت، مالکیت و متادیتا به گره‌ها و ذخیره‌سازی نهایی در پایگاه‌دادهٔ گراف برای پرس‌وجو و کاوش زمان واقعی.

اهمیت جداسازی مراحل

در طراحی قبلی، مقصدهای محبوب و واسطه‌ها بار زیادی روی چند نمونه ایجاد می‌کردند و همان نمونه‌ها عملیات غنی‌سازی I/O-سنگین را نیز بر عهده داشتند؛ در نتیجه برخی نمونه‌ها تا صد برابر ترافیک معمول را تجربه می‌کردند. جدا کردن حل واسطه از غنی‌سازی و ماندگاری امکان بازتوزیع بار و کاهش نقاط «داغ» را فراهم کرد و مقیاس‌پذیری را بهبود داد.

معماری سه‌مرحله‌ای Service Topology نتفلیکس

مدیریت فشار برگشتی با Pekko Streams و Kafka

نتفلیکس از Apache Pekko Streams برای مدیریت backpressure استفاده می‌کند. وقتی نوشتن به لایهٔ گراف با تأخیر مواجه می‌شود، سیگنال تقاضا به سمت upstream منتشر و در نهایت مصرف‌کنندهٔ Kafka متوقف (pause) می‌شود؛ رکوردها در Kafka باقی می‌مانند تا ظرفیت بازگردد. رویکرد نتفلیکس این است که تحت بار، تازه‌بودن داده‌ها ممکن است با تأخیر مواجه شود اما هیچ رکوردی حذف نمی‌شود—این رویکرد نسبت به از بین رفتن داده یا تولید نقشه‌های منسوخ مزیت قابل‌توجهی دارد.

مستندات Apache Kafka مرجع مناسبی برای جزئیات پیام‌رسانی و صف‌ها است.

انتخاب Server-Sent Events برای انتقال داخلی

در فشارهای بسیار بالا، سریال‌سازی، مدیریت استخر اتصال و مصرف حافظهٔ پاسخ‌های استریم‌شده در gRPC هزینه‌زا می‌شد. نتفلیکس انتقال داخلی بین مراحل را به Server-Sent Events (SSE) منتقل کرد؛ SSE سبک‌تر است و با الگوی فشار برگشتی واکنشی سازگار عمل می‌کند. این تغییر برای ارتباطات داخلی اعمال شده و API gRPC خارجی برای مشتریان Service Topology همچنان حفظ شده است (gRPC).

مقیاس نامتقارن و هشینگ سازگار

ناوگان پردازشی بر اساس تقاضا رشد و کوچک می‌شود. هر نمونه فهرست نمونه‌های سالم را از رجیستری می‌خواند و با استفاده از هشینگ سازگار مالکیت هر تجمیع‌گر را تعیین می‌کند. وقتی نمونه‌ای اضافه یا حذف می‌شود، تنها تجمیع‌گرهای متأثر منتقل می‌شوند و نیاز به تعادل مجدد سراسری نیست؛ این موضوع جابه‌جایی داده را کاهش و پایداری را افزایش می‌دهد.

پردازش مستقیم IPC

معیارهای IPC از ابتدا تماس‌های سطح برنامه را توصیف می‌کنند و معمولاً پیش‌پارتیشن‌شده برای تجمیع آماده‌اند؛ بنابراین پردازش آن‌ها ساده‌تر و در یک مرحله انجام می‌شود و پیچیدگی ناشی از مسیر شبکه را ندارند.

بازسازی تاریخی مبتنی بر عکس‌های پنجره‌ای

به‌جای نگهداری عکس‌های کامل گراف یا بازپخش تمام لاگ رویدادها، Service Topology از عکس‌های تجمیع‌گر براساس پنجره‌های زمانی و تاریخچهٔ تغییرات ویژگی‌ها استفاده می‌کند. این امکان بازسازی توپولوژی برای یک نقطهٔ زمانی مشخص را فراهم می‌کند تا مهندسان بتوانند تغییرات وابستگی را حول یک حادثه تحلیل کنند، بدون هزینهٔ ذخیره‌سازی و بازپخش کامل رخدادها.

پیامدها برای سازمان‌های بزرگ

  • تفکیک وظایف سنگین به مراحل مستقل نقاط داغ را کاهش می‌دهد و مقیاس‌پذیری را بهبود می‌بخشد.
  • پذیرش backpressure تا لایهٔ پیام‌رسانی از بین رفتن داده‌ها را جلوگیری می‌کند و نقشهٔ بلادرنگ سازگار با ظرفیت سیستم تولید می‌کند.
  • استفاده از پروتکل‌های سبک‌تر مثل SSE برای ارتباطات داخلی می‌تواند هزینه‌های عملیاتی در حجم‌های بالا را کاهش دهد.

این طراحی نشان می‌دهد که در سیستم‌های توزیع‌شدهٔ بزرگ، ترکیب جداسازی منطقی پردازش، مدیریت فشار برگشتی در لایهٔ پیام‌رسانی و انتخاب پروتکل انتقال مناسب، نگهداری نقشه‌های بلادرنگ وابستگی را در سطح تولید قابل‌اطمینان و عملیاتی می‌کند. مهندسین زیرساخت که با نقشه‌برداری وابستگی و پاسخ به حادثه سروکار دارند می‌توانند از این رویکرد برای کاهش نقاط شکست و افزایش دقت تحلیل‌های زمان واقعی الگوبرداری کنند.