https://virgool.io/feed/@sayadaazami توسعه دهنده وب هستم و خیلی به برنامه نویسی و هرچی به برنامه نویسی مربوط میشه علاقه دارم، خیلی چیزا رو بلد نیستم و دارم یاد میگیرم. یه سری چیزایی که میخونم رو اینجا یادداشت میکنم که بعدا بتونم بخونم fa 2026-06-30 20:15:37 https://files.virgool.io/upload/users/68830/avatar/WqUrdV.png?height=120&width=120 https://virgool.io/@sayadaazami https://virgool.io/apieco/soa-vs-microservice-a0hhin9nxv3i آیا میکروسرویس نسل جدید SOA هست؟ و آیا هنوز هم از SOA استفاده میشه؟توی این مقاله میخایم تفاوت بین معماری های Monolithic و SOA و Microservice رو باهم بررسی میکنیم.در پست قبلی در رابطه با میکروسرویس ها یه مقداری میکروسرویس آشنا شدیم و فهمیدیم به کمک ما میاد که معماری رو تجزیه و توزیع کنیم و مزایای بیشتری نسبت به معماری یکپارچه داره. حالا توی این مقاله میخایم معماری layered-based رو توضیح بدیم و ببینیم تفاوت SOA و Microservice چیه؟قبل از اینکه بریم ببینیم تفاوت این دوتا چیه بهتره تفاوت های اساسی معماری monolithic و SOA و Microservice رو ببینیم.معماری یکپارچه - Monolithicبه طور خلاصه اگه بخوایم بگیم، این قبیل معماری ها شبیه به یک کانتینر(حالا شما فکر کنید یه جعبه) بزرگ هستن که تمام اجزای یک برنامه داخلشون قرار میگیره و با همدیگه یه پیکج(بسته نرم افزاری) یکپارچه رو تشکیل میدن.معماری سرویس گرا - SOAشامل مجموعه ای از سرویس هاست که با هم در ارتباط هستن. این ارتباطات میتونه شامل انتقال داده های ساده یا پیچیده بین دو یا چند سرویس برای هماهنگی یه سری فعالیت ها باشه. برای ایجاد این ارتباطات به یه سری ابزار نیاز داریم.معماری میکروسرویس - Microserviceیه سبک خاص معماریه که با استفاده از اون یه برنامه کاربردی رو به مجموعه ای از سرویس های مستقل تقسیم میکنیم که حول یه بیزنس دامین قرار میگیرن!تفاوت MicroService و SOAهمونطوری که اسم این دو معماری مشخصه هر دوتاشون حول سرویس ها میچرخن و کار میکنن، یعنی هر دو سرویس گرا هستن اما تفاوت اصلی این دوتا توی ویژگی ها و خصوصیات سرویس ها هستش.معماری سرویس گرا - SOA: با توجه به چیزی که توی شکل زیر میبینیم این معماری سرویس هاش رو به ۴ دسته اصلی تقسیم میکنه:سرویس های عملکرد(سرویس های تجاری) - Functional Services: سرویس هایی که درشت دانه تر هستن و هسته اصلی کار رو تشکیل میدنبه وسیله XML، زبان اجرای فرایند کسب و کار(BPEL) و... نمایش داده میشندر نهایت افرادی که تو حوزه کسب و کارتون هستن توی این لایه قرار میگیرنسرویس های سازمانی - Enterprise Services: عملکردهای تعریف شده توسط سرویس های تجاری رو پیاده سازی میکنن (یعنی عملکرد هایی که توی لایه بالاتر بهش نیاز داریم رو پیاده سازی میکنن) عمدتاً برای تحقق درخواست های business به سرویس های برنامه و سرویس های زیربنایی متکی هستن (پس لایه واسط ما ایجاس)سرویس های برنامه - Application Services: سرویس های ریز دانه ای که محدود به یه برنامه کاربردی خاص هستنتوی این لایه برنامه هامون توسعه داده میشهبرای استفاده از این سرویس ها باید رابط کاربری اختصاصی تهیه بشهسرویس های زیربنایی - Infrastructure Services:وظایف غیر کاربردی مثل تایید اعتبار، حسابرسی کاربران، امنیت و ورود به سیستم رو انجام میدنمیشه از طریق سایر برنامه ها و سرویس ها فراخوانی بشندر مقابل میکروسرویس ها طبقه بندی محدود تری دارن، با توجه به شکلی که پایین میتونید ببینید فقط ۲ نوع سرویس توی این معماری وجود داره:سرویس های عملکرد - Functional Services: عملکرد های کسب و کار رو پیاده سازی میکنندسترسی به این سرویس ها از بیرون انجام میشه و با بقیه سرویس ها به اشتراک گذاشته نمیشنسرویس های سازمانی - Enterprise Services: مثل معماری SOA، وظایف غیر کاربردی مثل تایید اعتبار، حسابرسی کاربران، امنیت و ورود به سیستم رو انجام میدنهیچ دسترسی ای به این سرویس ها از بیرون وجود ندارهتفاوت های اساسی SOA و MSAمعماری SOA سعی داره تا جایی که ممکنه همه چیز رو به اشتراک بزاره، در مقابل توی MSA سعی میشه حد اقل اشتراک گذاری داده ها و منابع رو داشته باشهمعماری SOA هدف استفاده مجدد از عملکرد های سیستم هستش، در مقابل MSA تمرکزش رو روی مفهوم bounded-context گذاشتهمعماری SOA همه سرویس هاش بر اساس استاندارد های رایج هست، در مقابل MSA تمرکزش رو روی توسعه دهنده ها، همکاری بین اونها، آزادی انتخاب ها و گزینه های دیگه گذاشتهمعماری SOA برای ارتباط بین سرویس ها از ESB (بیاید بهش بگیم اتوبوس خدمات سازمان) استفاده میکنه، در مقابل MSA از یک messaging-system ساده استفاده میکنهمعماری SOA از چندین پروتکل های پیام استفاده میکنه، در مقابل MSA از پروتکل های ساده مثل HTTP/REST استفاده میکنهمعماری SOA به صورت چند نخی و با سربار I/O کمتر کار میکند، در مقابل MSA به صورت تک نخی و معمولا با استفاده از EventLoop(جهت جلوگیری از بلاک شدن I/O) پیاده سازی میشهمعماری SOA قابلیت استفاده مجدد از سرویس های برنامه رو به حداکثر میرسونه، در مقابل MSA کل تمرکزش رو گذاشته روی جداسازی سرویس هامعماری SOA بیشتر از دیتابیس های رابطه ای مروسوم استفاده میکنه، در مقابل MSA غالبا دیتابیس های جدید با هر ساختاری رو پشتیبانی میکنهمعماری SOA اگر نیاز به یک تغییر سیستماتیک داشته باشه نیازه که تغییرات یکپارچه ای روی سرویس هاش بدیم، در مقابل توی MSA با اضافه کردن یه سرویس جدید میشه مشکل رو حل کردمعماری SOA سعی میکنه از DevOps و CI/CD استفاده کنه اما هنوز خیلی باهاشون هماهنگ نیست، در مقابل MSA به شدت با DevOps و CI/CD دوسته و ازشون استفاده میکنهتشریح تفاوت های اساسی SOA و MSAریز دانگی - Service Granularity: هر سرویس در معماری MSA به طور کلی یک کار رو انجام میده ولی همین یه کار رو به بهترین شکل انجام میده. اما در SOA هر سرویس میتونه به اندازه یه پروژه کوچیک، متوسط یا بزرگ وسعت داشته باشه. درواقع سرویس هایی که توی SOA ایجاد میشن غالبا به در قالب یه محصول بزرگ یا به صورت زیرسیستم از یه سیستم بزرگ ارائه میشن. اشتراک گذاری اجزاء - Component Sharing: یکی از اصول پایه معماری SOA اشتراک گذاری اجزای سیستمه، در واقع هدف اصلی سرویس های سازمانی به اشتراک گذاری اجزای سیستمه. معماری SOA این اشتراک گذاری رو تسهیل میکنه درحالی که MSA سعی داره با استفاده از مفهوم bounded-context این اشتراک گذاری را به حداقل برسونه.مفهوم bounded-context یعنی اینکه هر جزء یا اجزای مرتبط رو با داده های مورد استفاده ش توی یه بسته بندی قرار بدیم جوری که دیگه هیچ وابستگی ای به سایر بخشها نداشته باشه. و چون SOA برای اینکه بتونه درخواست ها رو پاسخ بده به چندین سرویس متکی هست این باعث میشه از معماری MSA کند تر باشه.استفاده از Middleware یا API Layer: الگوی معماری میکروسرویس از API Layer استفاده میکنه، ولی SOA در مقابل messaging-middleware رو داره. وجود messaging-middleware در SOA به ما یه سری قابلیت ها ارائه میده که توی MSA دیگه خبری ازشون نیست (قابلیت هایی مثل routing، meditation، message، message-enhancement، protocol-transformation و...) توی MSA یک واسط Api Layer داره که بین سرویس ها و service-consumer هاش میشینه.سرویس های راه دور - remote services: معماری SOA براساس messaging هایی مثل AMQP و MSMQ کار میکنه و پروتکل اصلیش SOAP هستش. در مقابل MSA از پروتکل REST و simple-messaging هایی مثل JMS و MSMQ استفاده میکنه و اینکه پروتکل انتخاب شده باید بین سرویس ها مشابه باشه.همکاری ناهمسان - Heterogeneous interoperability: معماری SOA مارو ترغیب میکنه که از چند پروتکل ناهمگون توی messaging-middlewareش استفاده کنیم. در مقابل MSA سعی میکنه با کم کردن تعداد راههای ارتباطی معماری ساده تری رو ارائه کنه. پس نتیجه میگیریم هرجا لازمه چنتا پروتکل ناهمسان داشته باشیم بهتره از SOA استفاده کنیم و در حالتی که یک پروتکل مشترک داریم MSA گزینه بهتریه.درنهایت باید بگم که خیلی راحت نمیشه گفت کدوم معماری بهتر از اون یکیه. و این به شدت وابسته به هدف و شالوده برنامه ای هست که میخاید ایجاد کنید.معماری SOA بیشتر مناسب کسب و کارهای پیچیده ای هست که نیازه برنامه های ناهمسان زیادی رو با هم ادغام کنیم؛ و اگر برنامه شما به اندازه کافی بزرگ نیست که نیاز به یک messaging-middleware داشته باشه بهتره سمت این معماری نرید.از طرف دیگه MSA مناسب پروژه های web هست که میشه به اندازه کافی خورد بشه و هر قسمت جدای از بقیه کار بکنه، و این قابلیت رو به توسعه دهنده میده که بتونه اشراف بیشتری روی کنترل جداگانه هر سرویس داشته باشه.در نهایت اول باید یه ۲ ۲ تا ۴ تا بکنید زیر و بم کسب و کارتون رو در بیارید ببینید کدوم معماری بیشتر به کارتون میاد. ادامه دارد... صیاد اعظمی صیاد اعظمی Wed, 04 Sep 2019 10:35:02 +0430 https://virgool.io/apieco/%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%DA%86%DB%8C%D8%B3%D8%AA-pnrjgh0w7duv تا حالا اسم میکروسرویس به گوشتون خورده؟ اصلن میکروسرویس چیه و چجوری توی scaling ازش استفاده میشه؟ (خودمم نمیدونم باور کنید بریم با هم یاد بگیریم!)برای اینکه یه ذهنیتی از میکروسرویس داشته باشیم بهتره درک کنیم که چجوری میشه یک برنامه یکپارچه رو به اجزای کوچیکتر(حالا این کوچیکی میتونه یه ذره باشه یا یه هکتار) تقسیم کنیم و هرکدوم رو جداگانه نصب و راه اندازی کنیم!توی این مقاله یاد میگیریم:چرا باید از میکروسرویس استفاده کرد؟میکروسرویس چیه؟ویژگی های معماری میکروسرویس چیه؟مزایای معماری میکروسرویس چیه؟بهترین روشهای طراحی میکروسرویس چیاس؟چرا باید از میکروسرویس استفاده کرد؟قبل از اینکه راجع به میکروسرویس بخایم حرف بزنیم بزارید ساختار برنامه های monolithic رو که قبل از میکروسرویس رایج بودن رو با هم ببینیم که به چه شکل بوده!به طور خلاصه اگه بخوایم بگیم، این قبیل معماری ها شبیه به یک کانتینر(حالا شما فکر کنید یه جعبه) بزرگ هستن که تمام اجزای یک برنامه داخلشون قرار میگیره و با همدیگه یه پیکج(بسته نرم افزاری) یکپارچه رو تشکیل میدن.مواردی که توی برنامه های یکپارچه باهاشون چالش داریم:عدم انعطاف پذیری: برنامه های یکپارچه رو نمیتونیم با استفاده از تکنولوژی های متفاوتی ایجاد کنیم چون بلخره داریم از یه استک(مجموعه ابزار و زبان) خاص استفاده میکنیم و همین و بس...غیر قابل اعتماد بودن: اگر حتی یک بخش کوچک از برنامه دچار مشکل بشه کل برنامه کار نمیکنه و به قول معروف میریم تو باقالیامقیاس پذیر نبودن: برنامه هارو نمیشه راحت توسعه داد چون به ازای هر تغییر کل برنامه باید مجددا کامپایل بشه (حالا نیاید بگید php و... اگر باشه کامپایل نمیخاد منظورم روال یکپارچه سازی و توسعه س که باید به ازای هر تغییر دوباره روی کل برنامه اجرا بشه)توالی توسعه نرم افزار(معنی بهتری برای continuous development پیدا نکردم بخدا) رو مسدود میکنند: بسیاری از ویژگی های برنامه رو نمیشه همزمان توسعه و انتشار داد چون خیلی به هم وابسته هستن و نیاز هست که قدم به قدم هر کدوم رو طراحی کنیم و بعد بریم مرحله بعد!روال توسعه را کند میکنند: روال توسعه توی این برنامه ها کنده چون قسمت های مختلف برنامه باید به ترتیب ایجاد بشن و همین باعث میشه برای اضافه کردن یک ویژگی به برنامه نیاز باشه منتظر طراحی پیش نیاز های اون بخش بشیم.برای برنامه های پیچیده مناسب نیستند: امکانات برنامه های یکپارچه خیلی به هم وابسته هستن و این وابستگی ها کار توسعه رو سخت میکنه (خدایی تا کجا میتونیم پیش بریم یه جایی بلخره میریم تو دیوار)چالشهایی که بالا گفتیم باعث شد کم کم بریم(البته باید بگیم باعث شد بروند :دی) به سمت میکرویس ها...میکروسرویس چیه؟یه سبک خاص معماریه که با استفاده از اون یه برنامه کاربردی رو به مجموعه ای از سرویس های مستقل تقسیم میکنیم که حول یه بیزنس دامین قرار میگیرن!اگر بخایم راحت تر بگیم اینجوری میشه که، برنامه رو خورد میکنیم به یه سری سرویس که هر کدوم کار خودش رو انجام میده ولی در نهایت با قرار دادن اینا کنار هم به یه برنامه واحد میرسیم! (فکر کنم رو شکل راحت تر بشه درکش کرد).نمایی از یک معماری میکروسرویستوی معماری میکروسرویس هر سرویس self-contained (خود مختار) هستش و یک قابلیت خاص رو پیاده سازی میکنه.تفاوت میکروسرویس و معماری های سنتی(مرسوم)برای درک این موضوع بیاید یک برنامه E-commerce رو در نظر بگیریم (شکل زیر رو ببینید)تفاوت یک برنامه e-commerce به صورت میکروسرویس و یکپارچهاولین تفاوتی که توی شکل بالا به چشم میاد اینه که توی معماری یکپارچه همه بخش های پروژه توی یه instance قرار گرفتن و به طبع یه دیتابیس واحد هم دارن ولی توی معماری میکروسرویس هر سرویس جداگانه داره کار میکنه و داده های خودش رو خودش نگهداری میکنه و قطعا هرکدوم داره کار خودش رو انجام میده و توی بقیه بخش ها دخالت مستقیمی نداره.حالا یه نگاهی میندازیم به شکل زیر که معماری میکروسرویس رو دقیقتر متوجه بشیمشمایی از معماری میکروسرویسحالا با هم ببنیم ویژگی های این معماری چیه!؟کلاینت های مختلف میخواهند از سرویس های مختلفی مثل جستجو، پیکربندی، مکان یابی و... استفاده کننهمه سرویس ها بر اساس عملکرد و دامنه(حوزه کاری) از هم جدا شدن و به میکروسرویس های جداگانه ای تقسیم شدناین میکروسرویس ها داخل خودشون شامل load balancer و محیط اجرایی اختصاصی هستن تا بتونن کارهای خودشون رو انجام بدن و داده های خودشون رو داخل خودشون نگهداری کننهمه میکروسرویس ها از طریق یک سرور stateless که حالا میتونه REST باشه یا Message Bus با هم ارتباط برقرار میکننبرای اینکه میکروسرویس ها مسیر ارتباطی خودشون رو متوجه بشن از Service Discovery استفاده میکنن و کارهایی مثل اتوماسیون و مونیتورینگ را انجام میدنکلاینت برای ارتباط با تمامی میکروسرویس ها از یک API-Gateway استفاده میکنهتمامی نقاط داخلی(میکروسرویس ها) به API-Gateway متصل هستن پس کلاینت بعد از اتصال به این نقطه میتونه به سرویس ها دسترسی پیدا کنه (درواقع دروازه شهر میکروسرویس هامون میشه)ویژگی های معماری میکروسرویس چیه؟حالا یه نگاهی میندازیم به شکل زیر که ویژگی های معماری میکروسرویس رو متوجه بشیمویژگی های میکروسرویسجداسازی (Decoupling): سرویس های داخل یک سیستم تا حد زیادی از هم جدا میشن و این باعث میشه مراحل ایجاد، تغییر و مقیاس دهی سرویس آسون تر بشهمولفه سازی (Componentization): میکروسرویس ها به صورت کامپوننت های کاملا مجزا عمل میکنن پس راحت میشه اونهارو جایگزین کرد یا ارتقا دادتوانایی های تجاری (Business Capabilities): میکروسرویس ها خیلی ساده عمل میکنن و تنها روی یک قابلیت تمرکز میکنن و تا جایی که میشه پیچیدگی رو توی خودشون به حد اقل میرسونناستقلال (Autonomy): توسعه دهنده ها و تیم به راحتی میتونن بدون هیچ وابستگی به دیگران کار خودشون رو انجام بدن و این باعث میشه سرعت توسعه بالا برهتحویل مداوم (Continous Delivery): چون میکروسرویس ها جدای از هم توسعه داده میشن این باعث میشه بتونیم مدام نسخه های جدیدی رو منتشر کنیم و با استفاده از اتوماسیون نرم افزار رو تست کنیم و اشکالات رو رفع کنیم و به مشتری تحویل بدیمپاسخگویی (Responsibility): از اونجایی که میکروسرویس ها رو تمام قابلیت های پروژه تمرکز نمیکنن پس راحت تر میتونن روی کار خودشون تمرکز کنن و خروجی مناسب رو داشته باشنحاکمیت غیر متمرکز (Decentralized Governance): توی میکروسرویس تمرکز روی استفاده از ابزار مناسب برای کار مناسب هست، یعنی اینکه هیچ الگو و تکنولوژی واحدی وجود نداره که مجبور باشیم از اون استفاده کنیم؛ پس توسعه دهنده مجازه از هر ابزاری که مناسب کار هست استفاده کنهمزایای معماری میکروسرویس چیه؟مزایای میکروسرویستوسعه مستقل (Independent Development): تمامی میکروسرویس ها میتونن به صورت جداگانه (بر اساس عملکردشون) توسعه داده بشن استقرار مستقل (Independent Deployment): بر اساس سرویسی که دارن ارائه میدن، میتونن تو هر برنامه ای مستقر بشنجداسازی خطا (Fault Isolation): اگر یک یا چند سرویس کار نکنند خللی در روال کار سایر سرویس ها ایجاد نمیکنه ترکیب تکنولوژی ها (Mixed Technology Stack): خیلی راحت میشه از زبان های برنامه نویسی و ابزارهای مختلف استفاده کرد، پس برنامه میتونه با n تا زبان و ابزار ساخته بشهمقیاسدهی ریزدانه (Granular Scaling): هر کدام از سرویس ها به صورت جداگانه میتونه مقیاس دهی بشه و نیازی نیست بقیه اجزا مقیاس دهی بشهبهترین روشهای طراحی میکروسرویس چیاستوی دنیای امروزه برنامه ها در حال بزرگ شدن هستن و به ناچار دارن پیچیده میشن. معماری میکروسرویس این نوید رو به ما میده که میتونیم عملکرد و مقیاس تیم و پروژه مون رو به راحتی مدیریت کنیم.نمودار زیر لیست بهترین روشهای طراحی میکروسرویس رو نشون میدهبهترین روش های طراحی میکروسرویسحالا یه مثال از یک سبد خرید میزنیم که معماری میکروسرویس رو بهتر درکش کنیموقتی برنامه سبد خرید رو باز میکنید، تمام چیزی که میبینیم یک وبسایته. اما توی پس زمینه سرویس هایی مثل پرداخت، مدیریت کاربران، مدیریت محصولات و... وجود داره.حالا بیاید فرض کنیم که این برنامه با یک فریمورک یکپارچه طراحی شده است که شکلش رو پایین میتونید ببینیدفریم ورک یکپارچه سبد خریدبا توجه که چیزی که توی شکل میبینیم متوجه میشیم که همه قسمت های برنامه کنار هم قرار گرفتن و از یه دیتابیس واحد دارن استفاده میکنن.حالا فکر کنید که یک قسمت جدید میخاد به برنامه اضافه بشه و توسعه دهندگان این برنامه ناچار میشن قسمت مربوطه رو با تمام وابستگی ها و تغییرات لازمه ش به برنامه اضافه کنن. حالا نه تنها باید روی قسمت های موجود توی سیستم دوباره کاری بکنن بلکه مجبور میشن حتی کل سیستم رو کاملا تغییر بدن و دوباره مستقر کنن.به همین خاطر حالا توسعه دهنده ها تصمیم میگرن برن سراغ میکروسرویس تا بتونن نیازهای بعدی رو هم راحت پوشش بدن. برای اینکه دید مناسبی به معماری جدیدشون داشته باشیم میتونید شکل زیر رو بررسی کیند.فریم ورک میکروسرویس سبد خرید چیزی که از شکل بالا میشه فهمید اینه که توسعه دهنده ها بجای اینکه بیان سرویس هاشونو به میکروسرویس وب، میکروسرویس لاجیک یا میکروسرویس دیتابیس تجزیه کنن در عوض میان میکروسرویس های جستجو، پیشنهادات، مدیریت مشتریان و... رو پیاده سازی میکنن.این نوع از معماری نه تنها به توسعه دهنده ها کمک میکنه تمامی چالش هایی که توی نسخه یکپارچه باهاش روبرو بودن رو برطرف کنن، بلکه این قابلیت رو بهشون میده که برنامه رو به راحتی ایجاد، نگهداری و مقیاس دهی بشه.ادامه دارد...دوستان بنده هیچ ادعایی روی درستی مطلق این مطالب ندارم و خوشحال میشم اگر اشتباهی چیزی هست رو بهم گوشزد کنید که اصلاح کنم. چون خودم دارم یاد میگیرم... صیاد اعظمی صیاد اعظمی Mon, 02 Sep 2019 15:21:49 +0430