Учим как да развиваме микросервиси. Част 1. Spring Boot и Docker

Здравей, Хабр.

В тази статия искам да споделя опита си в създаването на учебна среда за експериментиране с микросервизи. Когато изучавам всеки нов инструмент, винаги съм искал да го пробвам не само на локалната машина, но и при по-реалистични условия. Затова реших да създам опростено микросервисно приложение, което впоследствие може да бъде "обогатено" с всевъзможни интересни технологии. Основното изискване към проекта е максималната функционална близост до реална система.

Първоначално разделих създаването на проекта на няколко стъпки:

1. Създаване на две услуги – ‘бекенд’ (backend) и ‘шлюз’ (gateway), опаковане в docker образи и настройка на тяхната съвместна работа

   Ключови думи: Java 11, Spring Boot, Docker, оптимизация на изображения

2. Разработка на конфигурация за Kubernetes и деплой на системата в Google Kubernetes Engine

   Ключови думи: Kubernetes, GKE, управление на ресурси, автоматично мащабиране, тайни

3. Създаване на чарт с помощта на Helm 3 за по-ефективно управление на клъстера

   Ключови думи: Helm 3, разгръщане на чарт

4. Настройка на Jenkins и пайплайн за автоматично доставяне на кода в клъстера

   Ключови думи: конфигурация на Jenkins, плъгини, отделен репозиторий за конфигурации

На всяка стъпка планирам да посветя отделна статия.

Целта на този цикъл статии не е как да напишем микросервизи, а как да ги накараме да работят в единна система. Въпреки че всичко това обикновено пада извън отговорността на разработчика, мисля, че е полезно да бъдеш запознат с тях поне на 20% (които, както е известно, дават 80% от резултата). Някои изключително важни теми, като осигуряване на сигурност, ще бъдат оставени извън обсъждане, тъй като авторът не разбира много от това, системата се създава изцяло за лична употреба. Ще се радвам на всякакви мнения и конструктивна критика.

Създаване на микросервизи

Услугите бяха написани на Java 11, използвайки Spring Boot. Взаимодействието между услугите е организирано с помощта на REST. Проектът ще включва минимално количество тестове (за да има какво да се тества в Jenkins). Изходният код на услугите е наличен в GitHub: бекенд и шлюз.

За да имате възможност да проверите състоянието на всеки от сервисите, в зависимостите им беше добавен Spring Actuator. Той ще създаде ендпойнт /actuator/health и ще връща статус 200, ако сервисът е готов да приема трафик, или 504 в случай на проблеми. В този случай това е доста символична проверка, тъй като сервисите са много прости и при някакъв форсмажор те по-скоро ще станат напълно недостъпни, отколкото да запазят частична работоспособност. Но в реални системи Actuator може да помогне за диагностицирането на проблема, преди потребителите да започнат да се оплакват. Например, при възникване на проблеми с достъпа до БД, ние ще можем автоматично да реагираме, прекратявайки обработката на заявки от повреден екземпляр на сервиза.

Сервиз Backend

Сервисът бекенда просто ще брои и ще връща броя на получените заявки.

Код на контролера:

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

    @GetMapping("/requests")
    public Long getRequestsCount() {
        return counter.incrementAndGet();
    }
}

Тест на контролера:

@WebMvcTest(RequestsCounterController.class)
public class RequestsCounterControllerTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void firstRequest_one() throws Exception {
        mockMvc.perform(get("/requests"))
            .andExpect(status().isOk())
            .andExpect(MockMvcResultMatchers.content().string("1"));
    }
}

Сервиз Gateway

Шлюзът ще пренасочва заявките към сервиза бекенд и ще ги допълва с информацията:

• ид на шлюза. Необходим е, за да можем да различим различните екземпляри на шлюза по отговора от сървъра
• Някакъв "секрет", който ще играе роля на много важна парола (№ на ключа за криптиране на важна бисквитка)

Конфигурация в application.properties:

backend.url=http://localhost:8081
instance.id=${random.int}
secret="default-secret"

Адаптер за връзка с бекенда:

@Service
public class BackendAdapter {

    private static final String REQUESTS_ENDPOINT = "/requests";

    private final RestTemplate restTemplate;

    @Value("${backend.url}")
    private String backendUrl;

    public BackendAdapter(RestTemplateBuilder builder) {
        restTemplate = builder.build();
    }

    public String getRequests() {
        ResponseEntity response = restTemplate.getForEntity(
backendUrl + REQUESTS_ENDPOINT, String.class);
        return response.getBody();
    }
}

Контролер:

@RestController
@RequiredArgsConstructor
public class EndpointController {

    private final BackendAdapter backendAdapter;

    @Value("${instance.id}")
    private int instanceId;

    @Value("${secret}")
    private String secret;

    @GetMapping("/")
    public String getRequestsCount() {
        return String.format("Брой заявки %s (гейтуей %d, секрет %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

Стартиране:

Стартираме бекенда:

./mvnw package -DskipTests
java -Dserver.port=8081 -jar target/microservices-backend-1.0.0.jar

Стартираме шлюза:

./mvnw пакет -DskipTests
java -jar target/microservices-gateway-1.0.0.jar

Проверяваме:

$ curl http://localhost:8080/
Брой заявки 1 (gateway 38560358, секрет "default-secret")

Всичко работи. Внимателният читател ще отбележи, че нищо не ни пречи да се обърнем към бекенда директно, заобикаляйки шлюза (http://localhost:8081/requests). За да го поправим, услугите трябва да бъдат обединени в една мрежа, а навън "да стърчи" само шлюзът.
Също така и двата сървиса споделят една файлова система, множат потоци и в един момент могат да започнат да се пречат един на друг. Налага се да изолираме нашите микросервиси. Това може да се постигне чрез разпределяне на приложенията на различни машини (много пари, сложно), използване на виртуални машини (ресурсоемко, дълъг старт) или чрез контейнеризация. Очаквано избираме третия вариант и Docker като инструмент за контейнеризация.

Docker

Накратко, Docker създава изолирани контейнери, по един за приложение. За да използвате Docker, трябва да напишете Dockerfile — инструкция за изграждане и пускане на приложението. След това ще можете да изградите образ, да го качите в регистър за образи (№ DockerHub) и с една команда да развернете своя микросервис в околната среда с Docker.

Dockerfile

Една от най-важните характеристики на образа е неговият размер. Компактният образ по-бързо ще бъде изтеглен от отдалечен репозиторий, ще заеме по-малко място и вашият сервис ще стартира по-бързо. Всеки образ се изгражда на базата на основен образ и се препоръчва да се избере най-минималистичната версия. Добър вариант е Alpine — пълен дистрибутив на Linux с минимум пакети.

За начало ще опитаме да напишем Dockerfile "в лицето" (веднага казвам, че това е лош начин, не го правете):

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests
EXPOSE 8080
ENTRYPOINT ["java","-jar","target/microservices-gateway-1.0.0.jar"]

Тук използваме основен образ, базиран на Alpine, с вече инсталирано JDK за изграждане на нашия проект. С командата ADD добавяме текущата директория src в образа, определяме я като работна (WORKDIR) и стартираме изграждането. Командата EXPOSE 8080 сигнализира на Docker, че приложението в контейнера ще използва неговия порт 8080 (това не прави приложението достъпно навън, но ще позволи достъп до приложението, например, от друг контейнер в същата мрежа на Docker).

За да опаковате услугите в образи, трябва да изпълните командите от корена на всеки проект:

docker image build . -t msvc-backend:1.0.0

В резултат получаваме образ с размер 456 Мбайта (от които основният образ JDK зае Мбайта). И всичко това, при положение че класовете в нашия проект могат да се преброят на пръстите на едната ръка. За да намалим размера на нашия образ:

• Използваме многостепенна компилация. На първата стъпка ще компилираме проекта, на втората ще инсталираме JRE, а на третата стъпка ще копираме всичко в нов чист образ Alpine. В крайния образ ще останат само необходимите компоненти.
• Ще се възползваме от модулизацията на java. Започвайки от Java 9, можем с помощта на инструмента jlink да създадем JRE само от необходимите модули.

За любопитните, ето добра статия за подходите за намаляване на размерите на образа. https://habr.com/ru/company/ruvds/blog/485650/.

Краен Dockerfile:

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine as builder
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests

FROM alpine:3.10.3 as packager
RUN apk --no-cache add openjdk11-jdk openjdk11-jmods
ENV JAVA_MINIMAL="/opt/java-minimal"
RUN /usr/lib/jvm/java-11-openjdk/bin/jlink 
    --verbose 
    --add-modules 
        java.base,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument 
    --compress 2 --strip-debug --no-header-files --no-man-pages 
    --release-info="add:IMPLEMENTOR=radistao:IMPLEMENTOR_VERSION=radistao_JRE" 
    --output "$JAVA_MINIMAL"

FROM alpine:3.10.3
LABEL maintainer="Anton Shelenkov anshelen@yandex.ru"
ENV JAVA_HOME=/opt/java-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"
COPY --from=packager "$JAVA_HOME" "$JAVA_HOME"
COPY --from=builder /src/target/microservices-backend-*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

Пресъздаваме образа и той в крайна сметка е намалял 6 пъти, достигайки 77 Мбайта. Не е зле. След това готовите образи могат да бъдат качени в регистъра на образите, за да бъдат достъпни за сваляне от интернет.

Съвместно стартиране на услуги в Docker

Първо нашите услуги трябва да бъдат в една мрежа. В Docker съществуват няколко типа мрежи, и ние използваме най-простия от тях — bridge, който позволява обединяване на контейнери, стартирани на един хост, в мрежа. Ще създадем мрежата с командата:

docker network create msvc-network

След това ще стартираме контейнер за бекенда с името ‘backend’ с образ microservices-backend:1.0.0:

docker run -dit --name backend --network msvc-net microservices-backend:1.0.0

Струва си да се отбележи, че bridge мрежата предоставя автоматично откриване на услуги за контейнерите по техните имена. Тоест, услугата бекенд ще бъде достъпна вътре в Docker мрежата на адрес http://backend:8080.

Стартираме шлюза:

docker run -dit -p 80:8080 --env secret=my-real-secret --env BACKEND_URL=http://backend:8080/ --name gateway --network msvc-net microservices-gateway:1.0.0

В този екип посочваме, че пренасочваме 80 порта на нашия хост на 8080 порта на контейнера. Опцията env използваме за задаване на променливи на средата, които автоматично ще бъдат извлечени от Spring и ще заместят свойствата от application.properties.

След стартиране извикваме http://localhost/ и се уверяваме, че всичко работи, както в предишния случай.

Заключение

В крайна сметка създадохме два опростени микросервиза, опаковахме ги в Docker контейнери и ги стартирахме съвместно на една машина. Въпреки това, получената система има ред недостатъци:

• Лоша отказоустойчивост — всичко работи на един сървър
• Лоша мащабируемост — при увеличаване на натоварването би било добре автоматично да се разгръщат допълнителни екземпляри на услугите и да се балансира натоварването между тях
• Сложност на стартиране — необходимо беше да въведем минимум 3 команди, с определени параметри (това само за 2 услуги)

За решаване на горепосочените проблеми съществуват редица решения, като Docker Swarm, Nomad, Kubernetes или OpenShift. Ако цялата система е написана на Java, можем да разгледаме Spring Cloud (добра статия).

В следващата част ще разкажа как конфигурирах Kubernetes и деплойвах проекта в Google Kubernetes Engine.

Източник: habr.com