چرا ریزسرویس ها ممکن است با بازگشت یکپارچه با انتقام تمام شوند

در اوایل دهه 2010، زم، که شرکت های فناوری محدودیت های معماری های یکپارچه را تشخیص دادند، حرکت به سمت میکروسرویس ها آغاز شد. با این حال، بسیاری از شرکت ها مانند Amazon (Prime Video)، Invision، Istio و Segment در حال بازگشت به معماری های یکپارچه هستند. این مقاله به بررسی این موضوع می پردازد که چرا بسیاری از سازمان ها هنگام انتقال به معماری میکروسرویس ش،ت می خورند.

یکپارچه چیست؟

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

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

چرا میکروسرویس؟

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

واقعیت

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

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

مرزهای دامنه نادرست

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

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

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

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

داده ها و عملکرد عمیقاً همراه

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

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

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

انتقال داده ها

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

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

نتیجه گیری

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

سوپریا لال رهبر فناوری گروه برای سازمان پلتفرم تجارت در است فریاد زدن.