Методология двенадцати факторов в микросервисе Spring Boot

Автор оригинала: Kumar Chandrakant.

1. Обзор

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

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

2. Что Такое Методология Двенадцати Факторов?

Методология двенадцати факторов представляет собой набор из двенадцати лучших практик разработки приложений, разработанных для запуска в качестве службы . Это было первоначально разработано Heroku для приложений, развернутых в качестве сервисов на их облачной платформе, еще в 2011 году. Со временем это оказалось достаточно общим для любой разработки software-as-a-service (SaaS).

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

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

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

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

3. Микросервисы с пружинным загрузчиком

Микросервис – это архитектурный стиль разработки программного обеспечения в виде слабо связанных сервисов. Ключевым требованием здесь является то, что службы должны быть организованы вокруг границ бизнес-домена . Это часто самая трудная часть для идентификации.

Кроме того, служба здесь имеет исключительную власть над своими данными и предоставляет операции другим службам. Связь между службами обычно осуществляется по облегченным протоколам, таким как HTTP. Это приводит к независимому развертыванию и масштабируемым службам.

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

Spring Boot – это фреймворк приложений, основанный на Spring, который устраняет множество шаблонов, связанных с разработкой корпоративного приложения. Это дает нам очень самоуверенную, но гибкую платформу для разработки микросервисов. В этом уроке мы будем использовать Spring Boot для предоставления микросервиса с использованием методологии двенадцати факторов.

4. Применение Двенадцатифакторной Методологии

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

Итак, кто хотел бы начать фильм, а затем отказаться от него позже? Что нам нужно, так это простой сервис для записи и запроса фильмов, которые мы смотрели:

Это довольно простой и стандартный микросервис с хранилищем данных и конечными точками REST. Нам нужно определить модель, которая также будет соответствовать постоянству:

@Entity
public class Movie {
    @Id
    private Long id;
    private String title;
    private String year;
    private String rating;
    // getters and setters
}

Мы определили сущность JPA с идентификатором и несколькими другими атрибутами. Теперь давайте посмотрим, как выглядит контроллер REST:

@RestController
public class MovieController {
 
    @Autowired
    private MovieRepository movieRepository;
    @GetMapping("/movies")
    public List retrieveAllStudents() {
        return movieRepository.findAll();
    }

    @GetMapping("/movies/{id}")
    public Movie retrieveStudent(@PathVariable Long id) {
        return movieRepository.findById(id).get();
    }

    @PostMapping("/movies")
    public Long createStudent(@RequestBody Movie movie) {
        return movieRepository.save(movie).getId();
    }
}

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

4.1. Кодовая база

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

Spring Boot предлагает множество удобных способов загрузки приложения, включая инструмент командной строки и веб-интерфейс . Как только мы создадим приложение начальной загрузки, мы сможем преобразовать его в репозиторий git:

git init

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

git add .
git commit -m "Adding the bootstrap of the application."

Наконец, мы можем добавить пульт дистанционного управления и отправить наши коммиты на пульт дистанционного управления, если захотим (это не является строгим требованием):

git remote add origin https://github.com//12-factor-app.git
git push -u origin master

4.2. Зависимости

Далее, приложение двенадцать факторов всегда должно явно объявлять все свои зависимости . Мы должны сделать это с помощью манифеста объявления зависимостей. Java имеет несколько инструментов управления зависимостями, таких как Maven и Gradle. Мы можем использовать один из них для достижения этой цели.

Таким образом, наше простое приложение зависит от нескольких внешних библиотек, таких как библиотека для облегчения API REST и подключения к базе данных. Давайте посмотрим, как мы можем декларативно определить их с помощью Maven.

Maven требует, чтобы мы описывали зависимости проекта в XML-файле, обычно известном как Объектная модель проекта (POM):

    
        org.springframework.boot
        spring-boot-starter-web
    
    
        com.h2database
        h2
        runtime
    

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

4.3. Конфигурации

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

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

Двенадцатифакторное приложение должно экстернализировать все такие конфигурации, которые различаются между развертываниями . Здесь рекомендуется использовать переменные среды для таких конфигураций. Это приводит к чистому разделению конфигурации и кода.

Spring предоставляет файл конфигурации, в котором мы можем объявить такие конфигурации и прикрепить его к переменным среды:

spring.datasource.url=jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/movies
spring.datasource.username=${MYSQL_USER}
spring.datasource.password=${MYSQL_PASSWORD}

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

В Windows мы можем установить переменную среды перед запуском приложения:

set MYSQL_HOST=localhost
set MYSQL_PORT=3306
set MYSQL_USER=movies
set MYSQL_PASSWORD=password

Мы можем использовать инструмент управления конфигурацией, такой как Ansible или Chef , чтобы автоматизировать этот процесс.

4.4. Банковские Услуги

Банковские услуги-это услуги, от которых зависит работа приложения. Например, база данных или брокер сообщений. Двенадцатифакторное приложение должно рассматривать все такие банковские услуги как вложенные ресурсы. Это фактически означает, что для замены совместимой службы резервного копирования не требуется никаких изменений кода. Единственное изменение должно быть в конфигурациях.

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

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

@Repository
public interface MovieRepository extends JpaRepository {
}

Как мы видим, это напрямую не зависит от MySQL. Spring обнаруживает драйвер MySQL на пути к классу и динамически предоставляет специфичную для MySQL реализацию этого интерфейса. Кроме того, он напрямую извлекает другие детали из конфигураций.

Итак, если нам нужно перейти с MySQL на Oracle, все, что нам нужно сделать, это заменить драйвер в наших зависимостях и заменить конфигурации.

4.5. Сборка, выпуск и запуск

Методология двенадцати факторов строго разделяет процесс преобразования кодовой базы в работающее приложение на три отдельных этапа:

• Этап сборки: здесь мы берем кодовую базу, выполняем статические и динамические проверки, а затем генерируем исполняемый пакет, такой как JAR. Используя такой инструмент , как Maven , это довольно тривиально:

     mvn clean compile test package

• Этап выпуска: Это этап, на котором мы берем исполняемый пакет и объединяем его с правильными конфигурациями. Здесь мы можем использовать Packer с поставщиком, таким как Ansible , для создания образов Docker:

     packer build application.json

• Этап выполнения: Наконец, это этап, на котором мы запускаем приложение в целевой среде выполнения. Если мы используем Docker в качестве контейнера для выпуска нашего приложения, запуск приложения может быть достаточно простым:

     docker run --name  -it 

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

4.6. Процессы

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

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

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

4.7. Привязка Портов

Традиционное веб-приложение на Java разрабатывается как WAR или веб – архив. Обычно это набор сервлетов с зависимостями, и он ожидает соответствующей среды выполнения контейнера, такой как Tomcat. Двенадцатифакторное приложение, напротив, не ожидает такой зависимости от времени выполнения. Он полностью самодостаточен и требует только выполнения среды выполнения, такой как Java.

В нашем случае мы разработали приложение с использованием Spring Boot. Spring Boot, помимо многих других преимуществ, предоставляет нам встроенный сервер приложений по умолчанию. Следовательно, JAR, который мы создали ранее с помощью Maven, полностью способен выполняться в любой среде, просто имея совместимую среду выполнения Java:

java -jar application.jar

Здесь наше простое приложение предоставляет свои конечные точки через HTTP-привязку к определенному порту, например 8080. После запуска приложения, как мы делали выше, должна быть возможность доступа к экспортируемым сервисам, таким как HTTP.

Приложение может экспортировать несколько служб, таких как FTP или WebSocket, путем привязки к нескольким портам.

4.8. Параллелизм

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

Методология двенадцати факторов предлагает приложениям полагаться на процессы масштабирования. Это фактически означает, что приложения должны быть разработаны таким образом, чтобы распределять рабочую нагрузку между несколькими процессами. Однако отдельные процессы могут свободно использовать модель параллелизма, такую как Поток внутренне.

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

4.9. Возможность утилизации

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

Например, в нашем приложении одной из конечных точек является создание новой записи базы данных для фильма. Теперь приложение, обрабатывающее такой запрос, может неожиданно выйти из строя. Однако это не должно влиять на состояние приложения. Когда клиент отправляет тот же запрос снова, это не должно приводить к дублированию записей.

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

4.10. Четность Dev/Prod

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

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

Теперь такие технологии, как Spring Boot и Docker, в значительной степени автоматически устраняют этот разрыв. Ожидается, что контейнерное приложение будет вести себя одинаково, независимо от того, где мы его запускаем. Мы также должны использовать те же службы резервного копирования, что и база данных.

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

4.11. Бревна

Журналы – это важные данные, которые приложение генерирует в течение своего жизненного цикла. Они дают бесценную информацию о работе приложения. Как правило, приложение может генерировать журналы на нескольких уровнях с различной детализацией и выводить их в нескольких различных форматах.

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

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

Это мы можем передать в Elasticsearch для хранения и индексирования. Наконец, мы можем создавать значимые информационные панели для визуализации в Kibana .

4.12. Процессы администрирования

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

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

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

Кроме того, мы можем использовать Groovy, интегрированный с Java runtime, для запуска таких процессов.

5. Практическое применение

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

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

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

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

6. Заключение

В этом уроке мы рассмотрели концепции двенадцатифакторной методологии. Мы обсудили, как использовать архитектуру микросервисов с Spring Boot для их эффективной доставки. Кроме того, мы подробно изучили каждый фактор и то, как применить их к нашему приложению. Мы также изучили несколько инструментов для эффективного применения этих отдельных факторов.