معماری سرویس‌گرا (SOA) چیست؟
معماری سرویس‌گرا (Service-oriented architecture یا SOA) روشی در توسعه نرم‌افزار است که از مؤلفه‌هایی به نام «سرویس» برای ساخت برنامه‌های تجاری استفاده می‌کند. هر سرویس یک قابلیت مشخص تجاری را ارائه می‌دهد و می‌تواند با دیگر سرویس‌ها، حتی در پلتفرم‌ها و زبان‌های مختلف، ارتباط برقرار کند. توسعه‌دهندگان از SOA برای استفاده مجدد از سرویس‌ها در سیستم‌های مختلف یا ترکیب چند سرویس مستقل برای انجام وظایف پیچیده استفاده می‌کنند.
برای نمونه، در یک سازمان، فرایندهای مختلف به قابلیت احراز هویت کاربران نیاز دارند. به‌جای نوشتن دوباره کد احراز هویت برای هر فرایند، می‌توان یک سرویس واحد برای این کار ساخت و آن را در همه برنامه‌ها به کار گرفت. به همین شکل، در یک سازمان سلامت، بیشتر سیستم‌ها مثل سامانه مدیریت بیماران یا سامانه پرونده سلامت الکترونیکی (Electronic Health Record یا EHR) به ثبت اطلاعات بیماران نیاز دارند. این سیستم‌ها می‌توانند از یک سرویس مشترک برای انجام این کار بهره ببرند.
مزایای معماری سرویس‌گرا
معماری سرویس‌گرا نسبت به معماری‌های سنتی یکپارچه که در آن همه فرایندها در یک واحد واحد اجرا می‌شوند، مزایای زیادی دارد. برخی از مزایای مهم آن عبارت‌اند از:
زمان کمتر برای عرضه به بازار
چون سرویس‌ها در فرایندهای مختلف قابل استفاده مجدد هستند، توسعه‌دهندگان می‌توانند برنامه‌ها را سریع‌تر و با هزینه کمتر بسازند.
نگهداری آسان‌تر
ایجاد، به‌روزرسانی یا رفع اشکال سرویس‌های کوچک آسان‌تر از کدهای بزرگ در برنامه‌های یکپارچه است. تغییر یک سرویس در SOA روی عملکرد کلی سیستم تأثیری ندارد.
انعطاف‌پذیری بیشتر
این معماری با فناوری‌های جدید سازگارتر است و به‌روزرسانی برنامه‌ها با آن ساده‌تر و مقرون‌به‌صرفه‌تر انجام می‌شود. مثلاً سازمان‌های سلامت می‌توانند از قابلیت‌های سیستم‌های قدیمی ثبت پرونده بیماران در برنامه‌های مدرن ابری استفاده کنند.
چه اصولی در معماری سرویس‌گرا وجود دارد؟
اگرچه استانداردهای مشخص و یکسانی برای پیاده‌سازی معماری SOA وجود ندارد، اما برخی اصول پایه آن مشترک هستند:
قابلیت تعامل‌پذیری (Interoperability)
هر سرویس در SOA دارای اسنادی است که عملکرد و شرایط استفاده از آن را توضیح می‌دهد. هر سیستم کلاینت، بدون توجه به پلتفرم یا زبان برنامه‌نویسی، می‌تواند از این سرویس‌ها استفاده کند. مثلاً فرایندهای تجاری می‌توانند هم‌زمان از سرویس‌هایی نوشته‌شده به زبان‌های #C و پایتون (Python) استفاده کنند. چون تعامل مستقیمی میان سرویس‌ها وجود ندارد، تغییر در یک سرویس روی دیگر اجزای استفاده‌کننده از آن تأثیری نمی‌گذارد.
اتصال سست (Loose Coupling)
سرویس‌ها باید تا حد ممکن مستقل از منابع بیرونی مثل مدل‌های داده یا سیستم‌های اطلاعاتی باشند. همچنین بهتر است بدون حالت یا استیتلس (stateless) باشند؛ یعنی اطلاعات نشست‌ها یا تراکنش‌های قبلی را نگه ندارند. در این صورت، اگر یک سرویس تغییر کند، تأثیر زیادی روی برنامه‌های کلاینت یا سرویس‌های دیگر نخواهد داشت.
انتزاع (Abstraction)
کلاینت‌ها یا کاربران سرویس نیازی به دانستن منطق داخلی کد یا جزئیات پیاده‌سازی ندارند. سرویس‌ها باید برای آن‌ها مثل جعبه سیاه عمل کنند. آنچه کاربران نیاز دارند، در قالب قراردادهای سرویس و اسناد توضیحی در اختیارشان قرار می‌گیرد.
دانه‌بندی (Granularity)
هر سرویس باید اندازه و محدوده مناسبی داشته باشد و به صورت ایده‌آل، یک وظیفه تجاری مشخص را انجام دهد. سپس توسعه‌دهندگان می‌توانند چند سرویس را با هم ترکیب کرده و یک سرویس مرکب برای انجام عملیات‌های پیچیده‌تر ایجاد کنند.
معماری سرویس‌گرا (SOA) از چهار مؤلفه اصلی تشکیل شده است:
سرویس (Service)
سرویس‌ها واحدهای اصلی در SOA هستند. آن‌ها ممکن است خصوصی (فقط برای کاربران داخلی یک سازمان) یا عمومی (قابل‌دسترسی برای همه از طریق اینترنت) باشند. هر سرویس به‌طور کلی سه بخش دارد:
- پیاده‌سازی سرویس (Service Implementation):
کدی است که منطق اجرای وظیفه خاص سرویس، مانند احراز هویت کاربر یا محاسبه صورتحساب را پیاده‌سازی می‌کند.
- قرارداد سرویس (Service Contract):
این بخش مشخص می‌کند سرویس چه کاری انجام می‌دهد و چه شرایطی دارد؛ مثل پیش‌نیازهای استفاده، هزینه، یا کیفیت ارائه‌شده.
- رابط سرویس (Service Interface):
سایر سرویس‌ها یا سیستم‌ها از طریق این رابط با سرویس ارتباط برقرار می‌کنند. این رابط نحوه فراخوانی سرویس برای انجام عملیات یا تبادل داده را تعریف می‌کند و باعث کاهش وابستگی بین سرویس‌ها و مصرف‌کننده می‌شود. حتی کاربران بدون دانش برنامه‌نویسی هم می‌توانند از سرویس از طریق رابط آن استفاده کنند.
ارائه‌دهنده سرویس (Service Provider)
ارائه‌دهنده، مسئول ساخت، نگهداری و ارائه یک یا چند سرویس برای دیگران است. سازمان‌ها می‌توانند سرویس‌های خود را بسازند یا از فروشندگان سرویس شخص ثالث خریداری کنند.
مصرف‌کننده سرویس (Service Consumer)
مصرف‌کننده از ارائه‌دهنده درخواست اجرای یک سرویس مشخص را می‌کند. این مصرف‌کننده ممکن است یک سیستم، یک برنامه کاربردی یا حتی یک سرویس دیگر باشد. تعامل بین ارائه‌دهنده و مصرف‌کننده براساس قرارداد سرویس انجام می‌شود. آن‌ها می‌توانند از بخش‌ها، سازمان‌ها یا حتی صنایع متفاوت باشند.
رجیستری سرویس (Service Registry)
رجیستری سرویس یا مخزن سرویس، یک فهرست قابل‌دسترسی در شبکه است که اطلاعات مربوط به سرویس‌های موجود را نگه می‌دارد. این رجیستری اسناد توصیفی سرویس‌ها را که از ارائه‌دهندگان دریافت شده، ذخیره می‌کند. این اسناد شامل جزئیاتی درباره سرویس و نحوه ارتباط با آن هستند. مصرف‌کنندگان سرویس با جستجو در رجیستری می‌توانند سرویس مورد نیاز خود را پیدا کنند.
معماری سرویس‌گرا چگونه کار می‌کند؟
در معماری سرویس‌گرا (SOA)، هر سرویس به‌صورت مستقل عمل می‌کند و یک قابلیت یا تبادل داده را برای مصرف‌کنندگان فراهم می‌سازد. مصرف‌کننده داده‌هایی را به سرویس ارسال می‌کند و در پاسخ، نتیجه را دریافت می‌نماید. برای مثال، وقتی یک برنامه از سرویس احراز هویت استفاده می‌کند، نام کاربری و رمز عبور را به سرویس می‌دهد؛ سرویس این اطلاعات را بررسی کرده و پاسخ مناسب را برمی‌گرداند.
پروتکل‌های ارتباطی
سرویس‌ها با استفاده از قوانین مشخصی که نحوه ارسال داده در شبکه را تعیین می‌کنند، با یکدیگر ارتباط برقرار می‌سازند. این قوانین، پروتکل‌های ارتباطی نام دارند. برخی از پروتکل‌های رایج در پیاده‌سازی SOA عبارت‌اند از:
- پروتکل دسترسی ساده به اشیاء (Simple Object Access Protocol یا SOAP)
• ارتباط REST مبتنی بر HTTP یا (RESTful HTTP)
• آپاچی تریفت (Apache Thrift)
• آپاچی اکتیو‌ام‌کیو (Apache ActiveMQ)
• سرویس پیام‌رسان جاوا (Java Message Service یا JMS)
حتی می‌توان بیش از یک پروتکل را در یک پیاده‌سازی SOA به‌کار گرفت.
ESB در معماری سرویس‌گرا چیست؟
گذرگاه سرویس سازمانی (Enterprise Service Bus یا ESB) نرم‌افزاری است که در ارتباط میان سیستمی با چندین سرویس استفاده می‌شود. این ابزار ارتباط بین سرویس‌ها و مصرف‌کنندگان را صرف‌نظر از فناوری به‌کار رفته، برقرار می‌سازد.
ESB از طریق یک رابط سرویس قابل‌استفاده مجدد، قابلیت ارتباط و تبدیل داده را فراهم می‌کند. می‌توان آن را به‌عنوان یک سرویس مرکزی در نظر گرفت که درخواست‌های سرویس را به سرویس مناسب هدایت می‌کند و در صورت نیاز، فرمت درخواست را به شکلی تبدیل می‌کند که با پلتفرم و زبان برنامه‌نویسی سرویس مقصد سازگار باشد.
محدودیت‌های پیاده‌سازی معماری سرویس‌گرا (SOA)
مقیاس‌پذیری محدود
زمانی که سرویس‌ها منابع مشترک زیادی دارند و برای انجام وظایفشان نیاز به هماهنگی با یکدیگر دارند، مقیاس‌پذیری سیستم به‌شدت کاهش می‌یابد.
افزایش وابستگی‌ها
با گذشت زمان، سیستم‌های مبتنی بر SOA می‌توانند پیچیده‌تر شده و وابستگی‌های متعددی میان سرویس‌ها به‌وجود آید. در چنین حالتی، تغییر یا اشکال‌زدایی سیستم دشوار می‌شود، به‌ویژه اگر سرویس‌ها به‌صورت زنجیره‌ای یکدیگر را فراخوانی کنند. منابع مشترک مانند پایگاه‌داده‌های مرکزی نیز می‌توانند باعث کند شدن عملکرد سیستم شوند.
نقطه شکست واحد
در پیاده‌سازی‌هایی که از ESB استفاده می‌کنند، ESB به یک نقطه شکست واحد تبدیل می‌شود. این ویژگی با اصل تمرکززدایی موردنظر در SOA در تضاد است. اگر ESB از کار بیفتد، سرویس‌ها و کاربران نمی‌توانند با یکدیگر ارتباط برقرار کنند.
معماری مایکروسرویس‌ها چیست؟
معماری مایکروسرویس مجموعه‌ای از اجزای نرم‌افزاری بسیار کوچک و کاملاً مستقل است که هر یک فقط روی یک وظیفه خاص تمرکز دارند. این مایکروسرویس‌ها از طریق API با دیگر سیستم‌ها ارتباط برقرار می‌کنند؛ یعنی مجموعه‌ای از قواعد که توسعه‌دهندگان تعریف می‌کنند تا دیگر برنامه‌ها بتوانند با مایکروسرویس ارتباط بگیرند.
معماری مایکروسرویس‌ها به‌ویژه برای محیط‌های ابری مدرن بسیار مناسب است و اغلب در کانتینرها (واحدهای مستقل نرم‌افزاری که شامل کد و وابستگی‌های لازم هستند) اجرا می‌شوند.
مزایای مایکروسرویس‌ها
مایکروسرویس‌ها به‌صورت مستقل مقیاس‌پذیر، سریع، قابل‌انتقال و مستقل از پلتفرم هستند که همه این ویژگی‌ها با محیط ابری سازگارند. این سرویس‌ها از سایر مایکروسرویس‌ها مستقل‌اند، چرا که به داده‌های موردنیاز خود به‌صورت محلی دسترسی دارند و نیازی به دسترسی از راه دور به پایگاه‌داده‌های مرکزی ندارند. این موضوع منجر به تکرار داده‌ها می‌شود، اما در مقابل، کارایی و انعطاف‌پذیری بیشتری فراهم می‌آورد.
مقایسه SOA با مایکروسرویس‌ها
معماری مایکروسرویس نسخه تکامل‌یافته‌تری از سبک معماری SOA است. این رویکرد، نقاط ضعف SOA را برطرف کرده و آن را با نیازهای محیط‌های مدرن ابری سازگارتر کرده است. مایکروسرویس‌ها کوچک‌تر و مستقل‌تر هستند و به‌جای اشتراک‌گذاری داده‌ها، تکرار داده را ترجیح می‌دهند. هر مایکروسرویس از طریق API سبک خود با دیگران ارتباط دارد و نیازی به ابزار مرکزی مانند ESB ندارد. در واقع، مسئولیت ارتباط با مایکروسرویس برعهده مصرف‌کننده است.
