معماری سرویس گرا چیست؟
معماری سرویس گرا SOA سرنام (Service-Oriented Architecture)، یک سبک معماری نرم‌افزاری است که در آن قابلیت‌ها و کارکردهای نرم‌افزار به صورت سرویس‌های مستقل و قابل استفاده مجدد در بستر شبکه ارائه می‌شوند. در معماری مذکور، هر مولفه یا سرویس یک کار مشخص انجام می‌دهد و امکان فراخوانی آن توسط سایر سرویس‌ها یا برنامه‌های کاربردی وجود دارد. این سرویس‌ها و مولفه‌ها از طریق استانداردهای باز و پروتکل‌های ارتباطی رایج با هم در تعامل هستند.
معماری سرویس‌گرا چیست؟
معماری سرویس گرا (SOA) یک الگوواره توسعه نرم افزار است که به مولفه‌ها و سرویس‌های مختلف اجازه می‌دهد از طریق زیرساخت‌های ارتباطی مختلف با یکدیگر در ارتباط باشند. به بیان دقیق‌تر، در معماری سرویس‌گرا، یک مولفه یا سرویس نرم‌افزاری تنها یک کار مشخص را انجام می‌دهد. بنابراین، سرویس‌های مختلف با کمترین وابستگی، به انتقال داده‌ها می‌پردازند و اگر هر فرآیند با مشکلی روبرو شود، نرم‌افزار از حرکت باز نمی‌ایستد.
این‌جا، مفهوم حداقل وابستگی به این معنا است که سرویس‌ها قادر هستند به شکل مستقل از یکدیگر عمل کنند، اما در عین حال، توانایی برقراری ارتباط با یکدیگر را داشته باشند. با این توصیف باید بگوییم که SOA از طریق پیاده‌سازی حداقل پیش‌نیازهای لازم در راستای قابلیت همکاری میان برنامه‌ها و سرویس‌ها، کاهش هزینه‌های توسعه نرم‌افزارها را به همراه دارد. رویکردی که هزینه تمام شده نرم‌افزارهای اختصاصی برای سازمان را کاهش می‌دهد. همچنین، SOA از گسترش‌پذیری و مقیاس‌پذیری به بهترین شکل پشتیبانی می‌کند، بنابراین، سازمان‌ها مشکلی از بابت به‌روزرسانی نرم‌افزارهای خود نخواهند داشت.
معماری SOA
برای درک بهتر معماری فوق بهتر است کار را با ذکر یک مثال ساده شروع کنیم. یک رستوران را به عنوان یک سیستم نرم‌افزاری در نظر بگیرید. در معماری سرویس گرا، هر بخش از رستوران (مثل آشپزخانه، پیشخوان، انبار) به عنوان یک سرویس مجزا عمل می‌کند. آشپزخانه، وظیفه پخت غذا، پیشخوان وظیفه سفارش‌گیری و پرداخت و انبار وظیفه مدیریت مواد اولیه را بر عهده دارد. هر بخش به صورت مستقل کار می‌کند، اما با بخش‌های دیگر ارتباط دارد تا در نهایت یک وعده غذایی کامل به مشتری تحویل داده شود. لازم به توضیح است که معماری سرویس گرا از الگوواره معماری توزیع‌شده پشتیبانی می‌کند که دسترسی مستقل به منابع را امکان‌پذیر می‌کند.
به بیان دقیق‌تر، معماری سرویس‌گرا مبتنی بر مفهوم سرویس یا مدل سرویس در دنیای محاسبات است. در الگوی طراحی مذکور، فرآیندهای تجاری به‌عنوان سرویس‌های نرم‌افزاری پیاده‌سازی می‌شوند، دسترسی به آن‌ها از طریق رابط‌های برنامه‌نویسی کاربردی (API) انجام می‌شود و از طریق مکانیزم‌های ارتباطی پویا به برنامه‌ها متصل می‌شوند. این معماری دارای دو مولفه اصلی به شرح زیر است:
۱. ارائه‌دهنده سرویس
ارائه‌دهنده سرویس یا خدمات، سازمانی است که مسئولیت نگهداری سرویس را بر عهده دارد و سرویس‌های موردنیاز مشتریان را در اختیارشان قرار می‌دهد. به طور معمول، ارائه‌دهنده، سرویس‌ها را بر مبنای یک قرارداد خدماتی که نوع کاربری سرویس در آن شرح داده شده، نحوه استفاده از آن، ملزومات اولیه استفاده از خدمات و هزینه‌های دریافتی را تعیین می‌کند.
۲. مصرف‌کننده سرویس یا مشتری
کاربر یا سازمانی است که قصد استفاده از سرویس‌ها را دارد. این فرد می‌تواند فراداده‌های سرویس را از طریق مستنداتی که سازمان در اختیارش قرار می‌دهد، پیدا کند، نحوه متصل کردن سرویس‌ها به یکدیگر را یاد بگیرد و در صورت لزوم، سرویس‌های موردنظر خود را توسعه دهد.
هر خدمات در معماری سرویس‌گرا، مبتنی بر کد و داده‌هایی است که برای اجرای کامل و مستقل یک سرویس مثل ارزیابی اعتبار مشتری، بررسی نحوه پرداخت ماهانه وام یا درخواست وام نیاز است. این رابط، از طریق عقد قرارداد میان ارائه‌دهنده و مصرف‌کننده در دسترس او قرار می‌گیرد.
در این حالت، برنامه‌های کاربردی مرتبط با سرویس به زبان‌های مختلف مثل جاوا، سی‌پلاس‌پلاس، گو و… قابل نوشته هستند و به شکل یک بسته نرم‌افزاری از طریق یک فروشنده، در قالب مدل نرم‌افزار به عنوان سرویس (SaaS) یا نرم‌افزارهای متن باز عرضه می‌شوند. همچنین، رابط‌های سرویس نیز عمدتا با استفاده از WSDL نوشته می‌شوند که ساختار برچسب‌گذاری استاندارد مبتنی بر XML است. نکته مهمی که باید به آن اشاره داشت، خدمات تعریف شده در معماری سرویس‌گرا است که باهدف ارسال درخواست‌های خواندن، تغییر و ویرایش داده‌ها انجام می‌شود و از پروتکل‌های استاندارد شبکه مثل SOAP، HTTP، Restful HTTP، SOAP و غیره استفاده می‌کنند. در این میان، چرخه عمر توسعه یک سرویس و نظارت بر آن، بر مبنای اصلی که حاکمیت سرویس (service governance) نام دارد، انجام می‌شود.
همان‌گونه که اشاره کردیم، معماری سرویس‌گرا (SOA) از پروتکل‌های استاندارد شبکه مانند SOAP/HTTP یا REST/HTTP برای ارسال درخواست‌ها باهدف خواندن یا تغییر داده‌ها استفاده می‌کند. این روش باعث می‌شود سرویس‌ها به شکل خوبی از ویژگی قابلیت استفاده مجدد پشتیبانی کنند و امکان استفاده از آن‌ها در برنامه‌های دیگر وجود داشته باشد.
به طور مثال، می‌توان سرویس‌ها را از ابتدا نوشت یا از سرویس‌های موجود استفاده کرد. در چند دهه گذشته، این رویکرد، نقش مهمی در فرآیند تکامل توسعه و یکپارچه‌سازی برنامه‌ها داشته است. قبل از ظهور SOA، اتصال یک برنامه به داده‌ها یا عملکردهای موجود در سیستم دیگری، نیاز به یکپارچه‌سازی پیچیده نقطه‌به‌نقطه داشت که توسعه‌دهندگان باید آن را برای هر پروژه توسعه، دوباره ایجاد می‌کردند. اکنون، SOA به توسعه‌دهندگان اجازه می‌دهد از قابلیت‌های موجود به راحتی استفاده کنند و از طریق معماری ESB سرنام (Enterprise Service Bus) به آن‌ها متصل شوند. اگرچه SOA و معماری میکروسرویس‌ها، کلمات مشترک زیادی دارند که “سرویس” و “معماری” دو مورد از آن‌ها هستند، اما تنها به صورت محدود مرتبط هستند و در واقع در سطوح مختلف عمل می‌کنند که در ادامه به آن اشاره خواهیم داشت.
ESB چیست؟
ESB سرنام (Enterprise Service Bus) یک معماری نرم افزاری است که به برنامه‌های مختلف اجازه می‌دهد با یکدیگر در ارتباط باشند. ESB می‌تواند داده‌ها را تبدیل کند، ارتباطات را مدیریت کند، و بین پروتکل‌های ارتباطی مختلف فرآیند تبدیل را انجام دهد. همچنین، ESB می‌تواند این قابلیت‌ها را به عنوان یک سرویس در اختیار برنامه‌های دیگر قرار دهد. این روش باعث می‌شود توسعه‌دهندگان مجبور به بازنویسی کدها نشوند و بتوانند از سرویس‌های موجود استفاده کنند. اگرچه استفاده از ESB برای پیاده‌سازی SOA ضروری نیست، اما می‌تواند به بهبود کارایی و مدیریت سیستم کمک کند. بدون ESB، هر برنامه باید مستقیما به سرویس‌های مورد نیاز خود متصل شود و همچنین فرآیند تبدیل داده‌ها نیز به صورت دستی انجام شود. این کار باعث افزایش پیچیدگی و هزینه نگهداری سیستم می‌شود. به همین دلیل، ESB به عنوان یک عنصر ضروری در پیاده‌سازی SOA شناخته می‌شود.
معماری سرویس گرا چه مزایایی در اختیار ما قرار می‌دهد؟
برای آن‌که بتوانیم مزایای معماری سرویس‌گرا را به خوبی شرح دهیم، اجازه دهید به مثال رستوان بازگردیم. یک رستوران شلوغ را تصور کنید. در این رستوران، هر بخش وظیفه خاصی دارد؛ آشپزخانه غذا می‌پزد، پیش‌خدمت سفارش می‌گیرد و نوشیدنی آماده می‌کند و حسابدار هزینه‌ها را محاسبه می‌کند. هر بخش مثل یک سرویس مستقل عمل می‌کند. بدون وجود معماری سرویس‌گرا، رستوران به دلیل عدم ویژگی تقسیم کار با مشکلات زیر روبرو می‌شود:
- آشپزخانه و پیش‌خدمت با یکدیگر هماهنگ نیستند و در نتیجه غذا دیر آماده شود یا اشتباه آورده می‌شود.
- اگر حسابدار نتواند هزینه‌ها را به درستی محاسبه کند، ممکن است رستوران دچار مشکل مالی شود.
بر مبنای معماری سرویس‌گرا که مبتنی بر تقسیم کار و سرویس‌های مستقل است، به خروجی زیر می‌رسیم:
- هر بخش کار خود را به بهترین نحو انجام می‌دهد و برای انجام بهتر کارها با بخش‌های دیگر در ارتباط است.
- اگر بخواهیم یک غذای جدید به منو اضافه کنیم، فقط نیاز است دستور پخت آن را به آشپزخانه بدهیم و به پیش‌خدمت اطلاع دهیم. بقیه بخش‌ها نیازی به تغییر ندارند.
- اگر بخواهیم سیستم پرداخت را تغییر دهیم، فقط نیاز است سیستم حسابداری را تغییر دهیم، بقیه بخش‌ها به کار خود ادامه می‌دهند.
بنابراین، بر مبنای مثال فوق، می‌توانیم به راحتی منو را تغییر دهیم، سیستم پرداخت را به‌روز کنیم یا بخش‌های جدیدی به رستوران اضافه کنیم، به طوری که هر بخش به صورت تخصصی به کار خود می‌پردازد و در نتیجه کارها سریع‌تر و دقیق‌تر انجام می‌شود. همچنین، نباید از این نکته غافل شویم که فرآیند تقسیم کار، احتمال بروز خطا را کاهش می‌دهد و قابلیت توسعه‌پذیری بالایی در اختیار ما قرار می‌دهد تا بتوانیم به راحتی بخش‌های موجود را توسعه داده یا بخش‌های جدید به رستوران اضافه کنیم.
همین قاعده در دنیای نرم‌افزار نیز صادق است. به‌طوری که بخش‌های مختلف یک نرم‌افزار مثل سرویس ثبت‌نام، سرویس پرداخت، سرویس ارسال ایمیل و غیره به شکل مستقل کار می‌کنند و راهکاری قدرتمند برای سازماندهی سرویس‌ها به صورت مستقل و قابل استفاده مجدد در اختیارمان قرار می‌گیرد. به عبارت ساده‌تر، SOA باعث می‌شود نرم‌افزارها مانند قطعات لگو باشند که بتوان آن‌ها را به راحتی با هم ترکیب کرد و نرم‌افزارهای جدیدی ساخت. این کار باعث می‌شود توسعه و نگهداری نرم‌افزارها بسیار آسان‌تر و سریع‌تر شود. همچنین، به این نکته باید اشاره کرد که معماری سرویس‌گرا (SOA) مزایای زیادی نسبت به معماری‌های دیگر دارد که از مهم‌ترین آن‌ها به موارد زیر باید اشاره کرد:
چابکی بیشتر کسب‌وکار: با استفاده از سرویس‌های با ویژگی قابلیت استفاده مجدد، می‌توان برنامه‌های جدید را سریع‌تر توسعه داد. این کار باعث می‌شود شرکت‌ها بتوانند به سرعت به فرصت‌های جدید تجاری پاسخ دهند.
یکپارچگی بهتر: SOA از یکپارچه‌سازی برنامه‌ها، داده‌ها و فرایندهای کسب‌وکار پشتیبانی می‌کند و به توسعه‌دهندگان اجازه می‌دهد زمان کمتری را صرف یکپارچه‌سازی کنند و بیشتر وقت خود را صرف توسعه و بهبود برنامه‌ها کنند.
استفاده از قابلیت‌های قدیمی در زمینه‌های جدید: SOA به توسعه‌دهندگان اجازه می‌دهد تا قابلیت‌های قدیمی را در محیط‌های جدید استفاده کنند. به طور مثال، بسیاری از شرکت‌ها از SOA در تعامل با سیستم‌های قدیمی یا برنامه‌های جدید وب استفاده می‌کنند.
همکاری بهتر بین کسب‌وکار و فناوری اطلاعات: در SOA، سرویس‌ها می‌توانند به زبان کسب‌وکار تعریف شوند که باعث می‌شود تحلیلگران کسب‌وکار بتوانند بهتر با توسعه‌دهندگان همکاری کنند و نتایج بهتری کسب کنند.
مثال‌هایی از معماری سرویس‌گرا
شرکت Delaware Electric از معماری سرویس‌گرا برای یکپارچه‌سازی سیستم‌های مختلفی استفاده کرد که قبلا با هم ارتباط نداشتند. این رویکرد باعث شد تا شرکت بتواند در طول یک دوره پنج ساله که نرخ‌های برق ثابت بود، به فعالیت خود ادامه دهد.
شرکت سیسکو (Cisco) از معماری سرویس گرا برای اطمینان از اینکه تجربه سفارش محصول در تمام محصولات و کانال‌ها یکسان است، استفاده کرد. این کار با ارائه فرآیندهای سفارش به عنوان سرویس انجام شد که بخش‌ها، شرکت‌های تابعه و شرکای تجاری سیسکو را با زیرساخت و زنجیره تامین این شرکت یکپارچه کرد.
شرکت IBC سرنام Independence Blue Cross نیز از معماری سرویس گرا برای اطمینان از اینکه همه افرادی که با داده‌های بیماران سر و کار دارند، از یک منبع داده استفاده می‌کنند، بهره برد. این کار باعث شد اطلاعات بیماران به شکل یکسان در اختیار کادر درمانی قرار بگیرد.
معماری سرویس گرا در مقابل میکروسرویس‌ها
اگر به وب‌سایت‌های معتبر مراجعه کنید، مشاهده می‌کنید که متخصصان هزاران صفحه برای مقایسه معماری فوق و میکروسرویس‌ها و تعریف تفاوت‌های ظریف رابطه آن‌ها با یکدیگر به رشته تحریر در آورده‌اند. با این‌حال، در ادامه سعی می‌کنیم، تفاوت‌های کمتر دیده شده را مورد بررسی قرار دهیم.
SOA یک سبک معماری یکپارچه‌سازی و یک مفهوم کلان است که قابلیت گسترش‌پذیری در تمام ساختارهای سازمانی را دارد، به ویژه زمانی که در تعامل با چارچوب BPMS مورد استفاده قرار گیرد. این معماری اجازه می‌دهد تا برنامه‌های موجود از طریق رابط‌های اتصال آزاد به یکدیگر متصل شوند. برنامه‌هایی که هریک به یک نیاز تجاری سازمان پاسخ می‌دهند. بنابراین، برنامه‌های مورد استفاده در یک بخش در صورت نیاز قادر به استفاده از خدمات دیگر بخش‌ها خواهند بود (قابلیت استفاده مجدد).
معماری میکروسرویس یک سبک معماری کاربردی و یک مفهوم در سطح برنامه است که اجازه می‌دهد تا قسمت‌های داخلی یک برنامه واحد به قطعات کوچک تقسیم شوند تا بتوان آن‌ها را به طور مستقل تغییر داد، مقیاس‌بندی و مدیریت کرد. البته، توجه داشته باشید که این روش نحوه ارتباط برنامه‌ها با یکدیگر را تعریف نمی‌کند، زیرا این فرآیند بر مبنای اتصال به دامنه شرکت از طریق رابط‌های ارائه شده توسط SOA است.
معماری میکروسرویس با ظهور مجازی‌سازی، رایانش ابری، روش‌های توسعه چابک و دواپس (DevOps) ظهور کرد و محبوبیت یافت. عامل اصلی موفقیت معماری میکروسرویس‌ها، تفکیک مولفه‌ها از یکدیگر است که دستیابی به اهداف زیر را ساده‌تر و دقیق‌تر می‌کند:
چابکی و بهره‌وری توسعه‌دهنده: میکروسرویس‌ها به توسعه‌دهندگان اجازه می‌دهند از فناوری‌های جدید در یک بخش از برنامه بدون تاثیرگذاری بر بقیه برنامه استفاده کنند. هر مولفه می‌تواند به طور مستقل از بقیه اصلاح، آزمایش و مستقر شود که چرخه‌های تکرار را سرعت می‌بخشد.
مقیاس‌پذیری: میکروسرویس‌ها می‌توانند از مقیاس‌پذیری ابری حداکثر بهره را ببرند – هر مولفه می‌تواند به طور مستقل از بقیه مولفه‌ها، باهدف پاسخ‌گویی سریع به بارهای کاری و استفاده بهینه از منابع محاسباتی مقیاس‌بندی شود.
انعطاف‌پذیری: باز هم، به لطف جداسازی، خرابی یک میکروسرویس بر بقیه تاثیر نمی‌گذارد و هر میکروسرویس می‌تواند بر اساس نیازها، در دسترس باشد، بدون اینکه مولفه‌های دیگر یا کل برنامه را تحت تاثیر قرار دهد.
نویسنده: حمیدرضا تائبی
