در طراحی میکروسرویس ها یکی از مهم ترین موارد تنظیم یک Social Contract بین تیم میکروسرویس و مصرف کنندگان آن می باشد. این Contract در واقع یک چارچوب برای هماهنگی و همکاری بین طرفین می باشد و کمک می کند تا از تغییرات مشکل ساز(غافلگیرکننده) و ناسازگاری جلوگیری شود.
برای مثال فرض کنید یک میکروسرویس داریم که اینترفیس آن توسط چندین سرویس دیگر استفاده می شود. به دلیل نیازهای جدید مجبور به تغییر آن اینترفیس می‌شویم. این تغییر ممکن است سرویس های مصرف کنندگان را ایمپکت کند. برای همین نیاز می باشد تا قبل از هر تغییری با مصرف کنندگان درباره زمان بندی و جزئیات تغییرات هماهنگ شویم. به زبان ساده تر Social Contract یعنی توافق کنیم که چه نوع تغییراتی, چگونه و با شرایطی می توانند انجام شوند و مصرف کنندگان تا چه زمانی باید این تغییرات را انجام دهند.
دو نوع Breaking Contracts داریم:
ساختاری: این نوع شامل تغییرات در ساختار و فرمت اینترفیس, تغییر نام یا حذف پارامترها, تغییر تایپ پارامترها و حذف یک endpoint یا تغییر مسیر آن می باشد.
معنایی: این نوع شامل تغییرات در منطق خروجی یا مقدارهای بازگشتی, تغییر در رفتار یک عملیات و تغییر در پاسخ های مرتبط با کدهای خطا می باشد. این تغییرات معمولا به خاطر ساختار ثابت API به سختی قابل تشخیص می باشند.
انتخاب یک روش مناسب بستگی به انتظارات مصرف کنندگان از تغییرات دارد. به صورت کلی نگهداری یک اینترفیس قدیمی می تواند هزینه های زیادی داشته باشد, ولی باید زمان کافی برای مصرف کنندگان جهت مهاجرت به نسخه جدید در نظر بگیریم. این زمان و تعادل باید بین تیم میکروسرویس با مصرف کنندگان بررسی شود. در کتاب Building Microservices پیشنهاد می شود که تیم میکروسرویس و مصرف کنندگان درباره ی چند نکته مهم به توفق برسند:
- درخواست تغییر اینترفیس به چه شکل مطرح شود؟
- همکاری بین تیم میکروسرویس و مصرف کنندگان برای رسیدن به توافق به چه شکل می باشد؟
- چه کسی مسئول انجام تغییرات در مصرف کننده می باشد؟
- مصرف کنندگان برای انجام تغییرات چه مدت زمان دارند؟
همچنین برای اینکه بتوانیم مصرف کنندگان را به سمت سازگاری هدایت کنیم روش های زیر پیشنهاد می شود:
Tracking Usage
اگر به توافق رسیده ایم که مصرف کنندگان تا تاریخ مشخصی به اینترفیس جدید مهاجرت کنند باید مطمئن شویم که این تغییرات را انجام دهند. برای مثال میتوانیم از لاگ و client id برای بررسی این مورد استفاده کنیم.
Extreme Measures
اگر به هر دلیلی مصرف کنندگان همچنان از اینترفیس قدیمی استفاده می کنند, میتوانیم بعد از یک مدت مشخص آن اینترفیس را حدف کنیم. معمولا در سازمان ها یک مدت مشخص را برای مهاجرت به اینترفیس جدید در نظر گرفته می شود و بعد از آن بدون هیچ بررسی اضافی اینترفیس قدیمی را حذف می کنند. همچنین بعضی اوقات با کند کردن مصنوعی پاسخ میتوانیم مصرف کنندگان را مجبور به مهاجرت به نسخه جدید کنیم.
در پایان باید توجه داشته باشیم که موفقیت یک Social Contract کاملا به ارتباط و هماهنگی بین تیم ها بستگی دارد. اگر تمام تیم ها در جریان این توافقات بوده و همکاری داشته باشند این فرآیند باعث ایجاد تجربه ی مثبت می شود.
