معماری یکپارچه (monolithic) از نظر تاریخی برای مدت طولانی توسط توسعه دهندگان استفاده می شد، و برای مدت طولانی کار می کرد. متأسفانه، این معماری‌ها از قطعات کمتری استفاده می‌کنند که بزرگ‌تر هستند، به این معنی که در صورت خرابی یک قسمت، احتمال خرابی کامل آنها بیشتر است. اغلب، این برنامه‌ها به‌عنوان یک فرآیند منفرد اجرا می‌شدند که فقط مشکل را تشدید می‌کرد.
میکروسرویس ها این مسائل خاص را با اجرای هر میکروسرویس به عنوان یک فرآیند جداگانه حل می کنند. اگر یک چرخ دنده پایین بیاید، لزوماً به این معنی نیست که کل دستگاه کار نمی کند. به‌علاوه، تشخیص و رفع نقص در سرویس‌های کوچکتر و بسیار منسجم، اغلب ساده‌تر از سرویس یکپارچه بزرگ‌تر است.
الگوهای طراحی یا دیزاین پترن های میکروسرویس ها بلوک های بنیادی آزمایش شده و واقعی را ارائه می دهند که می توانند به نوشتن کد برای میکروسرویس ها کمک کنند. با استفاده از پترن ها در طول فرآیند توسعه، در زمان صرفه جویی می کنید و از دقت بالاتری نسبت به نوشتن کد برای برنامه میکروسرویس خود از ابتدا اطمینان می دهید. در این مقاله مروری جامع از 10 الگوی طراحی میکروسرویس که باید بدانید و همچنین زمان اعمال آنها را پوشش می دهیم.
استفاده از این الگوهای طراحی محبوب را در برنامه میکروسرویس بعدی خود در نظر بگیرید و سازمان را قابل مدیریت تر کنید. آیا با میکروفرانت اند نیز آشنا هستید؟
مزایای کلیدی استفاده از الگوهای طراحی میکروسرویس
دانستن مزایای کلیدی میکروسرویس ها به شما در درک دیزاین پترن ها کمک می کند. مزایای دقیق ممکن است بر اساس میکروسرویس های مورد استفاده و کاربردهایی که برای آنها استفاده می شود متفاوت باشد. با این حال، توسعه‌دهندگان و مهندسان نرم‌افزار معمولاً هنگام استفاده از الگوهای طراحی میکروسرویس‌ها می‌توانند انتظار مزایای زیر را داشته باشند:
ایجاد یک معماری کاربردی که به طور مستقل قابل استقرار و غیرمتمرکز است
مقیاس پذیری عظیم در زمان و در صورت نیاز
نسخه‌های جدید میکروسرویس‌ها که می‌توانند به صورت تدریجی عرضه شوند، بنابراین زمان از کار افتادگی را کاهش می‌دهند
تشخیص رفتار ناخواسته قبل از جایگزینی کامل نسخه قدیمی برنامه
استفاده از چندین زبان کدنویسی
پیشگیری از نارسایی سیستمیک به دلیل یک علت ریشه ای در یک جزء جدا شده
تعادل بار در زمان واقعی
در آنوفل، ما در تلاش استفاده از معماری میکروسرویس‌ها برای کمک به افزایش سرعت تحویل بدون افت کیفیت هستیم. البته، درک بهترین روش‌های میکروسرویس به شما کمک می‌کند بیشترین مزایا را به دست آورید. قبل از استفاده از بهترین روش، اولین قدم این است که شیوه‌های طراحی میکروسرویس‌هایی را که ممکن است اغلب در طول توسعه استفاده کنید، درک کنید.
1. پایگاه داده در هر الگوی سرویس
پایگاه داده یکی از مهم‌ترین اجزای معماری میکروسرویس‌ها است، اما غیرمعمول نیست که توسعه‌دهندگان هنگام ساخت سرویس‌های خود از الگوی پایگاه داده در هر سرویس چشم‌پوشی کنند. سازماندهی پایگاه داده بر کارایی و پیچیدگی برنامه تأثیر می گذارد. رایج ترین گزینه هایی که یک توسعه دهنده می تواند هنگام تعیین معماری سازمانی یک برنامه استفاده کند عبارتند از:
پایگاه داده اختصاصی برای هر سرویس:
پایگاه داده اختصاص داده شده به یک سرویس توسط سرویس های دیگر قابل دسترسی نیست. این یکی از دلایلی است که مقیاس و درک آن را از یک جنبه تجاری تمام عیار بسیار آسان تر می کند.
سناریویی را تصور کنید که در آن پایگاه داده های شما نیازها یا نیازهای دسترسی متفاوتی دارند. داده های متعلق به یک سرویس ممکن است تا حد زیادی رابطه ای باشند، در حالی که سرویس دوم ممکن است توسط یک راه حل NoSQL بهتر ارائه شود و سرویس سوم ممکن است به یک پایگاه داده برداری نیاز داشته باشد. در این سناریو، استفاده از سرویس‌های اختصاصی برای هر پایگاه داده می‌تواند به مدیریت آسان‌تر آنها کمک کند.
این ساختار همچنین اتصال را کاهش می دهد زیرا یک سرویس نمی تواند خود را به جداول سرویس دیگر متصل کند. سرویس ها مجبور به برقراری ارتباط از طریق رابط های منتشر شده هستند. نکته منفی این است که پایگاه داده های اختصاصی برای رویدادهایی که ارتباط با مشکل مواجه می شود، به مکانیزم محافظت از شکست نیاز دارند.
پایگاه داده واحد به اشتراک گذاشته شده توسط همه سرویس ها:
یک پایگاه داده مشترک استاندارد برای معماری میکروسرویس ها نیست، اما به هر حال باید به عنوان جایگزین ذکر شود. در اینجا، مسئله این است که میکروسرویس‌هایی که از یک پایگاه داده مشترک استفاده می‌کنند، بسیاری از مزایای کلیدی را که توسعه‌دهندگان به آن تکیه می‌کنند، از جمله مقیاس‌پذیری، استحکام و استقلال از دست می‌دهند.
با این حال، به اشتراک گذاری یک پایگاه داده فیزیکی ممکن است در برخی شرایط مناسب باشد. با این حال، هنگامی که یک پایگاه داده واحد توسط همه سرویس ها به اشتراک گذاشته می شود، بسیار مهم است که مرزهای منطقی را در آن اعمال کنید. به عنوان مثال، هر سرویس باید دارای اسکیمای خود باشد و دسترسی خواندن/نوشتن باید محدود شود تا اطمینان حاصل شود که سرویس‌ها نمی‌توانند در جایی که به آنها تعلق ندارند، نفوذ کنند.
2. پترن saga
saga مجموعه ای از معاملات محلی است. در برنامه های میکروسرویس، یک الگوی saga می تواند به حفظ ثبات داده ها در طول تراکنش های توزیع شده کمک کند.
پترن سگا راه‌حلی جایگزین برای سایر الگوهای طراحی است که با دادن فرصت‌های بازگشت امکان انجام معاملات متعدد را فراهم می‌کند.
یک سناریوی رایج یک برنامه تجارت الکترونیکی است که به کلاینتان اجازه می دهد محصولات را با استفاده از اعتبار خریداری کنند. داده ها ممکن است در دو پایگاه داده مختلف ذخیره شوند: یکی برای سفارشات و دیگری برای کلاینت ها. مبلغ خرید نمی تواند از سقف اعتبار تجاوز کند. برای پیاده سازی الگوی Saga، توسعه دهندگان می توانند بین دو رویکرد رایج یکی را انتخاب کنند.
1. Choreography:
با استفاده از رویکرد Choreography، یک سرویس یک تراکنش را انجام می دهد و سپس یک رویداد را منتشر می کند. در برخی موارد، سرویس‌های دیگر به آن رویدادهای منتشر شده پاسخ می‌دهند و وظایف را طبق دستورالعمل‌های کدگذاری شده خود انجام می‌دهند. این وظایف ثانویه ممکن است با توجه به تنظیمات از پیش تعیین شده، رویدادها را نیز منتشر کنند یا نه. در مثال بالا، می‌توانید از یک رویکرد Choreography استفاده کنید تا هر تراکنش تجارت الکترونیک محلی رویدادی را منتشر کند که یک تراکنش محلی را در سرویس اعتباری آغاز می‌کند.
2. ارکستراسیون:
یک رویکرد هماهنگ‌سازی، تراکنش‌ها را انجام می‌دهد و رویدادها را با استفاده از یک شی برای هماهنگ کردن رویدادها منتشر می‌کند، و سرویس دیگر را با تکمیل وظایف خود تحریک می‌کند تا پاسخ دهند. ارکستراتور به شرکت کنندگان می گوید که چه تراکنش های محلی را اجرا کنند.
ساگا یک الگوی طراحی پیچیده است که برای اجرای موفقیت آمیز آن به مهارت بالایی نیاز دارد. با این حال، مزیت اجرای صحیح، حفظ ثبات داده در چندین سرویس بدون اتصال محکم است.
3. الگوی دروازه API
برای برنامه های بزرگ با چندین کلاینت، پیاده سازی الگوی دروازه API یک گزینه قانع کننده است یکی از بزرگترین مزیت ها این است که کلاینت را از نیاز به دانستن نحوه پارتیشن بندی سرویس ها محافظت می کند. با این حال، تیم های مختلف به دلایل مختلف الگوی دروازه API را ارزش گذاری می کنند. یکی از این دلایل احتمالی این است که با کار به عنوان یک پروکسی معکوس بین برنامه های کلاینت و سرویس ها، یک نقطه ورودی واحد را برای گروهی از میکروسرویس ها اعطا می کند. مورد دیگر این است که کلاینتان نیازی به دانستن نحوه پارتیشن بندی سرویس ها ندارند و مرزهای سرویس می توانند به طور مستقل تغییر کنند زیرا کلاینت چیزی در مورد آنها نمی داند.
کلاینت همچنین نیازی به دانستن نحوه یافتن یا برقراری ارتباط با بسیاری از خدمات دائماً در حال تغییر ندارد. همچنین می‌توانید یک دروازه برای انواع خاصی از کلاینت‌ها (مثلاً بک اند ها برای فرانت‌اند) ایجاد کنید که ارگونومی را بهبود می‌بخشد و تعداد رفت‌وآمدهای مورد نیاز برای واکشی داده‌ها را کاهش می‌دهد. بعلاوه، یک الگوی دروازه API می تواند وظایف مهمی مانند احراز هویت، خاتمه SSL و حافظه پنهان را انجام دهد، که برنامه شما را ایمن تر و کاربر پسندتر می کند.
مزیت دیگر این است که این الگو کلاینت را از نیاز به دانستن نحوه پارتیشن بندی خدمات محافظت می کند. قبل از حرکت به الگوی بعدی، یک مزیت دیگر برای پوشش وجود دارد: امنیت. راه اصلی که این الگو امنیت را بهبود می بخشد، کاهش سطح حمله است. با ارائه یک نقطه ورودی واحد، نقاط پایانی API مستقیماً در معرض کلاینتان قرار نمی گیرند و مجوز و SSL را می توان به طور مؤثر پیاده سازی کرد.
توسعه‌دهندگان می‌توانند از این الگوی طراحی برای جدا کردن ریزسرویس‌های داخلی از برنامه‌های کلاینت استفاده کنند تا بتوان از یک درخواست تا حدی ناموفق استفاده کرد. این تضمین می کند که یک درخواست کامل شکست نمی خورد زیرا یک میکروسرویس منفرد پاسخگو نیست. برای انجام این کار، دروازه API کدگذاری شده از کش برای ارائه یک پاسخ خالی یا بازگرداندن یک کد خطای معتبر استفاده می کند.
آنوفل نیز دارای یک سرویس API برای انجام احراز هویت، مقاله ها و کاربران فیک برای تست اپلیکیشن های خود و نمونه کار های خود می توانید از این سرویس به صورت کاملا رایگان استفاده کنید، برای استفاده از این سرویس کافی است در آنوفل ثبت نام کنید و در بخش پنل کاربری می توانید به تمامی endpoint ها همراه با مثال و نمونه کد ببینید.
4. الگوی طراحی جمع کننده
یک الگوی طراحی جمع‌آوری (Aggregator) برای جمع‌آوری قطعات داده از میکروسرویس‌های مختلف استفاده می‌شود و یک مجموعه را برای پردازش برمی‌گرداند. اگرچه شبیه به الگوی طراحی backend-for-frontend (BFF) است، یک aggregator عمومی تر است و به صراحت برای UI استفاده نمی شود.
برای تکمیل وظایف، الگوی جمع‌آوری درخواستی را دریافت می‌کند و بر اساس وظایفی که به آن اختصاص داده شده، درخواست‌هایی را به چندین سرویس ارسال می‌کند. هنگامی که هر سرویس به درخواست ها پاسخ داد، این الگوی طراحی نتایج را ترکیب می کند و پاسخ به درخواست اصلی را آغاز می کند.
5. الگوی طراحی مدار شکن
این الگو معمولاً بین سرویس هایی که به صورت همزمان در حال ارتباط هستند اعمال می شود. زمانی که یک سرویس تاخیر بالایی را نشان می‌دهد یا کاملاً پاسخگو نیست، ممکن است یک توسعه‌دهنده تصمیم بگیرد که از قطع کننده مدار (Circuit breaker) استفاده کند. سودمندی در اینجا این است که وقتی یک میکروسرویس منفرد پاسخگو نباشد از خرابی در چندین سیستم جلوگیری می شود. بنابراین، تماس‌ها انباشته نمی‌شوند و از منابع سیستم استفاده نمی‌کنند، که می‌تواند باعث تاخیرهای قابل‌توجه در برنامه یا حتی مجموعه‌ای از خرابی‌های سرویس شود.
پیاده‌سازی این الگو به عنوان یک تابع در طراحی قطع کننده مدار، نیاز به فراخوانی یک شی برای نظارت بر شرایط خرابی دارد. هنگامی که یک وضعیت خرابی تشخیص داده شود، کلید قطع می شود. هنگامی که این کلید خاموش شد، تمام تماس‌های قطع کننده مدار منجر به خطا می‌شود و به سرویس دیگری هدایت می‌شود. از طرف دیگر، تماس‌ها می‌توانند منجر به بازیابی پیام خطای پیش‌فرض شوند.
سه حالت از عملکردهای الگوی قطع کننده مدار وجود دارد که توسعه دهندگان باید از آن آگاه باشند. اینها هستند:
باز: الگوی قطع کننده مدار زمانی باز است که تعداد خرابی ها از آستانه فراتر رفته باشد. در این حالت، میکروسرویس بدون اجرای عملکرد مورد نظر، برای تماس ها خطا می دهد.
Closed: هنگامی که یک مدارشکن بسته است، در حالت پیش فرض قرار دارد و به همه تماس ها به طور معمول پاسخ داده می شود. این حالت ایده آلی است که توسعه دهندگان می خواهند یک میکروسرویس قطع کننده مدار در آن باقی بماند - البته در یک دنیای عالی.
نیمه باز: هنگامی که یک مدارشکن در حال بررسی مشکلات اساسی است، در حالت نیمه باز باقی می ماند. ممکن است به برخی از تماس ها به طور معمول پاسخ داده شود، اما برخی ممکن است پاسخ داده نشوند. بستگی به این دارد که چرا مدارشکن در ابتدا به این حالت تغییر کرده است.
6. الگوی تفکیک مسئولیت کوئری فرمان (CQRS)
اگر یک توسعه‌دهنده بخواهد راه‌حلی برای مسائل سنتی پایگاه‌داده مانند خطر اختلاف داده‌ها داشته باشد، ممکن است از الگوی طراحی جداسازی مسئولیت کوئری فرمان (CQRS) استفاده کند. CQRS همچنین می تواند برای موقعیت هایی استفاده شود که عملکرد و امنیت برنامه پیچیده است و اشیا در معرض تراکنش های خواندن و نوشتن هستند.
روش کار به این صورت است که CQRS مسئول تغییر وضعیت موجودیت یا برگرداندن نتیجه در یک تراکنش است. برای اهداف پرس و جو می توان نماهای متعددی ارائه کرد و سمت خواندنی سیستم را می توان به طور جداگانه از سمت نوشتن بهینه کرد. این تغییر امکان کاهش پیچیدگی همه برنامه‌ها را با جستجوی جداگانه مدل‌ها و دستورات فراهم می‌کند تا:
سمت نوشتن مدل، رویدادهای پایداری را مدیریت می کند و به عنوان منبع داده برای سمت خوانده شده عمل می کند
سمت خوانده شده مدل، پیش‌بینی‌هایی از داده‌ها ایجاد می‌کند که نماهایی بسیار غیرعادی‌شده هستند
7. الگوی پیام رسانی ناهمزمان
اگر سرویسی نیازی به منتظر ماندن برای پاسخ نداشته باشد و بتواند به اجرای کد خود پس از شکست ادامه دهد، می توان از پیام رسانی ناهمزمان استفاده کرد. با استفاده از این الگوی طراحی، میکروسرویس ها می توانند به شیوه ای سریع و پاسخگو با یکدیگر ارتباط برقرار کنند. گاهی از این الگو به عنوان ارتباط رویداد محور یاد می شود.
برای دستیابی به سریعترین و پاسخگوترین برنامه، توسعه دهندگان می توانند از صف پیام برای به حداکثر رساندن کارایی و در عین حال به حداقل رساندن تاخیر پاسخ استفاده کنند. این الگو می تواند به اتصال چندین میکروسرویس بدون ایجاد وابستگی یا اتصال محکم آنها کمک کند. در حالی که معاوضه هایی با ارتباطات ناهمگام (مانند ثبات نهایی) وجود دارد، این هنوز یک رویکرد انعطاف پذیر و مقیاس پذیر برای طراحی معماری میکروسرویس است.
8. الگوی منبع یابی رویداد (Event sourcing)
الگوی طراحی منبع رویداد در میکروسرویس ها زمانی استفاده می شود که یک توسعه دهنده می خواهد تمام تغییرات در وضعیت موجودیت را ثبت کند. استفاده از فروشگاه‌های رویداد مانند کافکا یا جایگزین‌ها به پیگیری تغییرات رویداد کمک می‌کند و حتی می‌تواند به عنوان یک واسطه پیام عمل کند. کارگزار پیام به برقراری ارتباط بین ریزسرویس‌های مختلف، نظارت بر پیام‌ها و اطمینان از قابل اعتماد و پایدار بودن ارتباط کمک می‌کند. برای تسهیل این عملکرد، الگوی منبع یابی رویداد مجموعه ای از رویدادهای تغییر دهنده حالت را ذخیره می کند و می تواند با پخش مجدد رخدادهای یک موجود، وضعیت فعلی را بازسازی کند.
هنگامی که تراکنش ها برای برنامه حیاتی هستند، استفاده از منبع یابی رویداد یک گزینه مناسب در میکروسرویس ها است. این همچنین زمانی که نیاز به اجتناب از تغییرات در پایگاه کد لایه داده موجود است، به خوبی کار می کند.
9. الگوی Strangler
توسعه دهندگان بیشتر از الگوی طراحی Strangler برای تبدیل تدریجی یک برنامه یکپارچه به میکروسرویس ها استفاده می کنند. این کار با جایگزینی عملکرد قدیمی با یک سرویس جدید انجام می شود - و در نتیجه، این گونه نام الگو را دریافت می کند. هنگامی که سرویس جدید برای اجرا آماده شد، سرویس قدیمی "خفه می شود" تا سرویس جدید بتواند کنترل شود.
برای انجام این انتقال موفقیت‌آمیز از یکپارچه به میکروسرویس‌ها، یک رابط نما توسط توسعه‌دهندگان استفاده می‌شود که به آنها اجازه می‌دهد تا خدمات و عملکردهای فردی را در معرض دید قرار دهند. توابع هدف از یکپارچه جدا شده اند، بنابراین می توان آنها را خفه کرد و جایگزین کرد.
برای درک کامل این الگوی خاص، درک تفاوت برنامه های یکپارچه با میکروسرویس ها مفید است.
10. الگوهای تجزیه
الگوهای طراحی تجزیه برای شکستن یک برنامه یکپارچه به میکروسرویس های کوچکتر و قابل مدیریت تر استفاده می شود. یک توسعه‌دهنده می‌تواند به یکی از سه روش زیر دست یابد:
1. تجزیه بر اساس قابلیت تجاری:
بسیاری از کسب و کارها بیش از یک قابلیت تجاری دارند. به عنوان مثال، یک فروشگاه تجارت الکترونیک احتمالاً دارای قابلیت هایی است که شامل مدیریت کاتالوگ محصولات، موجودی، سفارشات و تحویل است. ممکن است در گذشته از یک برنامه یکپارچه برای هر سرویس استفاده شده باشد، اما مثلاً، کسب‌وکار تصمیم می‌گیرد یک اپلیکیشن میکروسرویس برای مدیریت این سرویس‌ها ایجاد کند. در این سناریوی رایج، کسب و کار ممکن است استفاده از تجزیه بر اساس قابلیت تجاری را انتخاب کند.
این ممکن است زمانی استفاده شود که یک برنامه دارای تعداد زیادی توابع یا فرآیندهای مرتبط با یکدیگر باشد. همچنین ممکن است زمانی که عملکردها یا فرآیندها به طور مکرر تغییر می کنند، توسعه دهندگان از آن استفاده کنند. مزیت این است که داشتن خدمات متمرکزتر و کوچکتر امکان تکرار و آزمایش سریعتر را فراهم می کند.
2. تجزیه بر اساس زیر دامنه:
این برای برنامه های فوق العاده بزرگ و پیچیده که از منطق تجاری زیادی استفاده می کنند مناسب است. برای مثال، اگر برنامه‌ای از چندین گردش کار، مدل‌های داده و مدل‌های مستقل استفاده می‌کند، ممکن است از این استفاده کنید. شکستن برنامه به زیر دامنه ها به مدیریت کد پایه آسان تر کمک می کند و در عین حال توسعه و استقرار سریع تر را تسهیل می کند. یک مثال آسان برای درک وبلاگی است که در یک زیر دامنه جداگانه (به عنوان مثال، blog.companyname.com) میزبانی شده است. این رویکرد می تواند وبلاگ را از منطق تجاری دامنه ریشه جدا کند.
3. تجزیه با معامله:
این یک الگوی مناسب برای بسیاری از عملیات تراکنش در چندین مؤلفه یا سرویس است. توسعه دهندگان می توانند این گزینه را زمانی انتخاب کنند که الزامات سازگاری دقیق وجود
داشته باشد. به عنوان مثال مواردی را در نظر بگیرید که ادعای بیمه ارائه می شود. درخواست ادعا ممکن است همزمان با یک برنامه کلاینت ها و ریزسرویس‌های Claims تعامل داشته باشد.
حالا که با بهترین دیزاین پترن های میکروسرویس ها آشنا شدید، برای آشنایی با 10 تا از آنتی پترن در میکروسرویس ها این مقاله را بررسی کنید. و اگر برنامه نویس لاراول هستید و دوست دارید از میکروسرویس در لاراول استفاده کنید این مقاله را بررسی کنید.
نتیجه
راه‌اندازی معماری مناسب و ابزار فرآیند به شما کمک می‌کند تا یک گردش کاری میکروسرویس موفق ایجاد کنید. از الگوهای طراحی شرح داده شده در بالا استفاده کنید و در مورد میکروسرویس ها در وبلاگ ما بیشتر بیاموزید تا یک برنامه قوی و کاربردی ایجاد کنید. برای آشنایی با میکروفرانت اند در ری اکت این مقاله را از دست ندهید.