اتصال ضعیف در طراحی نرم‌افزار

June 2020

ویدیویی وجود ندارد

 

چرا اتصال ضعیف بین سرویس‌ها مهم است؟

 

loose coupling به معنای مستقل بودن سرویس‌ها است به گونه ای که تغییرات در یک سرویس هیچ تأثیری در سرویس دیگر نخواهد داشت. هرچه وابستگی بیشتری بین سرویس‌ها داشته باشید، در زمان اعمال تغییرات احتمال وقوع مشکلات گسترده‌تر و غیرقابل‌پیش‌بینی‌تر وجود دارد.

 

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

 

چه چیزی باعث coupling در بین سرویس‌ها میشود؟

تشخیص اینکه coupling از کجا می‌آید برای شما مهم است زیرا در اینصورت میتوانید دید بهتری برای مدیریت کردن وابستگی‌ها داشته باشید و همچنین میتوانید اثرات منفی را کاهش دهید.

 

Behavioural coupling وقتی اتفاق می افتد که سرویس‌ها مسئولیت‌ فرایندهای تجاری را به اشتراک می گذارند. به عنوان مثال ، شما ممکن است چندین سرویس داشته باشید که باید در تولید فاکتور دخیل باشند. اگر یک سرویس برای تحقق مسئولیت‌های خود به حمایت مستقیم سرویس دیگری نیاز داشته باشد ، به معنی این است که مرزهای سرویس‌ها به درستی ترسیم نشده اند.

 

این رایج ترین شکل اتصال است و با از بین بردن مرزهای بین سرویس ها برای از بین بردن روابط اضافی می توان با آن سروکار داشت. سبک ادغام سرویس‌ها نیز میتواند مرتبط باشد، زیرا در زمانی که تعامل بین سرویس‌ها براساس رویداد‌ها است استفاده از روش ارسال پیغام(messaging) بیشتر به loose coupling نزدیکتر است تا نسبت به تعامل مستقیم یا تعامل براساس RPC.

 

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

 

Schema coupling سرویس‌هایی را توصیف می کند که به مجموعه مشترکی از رابط‌ها یا طرحواره‌ها محدود شده اند. سرویس‌ها باید قادر به ایجاد تغییر در داده های داخلی خود باشند بدون اینکه چیزی را خراب کنند. ایجاد تغییر در رابط های داده خارجی کمی دشوار است ، زیرا این امر تأثیری در همکاری سرویس‌ها خواهد داشت.

 

روش هایی وجود دارد که می تواند به سرکتر کردن این اتصال کمک کند. مشتریان باید به شکل انعطاف‌پذیری فقط آن بخش‌هایی را که احتیاج دارند مصرف کنند. این آسیب پذیری آنها را در برابر شکستن API ها کاهش می دهد.

 

Temporal, or time-based coupling زمانی اتفاق می افتد که یک سرویس قبل از ادامه پردازش ، انتظار پاسخ فوری از دیگری را دارد. این امر به ویژه در سیستم هایی که از تعامل به سبک request/response استفاده می کنند، شایع است به عنوان مثال microserviceهایی که براساس REST یا gRPC کار میکنند. در این حالت شما میتوانید در نحوه تعامل بین سرویس‌هایتان تجدید نظر کنید تا دیگر نیاز نداشته باشند به سرویس‌های خارجی وصل شوند.

 

در زمان طراحی مجدد سرویس‌ها میتوانید از تعامل‌های مختلفی بین سرویس‌ها استفاده کنید. Process coupling هنگامی اتفاق می افتد که خدمات بیش از حد مسئولیت های متمایزی را به عهده بگیرند. این امر منجر بزرگ شدگی نامطلوب می شود که مقیاس گذاری یا تغییر آن دشوار می شود. شکل شدیدترین آن در سیستم عامل های CRM یا ERP مانند Salesforce یا SAP یافت می شود که تمایل دارند تبدیل به سکوهای "هیولا" شوند که مسئولیت های مختلفی را در معماری شما دارند.

 

Implementation coupling خدماتی را توصیف می کند که با جزئیات مخالف قراردادها یا طرح ها هستند. مثال خوب در اینجا جایی است که یک سرویس از کتابخانه دیگری برای برقراری ارتباط با آن استفاده می کند. در صورت تمایل به همکاری ، این سرویس ها را به یک زبان یا چارچوب خاص متصل می کند.

 

و در نهایت location-based coupling جایی که یک سرویس انتظار دارد منبعی در مکان خاص وجود داشته باشد. این به طور معمول توسط نوعی کارگزار یا سرویس دهنده انجام می شود که یک سری از مقاصد منطقی را به مکان های فیزیکی آنها نقشه برداری می کنند.

 

چرا به loose coupling احتیاج داریم؟

loose coupling اغلب با توسعه پایدار همراه است ، اگرچه تمایل دارد با گذشت زمان تأثیر گسترده تری داشته باشد.

 

عملکرد ، مقیاس پذیری و کشش

در یک سیستم به هم وابسته(thight) ، عملکرد شما تا حد زیادی توسط کندترین مؤلفه شما دیکته شده است. به عنوان مثال ، معماری میکروسرویس با خدماتی که از طریق API های مبتنی بر HTTP همکاری می کنند ، در صورت کند شدن یک جزء می تواند در برابر مشکلات عملکردی آبشاری آسیب پذیر باشد. اگر سرویس‌های شما از هم جدا شوند (decouple)، آزادی بیشتری برای بهینه سازی آنها به صورت جداگانه برای بارهای کاری خاص خواهید داشت.

 

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

 

بهره وری و اتوماسیون

loose coupling معمولاً با استقرار راحت تر همراه است. Nicole Forsgren در کتابش به روابط بین تیمهای با عملکرد بالا و شیوه های مهندسی خاص نگاه کرد. آنها دریافتند که با loose coupling از نظر فرکانس و ثبات استقرار با تولید بهتری همراه است. آنها همچنین دریافتند که loose coupling باعث کاهش تعداد اعضای تیمها بدون کاهش این بهره وری می شود.

 

چرا این باید اینطوری باشد؟ loose coupling امکان جداسازی را فراهم می کند. مؤلفه هایی که به طور مستقل از یکدیگر مستقر می شوند ، آزادی بیشتری را نسبت به زمان و چه مکانی مستقر می کنند. تیم های تحویل عملکردی بدون نیاز به مدیریت هرگونه وابستگی به تیم های دیگر ، می توانند کار خود را انجام دهند. انجام آزمایش آسانتر است زیرا اجزاء می توانند به طور مستقل از یکدیگر اعتبارسنجی شوند.

 

انعطاف پذیری و هزینه تغییر

coupling همچنین بر توانایی شما برای ایجاد ایمن تغییرات تأثیر می گذارد. هرچه اتصال شما در یک سیستم بیشتر باشد احتمال تغییر آن اثرات غیر منتظره ای خواهد داشت. محدود کردن هرگونه وابستگی بدان معناست که کمتر پیچیدگی برای مقابله با آن وجود دارد ، بنابراین انجام تغییرات آسانتر و ایمن تر است. این یکی دیگر از عوارض جانبی انزوا(isolation) است که به کاهش هزینه تغییر کمک می کند.

 

چطور بفهمم که سرویس‌های من loose coupled هستند؟

اگرچه شما نمی توانید coupling را از بین ببرید ، اما می توانید اطمینان حاصل کنید که این امر مانع از بهره‌مندی از مزایای اصلی مرتبط با خدمات خودمختار نخواهد شد. برخی اتصالات کاملاً خوب هستند تا زمانی که نتیجه مطلوب را تحت تأثیر قرار ندهند. چندین آزمایش وجود دارد که تعیین می کند آیا این مورد است مثلا:

۱. آیا می توانید بدون توجه به سایر سرویس، سرویسی را مستقلاً مستقر کنید؟

۲. آیا می توانید بدون استفاده از یک محیط یکپارچه ، سرویس‌های خود را آزمایش و تأیید کنید؟

۳. آیا می توانید بدون مراجعه به سرویس دیگری ، سرویس‌های داخلی را در مقیاس بزرگ تغییر دهید؟

۴. اگر سرویس متوقف شود ، آیا از اجرای سایر سرویس‌ها جلوگیری می کند؟

 

اگر سرویس‌های شما در یکی از این تست ها را شکست بخورد ، coupling شما مشکل خواهد داشت.

ارسال نظر

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