Cloud Design Patterns - Ambassador pattern

توی این پست می‌خوام در مورد دیزاین پترن های کاربردی در cloud software engineer یا Cloud Design Patterns کلیاتی رو مطرح کنم. با توجه به انقلاب جدید در صنعت نرم افزار در حوزه پردازش ابری و محاسبات لبه و میکروسرویس و استفاده از ابزارهای مثل kubernetes , docker swarm , mesos نیازمند این هستیم که معماری مناسبی رو برای این نوع برنامه‌ها پیش ببریم.

در این پست از Cloud Design Patterns ها به سراغ Ambassador pattern میریم که در دو دسته Design and Implementation, Operational Excellence قرار میگیره و به طور خلاصه تعریفش میشه:

سرویس‌های helper ایجاد کنیم که درخواست های شبکه را از طرف یک consumer service یا application ارسال کند.

یک سرویس ambassador را می توان به عنوان یک پروکسی out-of-process در نظر گرفت که در کنار client قرار می گیرد. این الگو می‌تواند برای بارگیری وظایف مشترک اتصال client مانند monitoring، logging، مسیریابی، امنیت (مانند TLS) و الگوهای انعطاف‌پذیر مفید باشد. اغلب با برنامه‌های قدیمی یا سایر برنامه‌هایی که اصلاح آن‌ها دشوار است، به منظور گسترش قابلیت‌های ارتباطی آنها استفاده می‌شود.

طرح صورت مسئله:

در cloud-based applications با قابلیت انعطاف عملکرد بالا، به ویژگی‌هایی مانند circuit breaking routing، metering و monitoring و توانایی ایجاد به‌روزرسانی‌های پیکربندی مرتبط با شبکه نیاز دارند. ممکن است به‌روزرسانی برنامه‌های قدیمی یا کتابخانه‌های کد موجود برای افزودن این ویژگی‌ها دشوار یا غیرممکن باشد، زیرا توسعه کد دیگر پشتیبانی نمی‌شود یا نمی‌توان آن را به راحتی توسط تیم توسعه اصلاح کرد.

فراخوانی و درخواست های مکرر روی شبکه ممکن است به پیکربندی قابل توجهی برای connection, authentication, authorization نیاز داشته باشند. اگر این درخواست‌ها در چندین برنامه کاربردی که با استفاده از چندین زبان و framework ساخته شده‌اند، استفاده می‌شوند، درخواست‌ها باید برای هر یک از این حالت‌ها پیکربندی شوند. علاوه بر این، عملکرد شبکه و امنیت آن ممکن است نیاز به مدیریت یک تیم حرفه ای داشته باشد و این فقط تمام ماجرا نیست و معمولا در این شرایط یک پایگاه کد بزرگ هم داریم که به‌روزرسانی و کدهای اون سختی زیاد داره.

راه حل:

کتاب‌خانه‌ها و frameworks های client را در یک فرآیند خارجی قرار بدیم که به عنوان یک پروکسی بین برنامه شما و خدمات خارجی عمل می کنه. پروکسی را در همان محیط host برنامه خودمان مستقر کنیم تا امکان کنترل مسیریابی، انعطاف پذیری، ویژگی های امنیتی و جلوگیری از هرگونه محدودیت دسترسی مربوط به host را فراهم کند. همچنین می توانیم از الگوی ambassador برای استانداردسازی و گسترش دقیق سایر بخش‌های برنامه و ماژول های جدیدتر استفاده کنیم. پروکسی می‌تواند معیارهای عملکرد مانند latency یا استفاده از resource usage را monitor کند و این monitor در همان محیط host برنامه انجام می‌شود.

ویژگی هایی که برای ambassador واگذار می شوند را می توان مستقل از برنامه مدیریت کرد. می‌توانید بدون ایجاد اختلال در عملکرد قدیمی برنامه، ambassador را به‌روزرسانی و اصلاح کنید. همچنین به تیم‌های مجزا و تخصصی اجازه می‌دهد تا ویژگی‌های security, networking, or authentication که به ambassador منتقل شده‌اند را پیاده‌سازی و حفظ کنند.

سرویس Ambassador را می توان به عنوان یک سرویس جانبی برای متصل کردن با consuming application یا سرویس های دیگر استفاده کرد. از طرف دیگر، اگر یک Ambassador توسط چندین فرآیند جداگانه در یک host مشترک به اشتراک گذاشته شود، می تواند به عنوان یک daemon مستقر یا deploy شود. اگر سرویس مصرف کننده کانتینری باشد، Ambassador باید به عنوان یک کانتینر جداگانه در همان host ایجاد شود، با linkهای مناسبی برای ارتباط با سایر سرویس‌ها پیکربندی شده باشد.

مسائل و ملاحظات:

• پروکسی مقداری سربار latency اضافه می کند. در نظر بگیرید که آیا interface یا کتابخانه client که مستقیماً توسط برنامه فراخوانی می شود، رویکرد بهتری است یا خیر.
• تأثیر احتمالی گنجاندن ویژگی های تعمیم یافته یا ویژگی هایی که درآینده اضافه می شود را در پروکسی را در نظر بگیرید.
• مکانیزمی را در نظر بگیرید که به client اجازه می‌دهد تا مقداری context را به پروکسی و همچنین به client بازگرداند. برای مثال، headers های درخواست HTTP را برای انصراف از تلاش مجدد اضافه کنید یا حداکثر تعداد دفعات امتحان مجدد را مشخص کنید.
• نحوه package و deploy پروکسی را در نظر بگیرید.
• در نظر بگیرید که آیا از یک نمونه مشترک برای همه clients استفاده کنید یا یک نمونه برای هر client.

چه زمانی از این الگو استفاده کنیم؟

از این الگو زمانی استفاده کنید که:

• نیاز به ایجاد مجموعه ای مشترک از ویژگی های ارتباطی با client برای حالتی که چندین زبان برنامه نویسی یا framework های مختلف داریم.
• نیاز به کاهش مشکلات ارتباطی client با نرم افزار و جداسازی وظایف بین توسعه دهندگان زیرساخت باسایر تیم های تخصصی تر.
• نیاز به پشتیبانی یا راه اندازی cloud یا cluster ای در یک برنامه قدیمی یا برنامه ای که تغییر آن در ساختار cloud دشوار است.

این الگو ممکن است مناسب نباشد در حالتی که:

• زمانی که latency در درخواست شبکه بسیار مهم است. یک پروکسی مقداری سربار را ایجاد می‌کند، هرچند حداقل، و در برخی موارد ممکن است روی برنامه تأثیر بگذارد.
• وقتی در توسعه نرم افزار فقط از یک framework یا فقط از یک زبان برنامه نویسی خاص استفاده شده باشد. در آن صورت، یک گزینه بهتر ممکن است یک کتابخانه یا interface برای client باشد که به عنوان یک package بین تیم های توسعه استفاده شود.
• هنگامی که ویژگی های ارتباطی قابل تعمیم و سازگاری نیستند و نیاز به یکپارچگی عمیق تر با برنامه مشتری دارند.

مثال:

نمودار زیر برنامه‌ای را نشان می‌دهد که از طریق یک پراکسی ambassador به یک سرویس راه دور درخواست می‌دهد. Ambassador مواردی مثل routing, circuit breaking, logging به سیستم را فراهم می کند. سرویس راه دور را فراخوانی می کند و سپس پاسخ را به برنامه مشتری برمی گرداند.