چرا ما Enterprise Service Mesh می سازیم؟

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

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

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

در سطح پروکسی (سطح داده):

• تعیین و توزیع خط مشی های مسیریابی و تعادل ترافیک
• توزیع کلید، گواهینامه، توکن
• مجموعه تله متری، تولید معیارهای نظارت
• ادغام با زیرساخت های امنیتی و نظارتی

در سطح صفحه کنترل:

• اعمال سیاست های مسیریابی و تعادل ترافیک
• مدیریت تکرارها و زمان‌بندی‌ها، شناسایی گره‌های «مرده» (شکست مدار)، مدیریت خطاهای تزریق و اطمینان از انعطاف‌پذیری سرویس از طریق مکانیسم‌های دیگر
• احراز هویت/مجوز تماس
• معیارهای کاهش (مشاهده پذیری)

طیف کاربران علاقه مند به توسعه این فناوری بسیار گسترده است - از استارتاپ های کوچک گرفته تا شرکت های اینترنتی بزرگ، به عنوان مثال، PayPal.

چرا سرویس مش در بخش شرکتی مورد نیاز است؟

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

علاوه بر این، Service Mesh ارتباط بین تامین کنندگان و مصرف کنندگان را ساده می کند. امروزه، برای ارائه‌دهندگان و مصرف‌کنندگان API بسیار ساده‌تر است که به تنهایی بر روی رابط‌ها و قراردادها توافق کنند، بدون اینکه یک واسطه و داور یکپارچه‌سازی خاص - گذرگاه خدمات سازمانی، دخالت کنند. این رویکرد به طور قابل توجهی بر دو شاخص تأثیر می گذارد. سرعت ارائه عملکردهای جدید به بازار (زمان به بازار) افزایش می یابد، اما در عین حال هزینه راه حل افزایش می یابد، زیرا یکپارچه سازی باید به طور مستقل انجام شود. استفاده از Service Mesh توسط تیم های توسعه عملکرد تجاری به حفظ تعادل در اینجا کمک می کند. در نتیجه، ارائه دهندگان API می توانند به طور انحصاری بر روی مؤلفه برنامه سرویس خود تمرکز کنند و به سادگی آن را در Service Mesh منتشر کنند - API بلافاصله در دسترس همه مشتریان قرار می گیرد و کیفیت یکپارچه سازی آماده تولید خواهد بود و نیازی به یک واحد ندارد. خط کد اضافی

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

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

لازم به ذکر است که به روز رسانی برنامه های کاربردی توزیع شده در یک محیط مش سرویس آسان تر می شود. به عنوان مثال، یک توسعه آبی/سبز، که در آن دو محیط برنامه برای نصب در دسترس هستند، یکی از آنها به روز نشده و در حالت آماده به کار است. بازگشت به نسخه قبلی در صورت انتشار ناموفق توسط یک روتر خاص انجام می شود که نقش سرویس مش به خوبی با آن مقابله می کند.. برای تست نسخه جدید می توانید استفاده کنید رهاسازی قناری - تنها 10٪ از ترافیک یا درخواست های یک گروه آزمایشی از مشتریان به نسخه جدید تغییر دهید. ترافیک اصلی به نسخه قدیمی می رود، چیزی خراب نمی شود.

همچنین Service Mesh به ما کنترل SLA بلادرنگ می دهد. سیستم پراکسی توزیع شده اجازه نمی دهد که سرویس زمانی که یکی از مشتریان از سهمیه اختصاص داده شده به آن فراتر رود، از کار بیفتد. اگر توان عملیاتی API محدود باشد، هیچ کس نمی تواند آن را با تعداد زیادی تراکنش تحت تأثیر قرار دهد: مش سرویس در جلوی سرویس می ایستد و اجازه ترافیک غیر ضروری را نمی دهد. این به سادگی در لایه ادغام مقابله می کند و خود سرویس ها بدون توجه به آن به کار خود ادامه می دهند.

اگر شرکتی بخواهد هزینه‌های توسعه راه‌حل‌های یکپارچه‌سازی را کاهش دهد، Service Mesh همچنین کمک می‌کند: می‌توانید از محصولات تجاری به نسخه منبع باز آن بروید. Enterprise Service Mesh ما بر اساس نسخه منبع باز Service Mesh است.

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

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

چرا به سفارشی سازی Service Mesh نیاز دارید؟

در شرکت ما، صدها سیستم و ماژول با هم وجود دارند و زمان اجرا بسیار بارگذاری شده است. بنابراین یک الگوی ساده از یک سیستم که سیستم دیگر را فراخوانی می کند و پاسخ دریافت می کند کافی نیست، زیرا در تولید ما بیشتر می خواهیم. چه چیز دیگری از مش سرویس سازمانی نیاز دارید؟

خدمات پردازش رویداد

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

بسیار عجیب است که Remote Procedure Call (RPC) توسط تمام نسخه های Service Mesh پشتیبانی می شود، اما آنها با EDA سازگار نیستند. زیرا Service Mesh نوعی ادغام توزیع شده مدرن است و EDA یک الگوی معماری بسیار مرتبط است که به شما امکان می دهد کارهای منحصر به فردی را از نظر تجربه مشتری انجام دهید.

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

سرویس انتقال فایل

علاوه بر EDA، خوب است که بتوان فایل‌ها را انتقال داد: در مقیاس Enterprise، اغلب تنها یکپارچه‌سازی فایل‌ها امکان‌پذیر است. به طور خاص، از الگوی معماری ETL (Extract, Transform, Load) استفاده می شود. در آن، به عنوان یک قاعده، همه به طور انحصاری فایل ها را مبادله می کنند: از داده های بزرگ استفاده می شود، که انجام درخواست های جداگانه غیرعملی است. توانایی پشتیبانی بومی انتقال فایل در Enterprise Service Mesh به شما انعطاف پذیری مورد نیاز کسب و کارتان را می دهد.

خدمات ارکستراسیون

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

هوش مصنوعی و ML

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

سرویس دروازه API

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

• امنیت. مسائل مربوط به ddos، آسیب پذیری پروتکل ها، برنامه ها، سیستم عامل ها و غیره.
• ترازو. وقتی تعداد APIهایی که باید به مشتریان ارائه شوند به هزاران یا حتی صدها هزار می رسد، نیاز به نوعی ابزار مدیریتی برای این مجموعه از APIها وجود دارد. شما باید دائماً API را زیر نظر داشته باشید: آیا آنها کار می کنند یا نه، وضعیت آنها چگونه است، چه ترافیکی جریان دارد، چه آماری و غیره. یک دروازه API باید این کار را انجام دهد در حالی که کل فرآیند را قابل مدیریت و ایمن می کند. به لطف این مؤلفه، Enterprise Service Mesh یاد می گیرد که به راحتی API های داخلی و خارجی را منتشر کند.

خدمات پشتیبانی برای پروتکل ها و فرمت های داده خاص (دروازه AS)

در حال حاضر، اکثر راه حل های Service Mesh می توانند به صورت بومی فقط با ترافیک HTTP و HTTP2 یا در حالت کاهش یافته در سطح TCP/IP کار کنند. Enterprise Service Mesh با بسیاری از پروتکل های انتقال داده بسیار خاص دیگر در حال ظهور است. برخی از سیستم ها ممکن است از واسطه های پیام استفاده کنند، برخی دیگر در سطح پایگاه داده یکپارچه شده اند. اگر شرکت دارای SAP باشد، می تواند از سیستم یکپارچه سازی خود نیز استفاده کند. علاوه بر این، همه اینها کار می کند و بخش مهمی از تجارت است.

شما نمی توانید فقط بگویید: "بیایید میراث را رها کنیم و سیستم های جدیدی بسازیم که می توانند از Service Mesh استفاده کنند." برای اتصال تمام سیستم های قدیمی با سیستم های جدید (در معماری میکروسرویس)، سیستم هایی که می توانند از Service Mesh استفاده کنند، به نوعی آداپتور، واسطه، دروازه نیاز دارند. موافقم، اگر همراه با سرویس در جعبه باشد، خوب است. دروازه AC می تواند هر گزینه یکپارچه سازی را پشتیبانی کند. فقط تصور کنید، شما فقط Enterprise Service Mesh را نصب می کنید و آماده تعامل با تمام پروتکل های مورد نیاز شما است. این رویکرد برای ما بسیار مهم است.

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

منبع: www.habr.com