هی هابر! ترجمه مقاله را مورد توجه شما قرار می دهم "صفحه داده مش سرویس در مقابل صفحه کنترل" نویسنده مت کلین.

این بار، من شرح هر دو بخش مش سرویس، صفحه داده و صفحه کنترل را "خواستم و ترجمه کردم". این توصیف برای من قابل درک ترین و جالب ترین به نظر می رسید و مهمتر از همه منجر به درک "آیا اصلاً لازم است؟"

از آنجایی که ایده "خدمات مش" در دو سال گذشته به طور فزاینده ای محبوب شده است (مقاله اصلی 10 اکتبر 2017) و تعداد شرکت کنندگان در این فضا افزایش یافته است، من شاهد افزایش متناسبی در سردرگمی در بین کل افراد بوده ام. جامعه فناوری در مورد نحوه مقایسه و مقایسه راه حل های مختلف.

این وضعیت با مجموعه توییت‌هایی که در ماه جولای نوشتم به بهترین شکل خلاصه می‌شود:

سردرگمی مش سرویس شماره 1: Linkerd ~ = Nginx ~ = Haproxy ~ = فرستاده. هیچ کدام با ایستیو برابری نمی کنند. ایستیو چیزی کاملا متفاوت است. 1 /

اولی ها به سادگی صفحات داده هستند. خودشون هیچ کاری نمیکنن آنها باید در حال و هوای چیزی بیشتر باشند. 2/

ایستیو نمونه ای از صفحه کنترلی است که قطعات را به هم متصل می کند. این یک لایه دیگر است. /پایان

توییت‌های قبلی چندین پروژه مختلف (Linkerd، NGINX، HAProxy، Envoy و Istio) را ذکر می‌کنند، اما مهم‌تر از آن مفاهیم کلی داده‌ها، مش سرویس و صفحه کنترل را معرفی می‌کنند. در این پست، من یک قدم به عقب برمی‌گردم و در مورد منظورم از اصطلاحات "صفحه داده" و "صفحه کنترل" در سطح بسیار بالایی صحبت می‌کنم و سپس در مورد نحوه اعمال این شرایط برای پروژه‌های ذکر شده در توییت‌ها صحبت می‌کنم.

واقعا مش سرویس چیست؟

شکل 1: نمای کلی مش سرویس

شکل 1 مفهوم مش سرویس را در ابتدایی ترین سطح آن نشان می دهد. چهار خوشه خدمات (AD) وجود دارد. هر نمونه سرویس با یک سرور پروکسی محلی مرتبط است. تمام ترافیک شبکه (HTTP، REST، gRPC، Redis، و غیره) از یک نمونه برنامه از طریق یک پروکسی محلی به خوشه های خدمات خارجی مناسب منتقل می شود. به این ترتیب، نمونه برنامه از کل شبکه بی اطلاع است و فقط از پروکسی محلی آن آگاه است. در واقع، شبکه سیستم توزیع شده از سرویس حذف شد.

صفحه داده

در یک سرویس مش، یک سرور پروکسی که به صورت محلی برای برنامه قرار دارد، وظایف زیر را انجام می دهد:

• کشف خدمات. چه خدمات/برنامه هایی برای برنامه شما موجود است؟
• بررسی سلامت. آیا نمونه های سرویس بازگردانده شده توسط سرویس کشف سالم و آماده پذیرش ترافیک شبکه هستند؟ این می تواند شامل بررسی های سلامت فعال (مثلاً پاسخ/بررسی سلامت) و غیرفعال (مثلاً استفاده از 3 خطای 5xx متوالی به عنوان نشانه ای از وضعیت خدمات ناسالم) باشد.
• مسیریابی. هنگام دریافت درخواست "/foo" از یک سرویس REST، درخواست به کدام خوشه خدمات باید ارسال شود؟
• تعادل بار. هنگامی که یک خوشه سرویس در طول مسیریابی انتخاب شد، درخواست باید به کدام نمونه سرویس ارسال شود؟ با چه تایم اوتی؟ با چه تنظیمات قطع مدار؟ اگر درخواست ناموفق باشد، آیا باید دوباره امتحان شود؟
• احراز هویت و مجوز. برای درخواست‌های دریافتی، آیا می‌توان سرویس تماس را با استفاده از mTLS یا مکانیسم دیگری از نظر رمزنگاری شناسایی/مجاز کرد؟ در صورت شناسایی/مجاز بودن، آیا امکان فراخوانی عملیات درخواستی (نقطه پایانی) در سرویس وجود دارد یا باید یک پاسخ احراز هویت نشده برگردانده شود؟
• قابلیت مشاهده. آمار دقیق، گزارش‌ها/ گزارش‌ها، و داده‌های ردیابی توزیع‌شده باید برای هر درخواست ایجاد شود تا اپراتورها بتوانند جریان ترافیک توزیع شده و مشکلات اشکال‌زدایی را در صورت بروز درک کنند.

صفحه داده مسئول تمام نقاط قبلی در مش سرویس است. در واقع، پراکسی محلی سرویس (sidecar) صفحه داده است. به عبارت دیگر، صفحه داده مسئول پخش، ارسال، و نظارت مشروط بر هر بسته شبکه ای است که به یا از یک سرویس ارسال می شود.

هواپیمای کنترلی

انتزاع شبکه ای که یک پروکسی محلی در صفحه داده ارائه می کند جادویی (؟) است. با این حال، چگونه پروکسی از مسیر "/foo" به سرویس B اطلاع دارد؟ چگونه می توان از داده های کشف سرویس که توسط درخواست های پراکسی پر شده است استفاده کرد؟ چگونه پارامترها برای تعادل بار، تایم اوت، قطع شدن مدار و غیره پیکربندی می شوند؟ چگونه یک برنامه کاربردی را با استفاده از روش آبی/سبز یا روش انتقال ترافیک برازنده اجرا می کنید؟ چه کسی احراز هویت و تنظیمات مجوز در سراسر سیستم را پیکربندی می کند؟

تمامی موارد فوق تحت کنترل صفحه کنترل مش سرویس می باشد. هواپیمای کنترل مجموعه ای از پراکسی های بدون حالت مجزا را می گیرد و آنها را به یک سیستم توزیع شده تبدیل می کند.

من فکر می‌کنم دلیل اینکه بسیاری از فن‌آوران مفاهیم جداگانه صفحه داده و صفحه کنترل را گیج‌کننده می‌دانند این است که برای اکثر مردم صفحه داده آشناست در حالی که صفحه کنترل خارجی/نافهم است. ما مدت زیادی است که با روترها و سوئیچ های شبکه فیزیکی کار می کنیم. ما می دانیم که بسته ها / درخواست ها باید از نقطه A به نقطه B بروند و ما می توانیم از سخت افزار و نرم افزار برای انجام این کار استفاده کنیم. نسل جدید پروکسی‌های نرم‌افزاری، نسخه‌های فانتزی ابزارهایی هستند که ما برای مدت طولانی استفاده می‌کنیم.

شکل 2: هواپیمای کنترل انسانی

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

بر شکل 2 چیزی را نشان می دهد که من آن را "هواپیما کنترل انسانی" می نامم. در این نوع استقرار، که هنوز بسیار رایج است، یک اپراتور انسانی احتمالاً بدخلق پیکربندی‌های ثابت را ایجاد می‌کند - احتمالاً از طریق اسکریپت‌ها - و آنها را از طریق برخی فرآیندهای خاص برای همه پراکسی‌ها مستقر می‌کند. سپس پراکسی ها شروع به استفاده از این پیکربندی کرده و با استفاده از تنظیمات به روز شده پردازش صفحه داده را آغاز می کنند.

شکل 3: صفحه کنترل مش سرویس پیشرفته

بر شکل 3 صفحه کنترل "بسط یافته" مش سرویس را نشان می دهد. از قسمت های زیر تشکیل شده است:

• انسان: هنوز یک نفر (امیدوارم کمتر عصبانی باشد) وجود دارد که تصمیمات سطح بالایی در مورد کل سیستم می گیرد.
• رابط کاربری هواپیما را کنترل کنید: یک فرد برای کنترل سیستم با نوعی از رابط کاربری تعامل دارد. این می تواند یک پورتال وب، یک برنامه خط فرمان (CLI) یا یک رابط دیگر باشد. با استفاده از رابط کاربری، اپراتور به پارامترهای پیکربندی سیستم جهانی مانند:
  • کنترل استقرار، آبی/سبز و/یا انتقال تدریجی ترافیک
  • گزینه های احراز هویت و مجوز
  • مشخصات جدول مسیریابی، برای مثال زمانی که برنامه A اطلاعاتی در مورد "/foo" درخواست می کند که چه اتفاقی می افتد
  • تنظیمات متعادل کننده بار، مانند مهلت زمانی، تلاش مجدد، تنظیمات قطع مدار و غیره.
• زمانبندی بار کاری: سرویس ها بر روی زیرساخت از طریق نوعی سیستم زمان بندی/ارکستراسیون مانند Kubernetes یا Nomad اجرا می شوند. زمانبند مسئول بارگیری سرویس به همراه پروکسی محلی آن است.
• کشف خدمات. زمانی که زمان‌بندی‌کننده نمونه‌های سرویس را شروع و متوقف می‌کند، وضعیت سلامت را به سیستم کشف سرویس گزارش می‌دهد.
• APIهای پیکربندی پراکسی Sidecar : پراکسی های محلی به صورت پویا حالت را از اجزای مختلف سیستم با استفاده از یک مدل در نهایت سازگار بدون دخالت اپراتور استخراج می کنند. کل سیستم، متشکل از تمام نمونه های سرویس در حال اجرا و سرورهای پروکسی محلی، در نهایت به یک اکوسیستم همگرا می شود. API صفحه داده جهانی Envoy نمونه ای از نحوه عملکرد این در عمل است.

اساساً هدف صفحه کنترل تنظیم خط مشی است که در نهایت توسط صفحه داده پذیرفته شود. هواپیماهای کنترلی پیشرفته‌تر، بخش‌های بیشتری از برخی سیستم‌ها را از اپراتور حذف می‌کنند و به عملیات دستی کمتری نیاز دارند، مشروط بر اینکه به درستی کار کنند!...

صفحه داده و صفحه کنترل. خلاصه صفحه داده در مقابل صفحه کنترل

• صفحه داده مش سرویس: بر هر بسته / درخواست در سیستم تأثیر می گذارد. مسئول کشف برنامه/سرویس، بررسی سلامت، مسیریابی، تعادل بار، احراز هویت/مجوز و مشاهده پذیری.
• صفحه کنترل مش سرویس: خط مشی و پیکربندی را برای تمام صفحات داده در حال اجرا در شبکه خدمات ارائه می کند. هیچ بسته / درخواستی را در سیستم لمس نمی کند. صفحه کنترل تمام صفحات داده را به یک سیستم توزیع شده تبدیل می کند.

چشم انداز پروژه فعلی

با درک توضیحات بالا، اجازه دهید به وضعیت فعلی پروژه مش خدمات نگاه کنیم.

• هواپیماهای داده: Linkerd، NGINX، HAProxy، Envoy، Traefik
• هواپیماهای کنترلی: Istio، Nelson، SmartStack

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

Linkerd یکی از اولین سرورهای پراکسی داده پلن برای سرویس مش در اوایل سال 2016 بود و کار فوق العاده ای در افزایش آگاهی و توجه به مدل طراحی مش خدمات انجام داده است. حدود 6 ماه پس از آن، انوی به لینکرد پیوست (اگرچه او از اواخر سال 2015 با Lyft بود). Linkerd و Envoy دو پروژه ای هستند که اغلب در بحث مش های سرویس به آنها اشاره می شود.

ایستیو در ماه می 2017 معرفی شد. اهداف پروژه ایستیو بسیار شبیه به صفحه کنترل توسعه یافته نشان داده شده در آن است شکل 3. Envoy for Istio پروکسی پیش فرض است. بنابراین، ایستیو صفحه کنترل است و Envoy صفحه داده است. در مدت کوتاهی، ایستیو هیجان زیادی ایجاد کرد و سایر هواپیماهای داده به عنوان جایگزینی برای Envoy شروع به ادغام کردند (هم لینکرد و هم NGINX یکپارچگی با ایستیو را نشان دادند). این واقعیت که صفحات داده های مختلف را می توان در یک صفحه کنترل استفاده کرد به این معنی است که صفحه کنترل و صفحه داده لزوماً به طور محکم جفت نمی شوند. API مانند Envoy's generic data plane API می تواند پلی بین دو قسمت از سیستم ایجاد کند.

نلسون و SmartStack به تشریح بیشتر تفکیک صفحه کنترل و صفحه داده کمک می کنند. نلسون از Envoy به عنوان پروکسی خود استفاده می کند و یک صفحه کنترل قابل اعتماد برای مش سرویس بر اساس پشته HashiCorp می سازد، یعنی. عشایر و غیره SmartStack شاید اولین مورد از موج جدیدی از مش های خدماتی بود. SmartStack یک صفحه کنترل در اطراف HAProxy یا NGINX ایجاد می کند، که توانایی جدا کردن صفحه کنترل را از مش سرویس از صفحه داده را نشان می دهد.

معماری میکروسرویس با مش سرویس روز به روز بیشتر مورد توجه قرار می گیرد (به درستی!) و پروژه ها و فروشندگان بیشتری در این راستا شروع به کار می کنند. در چند سال آینده شاهد نوآوری های زیادی در هر دو سطح داده و صفحه کنترل و همچنین ترکیب بیشتر اجزای مختلف خواهیم بود. در نهایت، معماری میکروسرویس باید برای اپراتور شفاف تر و جادویی تر (؟) شود.
امیدوارم کمتر و کمتر عصبانی شود.

خوراکی های کلیدی

• یک سرویس مش از دو بخش مختلف تشکیل شده است: صفحه داده و صفحه کنترل. هر دو جزء مورد نیاز هستند و بدون آنها سیستم کار نخواهد کرد.
• همه با هواپیمای کنترل آشنا هستند و در این مرحله، هواپیمای کنترل می تواند شما باشید!
• همه صفحات داده در ویژگی ها، عملکرد، پیکربندی و توسعه پذیری با یکدیگر رقابت می کنند.
• همه هواپیماهای کنترلی در ویژگی ها، قابلیت پیکربندی، توسعه پذیری و سهولت استفاده با یکدیگر رقابت می کنند.
• یک صفحه کنترل می تواند حاوی انتزاعات و APIهای مناسب باشد تا بتوان از چندین صفحه داده استفاده کرد.

منبع: www.habr.com