گذرگاه سرویس سازمانی (ESB) چیست؟

(پیاده‌سازی ESB در AWS)

در ادامه، اجزای کلیدی معماری ESB را بررسی می‌کنیم.

نقاط پایانی (Endpoints)

در معماری ESB، نقاط پایانی را می‌توان به عنوان نقاط ورود یا خروج به ESB در نظر گرفت.

هر نقطه پایانی معمولاً یک آدرس یا شناسه منحصر به فرد دارد. می‌توانید نقاط پایانی را با استفاده از فناوری‌های مختلفی مانند رابط وب سرویس، صف‌های پیام یا سرورهای FTP پیاده‌سازی کنید. نقاط پایانی همچنین می‌توانند انواع مختلف پیام مانند XML، JSON یا داده‌های باینری را پردازش کنند.

انعطاف‌پذیری معماری نقطه پایانی به ESB امکان ادغام با طیف گسترده‌ای از سیستم‌ها و برنامه‌ها را می‌دهد.

آداپتور (Adapter)

جزء آداپتور در ابزارهای ESB پیام‌ها را بین فرمت‌ها و پروتکل‌های مختلف ترجمه می‌کند. این بدان معناست که برنامه‌های نرم‌افزاری گیرنده می‌توانند آنها را به درستی مصرف کنند. همچنین ممکن است ویژگی‌هایی مانند ثبت پیام، نظارت، احراز هویت و مدیریت خطا را ارائه دهد.

گذرگاه (Bus)

گذرگاه جزء اصلی ESB برای تبادل پیام بین نقاط پایانی است. از مجموعه‌ای از قوانین یا سیاست‌ها بر اساس معیارهای مختلف مانند نوع پیام، محتوا یا مقصد برای مسیریابی پیام‌ها استفاده می‌کند.می‌توانید سیاست‌ها را در پیکربندی ESB برای برآورده کردن الزامات فرآیندهای پیچیده تجاری تعریف کنید. از پروتکل‌های ارتباطی مختلفی مانند HTTP، JMS و FTP برای ارتباط با نقاط پایانی استفاده می‌کند.

نحوه عملکرد گذرگاه به این صورت است:

• گذرگاه پیام را در یک نقطه پایانی دریافت می‌کند.
• با بررسی قوانین سیاست تجاری، آدرس نقاط پایانی مقصد را تعیین می‌کند.
• پیام را پردازش کرده و به نقطه پایانی مقصد ارسال می‌کند.

به عنوان مثال، فرض کنید گذرگاه یک فایل XML را از یک برنامه متصل به نقطه پایانی A دریافت می‌کند. تعیین می‌کند که فایل XML باید به نقاط پایانی B و C ارسال شود. نقطه پایانی B به داده‌های JSON نیاز دارد در حالی که نقطه پایانی C به تابع HTTP Put نیاز دارد. آداپتور فایل XML را به JSON تبدیل می‌کند و گذرگاه آن را به نقطه پایانی B ارسال می‌کند. گذرگاه یک درخواست HTTP با XML در نقطه پایانی C انجام می‌دهد.

محدودیت‌های گذرگاه سرویس سازمانی (ESB) چیست؟

معماری سازمانی به دلیل محدودیت‌های زیر از گذرگاه سرویس سازمانی (ESB) فاصله گرفته است.

پیچیدگی

پیاده‌سازی و نگهداری ESB به دانش فنی تخصصی نیاز دارد که آن را پیچیده و پرهزینه می‌کند. قفل شدن به فروشنده، تغییر به یک راه‌حل ESB دیگر را دشوار می‌کند و گزینه‌های ادغام داده را محدود می‌کند. تیم‌ها زمان انتظار طولانی را تجربه می‌کنند زیرا فقط تیم مدیریت مرکزی ESB می‌تواند برنامه‌های سازمانی جدید را ادغام کند.

مقیاس‌پذیری

نرم‌افزار ESB به دلیل لایه‌های انتزاع و پردازش اضافی، تأخیر بیشتری در ارتباط ایجاد می‌کند. با افزایش تعداد نقاط پایانی و نقشه‌برداری خدمات ارتباطی، ESB به یک گلوگاه تبدیل می‌شود و بر عملکرد تأثیر می‌گذارد. هزینه پیاده‌سازی دسترسی بالا و بازیابی فاجعه برای سرورهای ESB نیز افزایش می‌یابد.

دشواری ارتقا

ایجاد بهبود در یکپارچگی ESB ممکن است باعث بی‌ثباتی در سایر اجزای متصل شود و قبل از به‌روزرسانی به آزمایش قابل توجهی نیاز دارد. تأمین بودجه ارتقاء پروژه‌های ESB به همکاری بین تیمی نیاز دارد که می‌تواند چالش برانگیز باشد.

چه فناوری‌هایی جایگزین گذرگاه‌های سرویس سازمانی می‌شوند؟

امروزه، استفاده از گذرگاه‌های سرویس سازمانی (ESB) عمدتاً به سیستم‌های قدیمی که نیاز به ادغام‌های پیچیده دارند محدود شده است. الگوی معماری ESB با معماری میکروسرویس‌ها، در میان سایر فناوری‌ها، جایگزین شده است.معماری میکروسرویس‌ها از اجزای نرم‌افزاری بسیار کوچک و کاملاً مستقل با پروتکل‌های ارتباطی خود تشکیل شده است که از طریق APIهای سبک وزن در معرض نمایش قرار می‌گیرند. اساساً وظیفه مصرف‌کننده استفاده از میکروسرویس از طریق API آن است، بنابراین نیاز به یک ESB متمرکز را از بین می‌برد.برای اطلاعات بیشتر، می‌توانید درباره میکروسرویس‌ها و درباره APIها مطالعه کنید.ظهور رایانش ابری و معماری میکروسرویس‌ها منجر به ظهور فناوری‌های جدیدی شده است که اغلب به عنوان جایگزینی برای ESBها در نظر گرفته می‌شوند. در ادامه به برخی از آنها می‌پردازیم.

دروازه‌های API (API gateways)

دروازه‌های API اجزای سبک وزنی هستند که یک نقطه ورود واحد برای مشتریان فراهم می‌کنند تا به چندین سرویس دسترسی داشته باشند. آنها اغلب برای مدیریت APIها، اعمال امنیت و مدیریت ترافیک استفاده می‌شوند.

مش سرویس (Service mesh)

مش سرویس یک لایه زیرساخت اختصاصی برای مدیریت ارتباط سرویس به سرویس در یک معماری میکروسرویس‌ها است. ویژگی‌هایی مانند کشف سرویس، تعادل بار و مدیریت ترافیک را ارائه می‌دهد.

معماری رویداد محور (Event-driven architecture)

در یک معماری رویداد محور، سرویس‌ها از طریق مدیریت رویداد ناهمزمان به جای درخواست‌های همزمان ارتباط برقرار می‌کنند. یک رویداد، تغییری در وضعیت یا یک به‌روزرسانی است، مانند قرار دادن یک مورد در سبد خرید در یک وب‌سایت تجارت الکترونیک. رویدادها می‌توانند وضعیت (مورد خریداری شده، قیمت آن و آدرس تحویل) را حمل کنند یا شناسه‌ها (اعلان ارسال سفارش) باشند.

گذرگاه رویداد (Event bus) چیست؟

بسیاری از سازمان‌ها از گذرگاه‌های سرویس سازمانی (ESB) به گذرگاه‌های رویداد منتقل شده‌اند. گذرگاه رویداد یک خط لوله است که رویدادها را دریافت می‌کند. اجزای برنامه را بر اساس رویدادها به هم متصل می‌کند، که ساخت برنامه‌های رویداد محور مقیاس‌پذیر را برای شما آسان‌تر می‌کند.