Шаблонизатор Laravel Blade позволяет возвращать в ответе на запрос часть страницы 💪

https://laravel.com/docs/9.x/blade#rendering-blade-fragments

Подписывайся: @onecode_blog

Cлабая связанностью и сильная связностью

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

https://medium.com/german-gorelkin/low-coupling-high-cohesion-d36369fb1be9

Подписывайся: @onecode_blog

Что такое микросервисная архитектура

В интернете полно определений, а я попробую описать своими словами.

Архитектуру проекта можно назвать микросервисной, если этот проект состоит из нескольких мини-проектов (микросервисов).

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

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

Оптимальным размером микросервиса считается такой размер, который разработчик (или команда) может написать с нуля за 1-2 спринта (примерно месяц).

Микросервисы "общаются" друг с другом синхронно по HTTP (через API) или асинхронно при помощи брокера сообщений (через события).

В общем если твой проект имеет один репозиторий, в котором хранится весь исходный код - это монолит. А если проект состоит из нескольких репозиториев - это скорее всего микросервисы.

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

Следудющие посты будут про плюсы и минусы микросервисов - там самая жара.

Поделись опытом разработки микросервисной архитектуры в комментариях!

Сделай репост коллегам по цеху!

Подпишись: @onecode_blog

Плюсы микросервисов

Сегодня коротко обсудим основные преимущества микросервисной архитектуры. В процессе чтения предлагаю подумать - действительно ли тебе не хватает этих плюсов при работе в монолитной архитектуре? Или всё это фигня.

Итак, мы переписали интернет-магазин на микросервисную архитектуру и даже распилили базу данных на части. Какие плюсы получили?

Маленькие проекты

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

Устойчивость к ошибкам

Каждая ошибка влияет на свой микросервис. Ошибка в одном микросервисе редко приводит к остановке всего приложения. Конечно, здесь важно предусмотреть поведение сервисов, если "сосед" не отвечает, но в целом универсальной страницы "Упс, что-то пошло не так" достаточно. Отвалился сервис доставки? Хреново, но всё остальное работает, как часики.

Быстрая доставка обновлений

В маленький микросервис с чёткими границами проще вносить изменения. Ты можешь полностью изменять реализацию сервиса, не боясь сломать что-то в другом микросервисе. Главное, чтобы программынй интерфейс (API) и события (Events) остались прежними. Ну или выкатить новую версию API, а старую пока оставить для обратной совместимости. Нужно добавить новый способ доставки? Идёшь в сервис доставки и решаешь задачу, не беспокоясь о том, что можешь сломать сервис заказов или оплаты.

Высокая доступность

Можно масштабировать каждый сервис отдельно. Например использовать Docker Swarm, Kubernetes или вручную накинуть серверов при необходимости. Не всем сервисам нашего магазина нужны одинаковые ресурсы. Сервис аналитики требует больше ресурсов для генерации отчётов? Накинем ему мощностей в индивидуальном порядке, пока остальные сервисы работают на своих ресурсах. А в черную пятницу его наоборот можно не трогать.

Выделенная команда

Можно использовать небольшую команду из 3-5 человек для обслуживания 2-3 микросервисов. Умственная нагрузка на дизайнера, разработчика, тестировщика и менеджера меньше, потому что они несут ответственность только за свои сервисы. Нужно разработать новый сервис с Искуственным интеллектом? Соберём команду с соответсвующим опытом для этого микросервиса. При этом нет надобности показывать им код остальных сервисов.

Любые технологии

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

Быстрая сборка и тестирование

Автоматические тесты в каждом отдельном микросервисе проходят в разы быстрее, потому что там мало кода и функций. Сборка сервисов, написаных на компилируемых языках тоже будет выполняться быстро. Получаем экономию времени на разработку и тестирование. Вынесли модуль оплаты в отдельный микросервис? Теперь деплой в продакшен занимает 1 минуту вместо 20 минут, включая сборку и тесты.

Итог

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

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

Подумай что тебя напрягает в твоём монолите сейчас? Или проблемы, которые решают микросервисы высосаны из пальца? Пиши в комментариях!

Подпишись: @onecode_blog

Тестирую коворкинг CoSea Coworking в Аланьи, Турция.

Стоимость в конце видео. Инстаграм: instagram.com/cosea_coworking

Подпишись: @indigoram89_blog

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

Купил этот курс еще месяц назад, но добрался только сейчас. Ура!

Считаю, что получение чужого практического опыта - важнейшая часть развтия! Всегда готов заплатить за качественный материал 🤝

https://education.borshev.com/architecture

Расскажи, какие реально полезные курсы покупал в этом году?

Подпишись: @onecode_blog

Tabler - интересный шаблон для админки на основе Bootstrap 👇

Demo: https://preview.tabler.io/

Сайт: https://tabler.io

Спасибо, что делитесь полезными инструментами!

Подпишись: @onecode_blog

В выражении

match

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

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

Подпишись: @onecode_blog

TenChat - отечественный аналог Linkedin. Фронтенд на Tailwind и Vue 😃

https://tenchat.ru/

Подпишись: @onecode_blog

PlanetScale

Облачная безсерверная база данных MySQL для высоких нагрузок без заморочек.

https://planetscale.com

Подпишись: @onecode_blog

Продуктивности с удовольствием!

Изучаем фреймворк Laravel (PHP)

- Как модели работают под капотом?
- Создадим свой класс модели с нуля
- Два способа добавления записей в базу
- Какой способ лучше использовать?
- Полезные советы и нюансы

https://youtu.be/ZqPSBC5P7vY

Подпишись: @onecode_blog

Зашел в новый ЛК налоговой, а там Tailwind CSS

https://tailwindcss.com

Подпишись: @onecode_blog