آیا واقعاً به «میکروسرویس» نیاز دارید؟

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

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

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

عالی به نظر می رسد درست است؟ خوب، اگر معماری توزیع‌شده را انتخاب کنیم، چالش‌ها و معایب زیادی وجود دارد. در بخش بعدی آنها را شرح خواهم داد.

اشتباهات محاسبات توزیع شده

اشتباهات محاسبات توزیع شده مجموعه ای از هشت فرض نادرست است که برنامه نویسان و معماران اغلب مطرح می کنند. آنها توسط L Peter Deutsch و دیگران در Sun Microsystems در سال 1994 ساخته شده‌اند.

اشتباه 1: شبکه قابل اعتماد است.
اگر سیستم 2 کاملاً خوب کار می کند، اما به دلیل مشکلات شبکه برای سرویس 1 قابل دسترسی نیست، سرویس 2 هنوز در دسترس نیست. به همین دلیل خط‌مشی‌های زمان‌بندی، قطع‌کننده‌های سرویس و تلاش مجدد وجود دارد. یک ابزار عالی برای دات نت برای رسیدگی به مشکلات رایج شبکه، Polly است، اما حتی در هنگام استفاده از ابزاری مانند این، شبکه هنوز کاملاً قابل اعتماد نیست.

مغالطه 2: تأخیر صفر است
اگر مؤلفه 1 مؤلفه 2 را در داخل یکپارچه فراخوانی کند، تأخیر تقریباً صفر است. اگر باید تماس شبکه برقرار شود، مدت زمان تکمیل تماس بسیار بیشتر خواهد بود. به خصوص اگر تماس های شبکه زیادی باید برقرار شود. اگر تأخیر یک تماس خاص 100 میلی‌ثانیه باشد و ده تماس را زنجیره‌ای کنیم، تأخیر یک ثانیه برای تکمیل فرآیند تجاری اضافه می‌کند.

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

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

• ذخیره سازی
• ذخیره سازی داده ها به صورت محلی
• فشرده سازی
• GraphQL
• انتخابگرهای میدان
• همچنین می توانید از فرمت های داده سبک مانند JSON یا فرمت سریال سازی باینری استفاده کنید.

مغالطه 4: شبکه امن است

سطح حمله برنامه های کاربردی توزیع شده بسیار بزرگتر از سطح حمله برنامه های کاربردی توزیع شده است. تک تک مؤلفه‌ها باید ایمن باشند، زیرا راه‌های زیادی وجود دارد که می‌توان به برنامه‌های شما حمله کرد، مانند XSS، آسیب‌پذیری‌ها در سیستم‌های عملیاتی، کتابخانه‌ها و DDOS.

اشتباه 5: توپولوژی هرگز تغییر نمی کند

این اشتباه در مورد هر جزء شبکه مانند روترها، سرورها، فایروال ها و سرورهای پراکسی است. توپولوژی همیشه تغییر می کند. اجزای شبکه به‌روزرسانی‌شده می‌توانند سرویس‌ها را از دسترس خارج کنند، اگر مؤلفه‌ای خراب شود، جایگزین می‌شود، اگر سرور دیگر نتواند به درخواست رسیدگی کند، می‌تواند جایگزین شود یا یک متعادل‌کننده بار و یک سرور اضافی اضافه شود. به عنوان مثال، با فناوری مدرن مانند سرویس‌های اپلیکیشن Kubernetes، Docker و Azure، ماشین‌های مجازی یا کانتینرها می‌توانند به صورت پویا اضافه یا حذف شوند.

• از نام هاست به جای آدرس های IP کدگذاری شده سخت استفاده کنید.
• اگر این کافی نیست، از خدمات کشف استفاده کنید.
• چارچوب های سرویس باس نیز می توانند کمک کنند، زیرا هر مؤلفه با گذرگاه سرویس ارتباط برقرار می کند.
• تا جایی که ممکن است خودکار کنید تا بتوانید در سریع ترین زمان ممکن سرور را جایگزین کنید.
• نظارت بر کلیه خدمات

اشتباه 6: فقط یک ادمین وجود دارد

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

اشتباه 7: هزینه حمل و نقل صفر است

این مغالطه در مورد پول است. با یک معماری توزیع شده به سرورهای اضافی، پراکسی ها و فایروال های اضافی و غیره نیاز خواهید داشت که معماری توزیع شده را گران تر می کند. اگر می‌خواهید داده‌ها را ذخیره کنید، مانند آنچه در مغالطه 2 و 3 بحث شد، ممکن است به حافظه سرور اضافی یا یک خوشه Redis نیاز داشته باشیم. اگر از فشرده سازی مانند آنچه در مغالطه 3 بحث شد استفاده کنیم، برای فشرده سازی داده ها به قدرت محاسباتی بیشتری نیاز داریم. منابع اضافی نیز برای سریال‌سازی و سریال‌زدایی داده‌ها مورد نیاز است. این چیزها ممکن است ارزان به نظر برسند، اما در مقیاس بزرگ ممکن است بسیار گران شوند.

مغالطه 8: شبکه همگن است

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

• سعی کنید از استانداردهای باز و محبوب مانند JSON یا XML استفاده کنید.
• استفاده از ارائه دهندگان PaaS یا IaaS برخی از چالش های سخت افزاری را برطرف می کند.

چالش های دیگر

نظارت بر

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

نسخه سازی قرارداد

هنگامی که چندین مؤلفه با یکدیگر صحبت می کنند، باید یکدیگر را درک کنند. برای این منظور از قرارداد داده استفاده می شود. یک قرارداد داده پیام هایی را که از یک جزء به جزء دیگر ارسال می شود، توصیف می کند. این شامل نوع استانداردی است که استفاده می شود (به عنوان مثال XML یا JSON)، ویژگی ها، نوع داده و ساختار داده ها. قراردادها را نمی توان تغییر داد زیرا ممکن است باعث شکسته شدن یک جزء دیگر شود. بنابراین قراردادها نیاز به نسخه سازی دارند تا بتوانند به نسخه جدیدی از یک قرارداد مهاجرت کنند. تغییرات در قراردادها باید به سایر تیم‌های توسعه نیز اطلاع داده شود و باید یک نمای کلی از اینکه کدام واحد استقرار از کدام قرارداد استفاده می‌کند وجود داشته باشد تا بدانید چه زمانی می‌توانید قرارداد قدیمی را حذف کنید.

گسترش

بسیاری از مؤلفه ها باید در یک معماری توزیع شده مستقر شوند.

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

معاملات توزیع شده

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

توسعه محلی

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

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

• برنامه های کاربردی با پایه کد عظیم. من قبلاً در شرکتی کار می کردم که در آن تعدادی از همکارانم داشتم که روی یک برنامه یکپارچه بزرگ کار می کردند که کامپایل آن ساعت ها طول کشید. در این سناریو یک معماری توزیع شده می تواند ایده خوبی باشد.
• برنامه ای که در یک شرکت بزرگ با توسعه دهندگان بسیار ساخته شده است.
• برنامه هایی که باید بسیار مقیاس پذیر باشند.
• برنامه هایی که در دسترس بودن آنها بسیار مهم است.

در تمام سناریوهای دیگر، معماری یکپارچه احتمالا بهترین رویکرد است.

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

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

انواع معماری یکپارچه

• معماری لایه ای
• معماری خطوط لوله
• معماری میکروکرنل

انواع معماری پراکنده

• معماری سرویس گرا (SOA)
• میکروسرویس ها
• بدون سرور

امیدوارم از خواندن این مطلب لذت برده باشید و من دوست دارم هر گونه بازخوردی را بشنوم!