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

Кстати да. Есть модель продукта "Э-башня" и модель изменяется достаточно с течением времени, чтобы выделить несколько темпоральных кусков. (Например версии КД на "Э-башню" можно принять за воплощение таких кусков).

Ну или по составу разделить на основании выделения когнитивных моделей "Э-башни" в разных головах)

Ясно, встал в очередь, спасибо)

Организуем с Денисом Бесковым мероприятие. Формат - онлайн. Буду рад видеть заинтересованных )

17 октября проводим онлайн-митап по проблемам организации проектирования в ИТ-проектах: https://sysanschool.timepad.ru/event/1085653/ вместе с участниками российского подразделения INCOSE

17 октября 18:00–20:00
- в какой таймзоне?

MSK

👍

Коллеги, выходного всем! Посоветуйте плиз как разрулить такой интеграционный сценарий.

Есть два корпоративных контура: внутренний (закрытая сеть филиала) и внешний, в который можно попасть из интернета (это в том числе для общения с другими филиалами). Между контурами все данные гоняются через activemq (по 1 экземпляру на каждой стороне контура, всё через них). Всё что мимо — режется.

Есть достаточно большая и сложная распределённая система на несколько филиальных сеток, которую менять крайне затруднительно. Сервисы в ней между собой обмениваются по grpc. Систему нужно задеплоить так, чтобы она работала в таких условиях прозрачно.  То есть сервисы общаются между собой, не понимая что они живут в разных филиалах и по пути у них есть самодельный межсетевой экран из activemq.

Что думаю: можно на входе в сеть каждого филиала ставить специальный сервис, который как-то будет собирать весь входящий grpc-трафик, забрасывать его в activemq во внешнем контуре, затем во внутреннем контуре аналогичный специальный сервис будет из actimemq вынимать сообщения и как-то рассылать их дальше внутри сети уже в виде grpc-сообщений. По сути — получается что-то типа хитрой прокси, “туннеля” для grpc-сообщений на базе activemq. Только вот не могу сообразить как это сделать прозрачно и вообще реализовать: такое ощущение, что тут с настройками сети/маршрутизации надо очень сильно выдумывать, какие-то vlan сложные делать, с адресацией что-то выдумывать и так далее.

Такая вот дичь. Кто что думает? ) Может, готовые решения есть или мысли?

на сколько связь просядет?.. и на долго встанет когда эти системы навернуться?

Связь сильно просядет, но не страшно для задачи

А может просто дописать приложульку что бы она могла в качестве транспорта amqp использовать ?

никак

Сетевой вариант, имхо, так и выглядит. Маршрутизировать трафик куда-то, дальше этот трафик оборачивается в mq, дальше ловится и распаковывается. Но это же дыра в безопасности. Любой сможет производить вызов этих процедур, а проверку можно будет устраивать только по адресам источникам запросов.
Проще такие запросы не на сетевом уровне обрабатывать. Так можно будет и доступ сконфигурировать полноценно.
А в чем ограничения по написанию такого софта, если не секрет?

вы реально там не смогли межсетевой трафик настроить?

Рассматривали вариант в каждый филиал воткнуть разделение на "внешний" и "внутренний" контуры, связать их туннелями на сетевом уровне, настроить на каждой стороне AMQ и настроить маршрутизацию сообщений между экземплярами AMQ ?

Кстати я вообще не видел решений на несколько филиальных сеток хотябы без EIGRP. У меня постоянно в таких ситуациях OSPF был прикручен. Ну и план IP-адресации на организацию в целом конечно обязательно.

Можно конечно вообще сделать q-n-q и сделать единую серверную подсеть на всю организацию, если политика это позволяет. И сделать 1 VLAN для всех серверов и сервисов. Если у вас там broadcast storm от этого не прогнозируется конечно =)

Да, разделение на контуры в каждом филиале уже имеется. В каждом контуре сидит по экземпляру AMQ и перекачивают данные туда-сюда. Беда, соответственно, в том, что grpc-сервисов много и кто его знает куда, как, когда и что они слать будут — поэтому мы хотим сделать “ловушку” (из чего?) для grpc, запаковывать его, бросать в amq, amq протолкнет в amq в другом контуре, оттуда забрать, распаковать, разослать дальше по сервисам. То есть что-то типа grpc-прокси, работающей с туннелем в виде AMQ. Но как это сделать — какой софт? Как обеспечить запаковывание это, как сделать чтобы имена/адреса нормально работали?
Вообще, может кто-то видел хотя бы кейсы http-прокси поверх amq/activemq? ) В принципе, grpc так-то — он на http 2 работает.

На мой взгляд, если нет понимания кто и куда что-то отправляет, то http/2 ловить на сетевом уровне как-то может и не получиться. Как миниумум, из-за TLS. Вам для начала хотя бы составить карту взаимодействий этих сервисов. А дальше уже можно через специальные шлюзы перенастроить их общение