Service Mesh: آنچه که هر مهندس نرم افزار باید درباره داغترین فناوری بداند

توجه داشته باشید. ترجمه: سرویس مش پدیده ای است که هنوز ترجمه پایداری به روسی ندارد (بیش از 2 سال پیش گزینه "مش برای خدمات" را ارائه کردیم و کمی بعد ، برخی از همکاران شروع به ترویج فعال ترکیب "غربال سرویس" کردند) . صحبت های مداوم در مورد این فناوری منجر به وضعیتی شده است که در آن بازاریابی و مؤلفه های فنی بسیار در هم تنیده شده اند. این مطالب فوق‌العاده از یکی از نویسندگان اصطلاح اصلی برای شفاف‌سازی مهندسین و نه تنها در نظر گرفته شده است.

کمیک از سباستین کاسرس

معرفی

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

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

در این پست، من سعی خواهم کرد دقیقاً این کار را انجام دهم: یک راهنمای صادقانه، عمیق و مهندس محور برای مش سرویس ارائه کنم. من بیشتر از این سؤال را پاسخ خواهم داد: "آن چیست؟"، - اما همچنین "چرا؟"و "چرا حالا؟". در نهایت، من سعی خواهم کرد توضیح دهم که چرا (به نظر من) این فناوری خاص باعث ایجاد چنین تبلیغات دیوانه کننده ای شده است که خود داستان جالبی است.

چه کسی؟

سلام به همه! اسم من هست ویلیام مورگان. من یکی از سازندگان هستم لینکرد - اولین پروژه مش خدمات و پروژه ای که مقصر ظاهر این اصطلاح است مش سرویس به این ترتیب (ببخشید بچه ها!). (ترجمه یادداشت: اتفاقاً در ابتدای ظهور این اصطلاح، بیش از 2,5 سال پیش، ما قبلاً مطالب اولیه همان نویسنده را به نام " ترجمه کردیم.سرویس مش چیست و چرا [برای یک برنامه ابری با میکروسرویس ها] به آن نیاز دارم؟".) من هم رهبری می کنم شناور استارت آپی است که چیزهای جالبی مانند Linkerd و Mesh را ایجاد می کند شیرجه رفتن.

احتمالاً می توانید حدس بزنید که من نظری بسیار جانبدارانه و ذهنی در مورد این موضوع دارم. با این حال، من سعی خواهم کرد سوگیری را به حداقل برسانم (به استثنای یک بخش: "چرا اینقدر در مورد سرویس مش صحبت می شود؟"، - که در آن با این وجود ایده های از پیش تعیین شده خود را به اشتراک خواهم گذاشت). من همچنین تمام تلاش خود را می کنم تا این راهنما تا حد امکان عینی باشد. در مثال‌های خاص، من عمدتاً به تجربه Linkerd تکیه می‌کنم، در حالی که به تفاوت‌هایی (در صورت وجود) که در اجرای انواع دیگر سرویس مش می‌دانم اشاره می‌کنم.

خوب، وقت آن است که به سراغ خوراکی ها بروید.

مش سرویس چیست؟

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

این پروکسی چیست؟ این یک پروکسی TCP از دسته "لایه 7 آگاه" است (یعنی "با در نظر گرفتن" لایه هفتم مدل OSI) مانند HAProxy و NGINX. شما می توانید یک پروکسی را به دلخواه انتخاب کنید. Linkerd از یک پراکسی Rust استفاده می کند که نام آن پیچیده نیست پیوند دهنده-پراکسی. ما آن را به طور خاص برای سرویس مش کامپایل کرده ایم. مش های دیگر پروکسی های دیگر را ترجیح می دهند (Envoy یک انتخاب رایج است). با این حال، انتخاب یک پروکسی فقط یک موضوع اجرایی است.

این سرورهای پروکسی چه کاری انجام می دهند؟ بدیهی است که آنها تماس های پراکسی به و از سرویس ها را انجام می دهند (به بیان دقیق، آنها به عنوان پراکسی و معکوس عمل می کنند و تماس های ورودی و خروجی را مدیریت می کنند). و آنها مجموعه ای از ویژگی ها را اجرا می کنند که بر تماس ها تمرکز دارد میان خدمات. این تمرکز روی ترافیک بین سرویس ها چیزی است که یک پروکسی مش سرویس را از مثلاً دروازه های API یا پراکسی های ورودی متمایز می کند (که دومی بر تماس هایی است که از دنیای خارج وارد خوشه می شوند). (توجه داشته باشید. ترجمه: برای مقایسه کنترل کننده های Kubernetes Ingress موجود، که بسیاری از آنها از Envoy قبلاً ذکر شده استفاده می کنند، نگاه کنید به این مقاله.)

بنابراین، ما صفحه داده را کشف کردیم. صفحه کنترل ساده‌تر است: مجموعه‌ای از اجزا است که تمام مکانیک‌هایی را که هواپیمای داده برای کار کردن به روشی هماهنگ به آن نیاز دارد، از جمله کشف سرویس، صدور گواهی TLS، تجمیع معیارها و غیره را فراهم می‌کند. رفتار آن؛ به نوبه خود، صفحه کنترل یک API را فراهم می کند که به شما امکان می دهد رفتار صفحه داده را به طور کلی تغییر داده و ردیابی کنید.

در زیر نموداری از صفحه کنترل و صفحه داده در لینکرد ارائه شده است. همانطور که می بینید، صفحه کنترل شامل چندین مؤلفه مختلف است، از جمله یک نمونه Prometheus که معیارها را از سرورهای پراکسی جمع آوری می کند، و همچنین اجزای دیگری مانند destination (کشف خدمات)، identity (مرجع صدور گواهی، CA) و public-api (نقاط پایانی برای وب و CLI). در مقابل، صفحه داده یک پیوند دهنده-پراکسی ساده در کنار نمونه برنامه است. این فقط یک نمودار منطقی است. در یک استقرار در دنیای واقعی، ممکن است سه کپی از هر جزء صفحه کنترل و صدها یا هزاران پراکسی در صفحه داده داشته باشید.

(جعبه های آبی رنگ در این نمودار نشان دهنده مرزهای غلاف های Kubernetes هستند. می بینید که کانتینرهای دارای پیوند دهنده-پراکسی در یک غلاف با کانتینرهای برنامه قرار دارند. این طرح به عنوان شناخته می شود. ظرف کناری.)

معماری مش سرویس چندین مفهوم مهم دارد. اولاً، از آنجایی که وظیفه یک پروکسی رهگیری تماس‌های بین سرویس‌ها است، مش سرویس تنها زمانی معنا پیدا می‌کند که برنامه شما برای مجموعه‌ای از خدمات ساخته شده باشد. مش می توان با یکپارچه ها استفاده کنید، اما این به وضوح به خاطر یک پروکسی منفرد اضافی است و بعید است که عملکرد آن مورد تقاضا باشد.

پیامد مهم دیگر این است که مش سرویس نیاز دارد بزرگ تعداد پروکسی ها در واقع، Linkerd یک لینکر-پراکسی را به هر نمونه از هر سرویس متصل می‌کند (سایر پیاده‌سازی‌ها یک پروکسی را به هر میزبان/میزبان/VM اضافه می‌کنند. به هر حال این مقدار زیادی است). چنین استفاده فعال از یک پروکسی به خودی خود دارای تعدادی از عوارض اضافی است:

1. پراکسی ها در صفحه داده باید باشند سریع، زیرا برای هر تماس چند تماس با پروکسی وجود دارد: یکی در سمت مشتری، دیگری در سمت سرور.
2. همچنین پروکسی ها باید باشند کم اهمیت и سبک وزن. هر کدام حافظه و منابع CPU را مصرف می کنند و این مصرف به صورت خطی با برنامه افزایش می یابد.
3. برای استقرار و به روز رسانی تعداد زیادی پراکسی به مکانیزمی نیاز دارید. انجام آن به صورت دستی یک گزینه نیست.

به طور کلی، مش سرویس به این شکل است (حداقل از دید پرنده): شما یک دسته از پراکسی های فضای کاربر را مستقر می کنید که با ترافیک داخلی و بین سرویسی "کاری انجام می دهند" و از صفحه کنترل برای نظارت و مدیریت آنها استفاده می کنند.

نوبت به این سوال رسیده است که "چرا؟"

مش سرویس برای چیست؟

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

پاسخ این سوال دو بخش دارد. اول، هزینه‌های تراکنش مرتبط با استقرار این پراکسی‌ها می‌تواند به‌دلیل تغییراتی که در اکوسیستم رخ می‌دهد، به میزان قابل‌توجهی کاهش یابد (در ادامه در این مورد بیشتر توضیح خواهیم داد).

ثانیا، چنین دستگاهی در واقع یک راه عالی برای معرفی منطق اضافی به سیستم است. و نه تنها به این دلیل که بسیاری از ویژگی های جدید را می توان با استفاده از مش سرویس اضافه کرد، بلکه به این دلیل که می توان بدون تداخل با اکوسیستم انجام داد. در واقع، کل مدل مش خدمات مبتنی بر این اصل است: در یک سیستم چند سرویس، مهم نیست که چه باشد انجام می دهند خدمات فردی، ترافیک بین آنها نقطه ایده آل برای افزودن قابلیت است.

به عنوان مثال، در Linkerd (مانند اکثر مش ها) عملکرد عمدتاً بر روی تماس های HTTP، از جمله HTTP/2 و gRPC* متمرکز است. عملکرد بسیار غنی است - می توان آن را به سه کلاس تقسیم کرد:

1. ویژگی های مرتبط قابلیت اطمینان. درخواست های مجدد، مهلت زمانی، رویکرد قناری (تقسیم ترافیک/تغییر مسیر) و غیره را امتحان کنید.
2. ویژگی های مرتبط نظارت بر. تجمیع نرخ موفقیت، تأخیر و حجم درخواست برای هر سرویس یا مقصد جداگانه؛ ساختن نقشه های توپولوژیکی خدمات و غیره
3. ویژگی های مرتبط امنیت. TLS متقابل، کنترل دسترسی و غیره

* از دیدگاه Linkerd، gRPC عملاً هیچ تفاوتی با HTTP/2 ندارد: فقط از protobuf در بار استفاده می‌کند. از نقطه نظر یک توسعه دهنده، این دو چیز، البته، متفاوت هستند.

بسیاری از این مکانیسم ها در سطح درخواست (از این رو "پراکسی L7") عمل می کنند. برای مثال، اگر سرویس Foo یک تماس HTTP به نوار سرویس برقرار کند، پیوند دهنده-پراکسی در سمت Foo می‌تواند به طور هوشمندانه بارگذاری تعادل را انجام دهد و تماس‌ها را از نمونه‌های Foo به Bar بر اساس تأخیر مشاهده‌شده هدایت کند. در صورت لزوم می تواند درخواست را تکرار کند (و اگر ناتوان باشد). او می تواند کد پاسخ و مهلت زمانی و غیره را ضبط کند. به طور مشابه، پیوند دهنده-پراکسی در سمت نوار می‌تواند درخواستی را در صورتی که مجاز نباشد یا از حد درخواست فراتر رود، رد کند. می تواند تاخیر از طرف خود و غیره را برطرف کند.

پروکسی ها می توانند در سطح اتصال نیز "کاری انجام دهند". برای مثال، یک linkerd-proxy در سمت Foo می‌تواند یک اتصال TLS را راه‌اندازی کند، و یک linkerd-proxy در سمت Bar می‌تواند آن را خاتمه دهد، و هر دو طرف می‌توانند گواهی‌های TLS یکدیگر را تأیید کنند*. این نه تنها رمزگذاری بین سرویس‌ها را فراهم می‌کند، بلکه یک راه امن رمزنگاری برای شناسایی سرویس‌ها نیز فراهم می‌کند: Foo and Bar می‌توانند ثابت کنند که همان چیزی هستند که می‌گویند.

* "Friend of a Friend" یعنی گواهی مشتری نیز تایید شده است (TLS متقابل). در TLS "کلاسیک"، برای مثال، بین مرورگر و سرور، گواهینامه تنها یک طرف (سرور) معمولا تایید می شود.

این که آیا آنها در سطح درخواست یا اتصال کار می کنند، مهم است که تأکید کنیم که همه ویژگی های مش خدمات هستند عملیاتی شخصیت. Linkerd قادر به تغییر معنایی بارگذاری نیست، مانند افزودن فیلدها به یک قطعه JSON یا ایجاد تغییرات در یک پروتوباف. بعداً وقتی در مورد ESB و میان افزار صحبت می کنیم در مورد این ویژگی مهم صحبت خواهیم کرد.

این مجموعه ویژگی هایی است که سرویس مش ارائه می دهد. این سوال مطرح می شود: چرا آنها را مستقیماً در برنامه پیاده سازی نمی کنید؟ و اصلاً چرا با یک پروکسی سر و کار داریم؟

چرا مش سرویس ایده خوبی است

در حالی که قابلیت های مش سرویس فریبنده است، ارزش اصلی آن واقعاً در ویژگی ها نیست. در پایان ما می توان آنها را مستقیماً در برنامه پیاده سازی کنید (بعداً خواهیم دید که منشاء مش سرویس این بوده است). برای بیان آن در یک جمله، ارزش مش سرویس برابر است با: عملکردی حیاتی برای اجرای نرم افزار سرور مدرن به شیوه ای سازگار، گسترده، برنامه کاربردی-کد-آگنوستیک ارائه می دهد..

بیایید این پیشنهاد را تحلیل کنیم.

«توابع حیاتی برای اجرای نرم افزار سرور مدرن". اگر در حال ساختن یک برنامه سرور تراکنشی متصل به اینترنت عمومی هستید که درخواست های دنیای خارج را می پذیرد و در مدت کوتاهی به آنها پاسخ می دهد - برای مثال، یک برنامه وب، یک سرور API، و اکثریت قریب به اتفاق دیگر برنامه های کاربردی مدرن - و اگر آن را به عنوان مجموعه ای از خدمات که به طور همزمان با یکدیگر تعامل دارند پیاده سازی کنید و اگر دائماً در حال ارتقاء این نرم افزار هستید، ویژگی های جدید اضافه می کنید و اگر مجبور شدید این سیستم را در هنگام اصلاح در شرایط کار نگه دارید - در این مورد، به شما تبریک می گویم. ، شما در حال ایجاد نرم افزار سرور مدرن هستید. و تمام آن ویژگی های فوق العاده ذکر شده در بالا در واقع برای شما حیاتی است. برنامه باید قابل اعتماد، ایمن باشد و شما باید بتوانید ببینید چه کاری انجام می دهد. این سؤالات است که مش سرویس به حل آنها کمک می کند.

(خوب، اعتقاد من به این که این رویکرد روشی مدرن برای ساختن نرم‌افزار سرور است، در پاراگراف قبلی رخنه کرده است. دیگران ترجیح می‌دهند یکپارچه‌سازی‌ها، «ریزسرویس‌های واکنشی» و چیزهای دیگری را توسعه دهند که تحت تعریف بالا قرار نمی‌گیرند. این افراد احتمالاً نظر دارند. که با من متفاوت است، و به نوبه خود، من معتقدم که آنها "اشتباه" هستند - اگرچه در هر صورت، مش سرویس برای آنها خیلی مفید نیست).

«یکنواخت برای کل پشته". ویژگی های ارائه شده توسط مش سرویس فقط حیاتی نیستند. آنها بدون توجه به اینکه به چه زبانی نوشته شده‌اند، از چه چارچوبی استفاده می‌کنند، چه کسی آنها را نوشته است، چگونه به کار گرفته شده‌اند، و همه ظرافت‌های دیگر توسعه و استفاده از آن‌ها، برای همه سرویس‌های یک برنامه کاربردی اعمال می‌شوند.

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

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

و تنها کاری که باید انجام دهید این است که یک دسته پروکسی اضافه کنید! من قول می دهم که به زودی هزینه های عملیاتی مربوط به اضافه کردن این پروکسی ها را بررسی خواهیم کرد. اما ابتدا اجازه دهید بایستیم و به این ایده استقلال از منظر افراد مختلف نگاه کنیم مردم.

سرویس مش به چه کسی کمک می کند؟

هر چقدر هم که ناخوشایند باشد، برای اینکه یک فناوری به بخش مهمی از اکوسیستم تبدیل شود، باید توسط مردم پذیرفته شود. پس چه کسی به مش سرویس علاقه مند است؟ چه کسی از استفاده آن سود می برد؟

اگر نرم افزار سرور مدرن را توسعه دهید، تقریباً می توانید تیم خود را به عنوان یک گروه تصور کنید صاحبان خدماتکه با هم منطق تجاری را توسعه و پیاده سازی می کنند، و صاحبان پلت فرمدر توسعه پلتفرم داخلی که این خدمات بر روی آن اجرا می شوند، نقش دارند. در سازمان‌های کوچک، این افراد می‌توانند همان افراد باشند، اما با رشد شرکت، این نقش‌ها برجسته‌تر می‌شوند و حتی به نقش‌های فرعی تقسیم می‌شوند... (در اینجا چیزهای زیادی درباره تغییر ماهیت devops وجود دارد، تأثیر سازمانی ریزسرویس‌ها و غیره).

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

صاحبان خدمات نیز سود می برند، البته به روشی غیرمستقیم تر. هدف صاحب خدمات این است که در اجرای منطق فرآیند کسب و کار تا حد امکان بهره وری داشته باشد و هر چه کمتر نگران مسائل عملیاتی باشد، بهتر است. آنها می توانند به جای اجرای، مثلاً، سیاست های مجدد یا TLS، فقط روی کسب و کار تمرکز کنند و امیدوار باشند که پلتفرم از بقیه مراقبت کند. برای آنها این یک مزیت بزرگ است.

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

ما این درس را زمانی یاد گرفتیم که یکی از طرفداران اولیه Linkerd به ما گفت که چرا سرویس مش را انتخاب کردند: زیرا این امکان را به آنها می داد تا "به حداقل ممکن صحبت کنند." در اینجا برخی جزئیات وجود دارد: بچه های یک شرکت بزرگ پلت فرم خود را به Kubernetes مهاجرت کردند. از آنجایی که برنامه با اطلاعات حساس کار می کرد، آنها می خواستند تمام ارتباطات موجود در خوشه ها را رمزگذاری کنند. با این حال، وضعیت با حضور صدها سرویس و صدها تیم توسعه پیچیده شد. چشم انداز تماس با همه و متقاعد کردن آنها برای گنجاندن پشتیبانی از TLS در برنامه های خود به هیچ وجه آنها را خوشحال نکرد. با نصب لینکرد مهاجرت کردند مسئوليت از توسعه دهندگان (از نظر آنها دردسر غیرضروری بود) تا پلتفرمرها، که برای آنها این یک اولویت در سطح بالا بود. به عبارت دیگر، لینکرد برای آنها نه چندان مشکل فنی که یک مشکل سازمانی را حل می کرد.

به طور خلاصه، مش سرویس، بلکه یک راه حل فنی نیست، اما اجتماعی و فنی چالش ها و مسائل. (متشکرم سیندی سریدهان برای معرفی این اصطلاح

آیا مش سرویس تمام مشکلات من را حل می کند؟

آره. منظورم نه است!

با نگاهی به سه دسته از ویژگی های ذکر شده در بالا - قابلیت اطمینان، امنیت و قابلیت مشاهده - مشخص می شود که مش سرویس راه حل کاملی برای هیچ یک از این مشکلات نیست. اگرچه Linkerd می‌تواند درخواست‌های مکرر ارسال کند (اگر می‌داند که این درخواست‌ها بی‌قدرت هستند)، در موقعیتی نیست که تصمیم بگیرد که در صورت از بین رفتن سرویس، چه چیزی را به کاربر بازگرداند - چنین تصمیم‌هایی باید توسط اپلیکیشن گرفته شود. Linkerd می‌تواند آمار درخواست‌های موفقیت‌آمیز را حفظ کند، اما قادر به بررسی سرویس و ارائه معیارهای داخلی آن نیست - یک برنامه باید چنین جعبه ابزاری داشته باشد. و در حالی که Linkerd قادر به میزبانی mTLS است، راه حل های امنیتی تمام عیار به موارد بیشتری نیاز دارند.

زیرمجموعه ای از ویژگی های ارائه شده در این مناطق توسط سرویس مش مربوط به ویژگی های پلت فرم. منظور من توابعی است که:

1. مستقل از منطق تجاری. روشی که در آن هیستوگرام های فراخوانی بین Foo و Bar ساخته می شوند کاملاً مستقل از این است چرا Foo با بار تماس می گیرد.
2. اجرای صحیح مشکل است. در Linkerd، تلاش‌های مجدد با انواع چیزهای فانتزی مانند بودجه‌های تلاش مجدد پارامتربندی می‌شوند. (دوباره بودجه ها را امتحان کنید)از آنجایی که رویکرد ساده‌اندیشی در اجرای چنین مواردی قطعاً منجر به ظهور بهمنی از درخواست‌ها می‌شود. (تلاش مجدد طوفان) و سایر مشکلات خاص سیستم های توزیع شده.
3. زمانی موثرتر است که به طور مداوم استفاده شود. مکانیسم TLS تنها زمانی معنا دارد که در همه جا اعمال شود.

از آنجایی که این ویژگی‌ها در لایه پروکسی (و نه در لایه برنامه) پیاده‌سازی می‌شوند، مش سرویس آنها را در لایه نشان می‌دهد. سیستم عامل ها، نه برنامه های کاربردی بنابراین، مهم نیست که سرویس ها به چه زبانی نوشته شده اند، از چه چارچوبی استفاده می کنند، چه کسی آنها را نوشته و چرا. پروکسی ها فراتر از همه این جزئیات کار می کنند و اساس اساسی این عملکرد، از جمله وظایف پیکربندی، به روز رسانی، عملیات، نگهداری و غیره، صرفاً در سطح پلت فرم قرار دارد.

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

به طور خلاصه، مش سرویس راه حل کاملی برای قابلیت اطمینان، قابلیت مشاهده یا امنیت نیست. دامنه این حوزه ها مستلزم مشارکت اجباری صاحبان خدمات، تیم های Ops / SRE و سایر سهامداران شرکت است. مش سرویس فقط یک "برش" در سطح پلت فرم برای هر یک از این مناطق فراهم می کند.

چرا سرویس مش در حال حاضر محبوب شده است؟

احتمالاً در حال حاضر از خود می پرسید: خوب، اگر مش سرویس آنقدر خوب است، چرا ده سال پیش شروع به استقرار میلیون ها پراکسی روی پشته نکردیم؟

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

البته، اگرچه ده سال پیش شرکت‌هایی وجود داشتند که از میکروسرویس‌ها بهره‌برداری می‌کردند، اما در هر کجا که می‌توانستند پروکسی‌ها را برای ایجاد یک شبکه خدماتی نچسبانند. با این حال، اگر دقت کنید، آن‌ها کاری مشابه انجام دادند: بسیاری از این شرکت‌ها استفاده از یک کتابخانه داخلی ویژه را برای شبکه‌سازی اجباری کردند (که گاهی اوقات به نام کتابخانه fat Client، کتابخانه مشتری چربی).

نتفلیکس هیستریکس داشت، گوگل استابی داشت، توییتر کتابخانه فیناگل را داشت. به عنوان مثال، Finagle برای هر سرویس جدید در توییتر اجباری شده است. هر دو سمت کلاینت و سرور اتصالات را مدیریت می کرد، درخواست های مکرر را امکان پذیر می کرد، از مسیریابی درخواست، تعادل بار و اندازه گیری پشتیبانی می کرد. این یک لایه ثابت از قابلیت اطمینان و مشاهده در کل پشته توییتر، بدون توجه به آنچه سرویس انجام می‌داد، ارائه می‌کرد. البته فقط برای زبان های JVM کار می کرد و بر اساس یک مدل برنامه نویسی بود که باید برای کل برنامه استفاده می شد. با این حال، عملکرد آن تقریباً مشابه مش سرویس بود. (در واقع، اولین نسخه Linkerd فقط Finagle بود که به صورت پروکسی پیچیده شده بود.)

بنابراین، ده سال پیش نه تنها میکروسرویس‌ها، بلکه کتابخانه‌های مشبک-سرویس ویژه نیز وجود داشتند که همان مشکلاتی را که سرویس مش امروزی حل می‌کند، حل می‌کرد. با این حال، خود مش سرویس در آن زمان وجود نداشت. قبل از اینکه او ظاهر شود باید تغییر دیگری ایجاد می شد.

و اینجاست که پاسخ عمیق‌تر نهفته است که در تغییر دیگری که در 10 سال گذشته رخ داده است پنهان شده است: کاهش شدید هزینه‌های استقرار میکروسرویس‌ها. شرکت‌هایی که در بالا ذکر شد و یک دهه پیش از میکروسرویس‌ها استفاده می‌کردند - توییتر، نتفلیکس، فیس‌بوک، گوگل - شرکت‌هایی در مقیاس عظیم و منابع عظیم بودند. آنها نه تنها نیاز، بلکه توانایی ساخت، استقرار و اجرای برنامه های کاربردی بزرگ را بر اساس میکروسرویس ها داشتند. انرژی و تلاشی که مهندسان توییتر برای حرکت از رویکرد یکپارچه به ریزسرویس انجام داده‌اند شگفت‌انگیز است. (راستش، همانطور که کار می کرد.) این نوع مانور زیرساخت در آن زمان برای شرکت های کوچکتر غیرممکن بود.

به زمان حال برویم. امروزه استارت آپ هایی وجود دارند که نسبت میکروسرویس ها به توسعه دهندگان 5:1 (یا حتی) است 10:1، و علاوه بر این، آنها با موفقیت با آنها کنار می آیند! اگر یک استارت‌آپ 5 نفره بتواند 50 میکروسرویس را بدون زحمت راه‌اندازی کند، چیزی به وضوح هزینه اجرای آنها را کاهش می‌دهد.

1500 میکروسرویس در مونزو؛ هر خط یک قانون شبکه تجویز شده است که به ترافیک اجازه می دهد

کاهش چشمگیر هزینه های میکروسرویس ها نتیجه یک فرآیند واحد است: محبوبیت روزافزون کانتینرها и ارکستراتورها. این دقیقاً پاسخ عمیق به این سؤال است که چه چیزی به ظهور مش خدمات کمک کرد. همین فناوری هم سرویس مش و هم میکروسرویس ها را جذاب کرد: Kubernetes و Docker.

چرا؟ خوب، داکر یک مشکل بزرگ را حل می کند - مشکل بسته بندی. با بسته بندی یک برنامه و وابستگی های زمان اجرا (غیر شبکه ای) آن در یک کانتینر، Docker برنامه را به یک واحد قابل تعویض تبدیل می کند که می تواند میزبانی شود و در هر مکانی اجرا شود. در عین حال، عملیات را تا حد زیادی ساده می کند. چند زبانه پشته: از آنجایی که یک کانتینر یک واحد اجرای اتمی است، برای اهداف استقرار و عملیاتی، مهم نیست که چه چیزی در داخل آن وجود دارد، خواه یک برنامه JVM، Node، Go، Python یا Ruby باشد. شما فقط آن را اجرا کنید و تمام.

Kubernetes همه چیز را به سطح بعدی می برد. اکنون که مجموعه‌ای از "چیزهای قابل اجرا" و ماشین‌های زیادی برای اجرای آنها وجود دارد، نیاز به ابزاری وجود دارد که بتواند آنها را با یکدیگر مطابقت دهد. در یک مفهوم گسترده، شما به کوبرنتس کانتینرهای زیادی و ماشین‌های زیادی می‌دهید، و آنها را با یکدیگر مطابقت می‌دهد (البته، این یک فرآیند پویا و دائماً در حال تغییر است: کانتینرهای جدید در اطراف سیستم حرکت می‌کنند، ماشین‌ها شروع به کار می‌کنند و متوقف می‌شوند، و غیره. Kubernetes همه اینها را در نظر می گیرد).

زمانی که Kubernetes راه اندازی شد، زمان لازم برای استقرار و راه اندازی یک سرویس با هزینه استقرار و اجرای ده سرویس تفاوت چندانی ندارد (در واقع، تقریباً برای 100 سرویس یکسان است). به این ظروف به عنوان مکانیزم بسته‌بندی که اجرای چند زبانه را تشویق می‌کند، اضافه کنید، و تعداد زیادی برنامه کاربردی جدید به‌عنوان میکروسرویس‌هایی که به زبان‌های مختلف نوشته شده‌اند، پیاده‌سازی می‌شوند، دقیقاً همان محیطی که مش سرویس به خوبی برای آن مناسب است.

بنابراین، به پاسخ این سوال می رسیم که چرا ایده مش سرویس در حال حاضر رایج شده است: یکنواختی که Kubernetes برای خدمات ارائه می دهد مستقیماً برای وظایف عملیاتی پیش روی سرویس مش قابل اجرا است. شما پراکسی ها را در ظروف بسته بندی می کنید، به Kubernetes این وظیفه را می دهید که آنها را تا جایی که ممکن است بچسبانند، و voila! در نتیجه، یک مش سرویس دریافت می کنید، در حالی که Kubernetes تمام مکانیک های استقرار آن را کنترل می کند. (حداقل از دید پرنده. البته، تفاوت های ظریف زیادی در این فرآیند وجود دارد.)

به طور خلاصه: دلیل محبوبیت مش سرویس در حال حاضر و نه ده سال پیش این است که Kubernetes و Docker نه تنها به طور قابل توجهی افزایش یافته اند. نیاز داشتن در آن، اجرای برنامه‌های کاربردی به عنوان مجموعه‌ای از ریزسرویس‌های چند زبانه را ساده می‌کند، اما همچنین به میزان قابل توجهی کاهش می‌یابد. هزینه ها برای عملکرد آن با ارائه مکانیسم هایی برای استقرار و نگهداری پارک های پروکسی سایدکار.

چرا اینقدر در مورد سرویس مش صحبت می شود؟

هشدار: در این بخش به انواع فرضیات، حدس ها، ساختگی ها و اطلاعات داخلی متوسل می شوم.

با جستجوی «مش خدمات»، مجموعه‌ای از محتوای بازیافتی، کم کالری، پروژه‌های عجیب و غریب، و کالیدوسکوپی از اعوجاج که ارزش یک محفظه پژواک را دارد، پیدا می‌کند. هر فناوری جدید مرسوم، مد روز این را دارد، اما در مورد مش سرویس، مشکل به ویژه حاد است. چرا؟

خب تا حدودی تقصیر منه من تمام تلاش خود را برای تبلیغ Linkerd و سرویس مش در هر فرصتی از طریق پست های وبلاگ و مقالات بی شماری مانند این انجام داده ام. اما من آنقدر قدرتمند نیستم. برای پاسخ واقعی به این سوال، باید کمی در مورد وضعیت کلی صحبت کنیم. و نمی توان بدون ذکر یک پروژه در مورد آن صحبت کرد: ایستیو یک مش سرویس منبع باز است که به طور مشترک توسط Google، IBM و Lyft توسعه یافته است.

(این سه شرکت نقش‌های بسیار متفاوتی دارند: به نظر می‌رسد مشارکت Lyft فقط به نام محدود می‌شود؛ آنها Envoy را می‌نویسند اما از توسعه ایستیو استفاده نمی‌کنند یا در آن مشارکت دارند. IBM در توسعه Istio شرکت دارد و از آن استفاده می‌کند. گوگل به شدت از آن استفاده می‌کند. در توسعه Istio نقش داشته است، اما تا آنجا که می توانم بگویم، در واقع از آن استفاده نمی کند.)

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

(در عمل، به نظر می رسد ایستیو نه تنها از نظر پیچیدگی و UX، بلکه با عملکرد نیز مشکل دارد. به عنوان مثال، در طول ارزیابی عملکرد لینکردکه توسط شخص ثالث انجام شد، کارشناسان موقعیت‌هایی را یافتند که در آن تأخیر دنباله ایستیو 100 برابر بیشتر از لینکرد بود، و همچنین موقعیت‌هایی با کمبود منابع، زمانی که لینکرد با موفقیت به کار خود ادامه داد و ایستیو کاملاً از کار افتاد.

با کنار گذاشتن نظریات من در مورد اینکه چرا این اتفاق افتاد، من معتقدم که تبلیغات غیرمقیاس در مورد مش خدمات به دلیل دخالت گوگل است. یعنی ترکیبی از سه عامل زیر:

1. تبلیغ وسواس گونه ایستیو توسط گوگل؛
2. نگرش مخالف و انتقادی مناسب نسبت به پروژه؛
3. محبوبیت سرسام آور اخیر Kubernetes که خاطره آن هنوز تازه است.

این عوامل با هم به نوعی محیط مسموم کننده و بی اکسیژن تبدیل می شوند که در آن ظرفیت قضاوت عقلانی ضعیف می شود و تنها تنوع شگفت انگیزی باقی می ماند. شیدایی لاله.

از دیدگاه لینکرد، این ... من آن را به عنوان یک نعمت ترکیبی توصیف می کنم. منظورم این است که خیلی خوب است که مش سرویس وارد جریان اصلی شده است - که در سال 2016 زمانی که لینکرد برای اولین بار ظاهر شد اینطور نبود و جلب توجه مردم به پروژه واقعاً دشوار بود. الان همچین مشکلی نیست! اما خبر بد این است که وضعیت سرویس مش امروزه به قدری گیج کننده است که تقریباً غیرممکن است که بفهمیم کدام پروژه ها واقعاً در دسته سرویس مش قرار دارند (چه رسد به اینکه بفهمیم کدام یک برای یک مورد استفاده خاص بهترین است). این مطمئناً مانع همه افراد می شود (و قطعاً در برخی موارد Istio یا پروژه دیگری بهتر از Linkerd است، زیرا دومی یک راه حل یکسان نیست).

از طرف Linkerd، استراتژی ما نادیده گرفتن سر و صدا، تمرکز بر حل مشکلات واقعی در جامعه و اساساً منتظر ماندن برای از بین رفتن هیاهو بوده است. در نهایت هیاهو فروکش خواهد کرد و ما می توانیم در آرامش به کار خود ادامه دهیم.

تا آن زمان، همه ما باید صبور باشیم.

آیا مش سرویس برای من یک مهندس نرم افزار متواضع مفید خواهد بود؟

پرسشنامه زیر به پاسخ به این سوال کمک می کند:

آیا شما منحصراً با اجرای منطق تجاری سروکار دارید؟ در این صورت مش سرویس برای شما مفید نخواهد بود. البته ممکن است به آن علاقه داشته باشید، اما در حالت ایده آل، مش سرویس نباید مستقیماً بر هیچ چیز در محیط شما تأثیر بگذارد. به کار روی چیزی که برای آن پول می گیرید ادامه دهید.

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

آیا شما پلتفرمی را برای شرکتی اجرا می کنید که از Kubernetes استفاده نمی کند اما از میکروسرویس ها استفاده می کند؟ در این صورت مش سرویس برای شما مفید خواهد بود اما استفاده از آن بی اهمیت خواهد بود. البته که می توانی تقلید کنید سرویس مش با میزبانی یک دسته از پراکسی ها، اما مزیت مهم Kubernetes دقیقاً مدل استقرار است: نگهداری دستی این پراکسی ها به زمان، تلاش و هزینه بسیار بیشتری نیاز دارد.

آیا شما مسئول پلتفرم شرکتی هستید که با مونولیت کار می کند؟ در این مورد، احتمالاً نیازی به مش سرویس ندارید. اگر با یکپارچه‌ها (یا حتی مجموعه‌هایی از یکپارچه‌ها) کار می‌کنید که دارای الگوهای تعاملی کاملاً مشخص و به ندرت در حال تغییر هستند، پس مش سرویس چیز زیادی برای ارائه به شما ندارد. بنابراین می توانید آن را نادیده بگیرید و امیدوار باشید که مانند یک رویای بد ناپدید شود ...

نتیجه

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

من می خواهم Linkerd را امتحان کنید - نصب آن در یک خوشه Kubernetes (یا حتی Minikube در لپ تاپ) حدود 60 ثانیه طول می کشدو خودتان می توانید ببینید در مورد چه چیزی صحبت می کنم.

پاسخ به برخی سوالات مهم

- اگر مش سرویس را نادیده بگیرم ناپدید می شود؟
- من باید شما را ناامید کنم: مش خدمات برای مدت طولانی با ما است.

- اما من نمی خواهم از مش سرویس استفاده کنم!
- خب لازم نیست! فقط پرسشنامه من را در بالا بخوانید تا ببینید آیا حداقل باید با اصول اولیه آن آشنا شوید یا خیر.

- آیا ESB/middleware خوب قدیمی با سس جدید نیست؟
- سرویس مش با منطق عملیاتی سروکار دارد نه معنایی. این عیب اصلی بود اتوبوس خدمات سازمانی (اتحادیه اروپا). حفظ این جداسازی به مش سرویس کمک می کند تا از سرنوشت مشابه جلوگیری کند.

- مش سرویس چه تفاوتی با دروازه های API دارد؟
میلیون ها مقاله در این زمینه وجود دارد. فقط گوگل کنید

آیا Envoy یک مش سرویس است؟
- نه، Envoy یک سرویس مش نیست، یک سرور پروکسی است. می توان از آن برای سازماندهی یک مش سرویس استفاده کرد (و خیلی بیشتر - این یک پروکسی با هدف عمومی است). اما به خودی خود یک مش سرویس نیست.

- مش سرویس شبکه - مش سرویس است؟
- نه با وجود نام، این یک مش خدمات نیست (شگفت‌های بازاریابی را چگونه دوست دارید؟).

- آیا مش سرویس به سیستم ناهمزمان واکنشی من بر اساس صف پیام کمک خواهد کرد؟
- نه، مش سرویس به شما کمکی نمی کند.

- از کدام سرویس مش استفاده کنم؟
- لینکرد، بدون متفکر

- مقاله بد است! / نویسنده - روی صابون!
— لطفا لینک آن را با همه دوستان خود به اشتراک بگذارید تا آنها در این مورد متقاعد شوند!

تقدیر و تشکر

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

در حالی که من دوست دارم خود را "توسعه دهنده لینکرد" بنامم، واقعیت این است که من بیشتر نگهدارنده فایل README.md در یک پروژه هستم. امروز روی Linkerd کار می کنم بسیار, بسیار, بسیار много مردم، و این پروژه بدون جامعه شگفت انگیز مشارکت کنندگان و کاربران امکان پذیر نبود.

و در نهایت تشکر ویژه از خالق لینکرد الیور گولد (primus inter pares)، که سالها پیش همراه من، با سر در این همه هیاهو با مش سرویس شیرجه زد.

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «سرویس مش چیست و چرا [برای یک برنامه ابری با میکروسرویس ها] به آن نیاز دارم؟"؛
• «Traefik 2.0: به روز رسانی مش سرویس با پشتیبانی از TCP و رابط وب جدید"؛
• «Maesh - یک مش سرویس ساده جدید برای Kubernetes از نویسندگان Traefik"؛
• «بازگشت به میکروسرویس ها با ایستیو. قسمت 1"؛
• «لوله - مش سرویس سبک وزن برای Kubernetes'.

منبع: www.habr.com