Это продолжения статьи про разработку архитектуры: https://habr.com/ru/post/658145/
Monolite or MicroService ?
Я на самом деле довольно часто вижу ситуацию, что в программировании происходит именно так:
Программисты последнее время часто работают с микросервисами и часто пытаются их встроить туда, куда это не нужно. Микросервисы это естественно хорошо, но как и всегда это не серебряная пуля которая может решить любые проблемы, а скорее наоборот их добавит.
Давайте для начала разберём что такое монолит и его преимущества и недостатки.
На самом деле я думаю что даже не нужно рассписывать что такое монолит, тут всё понятно. Все приложение находится в одном репозитории и по сути является отдельным, самостоятельным проектом который можно запустить.
Плюсы монолита:
Простая разработка и развертывание приложения
Меньше проблем с сетью и работой между серверами
Лучше производительность
Легко сделать прототип
Но у монолита есть и минусы:
МАСШТАБИРУЕМОСТЬ
На самом деле масштабируемость это чуть ли не главная и едитсвенная проблема монолитов. И я сейчас говорю про масштабируемость как в плане производительности(сколько пользователей может одновременно пользоваться вашим приложением), так и в плане размера команды, ведь чем больше проект, тем сложнее сохранить хорошее качество кода и убрать взаимосвязи между разными частями проекта. Сейчас это важно как никогда, особенно когда сервисы превратились в гигантов и уже чуть-ли не через каждое приложение можно заказать такси, купить авиабилеты или просто цветы любимой девушке...
Service-oriented architecture (Microservice)
Микросервисная архитектура подразумевает что мы разбиваем наше приложение на множество небольших, независимых приложений которые в теории могут работать самостоятельно, но всё же такое не всегда получается, но в идеальном мире при падении одного сервиса, это должно не сильно афектить нашу систему и все остальные сервисы должны продолжить работу без перебоев. Но как я и сказал в реальном мире это не всегда работает так как нужно. На следующей картинке вы можете увидеть разницу, между монолитом и микросервисной архитектурой.
Но почему же микросервисы это так сложно?
Сложное развертывание приложения (требуется развернуть множество сервисов и множество баз данных и настроить их взаимодействие
Получаем новый слой вроде сети (многие не учитывают это при проектировании архитектуры, но в больших системах именно уровень сети может являться “бутылочным горлышком” в которое упирается ваша система при масштабировании)
Больше микросервисов = работает медленно (не забывает также что передача данных по сети требует времени, так же сериализация и десериализация требуют процессорного времени, поэтому если у нас имеется множество микросервисов которые вызывают друг друга последовательно, это может замедлить получение финального результата по сравнению с монолитом)
Сложная горизонтальная масштабируемость (требуется правильно настроить взаимодействие всех ваших сервисов и их правильную линковку)
Нам нужна работа с Kubernates / OpenShift (естественно мы не планируем разворачивать всё ручками, по этому придётся научиться работать с одним из данных софтверных продуктов)
Мы хотим иметь хорошие логи (и даже при получении логов есть сложность. Мы можем конечно собирать логи все вместе в одном месте, но в таком случае все логи будут перепутаны и в них будет тяжело разбираться, по этому нам нужно научиться правильно собирать логи)
Нам нужно проверять наши сервисы на аптайм (в случае при работе с монолитом у нас нету больших проблем, просто пингуем что наш сервис жив и всё, при работе с микросервисами, нужно проверять каждый сервис на живучесть)
Нам нужен архитектор для разработки (как уже описал выше, есть много проблем, поэтому без хорошего архитектора не обойтись)
Тестировать микросервисную архитектуру сложнее (тестирование это уже давно стандарт IT индустрии, и развёртывать систему понадобится каждый раз, что потребует больше ресурсов и больше времени на её отладку)
Конфигурация хранилища для наших сервисов (когда мы доросли до масштаба когда монолит уже не справляется, нам вероятно потребуется и больше дискового пространства, с которым мы будем работать, сделать распределённую систему хранилища тоже не всегда тривиальная задача)
Контроль доступа (также требуется отслеживать каждый сервис и пытаться понять какой сервис имеет доступ в открытый мир, какой работает только с других микросервисов)
Как мы видим проблем при работе с микросервисами довольно много и они не всегда тривиальны. Естественно тут я указал не все проблемы которые могут возникнуть, но основные я постарался озвучить.
Но раз это так сложно, почему же все хотят микросервисы?
Тут как раз ответ довольно простой, это масштабируемость. Правильно построенная микросервисная архитектура способна масштабироваться почти без ограничений.
Давайте так же рассмотрим одну из довольно частых архитектур которая применяется в микросервисных архитектурах, извините за тавтологию.
API Composer
Допустим у нас есть какой то платёжный сервис который должен принимать платежи с Qiwi, с карточек и криптовалютой. В таком случае мы можем сделать API composer и сделает единый интерфейс для работы с платёжными данными. Выглядеть это будет следующим образом:
Как мы видим на картинке, в начале у нас есть запрос который идёт в API Composer и после этого он идёт уже в нужный ему сервис. Самой логики в API Composer почти нету и он будет почти не нагруженный, за то для нас это будет единая точка входа для всех вариантов платежа.
API Composer (Gateway)
Так же одной из популярных разновидностей API Composer является GateWay. Обычно Gateway называют единую точку входа для вашего приложения с минимальной логикой. Выглядит это примерно следующим образом:
Как мы видим на данной картинке, мы имеем множество клиентов, которые все обращаются в единый API Gateway и после этого Gateway уже сам выбирает в какой сервис ему нужно пойти. Обычно API Gateway стараются не нагружать логикой, но часто туда вешают логику отвечающую за некоторые основные вещи в приложении
Авторизация
Безопасность
Обработку ошибок
Кеширование данных
Сжатие и чистка данных перед отправкой клиенту
Специфическую работу с платформами, для веба например мы можем использовать HTTP REST(JSON), а под мобильные платформы возможно будет более выгодно использовать protoBuf.
Распределение нагрузки между серверами
Для реализации Gateway мы можем использовать обычное приложение и написать его с нуля самостоятельно, но рынок уже предлагает нам стандартные его реализации, вот лишь некоторый список из них
Amazon API Gateway
NGinx API Gateway
Netflix Zuul
Tyk
Google Api Gateway
Akamai Api Gateway
Больше про работу с API Gateway можно почитать на сайте, там много всего интересного: https://microservices.io/patterns/apigateway.html
Но если микросервисы это так сложно, наверняка же уже есть какие нибудь готовые тулы для этого? Да есть!
Я являюсь разработчиком на Java, поэтому приведу пример именно из Java мира.
JHipster
Если говорить коротко, то JHipster включает в себя всё то, что нам требуется для разработки больших приложений и микросервисной архитектуры.
Если мы посмотрим на картинку которую я взял с сайт JHipster, то увидим много чего интересного
во первых тут сразу видно что применяются Docker, Spring Boot, Logstash, Consul и другие нужные для микросервисов технологии. Так же там сразу можно завернуть контейнеры в kubernates. Вообще JHipster очень гибко настраивается и вы можете выбрать множество различных технологий которые будут использоваться в проекте. Есть возможность выбрать и различные базы данных и различные фронтовые технологии. Список реально очень обширный и в рамках данной статьи я не смогу его раскрыть.
Вот пример инициализации нового микросервисного приложения
В общем эти хипстеры могут немного упростить жизнь Java программиста, а могут и наоборот усложнить, если не достаточно разобраться в проекте.
Но не стоит забывать основное правило при создании нового проекта.
Есть классическое правило которое сформулировал Martin Fowler, которое звучит следующим образом MonolitFirst. Это правило означает что любой проект который вы начинаете разрабатывать с нуля, в начале следует разрабатывать с монолита, а потом уже пилить на микросервисы. Данное правило и правда помогает быстрее запустить проект и понять в реальности какие есть проблемы у проекта и как именно его следует распилить на микросервисы.
Также полезно будет почитать различные книги на тему микросервисной архитектуры, вот лишь некоторые из них:
Продолжение следует:
