В недавней презентации, которую я готовил, я начал изучать, как настроить простое приложение на основе микросервисов, используя технологии, с которыми я знаком. Я начал использовать Java в 2014 году, и, хотите верьте, хотите нет, пока я работал над крупными корпоративными приложениями, в Spring у меня было немного работы. Бу-у-у, я не знаю, чего мне не хватает, какого черта ты тогда использовал?, Я знаю, знаю, знаю. Тем не менее, наверное, есть что-то для таких, как я. Так началось мое исследование.

Я, конечно, знаком с тем фактом, что я, вероятно, мог бы просто взять и изучить Spring в один миг, поскольку он не должен сильно отличаться, и, честно говоря, контейнеры приложений Java - это контейнеры приложений Java. У вас есть свой механизм DI, ваши bean-компоненты, ваше классное автоматическое управление памятью, ваши хуки жизненного цикла и определения областей действия, а также многое другое. Но я действительно хотел держаться подальше от этого, поскольку я мог делать все, что хотел, я не хотел делать что-то СЛИШКОМ обычное.

Я начал изучать Payara Micro? Почему? Я думаю, что это одна из первых инициатив, которые я увидел, когда Microprofile только выходил, и она основана на действительно испытанном сервере приложений Glassfish от Oracle. Я также думаю, что это (не 100%, если это все еще так, но определенно было) эталонная реализация Java EE. Означает, что это то, на что смотрят все другие нереференсные реализации и чего они хотят, когда вырастут. 😏

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

Так что же такое микросервисная архитектура? По сути, это набор сервисов, заявивших о своей независимости. Что это значит, они не совсем уверены все время, так как практически все используют их по-своему, и в Интернете есть масса ресурсов о том, как это сделать, какой фреймворк использовать, какой язык и т. д. Одна из приятных вещей о дело в том, что теоретически он должен ускорить время выхода на рынок, имея отдельные развертываемые компоненты, каждый со своим собственным конвейером сборки и так далее. Это также может означать, что в более крупных отделах разные команды могут отвечать за разные службы, что еще больше усилит независимый дизайн. Когда вы думаете об этом, то иногда может быть полезно не думать о других разделах приложения в голове, когда вы проектируете свою маленькую часть. Это действительно воплощение парадигмы «программа-интерфейс», если вы взаимно определяете принятый протокол.

Еще одна не менее крутая вещь — быстрое развитие стека технологий. Вы знаете, как ваша работа была бы намного круче, если бы вам не приходилось работать с 10-летней техникой? Спросите себя, зачем изучать последние функции Java, если мы все равно находимся на Java 8? Люди говорят о CQRS, реактивности, сагах, непрерывной интеграции, доменно-ориентированной разработке, гексагональных архитектурах, бла-бла-бла…. все это вызывает у вас мурашки по спине, и вы неохотно смотрите на часы, говоря, что вам нужно быть где-то еще? Что ж, микросервисы могут помочь вернуть контроль над поддержанием ваших технологий в актуальном состоянии, а также улучшить вашу социальную жизнь.

Ты должен с чего-то начать, верно? Вы знаете, что в Spring Boot есть это замечательное стартовое приложение, которое вы можете использовать для создания шаблона для вашего первоначального сервиса? Что ж, очевидно, OpenLiberty, Payara, Micronaut и другие приняли этот подход генерировать проект, и я думаю, что это круто. Хотя я пошел другим путем. Я хотел создать свое приложение на основе Payara Micro, которая представляет собой урезанный корпоративный стек Jakarta EE, чтобы она запускалась быстро и была очень легкой. Это также потому, что я действительно не хотел использовать реализацию JPA (не кидайте в меня гнилыми яблоками, я просто хотел поиграть с вещами!). Поскольку я больше увлекаюсь функциональным программированием, я всегда хотел дать Speedment шанс. Хотя у него классная интеграция с JPA, у него также есть собственный ORM на основе потоков, и это то, на что я действительно смотрел. Бизнес JPAstreamer кажется обратной совместимостью и инструментом для включения уже существующих больших приложений, но я начинал что-то новое, так почему бы и нет.

В качестве хранилища данных я выбрал MariaDB, так как его поддерживает бесплатная версия Speedment. Они предлагают классный генератор, который я использовал для создания корневого (родительского) проекта Maven. Затем мне стало любопытно, как я могу создать отдельные дома для кода микросервиса, поскольку я хотел использовать монорепозиторий для своего нового и блестящего приложения. Монорепозиторий означает, что весь код будет находиться в одном и том же пространстве Git. Я думаю, это удобно.

Согласно Payara Docs, я мог бы использовать архетип Maven для создания нового сервиса. Итак, я записал компакт-диск домой к моему проекту и сделал:

$ mvn archetype:generate -DarchetypeGroupId=fish.payara.maven.archetypes -DarchetypeArtifactId=payara-micro-maven-archetype -DarchetypeVersion=1.0.1 -DgroupId=com.company.bookapp -DartifactId=book-lookup-service -Dversion=1.0-SNAPSHOT -Dpackage=com.company.bookapp -Darchetype.interactive=false

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

Это добавит новый модуль в ваш родительский pom и создаст все, что вам нужно, чтобы ваш новый проект работал как один большой монолит (шучу…). Затем вы можете создать Dockerfile внутри вашего нового сервиса и docker-compose.yml в своем родительском проекте (тот, который создан с помощью Speedment). Для этого случая это довольно просто. Вам нужно создать свой образ на основе существующего образа Payara Micro, а затем просто добавить созданный военный файл. Итак, что-то вроде:

FROM payara/micro:6.2023.1
COPY target/book-lookup-service-1.0-SNAPSHOT.war $DEPLOY_DIR
CMD [“--deploymentDir”, “/opt/payara/deployments”, “--contextroot”, “book-lookup”]

Я не очень уверен в последней строке, но я думаю, что она дает некоторый контроль над тем, как вы запускаете свой сервер. Крутая вещь, которую делает Docker, заключается в том, что он кэширует каждую строку в Dockerfile, поэтому, если он обнаружит, что ваше приложение не изменилось, он просто начнет с фактического выполнения любой из строк кода, объявленных там. Для приложений на основе Jakarta EE это удобно, поскольку основа вашего приложения, то есть сервер приложений, никогда не изменится, и его не нужно будет перестраивать. Команда Payara также предлагает подход uber-jar, но я хочу воспользоваться преимуществом этого кэширования Docker, поэтому я использовал старые старые военные архивы для своего приложения.

Последнее, о чем я хочу рассказать в этой статье, — это склейка. Я делаю это через файл docker-compose.yml, где я объявляю все службы, которые нужны моему приложению. Поскольку я придерживаюсь подхода микросервисов, я создам отдельный экземпляр базы данных для каждого из моих сервисов, чтобы у них не было соблазна использовать SQL в бизнесе друг друга 😅

version: "2.1"

services:
    maria-db:
        image: bitnami/mariadb:latest
        ports:
            - "3336:3306"
        volumes:
            - "~/my-app/data/books-lookup-db:/bitnami/mariadb"
        environment:
            - ALLOW_EMPTY_PASSWORD=yes
            - MARIADB_DATABASE=books-lookup-db
            - MARIADB_USER=user
            - MARIADB_PASSWORD=password
    book-lookup-service:
        build:
            context: book-lookup-service
            dockerfile: Dockerfile
        ports:
            - "8081:8080"
        depends_on:
            - maria-db

Это будет ссылаться на папку в моей текущей структуре. Сам файл docker-compose.yml будет находиться рядом с родительским файлом pom.xml, то есть в корне проекта.

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

Спасибо за прочтение! Сайя в следующий раз!