Научете как да внедрявате микроуслуги. Част 1. Spring Boot и Docker

Хей Хабр.

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

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

1. Създайте две услуги - 'backend' (бекенд) и 'gateway' (шлюз), опаковайте ги в докер изображения и ги настройте да работят заедно

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

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

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

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

   Етикети: Helm 3, внедряване на диаграма

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

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

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

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

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

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

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

Обслужване в задния край

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

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

@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"));
    }
}

Сервизен шлюз

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

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

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

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

Backend адаптер:

@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<String> 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("Number of requests %s (gateway %d, secret %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

Стартиране:

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

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

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

./mvnw package -DskipTests
java -jar target/microservices-gateway-1.0.0.jar

проверете:

$ curl http://localhost:8080/
Number of requests 1 (gateway 38560358, secret "default-secret")

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

докер

Накратко, docker създава изолирани контейнери, по един на приложение. За да използвате docker, трябва да напишете Dockerfile - инструкции за изграждане и стартиране на приложението. След това можете да създадете изображението, да го качите в регистъра на изображенията (No. Dockerhub) и внедрите вашата микроуслуга във всяка докеризирана среда с една команда.

Докер файл

Една от най-важните характеристики на изображението е неговият размер. Компактното изображение ще се изтегля по-бързо от отдалечено хранилище, ще заема по-малко място и услугата ви ще стартира по-бързо. Всяко изображение се изгражда на базата на основното изображение и се препоръчва да изберете най-минималистичния вариант. Добър вариант е 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 сигнализира на докера, че приложението в контейнера ще използва своя порт 8080 (това няма да направи приложението достъпно отвън, но ще позволи достъп до приложението, например, от друг контейнер в същата докер мрежа ).

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

docker image build . -t msvc-backend:1.0.0

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

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

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

Краен Docker файл:

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 [email protected]"
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 MB. Не е зле. След това готовите изображения могат да бъдат качени в регистъра на изображенията, така че вашите изображения да са достъпни за изтегляне от Интернет.

Услуги за съвместно изпълнение в 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

Струва си да се отбележи, че мостовата мрежа осигурява незабавно откриване на услуга за контейнери по техните имена. Това означава, че бекенд услугата ще бъде достъпна в докер мрежата на 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/ и се уверете, че всичко работи, както в предишния случай.

Заключение

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

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

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

В следващата част Ще говоря за това как настроих Kubernetes и внедрих проекта в Google Kubernetes Engine.

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