سلام مجدد!.. در آستانه شروع دوره ترجمه مفید دیگری را آماده کرده ایم.
مش سرویس یک لایه زیرساخت قابل تنظیم و با تأخیر کم است که برای رسیدگی به حجم زیادی از ارتباطات بین فرآیندی مبتنی بر شبکه بین رابط های برنامه نویسی برنامه (API) مورد نیاز است. Service Mesh ارتباط سریع، قابل اعتماد و ایمن را بین سرویس‌های زیرساخت کاربردی کانتینری و اغلب زودگذر ممکن می‌سازد. Service Mesh قابلیت هایی مانند کشف سرویس، تعادل بار، رمزگذاری، شفافیت، قابلیت ردیابی، احراز هویت و مجوز، و پشتیبانی از الگوی خاموش شدن خودکار را ارائه می دهد.قطع کننده مدار).
یک سرویس مش معمولاً با ارائه هر نمونه سرویس با یک نمونه پراکسی به نام اجرا می شود جانبی. جانبی ارتباطات بین سرویس‌ها را مدیریت می‌کند، مسائل امنیتی را نظارت و حل می‌کند، یعنی همه چیزهایی که می‌توان از خدمات فردی انتزاع کرد. به این ترتیب، توسعه‌دهندگان می‌توانند کد برنامه را در سرویس‌ها بنویسند، نگهداری کنند و ارائه دهند و مدیران سیستم می‌توانند با Service Mesh کار کرده و برنامه را اجرا کنند.
Istio از گوگل، IBM و Lyft در حال حاضر معروف ترین معماری مش خدمات است. و Kubernetes، که در ابتدا در گوگل توسعه داده شد، اکنون تنها چارچوب ارکستراسیون کانتینری است که توسط ایستیو پشتیبانی می شود. فروشندگان در تلاشند تا نسخه های تجاری ایستیو را ایجاد کنند. جالب خواهد بود که ببینیم چه چیزهای جدیدی را می توانند به پروژه منبع باز بیاورند.
با این حال، Istio تنها گزینه نیست زیرا سایر پیاده سازی های Service Mesh در حال توسعه هستند. الگو sidecar proxy محبوب ترین پیاده سازی است، همانطور که می توان توسط پروژه های Buoyant، HashiCorp، Solo.io و دیگران قضاوت کرد. معماری‌های جایگزینی نیز وجود دارد: جعبه ابزار فناوری Netflix یکی از رویکردهایی است که در آن قابلیت Service Mesh از طریق کتابخانه‌های Ribbon، Hysterix، Eureka، Archaius و همچنین پلتفرم‌هایی مانند Azure Service Fabric پیاده‌سازی می‌شود.
Service Mesh همچنین اصطلاحات خاص خود را برای اجزا و عملکردهای سرویس دارد:
- چارچوب ارکستراسیون کانتینر. همانطور که کانتینرهای بیشتری به زیرساخت برنامه اضافه می شوند، نیاز به یک ابزار جداگانه برای نظارت و مدیریت کانتینرها وجود دارد - یک چارچوب ارکستراسیون کانتینر. Kubernetes محکم این جایگاه را اشغال کرده است، به طوری که حتی رقبای اصلی آن Docker Swarm و Mesosphere DC/OS یکپارچه سازی با Kubernetes را به عنوان جایگزین ارائه می دهند.
- خدمات و موارد (Kubernetes Pods). یک نمونه یک نسخه در حال اجرا از یک میکروسرویس است. گاهی اوقات یک نمونه یک ظرف است. در Kubernetes، یک نمونه از گروه کوچکی از کانتینرهای مستقل به نام pod تشکیل شده است. کلاینت ها به ندرت مستقیماً به یک نمونه یا پاد دسترسی پیدا می کنند؛ بیشتر اوقات، آنها به سرویسی دسترسی دارند که مجموعه ای از نمونه ها یا پادهای یکسان، مقیاس پذیر و مقاوم به خطا (مثنی) است.
- Sidecar Proxy. Sidecar Proxy با یک نمونه یا پاد کار می کند. هدف Sidecar Proxy این است که ترافیک پروکسی را از کانتینری که با آن کار می کند، مسیریابی کند و ترافیک را برگرداند. Sidecar با سایر Sidecar Proxies تعامل دارد و توسط یک چارچوب ارکستراسیون مدیریت می شود. بسیاری از پیاده‌سازی‌های Service Mesh از Sidecar Proxy برای رهگیری و مدیریت کل ترافیک داخل و خارج از یک نمونه یا پاد استفاده می‌کنند.
- کشف خدمات. هنگامی که یک نمونه نیاز به برقراری ارتباط با سرویس دیگری دارد، باید یک نمونه سالم و در دسترس از سرویس دیگر را بیابد (کشف) کند. به طور معمول، نمونه جستجوهای DNS را انجام می دهد. چارچوب ارکستراسیون کانتینر فهرستی از نمونه هایی را که آماده دریافت درخواست هستند نگهداری می کند و یک رابط برای پرس و جوهای DNS فراهم می کند.
- تعادل بار. اکثر چارچوب های ارکستراسیون کانتینر، تعادل بار را در لایه 4 (حمل و نقل) ارائه می کنند. Service Mesh متعادل‌سازی بار پیچیده‌تری را در لایه 7 (سطح برنامه)، غنی از الگوریتم‌ها و موثرتر در مدیریت ترافیک پیاده‌سازی می‌کند. تنظیمات تعادل بار را می توان با استفاده از API تغییر داد و به شما این امکان را می دهد که استقرار آبی-سبز یا قناری را هماهنگ کنید.
- رمزگذاری. Service Mesh می‌تواند درخواست‌ها و پاسخ‌ها را رمزگذاری و رمزگشایی کند و این بار را از دوش سرویس‌ها بردارد. Service Mesh همچنین می‌تواند با اولویت‌بندی یا استفاده مجدد از اتصالات پایدار موجود، عملکرد را بهبود بخشد و نیاز به محاسبات گران قیمت برای ایجاد اتصالات جدید را کاهش دهد. رایج ترین پیاده سازی رمزگذاری ترافیک است TLS متقابل (mTLS)، جایی که یک زیرساخت کلید عمومی (PKI) گواهی ها و کلیدها را برای استفاده توسط Sidecar Proxy تولید و توزیع می کند.
- احراز هویت و مجوز. Service Mesh می‌تواند درخواست‌های خارج یا داخل برنامه را تأیید و تأیید کند و فقط درخواست‌های تأیید شده را به نمونه‌ها ارسال کند.
- پشتیبانی از الگوی خاموش شدن خودکار. سرویس مش پشتیبانی می کند ، که نمونه های ناسالم را جدا می کند و سپس در صورت نیاز به تدریج آنها را به مجموعه نمونه های سالم باز می گرداند.
بخشی از برنامه Service Mesh که ترافیک شبکه بین نمونه ها را مدیریت می کند نامیده می شود صفحه داده. ایجاد و استقرار پیکربندی که رفتار را کنترل می کند صفحه داده، با استفاده از یک جداگانه انجام می شود کنترل هواپیما. کنترل هواپیما معمولاً شامل یا برای اتصال به یک API، CLI یا GUI برای کنترل برنامه طراحی شده است.
صفحه کنترل در Service Mesh پیکربندی را بین Sidecar Proxy و Data Plane توزیع می کند.
معماری سرویس مش اغلب برای حل مشکلات عملیاتی پیچیده با استفاده از کانتینرها و میکروسرویس ها استفاده می شود. پیشگامان در این زمینه شرکت هایی مانند Lyft، Netflix و Twitter هستند که خدمات پایداری را به میلیون ها کاربر در سراسر جهان ارائه می دهند. (). برای برنامه های کاربردی کمتر، معماری های ساده تر احتمالا کافی خواهد بود.
بعید است که معماری Service Mesh هرگز پاسخی برای تمام مسائل مربوط به عملکرد و تحویل برنامه باشد. معماران و توسعه دهندگان زرادخانه عظیمی از ابزارها دارند و تنها یکی از آنها چکش است که در میان بسیاری از کارها، باید تنها یکی را حل کند - چکش زدن میخ. به عنوان مثال، شامل چندین مدل مختلف است که زنجیره ای از رویکردها را برای حل مشکلات با استفاده از میکروسرویس ها ارائه می دهد.
عناصری که در یک معماری Service Mesh گرد هم می آیند، مانند NGINX، کانتینرها، Kubernetes و میکروسرویس ها به عنوان یک رویکرد معماری، می توانند به همان اندازه در پیاده سازی های غیر سرویس مش مفید باشند. به عنوان مثال، ایستیو به عنوان یک معماری مش سرویس کامل طراحی شده است، اما ماژولار بودن آن به این معنی است که توسعه دهندگان می توانند تنها اجزای فناوری مورد نیاز خود را انتخاب و پیاده سازی کنند. با در نظر گرفتن این موضوع، مهم است که درک روشنی از مفهوم Service Mesh ایجاد کنید، حتی اگر مطمئن نیستید که هرگز قادر به پیاده سازی کامل آن در برنامه خود نیستید.
منبع: www.habr.com