Блог

У меня есть приложение, разделенное на различные пакеты OSGI, которые работают на одном экземпляре Apache Karaf. Однако я хочу перейти на платформу микросервиса, потому что

• Apache Karaf довольно сложно настроить из-за его механизма зависимости и
• Я хочу иметь возможность позже перенести приложение в облако (AWS, GCloud, что угодно).

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

Сейчас я борюсь в какой-то момент, и до сих пор я не нашел решения, но, возможно, у меня также может возникнуть недопонимание: мой план состоит в том, чтобы перенести почти каждый пакет OSGI моего приложения в отдельный микросервис. Таким образом, я мог бы масштабировать по горизонтали только те службы, для которых это необходимо, а также обновлять/развертывать их отдельно без необходимости перезапуска всего приложения. Таким образом, я предполагаю, что каждая служба должна запускаться в отдельном экземпляре Quarkus. Однако Кваркус, похоже, не поддерживает это из коробки?!? Вместо этого мне нужно было бы создать отдельную конфигурацию для каждого экземпляра Quarkus.

Действительно ли это правильный путь? Как службы могут обнаруживать друг друга? И есть ли способ, которым служба A может взаимодействовать со службой B не только с помощью вызовов REST, но также использовать объекты классов и методов службы B, включающие зависимость от службы B для службы A?

Большое спасибо за любые идеи по этому поводу!

Я думаю, что вы смешиваете некоторые моменты между микросервисами и приложениями на основе osgi. С микросервисами у вас обычно есть независимый процесс, выполняющий каждую микросервису, которая может быть развернута на тех же или других машинах. Благодаря этому вы можете масштабироваться, как вы сказали, и получать преимущества. Но модель коммуникации — это не процесс для процесса. Он должен использовать другой подход, и настоятельно рекомендуется использовать стандартный механизм интеграции, вы можете использовать REST, вы можете использовать Json RPC, SOAP или очереди или темы для использования связи, управляемой событиями. С помощью этих механизмов вы вызываете «другие» операции службы, как в osgi, но вы просто используете другой интерфейс, вместо локального вызова вы выполняете удаленный вызов.

Обнаружение служб-это то, что вы можете сделать, используя только виртуальные IP-адреса для доступа к другим службам через общее dns-имя и балансировщик нагрузки, или используя DNS kubernetes, если вы используете kubernetes в качестве платформы. Вы также можете использовать централизованную службу конфигурации или позволить каждой службе регистрироваться в центральном реестре. Для решения этой проблемы уже существует множество различных вариантов решений.

Также, что более важно, вам придется осознавать свои новые сложности, но некоторые из них у вас уже есть.

• Управление версиями и дизайном по контракту
• Синхронная или асинхронная связь между службами.
• Как бороться с безопасностью на границе сервисов / Нужна ли мне вообще безопасность в большинстве моих сервисов или мне просто нужна информация об идентификации пользователя.
• Увеличенные затраты на техническое обслуживание и избыточный дополнительный код для общих функций (здесь quarkus очень помогает вам с его расширениями, а также у вас есть совместимость с микропрофайлами).
• …

Решение использовать микросервисы-нелегкое решение, и его не следует принимать за один шаг. Моя рекомендация состоит в том, чтобы вы проанализировали домен своего приложения и попытались проверить, подходит ли ваш дизайн для работы с микросервисами (с точки зрения разделения концентраторов и согласованности моделей) и извлекли небольшие части вашей платформы osgi в микросервисы, в противном случае вам в основном придется вносить изменения в интерфейсы служб, что будет сложнее сделать из-за зависимости от контракта на обслуживание, чем изменить метод и некоторые вызовы.