https://virgool.io/feed/@z.hosseininm دانشجوی دکترا مهندسی کامپیوتر - علاقه مند به فرایند و داده fa 2026-06-17 10:13:04 https://files.virgool.io/upload/users/183047/avatar/inov5W.png?height=120&width=120 https://virgool.io/@z.hosseininm https://virgool.io/@z.hosseininm/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%B1%D8%A7%D9%87%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%86%D8%AC%D8%A7%D8%AA-ahtm5ppp6it4 در دو پست قبلی بحث معماری میکروسرویس را شروع کردیم. ابتدا با مثالی از یک اپلیکیشن با معماری یکپارچه زدیم و قدم به قدم مشکلاتش را بررسی کردیم. اصلی‌ترین دغدغه ای که برای یک اپلیکیشن بزرگ داریم، گسترش‌پذیری است. در این پست به کمک scale cube با این مفهوم آشنا می‌شویم.اگر دو پست قبلی را نخوانده‌اید، لطفا اول سری به آن‌ها بزنید :)معماری میکروسرویس - فرار از جهنم یکپارچه!معماری میکروسرویس - مزایا و معایب یکپارچگیو حال ادامه داستان...در قسمت‌های قبل دیدیم که ماری CTO شرکت FTGO است و او نهایتا به این نتیجه رسید که معماری میکروسرویس برای FTGO انتخاب مناسبی است.از آن جاییکه معماری ارتباط کمی با نیازمندی ها دارد، هر مجموعه از یوزکیس‌ها را می‌توان با هر معماری پیاده‌سازی کرد. (منظور از یوزکیس به طور ساده نیازمندی‌های کارکردی نرم‌افزار است.)در واقع معماری یک نرم‌افزار روی نیازمندی‌های غیرکارکردی یا به عبارتی روی نیازمندی‌های مربوط به کیفیت و در اصطلاح quality attribute تاثیرگذار است.با بزرگ شدن اپلیکیشن FTGO تعدادی از quality attribute ها مانند قابلیت نگهداری، گسترش‌پذیری و آزمون‌پذیری تحت تاثیر قرار گرفته و افت کردند.هر چقدر هم که تیم توسعه خبره باشند و ماژولاریتی را رعایت کند و تست‌های خودکار بنویسد، باز هم نمی‌تواند از پس معضل بزرگ شدن تیم توسعه و کار کردن روی تنها یک فایل اجرایی برآید و تنها می‌تواند مشکلات را به تاخیر اندازد اما نمی‌تواند جلوی رخ دادنشان را بگیرد.امروزه عقیده اکثر افراد بر این است که اگر یک نرم‌افزار بزرگ و پیچیده دارید، از معماری میکروسرویس استفاده کنید. اما سوالی که پیش می‌آید این است که معماری میکروسرویس دقیقا چیست؟تعاریف گوناگونی برای این مفهوم وجود دارد، بعضی معتقدند میکروسرویس همانطور که از نامش پیداست، مجموعه چند سرویس کوچک است برای مثال هر سرویس نهایتا 100 خط کد دارد. برخی دیگر می‌گویند که سرویس باید در یک زمان کوتاه برای مثال دو هفته توسعه پیدا کند. Adrian Cockcroft که قبلا در نتفلیکس کار می‌کرد معتقد است معماری میکروسرویس نوعی معماری سرویس‌گرا است که از المان‌های loosely coupled که bounded context دارند، تشکیل شده است. در ادامه این تعریف را واکاوی می‌کنیم تا بفهمیم دقیقا به چه معناست؟برای درک بهتر تعریف بالا، ابتدا با scale cube آشنا می‌شویم:در کتاب The Art of Scalability نوشته Martin Abbott و Michael Fisher یک مدل گسترش‌پذیری جالب معرفی شده است:مکعب scaleاین مکعب سه روش مختلف برای گسترش پذیری یک اپلیکیشن را بیان می‌کند:روش X-axisگسترش پذیری X-axis یکی از روش‎های رایج برای scale کردن یک اپلیکیشن monolithic است. در این حالت نمونه‌های مختلف اپلیکیشن اجرا شده و جلوی این‌ها یک لود بالانسر قرار می‌گیرد. لودبالانسر درخواست‌ها را بین این نمونه‌های مختلف توزیع می‌کند و این روش، راهی عالی برای بهبود ظرفیت و در دسترس بودن یک اپلیکیشن است. (برای مثال اگر یک نمونه اجرایی به مشکل بخورد، درخواست‌ها سمت آن نمی‌روند و نمونه‌های دیگر فعال هستند. در نتیجه اپلیکیشن کماکان در دسترس خواهد بود.)شکل زیر بیانگر این نوع گسترش‌پذیری است:گسترش‌پذیری X-axis و استفاده از یک لودبالانسر به همراه چندین نمونه از اپلیکیشنروش Z-axisدر گسترش‌پذیری به روش Z-axis، چندین نمونه از اپلیکیشن monolithic اجرا می‌شوند. اما برخلاف X-axis، هر نمونه تنها مسئول زیرمجموعه‌ای از داده است. مطابق آن چه در شکل زیر دیده می‌شود، یک router جلوی نمونه‌های مختلف اپلیکیشن قرار گرفته است و درخواست‌ها را مسیریابی می‌کند. این کار می‌تواند براساس پارامتری مانند userId انجام شود.گسترش‌پذیری Z-axis و استفاده از یک روتر جلوی درخواست‌ها، مسیریابی براساس پارامتر خاصی انجام می‌شودگسترش‌پذیری به روش Z-axis برای scale کردن اپلیکیشنی که قرار است تراکنش‌ها و حجم داده زیاد و روزافزون هندل کند، عالی است.روش Y-axisهر دو روش X-axis و Z-axis، ظرفیت و در دسترس بودن اپلیکیشن را بهبود می‌بخشند اما هیچ کدام نمی‌توانند مساله توسعه و پیچیدگی را حل کنند. برای حل این مورد از Y-axis یا functional decomposition استفاده می‌شود. همانطور که در شکل زیر دیده می‌شود، این روش از طریق تقسیم اپلیکیشن monolithic به مجموعه‌ای از سرویس‌ها کار می‌کند.روش Y-axisیک سرویس یک برنامه کوچک است که با تمرکز روی کارکرد خاصی پیاده‌سازی می‌شود. مانند مدیریت سفارشات، مدیریت مشتری و ... (یادآوری: اپلیکیشن FTGO که در این کتاب بررسی می‌شود، یک اپلیکیشن سفارش غذای آنلاین است.) حال هر سرویس می‌تواند به تنهایی با روش X-axis یا Z-axis، scale شود. برای مثال سرویس Order در بالا، از یک لودبالانسر و نمونه‌های مختلف سرویس استفاده کرده است.یک تعریف سطح بالا از معماری میکروسرویس عبارت است از یک استایل معماری که از نظر کارکردی یک اپلیکیشن را به مجموعه‌ای از سرویس‌ها تقسیم می‌کند. دقت کنید که این تعریف هیچ چیزی درباره سایز سرویس نمی‌گوید. به جای آن چیزی که اهمیت دارد این است که هر سرویس یک مجموعه وظایف منسجم دارد و روی آن‌ها متمرکز است.معماری میکروسرویس یک نوع modularity استماژولاریتی یک مفهوم ضروری به هنگام توسعه یک اپلیکیشن بزرگ و پیچیده است. یک اپلیکیشن امروزی مانند FTGO بزرگتر از آن است که توسط یک فرد توسعه یابد. همچنین پیچیده‌تر از آن است که توسط یک فرد فهمیده شود. بنابراین این اپلکیشن نیاز است به چندین ماژول تقسیم شود و هر ماژول توسط گروهی توسعه یابد. با یک معماری یکپارچه با توجه به دو پست قبلی، هر چقدر هم که ماژولاریتی رعایت شود، در عمل به big balls of mud تبدیل می‌شود.در معماری میکروسرویس از سرویس‌ها به عنوان یونیت‌های ماژولاریتی استفاده می‌شود. هر سرویس یک API دارد که مرزی بین سرویس‌ها تعیین می‌کند و اجازه نمی‌دهد یک سرویس به کلاس داخلی سرویس دیگر دسترسی داشته باشد. بنابراین به مرور زمان ماژولاریتی به خوبی تضمین می‌شود و از طرفی سرویس‌ها به عنوان building block ها هستند و می‌توانند مستقیما دیپلوی یا scale شوند.هر سرویس پایگاه‌داده خودش را داردیکی از مشخصه‌های بارز میکروسرویس این است که سرویس‌ها کاملا loosely coupled هستند و ارتباط آن‌ها تنها از طریق API می‌باشد. یکی از روش‌های دستیابی به loosely coupled این است که هر سرویس پایگاه‌داده خودش را داشته باشد. بنابراین در هر سرویس می‌توان به راحتی schema پایگاه‌داده را عوض کرد بدون آن که نگران باشیم در کار سرویس دیگری اختلال ایجاد می‌شود. همچنین در زمان اجرا، هر سرویس در محیطی کاملا ایزوله قرار دارد، بنابراین نگران آن نیستیم که یک سرویس در دسترسی به پایگاه‌داده بلاک شود چون سرویس دیگری با پایگاه‌داده کار می‌کند.در نوشته بعدی، برای معماری یکپارچه FTGO که قبلا دیدیم، معماری میکروسرویس ارائه می‌کنیم و این معماری را با معماری سرویس‌گرا مقایسه کرده و مزایا و معایب میکروسرویس را بیان می‌کنیم.منبع:Microservices Patterns: With Examples in Java Book by Chris Richardson زهرا حسینی نژاد زهرا حسینی نژاد Thu, 09 Jul 2020 12:47:26 +0430 https://virgool.io/@z.hosseininm/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%85%D8%B2%D8%A7%DB%8C%D8%A7-%D9%88-%D9%85%D8%B9%D8%A7%DB%8C%D8%A8-%DB%8C%DA%A9%D9%BE%D8%A7%D8%B1%DA%86%DA%AF%DB%8C-rwmkdlfrkkfc در ادامه مرور بخش‌هایی از کتاب Microservices Patterns: With Examples in Java نوشته Chris Richardson به مزایا و معایب معماری یکپارچه رسیدیم.اگر می‌خواهید با من در این ماجرای هیجان‌انگیز و تجربه ماری در شرکت FTGO همراه شوید لطفا ابتدا به پست قبلی سر بزنید:معماری میکروسرویس - فرار از جهنم یکپارچه!و اما حالا لطفا بیاید تا ادامه داستان را با هم باشیم:مزایای معماری monolithicدر روزهای اولی که تازه FTGO شروع به کار کرده بود، یک نرم‌افزار کوچک بود و استفاده از معماری یکپارچه مزایایی برای آن به همراه داشت:توسعه آسان – چون برنامه‌نویسان روی توسعه یک فایل اجرایی کار می‌کردند.امکان ایجاد تغیرهای افراطی به آسانی- کد و اسکیمای دیتابیس را می‌توانستند به راحتی عوض کرده و بیلد و دیپلوی کنند.تست آسان- توسعه‌دهندگان تست‌های end-to-end می‌نوشتند و نرم‌افزار را اجرا می‌کردند و این تست‌ها به آسانی اجرا می‌شد.دیپلوی آسان- کافی است تنها یک فایل دیپلوی شود.مقیاس‌پذیری آسان- FTGO چندین نسخه از اپلیکیشن را اجرا کرده و از یک لودبالانسر استفاده می‌کردند.اما به مرور زمان، توسعه، تست، دیپلوی و مقیاس‌پذیری دشوارتر شد. اما حالا ببینیم چرا؟متاسفانه در طول زمان توسعه‌دهندگان FTGO دریافتند که معماری یکپارچه محدودیت‌های زیادی دارد. اپلیکیشن‌های موفقی مانند FTGO به مرور زمان بزرگتر از آن می‌شوند که در معماری یکپارچه بگنجند! در هر اسپرینت تیم توسعه‌ی FTGO تعدادی استوری را پیاده‎سازی می‌کردند که این سبب بزرگتر شدن کد و پایگاه‌داده می‌شد. از طرفی هرچقدر که شرکت موفق‌تر می‌شد، تیم توسعه را بزرگتر می‌کرد. این بزرگ شدن تیم، سربارهای مدیریتی زیادی ایجاد می‌کرد و البته طبیعتا با همین نسبت، کار توسعه جلو نمی‌رفت.آن تیم توسعه کوچکِ روزهای اول، اکنون به چندین تیم اسکرام تبدیل شده بود که هر کدام بخشی از کارکرد را پیاده‌سازی می‌کردند. اما در نهایت یک فایل اجرایی وجود داشت. چنین روندی، توسعه را سخت کرد و عملا توسعه به سبک اجایل یا چابک را غیرممکن ساخت. اما چنین اتفاقی چگونه رخ داد؟ بیایید دقیق‌تر نگاه کنیم.معایب معماری monolithicپیچیدگی توسعه‌دهندگان را متوقف می‌کند!به مرور زمان کد به قدری بزرگ و پیچیده می‌شود که امکان اینکه یک برنامه‌نویس همه آن را بفهمد، ممکن نیست. در نتیجه این امر دیباگ و افزودن یک فیچر جدید فرایندی زمانبر و دشوار و خسته کننده است. در چنین شرایطی ددلاین‌ها مرتبا از دست می‌روند. برنامه‌نویسی که نداند این کد دقیقا چطور کار می‌کند، چگونه می‌تواند فیچر جدید را به درستی به آن اضافه کند؟ همچنین با هر تغییر جدید کد پیچیده‌تر و دشوارتر می‌شود و این چرخه باطل ادامه دارد! حتی ماژولاریتی که در قسمت قبل توضیح دادیم، نمی‌تواند در واقعیت این مشکل را کامل حل کند. در نهایت ماری که CTOشرکت FTGO بود فهمید که تنها یک راهکار برای نرم‌افزار بزرگ و پیچیده وجود دارد: معماری میکروسرویس.وجود چندین تیم توسعه در معماری یکپارچه کار توسعه را دشوار می‌کند، چون خروجی تنها یک فایل است، همه کدها باید در یک ریپازیتوری قرار بگیرد و سپس فرایند دیپلوی طی شود. وجود باگ در کار هر کدام از این تیم‌ها، سبب معطل شدن کار بقیه می‌شود. کند بودن روند توسعهبزرگ شدن یک اپلیکیشن روند توسعه را کند می‌کند. گاها در حدی این بزرگ شدن رخ می‌دهد که در IDE برنامه‌نویس به راحتی نمی‌گنجد. بنابراین زمان زیادی برای شروع برنامه صرف می‌شود و برنامه‌نویس نمی‌تواند مرتبا با چرخه edit-build-run-test جلو برود.طولانی و دشوار بودن مسیر کامیت تا دیپلوییکی دیگر از مشکلاتی که FTGO با آن دست و پنجه نرم می‌کرد، دشوار بودن فرایند دیپلوی است. گاها روزها باید طول می‌کشید تا بتوانند یک فیچر که کامیت شده را به پروداکشن برسانند. اگرچه که ساختار تیم‌ها اجایل بود و اسپرینتهای دو هفته‌ای وجود داشت، اما از زمانی که یک کد به درستی کامپایل می‌شود تا زمانی که این کد در پروداکشن دیپلوی شود، زمانی طولانی در حد چندین روز بود این در حالیست که برای مثال در سال 2011 آمازون هر تغییر را به طور میانگین در 11.6 ثانیه به پروداکشن منتقل می‎کرد! یکی بودن فایل اجرایی و طولانی شدن پروسه تست از اصلی‌ترین دلایل دشوار بودن فرایند دیپلوی در FTGOبود.دشوار بودن مقیاس‌پذیریبه مرور زمان مقیاس‌پذیری نیز دشوار شد. با بزرگ شدن کد، ماژول‌های مختلف از نظر منابعی که نیاز دارند، نیازمندی‌های متفاوتی دارند که گاها متناقض با یکدیگر است. برای مثال داده رستوران‌ها نیاز است روی یک دیتابیس بزرگ in-memoryباشد بنابراین نیاز به سروری که مموری زیاد دارد. در مقابل ماژول پردازش تصویر نیاز به سروری دارد که CPUخوبی داشته باشد. این ماژول‌ها همگی در یک اپلیکیشن هستند، پس سروری که بخواهد این اپلیکیشن روی آن اجرا شود، کانفیگ‌های متعدد و خاصی نیاز است داشته باشد.چالش قابلیت اطمینان در یکپارچگی!یکی از نکات مهم در قابلیت اطمینان، امکان تست است. اما در FTGO تست بسیار زمانبر و دشوار شده است. بنابراین وقتی قابلیت تست به آسانی وجود نداشته باشد، قابلیت اطمینان را تحت تاثیر قرار می‌دهد. از طرفی تمام ماژول‌ها همزمان با هم کار می‌کنند بنابراین قابلیت fault isolation عملا وجود ندارد. برای مثال اگر بخشی از برنامه به دلیل memort leak کرش کند، همه اجزا به دلیل آن که بهم وابسته‌اند کرش خواهند کرد در چنین حالتی دیباگ کاری دشوار و گاها غیرممکن است. چنین شرایطی اعتماد مشتری به سیستم را پایین می‌آورد و اهداف کسب و کار را به خطر می‌اندازد.تکنولوژی‌های منسوخبا گذشت زمان، یک سیستم که معماری یکپارچه دارد، بزرگ و بزرگ‌تر می‌شود، دنیای تکنولوژی به سرعت عوض می‌شود اما در این سیستم از فریمورک‌های قدیمی استفاده شده که به راحتی نمی‌توان آن‌ها را جایگزین کرد. معماری یکپارچه به راحتی اجازه نمی‌دهد که بتوان فریمورک یا زبان جدید در پروژه اضافه کرد. بنابراین از سویی نگهداری پروژه به مرور زمان دشوارتر می‌شود و امکان استفاده از ویژگی‌های جدید میسر نیست و از سوی دیگر انتخاب تکنولوژی تنها در ابتدای پروژه ممکن خواهد بود و بعدا به سختی می‌توان آن را تغییر داد. برای مثال در FTGO به دلیل مشکلاتی، نسخه فریمورک بروزرسانی نشده بود و در نتیجه با نسخه‎های جدید Springهمخوانی نداشت. همچنین برنامه‌نویسان FTGO مایل بودند بخش‌هایی را با زبان‌های non-JVMمانند GoLang یا NodeJS بنویسند که متاسفانه چنین چیزی در معماری یکپارچه ممکن نیست.اگر دوست دارید، در پست‌های بعدی ادامه داستان را دنبال کنین تا ببینیم این معماری یکپارچه چگونه به معماری میکروسرویس تبدیل می‌شود و چرا میکروسرویس برای این سیستم انتخاب خوبی است؟منبع:Microservices Patterns: With Examples in Java Book by Chris Richardsonپست بعدی:معماری میکروسرویس - راهی برای نجات! زهرا حسینی نژاد زهرا حسینی نژاد Sat, 04 Jul 2020 00:03:42 +0430 https://virgool.io/@z.hosseininm/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%81%D8%B1%D8%A7%D8%B1-%D8%A7%D8%B2-%D8%AC%D9%87%D9%86%D9%85-%DB%8C%DA%A9%D9%BE%D8%A7%D8%B1%DA%86%D9%87-mwqexhbuab3r کتاب Microservices Patterns: With Examples in Java نوشته Chris Richardson یکی از قشنگ‌ترین کتاب‌های فنی هست که تا الان خوندم. اولین بار 7 فصل از این کتاب رو به عنوان پروژه درس معماری نرم‌افزار پیشرفته دکتر علی اکبری در دانشگاه شهید بهشتی ارائه دادم. بعد یکی دو ماه این مفاهیم سر کار لازمم شد :) و این شد که تصمیم گرفتم یه بار دیگه کتاب رو عمیق‌تر و دقیق‌تر بخونم. از اون جایی که نیاز به یه انگیزه داشتم، تصمیم گرفتم دانشم رو در این جا با شما به اشتراک بذارم. اینجوری یک تیر و چند نشونه! هم کتاب رو میخونم و اینجا می‌نویسم که شاید به درد یکی دیگه بخوره و هم اینکه از نظرات ارزشمندتون استفاده می کنم.شروع کتاب با مثالی درباره شرکت FTGO است. Mary مدیر ارشد فنی(CTO) اونجاست و در یک کنفرانس درباره آخرین دستاوردهای مهندسی نرم‌افزار شرکت می‌کند. در این کنفرانس درباره معماری میکروسرویس صحبت می‌شود.ماری پس از شرکت در این کنفرانس یک هفته کاری را شروع می‌کند و طبق معمول یک جلسه ناخوشایند با برنامه‌نویس ارشد و افراد کسب و کار دارد. آن‌ها دو ساعت درباره تیم فنی صحبت کردند و اینکه باز هم قرار بود یک ددلاین مهم را از دست بدهند.متاسفانه این نوع جلسات طولانی و اکثرا بی‌فایده در چند سال اخیر در این شرکت زیاد شده بود و این مغایر با چابک بودن اجایل بود. در این صورت دسترسی به اهداف کسب و کار مرتبا به تعویق می افتد. وضعیت دشواری که به نظر نمی‌رسید راه حل ساده ای برای آن وجود داشته باشد.شرکت در کنفرانس سبب شده بود که ماری بفهمد چیزی که FTGO از آن رنج می برد، معماری یکپارچه است و تنها یک راه وجود دارد: معماری میکروسرویس!این که چگونه می‌توان به میکروسرویس مهاجرت کرد و از آن برای بهبود FTGO کمک گرفت، چیزی است که در این کتاب می‌آموزیم.ابتدا بهتر است کمی درباره معماری یکپارچه بدانیم و اینکه چگونه FTGO بدین جا رسید.در اواخر سال 2005 FTGO شروع به رشد کرد تا بدانجا که امروزه یکی از کمپانی های معروف سفارش غذا در ایالات متحده است. (Food To GO)کار با FTGO ساده است. کاربر از طریق وب سایت یا اپلیکیشن موبایل درخواست خود را در یکی از رستوران‌های اطرافش ثبت می‌کند. این درخواست به رستوران می‌رسد. مدیریت رستوران می‌تواند منو را ایجاد کرده یا تغییر دهد، درخواست‌ها را دریافت کرده و به آن ها پاسخ دهد. غذا برای مشتری با پیک ارسال می‌شود و صورتحساب برای او ایمیل می‌شود. همچنین مشتری می‌تواند از سرویس‌های پرداخت آنلاین استفاده کند. (مشابه اسنپ فود و ریحون در ایران)اپلیکیشن FTGO مانند خیلی دیگر از نرم‌افزارهای سازمانی (Enterprise) دارای یک معماری یکپارچه است به گونه ای که در نهایت یک فایل WAR که مخفف Java Web Application Archive است، تولید می‌شود. در طول زمان این فایل پیچیده و بزرگ شده است. علیرغم همه تلاش تیم فنی در نهایت این نرم‌افزار به یک مثال خوب از الگوی Big Ball of Mud تبدیل شد. (Big Ball of Mud چیست؟) به طور خلاصه این الگو یعنی جنگلی از کدهای اسپاگتی! چنین کدی باعث می‌شود که deliveryها کند به دست آیند.معماری یکپارچه این نرم‌افزار بدین شکل است:معماری شش ضلعی FTGO در این معماری از استایل شش‌ضلعی استفاده شده است که در فصل دوم این کتاب با جزئیات بررسی می‌شود. در یک معماری از نوع شش‌ضلعی، هسته اپلیکیشن Business Logic یا قوانین کسب و کار است. در اطراف آن، Adapterهای مختلف برای پیاده سازی UI و ارتباط با سیستم های خارج از این سیستم وجود دارد. (مثلا ارتباط با پرداخت بانکی، ایمیل، پیامک و ...)در شکل بالا Business logic از ماژول‌هایی تشکیل می‌شود که این ماژول‌ها مجموعه‌ای از اشیا هستند.مثال از ماژول در این نرم‌افزار:Order ManagementDelivery ManagementBillingPaymentsهمانطور که گفته شد، چندین adapters در اطراف Business logic قرار دارد که در دو دسته کلی قرار می‌گیرند:inbound adapters مانند web ui و rest api که به درخواست‌ها با فراخوانی business logic پاسخ می دهند.outbound adapters که برای ارتباط با خارج از business logic مانند پایگاه داده، کلود، پرداخت و ... به کار می روند.علیرغم ماژولار بودن FTGO، نتیجه نهایی در یک فایل WAR وجود دارد و مثالی از استایل یکپارچه در معماری نرم‌افزار است. در معماری یکپارچه ساختار یک سیستم در نهایت با یک فایل قابل اجرا تعریف می‌شود. یعنی در اینجا تنها یک فایل WAR! البته به خودی خود یکپارچه بودن بد نیست. بلکه کاملا بستگی به کاربرد دارد. برای شروع، توسعه دهندگان FTGO انتخاب درستی کرده‌اند اما در ادامه بهتر است استراتژی خود را عوض کنند!در پست بعدی برایتان از مزایا و معایب یکپارچگی و راهکار معماری میکروسرویس می‌نویسم. امیدوارم تا اینجا برایتان مفید بوده باشد.منبع:Microservices Patterns: With Examples in Java Book by Chris Richardson. زهرا حسینی نژاد زهرا حسینی نژاد Sun, 28 Jun 2020 00:13:50 +0430