#microservices #osgi #quarkus
Вопрос:
У меня есть приложение, разделенное на различные пакеты OSGI, которые работают на одном экземпляре Apache Karaf. Однако я хочу перейти на платформу микросервиса, потому что
- Apache Karaf довольно сложно настроить из-за его механизма зависимости и
- Я хочу иметь возможность позже перенести приложение в облако (AWS, GCloud, что угодно).
Я провел некоторое исследование, изучил различные фреймворки и пришел к выводу, что Quarkus может быть правильным выбором благодаря своему контейнерному подходу, производительности и возможным возможностям облачной интеграции.
Сейчас я борюсь в какой-то момент, и до сих пор я не нашел решения, но, возможно, у меня также может возникнуть недопонимание: мой план состоит в том, чтобы перенести почти каждый пакет OSGI моего приложения в отдельный микросервис. Таким образом, я мог бы масштабировать по горизонтали только те службы, для которых это необходимо, а также обновлять/развертывать их отдельно без необходимости перезапуска всего приложения. Таким образом, я предполагаю, что каждая служба должна запускаться в отдельном экземпляре Quarkus. Однако Кваркус, похоже, не поддерживает это из коробки?!? Вместо этого мне нужно было бы создать отдельную конфигурацию для каждого экземпляра Quarkus.
Действительно ли это правильный путь? Как службы могут обнаруживать друг друга? И есть ли способ, которым служба A может взаимодействовать со службой B не только с помощью вызовов REST, но также использовать объекты классов и методов службы B, включающие зависимость от службы B для службы A?
Большое спасибо за любые идеи по этому поводу!
Ответ №1:
Я думаю, что вы смешиваете некоторые моменты между микросервисами и приложениями на основе osgi. С микросервисами у вас обычно есть независимый процесс, выполняющий каждую микросервису, которая может быть развернута на тех же или других машинах. Благодаря этому вы можете масштабироваться, как вы сказали, и получать преимущества. Но модель коммуникации — это не процесс для процесса. Он должен использовать другой подход, и настоятельно рекомендуется использовать стандартный механизм интеграции, вы можете использовать REST, вы можете использовать Json RPC, SOAP или очереди или темы для использования связи, управляемой событиями. С помощью этих механизмов вы вызываете «другие» операции службы, как в osgi, но вы просто используете другой интерфейс, вместо локального вызова вы выполняете удаленный вызов.
Обнаружение служб-это то, что вы можете сделать, используя только виртуальные IP-адреса для доступа к другим службам через общее dns-имя и балансировщик нагрузки, или используя DNS kubernetes, если вы используете kubernetes в качестве платформы. Вы также можете использовать централизованную службу конфигурации или позволить каждой службе регистрироваться в центральном реестре. Для решения этой проблемы уже существует множество различных вариантов решений.
Также, что более важно, вам придется осознавать свои новые сложности, но некоторые из них у вас уже есть.
- Управление версиями и дизайном по контракту
- Синхронная или асинхронная связь между службами.
- Как бороться с безопасностью на границе сервисов / Нужна ли мне вообще безопасность в большинстве моих сервисов или мне просто нужна информация об идентификации пользователя.
- Увеличенные затраты на техническое обслуживание и избыточный дополнительный код для общих функций (здесь quarkus очень помогает вам с его расширениями, а также у вас есть совместимость с микропрофайлами).
- …
Решение использовать микросервисы-нелегкое решение, и его не следует принимать за один шаг. Моя рекомендация состоит в том, чтобы вы проанализировали домен своего приложения и попытались проверить, подходит ли ваш дизайн для работы с микросервисами (с точки зрения разделения концентраторов и согласованности моделей) и извлекли небольшие части вашей платформы osgi в микросервисы, в противном случае вам в основном придется вносить изменения в интерфейсы служб, что будет сложнее сделать из-за зависимости от контракта на обслуживание, чем изменить метод и некоторые вызовы.
Комментарии:
1. Большое спасибо за ваши идеи, которые очень помогают! 🙂 Единственный вопрос, который остается для меня, заключается в том, существует ли простой способ запустить несколько экземпляров quarkus на одной машине без необходимости создавать несколько конфигураций вручную? Поскольку я планирую запускать каждую микросервису в отдельном экземпляре, чтобы иметь возможность обновлять ее независимо от других запущенных служб, я ищу способ сделать этот процесс менее ручным и менее подверженным ошибкам.
2. Quarkus может прочитать свою конфигурацию из файла свойств внешнего приложения, вы можете создать его, а затем использовать для совместного использования конфигурации quarkus.io/guides/config-reference#configuration-sources . Имейте в виду, что некоторые конфигурации фиксируются во время сборки (те, что с блокировкой), другие могут быть перезаписаны во время выполнения. О каких конфигурациях мы говорим более конкретно ?
3. В принципе, мне нужно было бы настроить отдельный порт для каждого микросервиса. Поскольку некоторые микросервисы будут взаимодействовать друг с другом, мне также нужно будет предоставить им правильный URL-адрес для зависимых микросервисов.
4. @HansBlafoo Я бы хотел пойти с docker swarm или чем-то подобным, это немного упростит вашу жизнь в процессе предоставления услуг и их организации, хотя для производственной среды я бы использовал лучшие kubernetes. Если вы хотите сразу перейти к процессам java, вы можете сделать это с помощью файла env, просто сообщив порт quarkus с помощью аргументов командной строки и URL-адресов зависимых служб с помощью файла среды. Если вы используете клиент microprofile rest, вы можете переопределить местоположение во время выполнения с помощью файла свойств или переменной среды