7 марта 2022 г.

Прочитав заголовок, вы, вероятно, задаетесь вопросом, что такое микросервис и чем он отличается от монолитной Java-программы. Если мы посмотрим на определение микросервисов. По сути, микросервис — это архитектура.

Микросервисы (или архитектура микросервисов) — это подход к облачной архитектуре, в котором одно приложение состоит из множества слабо связанных и независимо развертываемых более мелких компонентов или сервисов

Так почему микросервисы, а не монолитные программы?

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

• Повышение производительности и скорости — Благодаря микросервисам каждая команда разработчиков может смотреть только на конкретный сервис, который они создают, не беспокоясь обо всем исходном коде. Это повысит производительность команды вместе со скоростью доставки.

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

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

Итак, теперь мы знаем, почему обычно все крупные организации предпочитают микросервисы поддержке большого комбинированного исходного кода. Давайте попробуем разработать микросервис с помощью Spring Boot — очень популярной платформы Java, используемой для разработки корпоративных приложений.

Описание Проекта

Мы собираемся разработать микросервис для создания RESTful API для приложения Tour в Калифорнии ????. Давайте начнем,

Создать проект

В экосистеме Spring можно найти множество зависимостей. Для этого нам понадобятся зависимости для

• Веб, который включает Tomcat и Spring MVC

• Репозитории Rest для доступа к репозиториям Spring Data через REST API.

Вы можете легко создать проект Spring с помощью Spring Initializer. Перейдите на веб-страницу Spring Initializer и выберите проект в качестве проекта Maven, для язык выберите Java, заполните метаданные проекта, выберите упаковку как JAR и выберите версию Java, которую вы разрабатываете. Затем добавьте зависимости,

И, наконец, нажмите «Создать», он загрузит zip-файл, который создал структуру вашего проекта с указанными зависимостями в вашем файле pom.xml.

Структура проекта

Как вы можете видеть на картинке выше, есть несколько файлов, и если мы проверим файл pom.xml, мы увидим, что здесь представлены зависимости, которые мы добавили в инициализаторе Spring.

Давайте посмотрим на файл CaliforniaApplication.java .

https://gist.github.com/maneeshaindrachapa/f0d9fc4cb4c06216abc94a0d8885731c

Этот файл CaliforniaApplication.java содержит метод main, а также аннотацию @SpringBootApplication. Добавление этой аннотации означает, что мы сообщаем JVM, что это место, где запускается микросервис, и main метод там, поэтому он не похож на упакованные файлы войны, поэтому мы можем фактически контролировать запуск и остановку веб-приложения.

@SpringBootApplication аннотация используется для обозначения класса конфигурации, который объявляет один или несколько @Bean методов, а также запускает автоконфигурацию и сканирование компонентов. Это то же самое, что объявить класс с @Configuration, @EnableAutoConfiguration и @ComponentScan аннотациями.

Запуск Spring Boot Server

Когда вы запускаете основной метод, вы видите, что приложение Spring запускается. Чтобы изменить порт, с которого запускается сервер, вы можете перейти в файл application.properties и добавить новое свойство server.port=8081

Чтобы проверить, работает ли сервер, перейдите на http://localhost:8081/profile и вы увидите примерно следующее:

Разработка проекта

Теперь мы готовы разработать спокойный веб-сервис Tour California. Во-первых, давайте проверим диаграмму классов спокойного веб-сервиса, который мы собираемся создать.

1. Создание моделей

Сначала создайте новый пакет и назовите его модель и создайте в нем эти бизнес-объекты.

https://gist.github.com/maneeshaindrachapa/58ec8c3924b2044dcc0468e1026cb429

https://gist.github.com/maneeshaindrachapa/dab4d0be4308ff21d545c33188ce8119

https://gist.github.com/maneeshaindrachapa/9c1c7570931c43dd781d30f2d184348d

https://gist.github.com/maneeshaindrachapa/64ad22989db443dc1996881cff5e5249

Как вы можете видеть в файлах Tour.java и TourPackage.java, были использованы некоторые аннотации. Давайте посмотрим, что они означают. Эти аннотации используются в Java Persistent API. В качестве спецификации;

:::Информация

• Java Persistence API связан с сохранением, что в общих чертах означает любой механизм, с помощью которого объекты Java переживают процесс приложения, создавший их. *

• @Entity — Аннотируйте все компоненты управления данными с помощью @Entity.

• @Column — укажите сопоставление столбцов с помощью аннотации @Column.

• @Id — аннотируйте столбец идентификатора с помощью @Id.

• @GeneratedValue — позволяет базе данных сгенерировать (автоматически увеличить) столбец идентификатора.

• @OneToOne — Для объектов, использующих один и тот же первичный ключ, мы можем связать их с помощью @OneToOne.

• @ManyToOne — Для сущностей, которые имеют много отношений с одной сущностью, например, в нашем проекте, один TourPacakge состоит из множества Tours.

• @Enumerated — Таким образом, мы можем указать поставщику JPA преобразовать перечисление в его порядковое или строковое значение.

2. Создание репозиториев

Создайте новое имя пакета repository и создайте репозитории, необходимые для проекта.

https://gist.github.com/maneeshaindrachapa/7cff46d5fa9eb49330c7f5a99947d2ab

https://gist.github.com/maneeshaindrachapa/638b0cf86a76bf4ed18958c202eb5ae0

• Мы создаем репозитории для двух имеющихся у нас объектов, а также расширяем * интерфейс CrudRepository, который представляет собой интерфейс Spring Data для общих операций CRUD в репозитории определенного типа. Он предоставляет несколько готовых методов для взаимодействия с базой данных. При расширении CrudRepository вам необходимо определить T-entity, ID-тип вашего столбца ID в Entity.

В приведенном выше коде использовались некоторые аннотации. Давайте посмотрим, какие они,

• @RepositoryRestResource —  используется для установки параметров в общедоступном интерфейсе репозитория — он автоматически создает конечные точки в зависимости от типа расширяемого репозитория (CrudRepository/PagingAndSortingRepository и т. д.)

• @Repository — специализация аннотации @Component , которая используется для указания того, что класс предоставляет механизм для хранения, извлечения, обновления, удаления и операции поиска объектов.

3. Создание сервисов

Создайте новое имя пакета service и создайте в нем службы, необходимые для проекта.

https://gist.github.com/maneeshaindrachapa/61ca2e4a380135eff34e9ab261c5b5a8

https://gist.github.com/maneeshaindrachapa/f6e61d5623268fd12d1b90e68714111e

В приведенном выше коде использовались некоторые аннотации. Давайте посмотрим, какие они,

• @Service — используется с классами, предоставляющими некоторые бизнес-функции. Контекст Spring автоматически обнаружит эти классы, когда используется конфигурация на основе аннотаций и сканирование путей к классам.

• @Autowired — эта аннотация обеспечивает более детальный контроль над тем, где и как должна выполняться автоматическая проводка. Аннотацию @Autowired можно использовать для автопривязки bean-компонента к методу установки точно так же, как аннотацию @Required , конструктор, свойство или методы с произвольными именами и/или несколькими аргументами.

Как вы можете видеть в приведенном выше коде, мы используем интерфейсы репозитория, которые мы создали до этого, чтобы использовать методы, уже разработанные в CrudRepository, такой интерфейс, как findById(), findAll()` . По сути, мы используем сервисы, чтобы маскировать репозитории от внешних сторон и использовать логику, которую мы хотим, на бизнес-уровне.

4. Настройка базы данных

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

«`javascript

spring.h2.console.enabled = правда

spring.datasource.url=jdbc:h2:mem:туркалифорния

spring.datasource.driverClassName=org.h2.Драйвер

spring.datasource.username = администратор

spring.datasource.password=admin

spring.jpa.database-platform = org.hibernate.dialect.H2Dialect

spring.jpa.hibernate.ddl-auto=create-drop

Теперь из CaliforniaApplication.java, где находится основной метод, мы можем реализовать интерфейс CommandLineRunner, который представляет собой простой интерфейс Spring Boot с методом запуска. Spring Boot автоматически вызовет метод run всех bean-компонентов, реализующих этот интерфейс, после загрузки контекста приложения.

Во-первых, мы добавляем свойство в наш файл application.properties для чтения файла ExploreCalifornia.json.

«`javascript

ec.importfile=ИсследоватьКалифорнию.json

Затем мы добавляем код для чтения файла JSON и добавляем его в базу данных в файле CaliforniaApplication.java. Мы можем использовать @value весной для импорта имени файла.

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

https://gist.github.com/maneeshaindrachapa/eefdf5333c6607eff93ae7e6be82e2a9

И нам нужно добавить новый метод для файла `TourPackageRepository.java , потому что мы используем

«`javascript

TourPackage tourPackage = tourPackageRepository.findByName(tourPackageName).orElseThrow(() ->

new RuntimeException(«Пакет тура не существует: » + tourPackageName));

Итак, давайте добавим Optional findByName(String, name); в файл TourPackageRepository.java.

https://gist.github.com/maneeshaindrachapa/f50f664fdd163d1d85694d866d40a68d

Давайте перезапустим сервер и перейдем к http://localhost:8081/h2-console/ URL, где находится консоль базы данных h2.

Затем добавьте имя пользователя, пароль, URL-адрес JDBC, который вы настроили в application.properties, и войдите в консоль h2. Чтобы убедиться, что данные, загруженные в таблицы, можно выполнить с помощью простого запроса, такого как `SELECT * from TOUR;

Или мы можем перейти на http://localhost:8081/tours/ в браузере и просмотреть данные (поскольку мы добавляем @RepositoryRestResource в наши репозитории, мы можем запускать команды GET/POST/PUT/DELETE в наши хранилища).

если вы не хотите, чтобы данные отображались таким образом, вам нужно добавить @RepositoryRestResource(exported = false) в свои репозитории.

5. Создание контроллеров

Создайте новое имя пакета controller и создайте там контроллеры, необходимые для проекта.

https://gist.github.com/maneeshaindrachapa/33b9175a896a064c92b9242ff32d7f9c

В приведенном выше коде использовались некоторые аннотации. Давайте посмотрим, какие они,

• @RestController — @RestController объединяет @Controller и @ResponseBody.

• @RequestBody — сопоставляет тело HTTP-запроса с объектом.

• @PathVariable — Эта аннотация указывает, что аргумент метода привязан к переменной шаблона URI.

• @RequestParam — эта аннотация используется для доступа к параметрам HTTP-запроса. @PostMapping — аннотированные методы @PostMapping в аннотированных классах @Controller обрабатывают HTTP-запросы POST, соответствующие заданному выражению URI.

• @GetMapping — аннотированные методы @GetMapping в аннотированных классах @Controller обрабатывают HTTP-запросы GET, соответствующие заданному выражению URI.

• @PutMapping — Аннотированные методы @PutMapping в аннотированных классах @Controller обрабатывают HTTP-запросы PUT, соответствующие заданному выражению URI.

• @DeleteMapping — Аннотированные методы @DeleteMapping в аннотированных классах @Controller обрабатывают HTTP-запросы DELETE, соответствующие заданному выражению URI.

• @PatchMapping — Аннотированные методы @PatchMapping в аннотированных классах @Controller обрабатывают HTTP-запросы PATCH, соответствующие заданному выражению URI.

• @ExceptionHandler — с помощью этой аннотации мы можем объявить собственный метод обработки ошибок. Spring вызывает этот метод, когда метод обработчика запросов выдает любое из указанных исключений.

• @ResponseStatus — с помощью этой аннотации мы можем указать желаемый HTTP-статус ответа, если мы аннотируем метод обработчика запроса этой аннотацией. Мы можем объявить код состояния с аргументом кода, или это псевдоним, аргумент значения

• @RequestMapping — этой аннотацией помечаются методы обработчиков запросов внутри классов @Controller; его можно настроить с помощью,

• путь или его псевдонимы, имя и значение: URL-адрес, на который сопоставляется метод

• метод: совместимые методы HTTP

• params: фильтрует запросы по наличию, отсутствию или значению параметров HTTP.

• заголовки: фильтрует запросы по наличию, отсутствию или значению заголовков HTTP

• потребляет: какие типы мультимедиа метод может использовать в теле запроса HTTP

• производит: какие типы мультимедиа метод может создавать в теле ответа HTTP

6. Тестирование API

Для тестирования API мы можем использовать Postman. Вы можете получить коллекцию почтальона из здесь.

Вы можете найти полный код здесь.

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

• Впервые опубликовано [здесь] (https://maneeshaindrachapa.medium.com/create-first-microservice-using-spring-boot-1994cd78bbdf)*

Оригинал

Как мы выбирали архитектуру и переносили 20-летние монолиты промышленного гиганта на микросервисы

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

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

В общем, расскажу, как на практике распиливаются монолиты огромных размеров, которые управляют всем производственным циклом. А размеры ещё те: НЛМК — гигант. Мы делаем 20% стали России и входим в TOP-20 по производству в мире.

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

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

Одновременно у нас идет много проектов на разных производственных переделах, и у каждой команды свой монолит.

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

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

Наши монолиты

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

В качестве «фронтенда» использовались Oracle Forms с интерфейсом из 90-х. Надо сказать, что и некоторые участки кода – настоящий антиквариат. Естественно, ни о каких системах контроля версий и совместной работы не было и речи.

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

Производственный процесс Группы НЛМК охватывает множество предприятий на разных континентах, и при этом в каждом цехе была собственная информационная система со своими особенностями. Общались эти системы, как с помощью шины данных на базе Kafka, так и банальными DBLink.

Схема производственного процесса липецкой площадки НЛМК https://studfile.net/preview/5990480/

На данном этапе — основные объекты трансформации — это MES (manufacturing execution system) – системы управления производством. Они находятся между уровнями АСУТП (датчики, исполнительные механизмы, контроллеры) и уровнем ERP (такими системами как SAP и 1C). В нашем случае это аналитически-учетные системы уровня цеха.

Структура систем управления производством

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

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

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

Распил на микросервисы

Для запуска прикладных сервисов у нас развернута «единая цифровая платформа» (ЕЦП) как совокупность инфраструктурных сервисов от хранения кода и CI/CD в GitLab до запуска в Openshift, сбора логов и мониторинга.

Общая структура единой цифровой платформы (ЕЦП) в НЛМК

Применение инструментов ЕЦП для наших сервисов определяется уровнем зрелости разработки. Начиная от хранения кода в GitLab, и заканчивая сбором инфраструктурных и бизнес-метрик на проде.

Ступени зрелости разработки сервисов

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

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

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

Возможно, в идеале будет еще как-то иначе. Чаще всего, первая команда становится техническим владельцем сервиса и отвечает за его развитие.

Задача параллельной разработки на нескольких проектах

Другой подход, когда мы используем горизонтальные сервисы, инстансы которых могут непосредственно использоваться несколькими проектами. И опять же пример — сервис нормативно-справочной информации (НСИ), который может использоваться многими системами.

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

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

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

Применение горизонтальных сервисов

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

Но для него приходится создавать middleware прослойку, которая содержит как backend for frontend (BFA), так и адаптеры для работы со старой системой, основанной на старой БД. Плюс такого подхода в том, что мы можем сразу дать бизнесу новый интерфейс и разом пересадить на него всех пользователей.

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

Послойная миграция

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

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

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

Поэтапная миграция функций

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

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

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

От монолита к микросервисам | Издательство БХВ

• Описание
• Детали
• Отзывы (0)

В книге “От монолита к микросервисам” Сэм Ньюмен дает четкое видение миграции на микросервисы, показывает, каких ловушек (как очевидных, так и коварных) следует остерегаться, и рассматривает ряд очень полезных шаблонов для организационных, архитектурных и технологических изменений.
Дэниел Брайант, технический консультант Datawire и InfoQ

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

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

ЭВОЛЮЦИОННЫЕ ШАБЛОНЫ ДЛЯ ТРАНСФОРМАЦИИ МОНОЛИТНОЙ СИСТЕМЫ

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

Еще несколько лет назад некоторые из нас лишь поговаривали о том, что, дескать, микрослужбы (микросервисы) — интересная идея.

И вот не успели мы оглянуться, как они стали архитектурой, принятой по умолчанию в сотнях компаний по всему миру (многие, вероятно, запущены как стартапы, призванные решать проблемы, вызванные микрослужбами), что заставило всех “перейти на бег”, чтобы успеть “запрыгнуть на подножку последнего вагона”, который, как они опасаются, вот-вот исчезнет за горизонтом.

Должен признаться, здесь есть часть моей вины. С тех пор как в 2015 году я написал свою собственную книгу “Создание микросервисов ” (Building Microservices) на эту тему, я зарабатываю на жизнь, работая с людьми, помогая им понять данный тип архитектуры.

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

Для многих моих клиентов с существующими (не ориентированными на микрослужбы) системами трудность состояла в том, как внедрить архитектуры, основанные на микрослужбах.

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

Чему вы научитесь

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

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

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

Сэм Ньюмен принимал участие в нескольких стартапах, 12 лет проработал в ThoughtWorks и теперь является независимым консультантом.

Специализируется на микросервисах и облачной архитектуре, проводит обучение и дает консультации, помогает клиентам быстрее и надежнее разрабатывать программно-информационное обеспечение, выступает на конференциях по всему миру. Автор известной книги “Создание микросервисов” издательства O’Reilly.

• ✓ Новинки на 2 недели раньше магазинов
• ✓ Цены от издательства ниже до 30%
• ✓ Акции и скидки только для подписчиков
• ✓ Важные новости БХВ

Монолит в микросервис

Практическое руководство по разделению монолитного приложения на микросервисы

«Ох, у меня конфликты слияния. кто сейчас отправил код? ???? »

«Дерьмо !! Профили клиентов не загружаются из-за развертывания нового платежного шлюза. Не знаю, сколько времени это займет. ????‍♂️ ”

«Этот рефакторинг требует большего, чем я думал, эти функции вызываются отовсюду; как мне проверить это и убедиться, что в других частях ничего не ломается. ???? ”

«Хотел бы я использовать Nodejs (или Golang) для выполнения параллельных сетевых вызовов для этого модуля проекта».

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

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

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

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

Когда начать

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

Ниже приведены некоторые из наиболее распространенных подходов к началу работы с микросервисами.

1. Разделитесь на новые возможности

При таком подходе мы начинаем создавать новые функции в новом репозитории микросервисов.

Эти функции полностью независимы от существующих функций (монолита) и могут быть интегрированы (с клиентами), протестированы и отслежены независимо.

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

2. Разделить по швам

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

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

Этот подход хорошо подходит для хорошо спроектированного и слабосвязанного монолита.

3. Рефакторинг микросервиса

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

Замена связи с базой данных

Чаще всего микросервисы тесно связаны через базу данных, особенно когда они отделены от монолита. Связь с базой данных — это плохо, потому что любые изменения в схеме БД должны быть отражены в нескольких местах, что нарушает согласованность.

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

Обработка внешнего ключа и объединений

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

Управление транзакциями

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

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

Один из популярных способов достижения этого в микросервисах — двухфазная фиксация (2pc). В 2pc диспетчер транзакций координирует свои действия со всеми службами для достижения общей атомарной транзакции.

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

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

Надеюсь, вы узнали о некоторых проблемах при переходе на архитектуру микросервисов и о том, как их решать. Не забудьте нажать кнопку «Хлопок» и подписаться на следующую статью в этой серии.

• Использованная литература:
• Https://tinylink.net/bjz12
• Https://tinylink.net/Q8b6D

Переход от монолита к микросервисам

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

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

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

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

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

Сначала монолит

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

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

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

От микросервисов не уйти

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

Главное начать

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

Вышеупомянутые три утверждения ставят перед нами два вопроса: когда и как. Давайте по порядку.

Как понять, что наступил тот самый момент, что пора уже пилить микросервисы?

Давайте подойдем к этому вопросу сугубо практически, и ограничим искомую временную точку сверху и снизу.

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

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

Выделять микросервисы уже становится поздновато, если возникает желание кешировать html-страницы целиком, потому что тормозят, а чтобы ускорить, нужно переписать половину приложения, заменить ORM или вообще переписать все на другом языке, где все хорошо и приложения не тормозят.

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

И самый главный критерий необходимости начать переходить на микросервисную архитектуру — когда стоимость добавления новой фичи начинает превосходить выгоду от этой самой фичи.

С чего начать миграцию архитектуры в пользу микросервисов?

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

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

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

Подход хороший и рабочий, но имеет один существенный недостаток — основное монолитное приложение в обозримом будущем не исчезнет.

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

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

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

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

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

Вместо выводов

Микросервисы — хорошо. Монолит — хорошо. Хороший код — хорошо. Рабочий код — хорошо.

Статья не призывает срочно менять принцип разработки в приложениях, которые тормозят, криво написаны или написаны не так, как хотелось бы.

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

«Отказоустойчивость», «распределенность», «масштабируемость» это безусловно хорошо, но не это главное преимущество микросервисной архитектуры. Самое важное, что дает такой подход — удешевление стоимости внесения изменений.