من همیشه مجذوب استفاده از APIها بوده‌ام. در واقع APIها، وب سرویس‌ها و سیستم‌های توزیع شده (distributed systems) دلیل شروع یادگیری کدنویسی برای من بوده اند. وقتی اولین شغل خود را به عنوان توسعه دهنده‌ی فرانت‌اند جوان (junior) شروع کردم، به استفاده از APIهای محیا شده توسط بکاند نزدیک‌تر شدم. من همیشه به معماری کلاینت-سرور جدا شده (decoupled client-server) علاقه‌مند بودم. وقتی در سال ۲۰۱۷ شروع به خوداشتغالی کردم و کارم را به عنوان مشاور مشتریان شروع کردم، به معماری‌های مربوط به میکروسرویس (microservice)ها بیش از پیش برخوردم. این اتفاق باعث شد که طرز دید من به جداسازی سرویس‌ها از هم وارد مرحله‌ی جدیدی شود.
زمانی‌که در حال کار بر روی پروژه‌های مشتریانم بودم، توانستم نمونه کار (portfolio)های آنلاینم را افزایش دهم. این پروژه‌ها هم شامل وبسایت‌ها می‌شد و هم شامل پروژه‌های جانبی دیگر. یکی از همین پروژه‌های جانبی یک پلتفرمی بود برای فروش کتاب‌های الکترونیکی افراد به شکل یک کورس آموزشی. این پروژه دقیقا همزمان بود با شروع خوداشتغالی من. این پروژه فراتر از فقط فروش می‌رفت؛ زیرا قابلیت‌های دیگری مثل پیشنهاد کوپن و یا برنامه‌های شراکتی در آن گنجانده شده بودند.
خب حالا سوال این‌جاست که این وب اپلیکیشن، چه ربطی به میکروسرویس دارد. من همیشه در حال جداسازی APIهای مختلف از یکدیگر بوده‌ام و این مسیر را هم به تنهایی طی کرده‌ام. به همین دلیل کار سخت و طاقت فرسایی به عنوان یک توسعه دهنده داشته ام. پس نتیجتا این مطلب و نتایج آن را که عنوانی قابل توجه و تعجب برانگیز دارد، نمی‌توان به شرکت‌های بزرگ تعمیم داد و از آن‌ها انتظار داشت که دست از استفاده از میکرو سرویس ها بکشند.
من ادعای متخصص بودن در میکرو سرویس ها را ندارم و تنها در حال آزمایش کردن آن هستم. به عنوان یک توسعه دهنده‌ی تنها، در پروژه‌های جانبی خود، به شکل وسیع و عمیقی از میکرو سرویس‌ها استفاده نکرده ام. به این معنی که پیش از دست کشیدن و نا امید شدن از میکرو سرویس‌ها، تنها از ۵ مورد آن استفاده کرده بودم و باید بدانید که من از استک‌های پیچیده‌ای مثل K8S استفاده نکرده ام.
بیاید ابتدا با نقاط قوت و در انتها با نقاط ضعف میکرو سرویس‌ها روبرو شویم:
- ساخت نرم افزار (+): من به ساختن چیزهای مختلف علاقه‌مند هستم. پا گذاشتن به مرحله‌ای از جداسازی که فراتر از جداسازی کلاینت و سرور که از دو جز (فرانت‌اند و بکاند) تشکیل شده، برای من هیجان انگیز بوده و همیشه دنبال چنین چالشی بوده‌ام. وقتی بحث یک پروژه‌ی جانبی است، ارزش آن را دارد که برای به‌دست آوردن پول بیش‌تر و هم‌چنین اهداف آموزشی، سراغ یادگیری چیزهای جدید بروید. پس من از خودم پرسیدم که آیا واقعا امکان جداسازی اجزا مختلف یک وبسایت مانند احراز هویت (authentication) و فرآیند پرداخت، با استفاده از میکرو سرویس‌ها، وجود دارد؟
- جداسازی (+): علاوه بر اشتیاق به یادگیری، طراحی API نیز من را تحت تاثیر قرار می‌دهد و با استفاده از میکروسرویسها، می‌توان جدا کردن APIهای مختلف را به راحتی انجام داد و هر کدام از آن‌ها بدون اطلاع و نیاز به دیگری، کار خود را انجام دهند. البته که در نهایت وقتی فرآیند خرید در وبسایتتان موفقیت آمیز بود، باید پایگاه داده سایت را از این موضوع با خبر کنید تا رخدادهای مورد نیاز پس از خرید،اتفاق بیفتند. در یک بکاند اپلیکیشن یکپارچه، ممکن است شما به سادگی از این تفکیک فرآیندها صرف نظر کنید و احساس نیاز به آن را نکنید. چون در این معماری هرکدام از سرویس‌های شما می‌توانند آزادانه به دیگر سرویس‌هایتان دسترسی داشته باشند؛ اما اگر بخواهید از میکروسرویسها استفاده کنید، باید مراقب باشید تا به نحوی درست تعامل بین این سرویس‌های مجزا را با استفاده از REST یا GraphQL مدیریت کنید.
- استفاده‌ی مجدد (+): علاوه بر قابلیت جداسازی سرویس‌ها از هم‌دیگر درون یک پروژه، قابلیت مناسب دیگر میکرو سرویس‌ها این است شما می‌توانید از یک فرآیند تعریف شده، در موقعیت‌های مختلف استفاده کنید و دوباره کاری نکنید. مثلا شما می‌توانید با استفاده از میکروسرویسها از API پرداخت یا API احراز هویتتان، در دیگر پروژه‌هایتان نیز استفاده کنید. به هر حال برای یک توسعه دهنده، انجام کارهای تکراری در پروژه‌های مختلف و پیادهسازی آن‌ها از صفر، ممکن است کلافه کننده شود. البته لازم به ذکر است که به همین سادگی نیز نیست و درست است که می‌توانید از میکرو سرویسی که ساخته‌اید در هر کجا که بخواهید استفاده کنید، اما ساخت میکرو سرویس و استفاده از آن هم، پیچیدگی‌های خاص خود را دارد؛ مخصوصا برای یک توسعه‌دهنده‌ی تنها.
- انتزاعی بودن (-): اگر نیاز است که میکروسرویسها برای داشتن قابلیت استفاده شدن مجدد، تغییر شکل دهند، باید در ذهن خود میکرو سرویس را یک مفهوم انتزاعی در نظر داشته باشیم؛ چرا که این قابلیت دیگر فقط برای حل یک ویژگی خاص نیست. برای مثال اگر میکرو سرویس احراز هویت، نیاز به تغییر شکل داشته باشد، این سرویس شما باید قابلیت تشخیص و تمیز دادن پروژه‌های مختلف شما را از یکدیگر، داشته باشد. پس باید بدانیم که در عین حال که این انتزاعی بودن میکروسرویسها از پیادهسازی چندباره‌ی یک API احراز هویت (که همه‌ی آن‌ها یک کار را انجام می‌دهند) جلوگیری می‌کند، اما یک سطح جدیدی از پیچیدگی را به API احراز هویت شما اضافه می‌کند. این کار برای یک توسعه‌دهنده‌ی تنها کار سختی است.
- خزش قابلیت‌ها (-): شما در کاربردهای ساده‌ی میکروسرویسها مشکل خاصی نخواهید داشت؛ اما در یک مثال پیچیده‌تر که با اپلیکیشنی گسترده‌تر روبرو هستیم،اوضاع به این سادگی نیست و البته که اضافه شدن قابلیت ها به اپ شما و در پی آن API هایشان، چیزی دور از ذهن نیست. مثلا در مثالی که از پروژه‌ی خودم آورده ام، زمانی که شروع به افزودن API کوپن کردم، به وضوح متوجه خزش قابلیت‌ها (اضافه شدن قابلیت‌ها به شکل تدریجی) شدم. نکته‌ی جالب این است که این بخش جدید از اپلیکیشن من، در بخش فرانت‌اند، مورد استفاده قرار می‌گرفت و نتیجتاً این API باید در بخش تایید شدن کوپن و به طور همزمان در بخش پرداخت (برای اعمال مقدار تخفیف) مورد استفاده قرار می‌گرفت.
- سربار بودن (overhead) ذهنی (-): با تمام صحبت‌هایی که درباره‌ی خزش ویژگی‌ها و انتزاعی بودن میکروسرویسها کردیم، به این نتیجه رسیدیم که استفاده از آن‌ها به عنوان یک توسعه‌دهنده‌ی تنها، منطقی به نظر نمی‌رسد. هم‌چنین درباره‌ی چند نقطه ضعف دیگر میکرو سرویس صحبت کردیم. تمام این موارد در کنار یکدیگر، باعث می‌شوند که اگر شما دغدغه‌ی ساخت یک اپلیکیشن بی نقص را دارید، ذهنتان بسیار درگیر شود و موارد جدیدی برای فکر کردن و مدیریت کردن، داشته باشید.
- قدرتمندی (-): بر روی کاغذ و در تئوری، میکروسرویسها ابزاری قدرتمند و کارآمد هستند که بیش‌تر این قدرت نیز در جداسازی وظایف خلاصه می‌شود. بدین ترتیب به نظر می‌رسد که با استفاده از آن‌ها، می‌توان سرویس‌هایی که به تنهایی قدرتمند هستند ساخت. اما باید بگویم که کار کردن به تنهایی بر روی میکروسرویسها، نه تنها به من قدرت نداد بلکه بیش‌تر خسته ام کرد. در نهایت به این نتیجه رسیدم که اگر از یک بکاند اپلیکیشن یکپارچه استفاده کنم، راحت‌تر خواهم بود. یکی از مشکلات من در استفاده از میکروسرویسها همین مجزا بودن و ایزوله بودن هر کدام از آن‌هاست که وقت و انرژی بالایی از یک فرد تنها می‌برند.
- موارد زیادی که منجر به شکست می‌شوند (-): به دلیل استفاده نکردن از استک‌های پیچیده، با گذشت زمان متوجه شدم که به خوبی نمی‌توانم از ترکیب سرویس‌ها با یکدیگر استفاده کنم و مدیریت آن‌ها، برایم دشوار شد و در موارد مختلفی منجر به شسکت عملیات‌هایم شد. وقتی شما دارای یک اپلیکیشن یکپارچه هستید، به خوبی می‌توانید در هنگام down شدن اپ‌تان، مشکل را پیدا و حل کنید؛ ولی زمانی که در حال استفاده از میکروسرویس‌های مختلفی در اپ خود هستید، باید به تک تک این میکروسرویسها نظارت داشته باشید تا متوجه اشکال در آن‌ها بشوید. پس به نظر می‌رسد راجع به این یک مورد، اگر یک منبع یکپارچه و یگانه برای اپ خود داشته باشید، اشکال‌زدایی و دیباگ آن، راحت‌تر خواهد بود.
- مدیریت زیرساخت‌ها (-): مدیریت کردن تمام زیرساخت‌های لازم برای پیادهسازی یک پروژه به وسیله‌ی وب‌سرویس‌‌ها برای یک توسعه دهنده،کار زیادی است و از عهده‌ی یک نفر بر نمی‌آید. شما به عنوان یک توسعه‌دهنده‌ی تنها در این نوع معماری نمی‌توانید تضمین کنید که تمام اتفاقات مطابق میل‌تان باشد؛ چرا که باید همیشه از صحت کارکرد تک تک میکروسرویس‌های مورد استفاده‌تان، اطمینان حاصل کنید.
نتیجه‌گیری
همان‌گونه که از متن بالا مشخص است، تجربه‌ی بنده از میکروسرویسها به عنوان یک توسعه‌دهنده‌ای که تنها کار می‌کند، به هیچ عنوان راضی کننده نبوده است. اما مطمئنا این قضیه برای گروه‌ها و شرکت‌های بزرگ، متفاوت است؛ چرا که آن‌ها می‌توانند با استفاده از منابع بسیارشان، میکروسرویسها را مدیریت کنند. اگر من هم زمان بسیار زیادی برای صرف کردن داشتم، قطعا به استفاده‌ی خود از میکروسرویسها ادامه می‌دادم. اما فعلا که این‌گونه نیست و من به عنوان یک تیم یک نفره‌ی برنامه‌نویسی، درحال استفاده از سیستم یکپارچه (monolithic) برای استفاده از مزایای آن هستم.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید