Каков наилучший способ открыть API через ESB?

Question

В настоящее время у нас есть количество компонентов, подвергая их API-интерфейсам REST и SOAP, а также количество существующих веб-приложений. Ниже представлен высокоуровневый вид некоторых конечных точек, имитирующих некоторые конечные точки с использованием образца домена, будет example.com

restsvc.example.com/v2 --ELB ---> | svr1.example.com/v2 |

soapsvc.example.com/v3 --ELB ---> | svr2.example.com/v3 |

corpwebapp.example.com --ELB ---> | svr1.example.com/someapp/index.html |

ncorpwebapp.example.com --ELB ---> | svr2.example.com/anotherapp/index.html |

Для решения различных сценариев использования мы внедрили ESB, и теперь все эти API и даже веб-приложения проксированы через ESB.

restsvc.example.com/v2 -ELB -> | esb.example.com: 8280/service/v2 | -> | svr1.example.com/v2 |

soapsvc.example.com/v2 -ELB -> | esb.example.com: 8280/service/v3 | -> | svr2.example.com/v3 |

corpwebapp.example.com -ELB -> | esb.example.com: 8380/someapp/index.html | -> | svr1.example.com/someapp/index.html |

nonwebapp.example.com -ELB -> | esb.example.com: 8480/someapp/index.html | -> | svr2.example.com/anotherapp/index.html |

Все эти общедоступные apis указывают на ESB, но теперь ESB раскрывает эти API и веб-приложения в разных портах и ​​конечных точках. Например: теперь приложение v2 прослушивает порт 8280 с помощью пути/службы/v2

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

У меня есть несколько вопросов

1. Является ли это правильный способ воздействия APIs через ESBS?
2. Является ли обработка портов и путей на уровне ELB нормальным и правильным поведением?
3. Является ли AWS ELB способным поддерживать это требование?
4. Если вопрос один отвечает «нет», хорошо ли иметь логику уровня посредничества для маршрутизации на разные серверы на основе шаблонов URL-адресов субдоменов и т. Д.?

Answer 1

После анализа некоторой информации и экспертных отзывов мы вводим эти политики и внедряем их в нашу инфраструктуру.

В идеале ESB должен прослушивать общие порты (80 или 443). Затем он должен посмотреть детали запроса и перенаправить запрос в различные приложения. Он может выполнять маршрутизацию на основе типа контента, URL-адреса запроса и т. Д.

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