КОллеги,
может быть не в ту ветку пишу, но прошу помощи.
У нас в Компании целый зоопарк различных систем написанных на разных языках и объединённых между собой через разнообразные синхронизации.
Хотелось бы это всё заменить на бесплатную ESB, но разнообразие их большое и не понятно в какую сторону смотреть.
Основные языки разработки внутри C# и немного Php.
Можете рассказать у кого есть положительный опыт по работе с ServiceMix, OpenESB или других шин?
Здравствуйте, awod, Вы писали:
A>КОллеги, A>может быть не в ту ветку пишу, но прошу помощи. A>У нас в Компании целый зоопарк различных систем написанных на разных языках и объединённых между собой через разнообразные синхронизации. A>Хотелось бы это всё заменить на бесплатную ESB, но разнообразие их большое и не понятно в какую сторону смотреть. A>Основные языки разработки внутри C# и немного Php. A>Можете рассказать у кого есть положительный опыт по работе с ServiceMix, OpenESB или других шин?
Если уровень технической культуры позволяет, я бы предпочел интеграцию через REST. Синхронные сетевые вызовы предсказуемее, но требуют service discovery, асинхронный код, управление таймаутами и т.п.
Для начала хорошо бы определиться, чего вы ждёте от интеграционной шины: тупо ли это асинхронный транспорт или нужны специфические фичи (e.g. управление временем жизни компонентов, активация, кластеризация, автомасштабирование под нагрузкой, мониторинг, адаптеры протоколов и т.п.)
У меня с MassTransit был в целом положительный опыт, посмотрите на ее.
Но вообще в эпоху микросервисов с их "dumb pipes, smart endpoints" идея использования шины выглядит странноватой.
Здравствуйте, RushDevion, Вы писали:
RD>Для начала хорошо бы определиться, чего вы ждёте от интеграционной шины: тупо ли это асинхронный транспорт или нужны специфические фичи (e.g. управление временем жизни компонентов, активация, кластеризация, автомасштабирование под нагрузкой, мониторинг, адаптеры протоколов и т.п.) RD>У меня с MassTransit был в целом положительный опыт, посмотрите на ее. RD>Но вообще в эпоху микросервисов с их "dumb pipes, smart endpoints" идея использования шины выглядит странноватой.
У нас логистическая компания. Основный пользователе ИТ это склад, курьеры, пункты выдачи заказов, интернет-магазины, получатели отправлений.
Операции которые они делают:
1. посчитать стоимость доставки
2. создать доставку
3. записать состояние доставки
4. вернуть состояние доставки
при этом с сезон количество заказов увеличивается в 5 раз по сравнению с не сезоном, что требует дышащей по производительности ИТ системы.
Выбор как раз сейчас стоить между шиной и реализацией микросервисов на кубере.
С кубером более менее понятно, но требуется много физических ресурсов, чтобы его поддерживать.
По шине (рассматривали Apache ServiceMix) плюсы это очереди, кэши и возможность связать уже имеющиеся сервисы между собой через него. Итогом может быть единый фасад всех вебсервисов, которые мы можем опубликовать и дать к ним доступ всем желающим.
Понятно.
Ну сложно что-то ещё посоветовать.
Единственное что Apache — это больше Java стек. Под .NET обычно что-то из NServiceBus, MassTransit, Azure Service Fabric с обвязкой смотрят.
В общем, я бы попробовал набросать минимальный proof of concept, чтобы понять насколько идея работоспособна.