Управление версиями веб-сервисов: ESB перебор?

Question

У нас есть несколько версий наших веб-сервисов (как REST, так и SOAP), и с каждым выпуском их число увеличивается.

Между версиями возможны незначительные изменения (обычно добавления новых полей).) на запросы и ответы.

Если бы нам пришлось удалить старые версии, как мы могли бы продолжать обслуживать запросы для старых версий?

Один из аспектов возможного решения заключается в создании «виртуальных конечных точек» для маршрутизации запросов для предыдущих версий кновые версии тех же сервисов.Таким образом, запросы на / v1 / customer / 1 отображаются на / v2 / customer / 1.Мы используем Mashery, с помощью которого это легко сделать.

Мы также хотим применить правила преобразования к запросам и ответам для генерации ответов XML и JSON, соответствующих старым контрактам.

Подводя итог, нам необходимо применять правила маршрутизации и преобразования ко всем входящим сообщениям и ответам.ESB излишне для этого?Наши критерии не совсем соответствуют критериям, изложенным в http://blogs.mulesoft.org/to-esb-or-not-to-esb/. Есть ли более простое решение этой проблемы?Тот, который не требует модификации нашего кода для реализации контроля версий запросов и ответов?

Answer 1

Если инструмент подходит ...

Если ESB, который вы рассматриваете, будет удовлетворять ваши потребности в версиях и преобразованиях, тогда используйте его.

ЧтоВы не хотите, «О, вот наш ESB слушает нашу единственную конечную точку для нашего единого веб-сервиса».Это просто безумие.

Мне кажется, ESB вполне может соответствовать вашим потребностям.Вам не нужно отмечать все коробки.Фактически, единственное поле, которое нужно отметить, это «стоит ли этот инструмент ресурсов и времени, чтобы изучить, использовать, поддержать и развернуть в нашей среде по сравнению с работой с тем, с чем нам удобнее».

Потому что одна проблема с такими программами, как ESB, заключается в том, что они могут поставляться с большим количеством материала и, таким образом, большим количеством документации, которая может быть сложной для новичка в платформе, чтобы пройтись и выбрать то, что уместно, и как его настроить..

Я бы взял ESB и выполнил пилот, а затем провел несколько тестов производительности.Если вы не тратите огромное количество времени на пилота, и, похоже, это сработает, тогда катитесь с ним.

Answer 2

Попробуйте UltraESB [http://adroitlogic.org], который показывает много примеров того, как можно выполнять маршрутизацию и преобразования.Вы также можете использовать тест в http://esbperformance.org для нагрузочного тестирования любого ESB, чтобы увидеть, насколько быстро они работают при маршрутизации, преобразованиях и т. Д. Это небольшой (~ 35 МБ) ESB, который не требует изменений кода или имеет крутое обучениекривая - когда вы пишете свои правила маршрутизации в виде пары строк Java или даже Javascript, Ruby, Groovy и т. д. - независимо от того, какой язык сценариев JSR 223 вам известен.

Answer 3

Некоторые компании, такие как IBM, разрабатывают программное обеспечение специально для вашего случая использования. У них в основном есть сервисный сервер реестра. Реестр сервисов действует как ваш псевдоним для всех ваших сервисов. Что еще более важно, большинство серверов реестра служб имеют рабочий процесс, который люди используют для продвижения, понижения, отмены, версии, уведомления пользователей службы о том, что что-то изменилось. Большинство людей называют рабочий процесс ... управление.

Answer 4

ESB может быть излишним для этого решения.Хотя мы можем отказаться от старой версии и иметь новые версии, что произойдет с клиентскими программами, которые все еще стремятся использовать старую версию службы.

Если мы изменили формат запроса / ответа в новой версии службы, клиенты, пытающиеся отправить старые форматы запросов, ожидают, что старые форматы ответов потерпят неудачу.Таким образом, мы не можем и не должны внезапно отключать старую версию сервиса, а постепенно отказываться от нее.Для этого нам нужны как старые, так и новые сервисы, работающие параллельно, по крайней мере, некоторое время.

Таким образом, введение ESB не решит проблему.Когда мы фактически удаляем старую службу, через некоторое время, которая позволяет клиентам, использующим старые, мигрировать на новые, мы можем перенаправить старые URL-адреса на новые.Однако нам не нужен ESB для этого, поскольку простое решение, такое как httpd mod_proxy или nginx, может сделать эту работу.

ESB действительно полезен для добавления значения посредничества сообщений между клиентами и фактическими конечными точками.Поэтому, независимо от того, существует ли так много исполняющих ESB , вам следует придерживаться простого и разумного решения для этого случая.