Доброго времени суток всем форумчанам, сегодня наконец дошли руки до того, чтобы поведать вам всем о микросервисах.
Итак, что это такое? Для начала нужно уяснить, что есть 2 основные архитектуры постройки web приложений: монолитная и микросервисная. При монолитной архитектуре ты собираете какое-то N-ое число своих функций и классов в одно приложение, подключëнное к единой базе данных. Это прекрасное решение, если у тебя лëгкий небольшой проект, в котором не предполагается длительная поддержка кодовой базы. Данный подход поможет максимально быстро собрать MVP (минимально жизнеспособный продукт), но при длительной поддержки становится крайне трудно вносить изменения и нововведения (твои прошлые костыли ломаются, а багов становится всё больше и больше).
1) И вдруг ты понимаешь спустя неделю, что ничего не работает, появилось 3к костылей, а единственная твоя мысль это то, что будет проще переписать с нуля. Будет он проклят этот монолит
2) И ты просто за пару дней написал новый микросервис для нейронки и потратил ещё часик на интеграцию в общую логику приложения. Храни Господь любимые микросервисы
Одни плюсы! Конечно нет... Во-первых данный подход достаточно дорогой из-за сложности тестирования, Во-вторых в принципе требуется больше времени. Данная архитектура предназначена как задел на будущее, но на стадии MVP излишне, так как идëт только лишь проверка нужно ли вообще данное приложение рынку. Одним словом запомни, если это стартап, то в 99% случаев там будет монолит, если же жизненный цикл приложения исчисляется годами, то наверняка там микросервисы.
Что, зачем и почему мы разобрали, пришла пора реализации.
Первым делом, для разработки микросервисов необходимо установить Docker. Благодаря нему ты сможешь создать минимальную среду для работы твоей программы, именуемый контейнером.
Как же собрать своë приложение в docker? Делается это достаточно просто, есть много шаблонов под разные ЯП, в этой статье я буду показать на примере python с фреймворком flask. Для начала разберëмся, как этот контейнер устроен. А на самом деле его структура, как Ханойская башня. По сути своей есть первый слой - ОС, с минимальным количеством софта, служб и прочего шлака. Дальше идëт какая-нибудь абстракция например ЯП, БД или какая другая утилита, например Nginx. А уже третим слоем мы переносим в эту среду все файлы нашего приложения-сервиса и устанавливаем нужные зависимости. Ты можешь взять чистый контейнер с Ubuntu и накидать в него хоть впн, хоть react app, хоть среду для обучения пентесту. Всё ограничивается только твоими знаниями, что впрочем можно сказать про любое направление программирования.
Итак, практика, соберëм наш "Hello, World!" на Flask в Docker контейнер
1) main.py
Python:
2) requirements.txt
Python:
3) Dockerfile
Dockerfile:
# Выбираем образ от которого наследоваться
# Устанавливаем переменную среды для предотвращения вывода буфера при стандартных операциях ввода/вывода
# Создаем и переходим в рабочую директорию
# Копируем все файлы приложения
# Устанавливаем зависимости с помощью pip
# Команда для запуска приложения
Итак, в принципе я комментариями к коду всë расписал, но сделаю акцент на ключевых словах
1) from - импорт образа, на базе которого ты будешь деплоить своë приложение
2) run - выполнение команды в bash
3) workdir - выбор рабочей директории
4) copy - копирование (почему не через bash, потому что она не имеет доступ к памяти вне контейнера)
5) CMD - что-то типо финальной команды для запуска всего приложения
Хм, а как это запустить?
Легко!
А если несколько контейнеров и их нужно вместе запускать?
В таком случае поможет docker-compose, конечно, есть ещё Kubernetes. Но это уже для продвинутых и нереальное сложных систем, где может быть несколько одинаковых микросервисов запущенных на разных серверах, нагрузка между которыми балансирует Nginx, а запускается этим самым Kubernetes.
Продолжим, мы рассматриваем концепцию, где у нас несколько контейнеров и они общаются между собой. Мы бы могли каждый из них отдельно запускать bash командой, или же все сразу одной, но ооооочень длинной. Разумеется, если мы упрощаем архитектуру, то деплой это тоже должно затронуть.
Сейчас создай файлик docker-compose.yaml. В нём будет храниться конфигурация параметров, с которыми будет развёрнуто наше приложение. Короче конфиг для контейнеров.
На этом всё, спасибо всем кто дочитал и надеюсь, что найдëтся хоть одна заблудшая душа, которая пересядет с монолита на микросервисы (пусть даже в рамках одного пет проекта). Я не так часто пишу статьи, хотелось бы уменьшить интервал между ними, материала для них ооочень много, а времени у меня на него мало. Мне нравится совершенствоваться как программист и я желаю всем перейти наконец от sqlite и говнокода к postgres и продуманным архитектурам с чистым кодом.
Итак, что это такое? Для начала нужно уяснить, что есть 2 основные архитектуры постройки web приложений: монолитная и микросервисная. При монолитной архитектуре ты собираете какое-то N-ое число своих функций и классов в одно приложение, подключëнное к единой базе данных. Это прекрасное решение, если у тебя лëгкий небольшой проект, в котором не предполагается длительная поддержка кодовой базы. Данный подход поможет максимально быстро собрать MVP (минимально жизнеспособный продукт), но при длительной поддержки становится крайне трудно вносить изменения и нововведения (твои прошлые костыли ломаются, а багов становится всё больше и больше).
Микросервисная архитектура нацелена на разграничений зон ответственность и некоторой автономности отдельных функций приложения. Если упрощать, предположим, что у нас есть логика для авторизации, бизнес-логики, тяжëлых вычислений и web интерфейс, а также модуль для рассылки пользователям сообщений в телеграмм. Пускай наше воображаемое приложение будет заниматься конвертацией фото. Казалось бы можно сделать это единственным приложением, но спустя условно полгода ты решил улучшить его добавив интеграцию с какой-нибудь навороченный нейронкой иии...
1) И вдруг ты понимаешь спустя неделю, что ничего не работает, появилось 3к костылей, а единственная твоя мысль это то, что будет проще переписать с нуля. Будет он проклят этот монолит
2) И ты просто за пару дней написал новый микросервис для нейронки и потратил ещё часик на интеграцию в общую логику приложения. Храни Господь любимые микросервисы
Одни плюсы! Конечно нет... Во-первых данный подход достаточно дорогой из-за сложности тестирования, Во-вторых в принципе требуется больше времени. Данная архитектура предназначена как задел на будущее, но на стадии MVP излишне, так как идëт только лишь проверка нужно ли вообще данное приложение рынку. Одним словом запомни, если это стартап, то в 99% случаев там будет монолит, если же жизненный цикл приложения исчисляется годами, то наверняка там микросервисы.
Что, зачем и почему мы разобрали, пришла пора реализации.
Первым делом, для разработки микросервисов необходимо установить Docker. Благодаря нему ты сможешь создать минимальную среду для работы твоей программы, именуемый контейнером.
Как же собрать своë приложение в docker? Делается это достаточно просто, есть много шаблонов под разные ЯП, в этой статье я буду показать на примере python с фреймворком flask. Для начала разберëмся, как этот контейнер устроен. А на самом деле его структура, как Ханойская башня. По сути своей есть первый слой - ОС, с минимальным количеством софта, служб и прочего шлака. Дальше идëт какая-нибудь абстракция например ЯП, БД или какая другая утилита, например Nginx. А уже третим слоем мы переносим в эту среду все файлы нашего приложения-сервиса и устанавливаем нужные зависимости. Ты можешь взять чистый контейнер с Ubuntu и накидать в него хоть впн, хоть react app, хоть среду для обучения пентесту. Всё ограничивается только твоими знаниями, что впрочем можно сказать про любое направление программирования.
Итак, практика, соберëм наш "Hello, World!" на Flask в Docker контейнер
1) main.py
Python:
Код:
from flask import Flask
from flask import request, jsonify
app = Flask(__name__)
@app.route('/', methods=['POST','GET'])
def home():
return b"Hello, World!"
if __name__ == '__main__':
from waitress import serve
serve(app, port=9753)Python:
Код:
blinker==1.6.2
click==8.1.6
colorama==0.4.6
Flask==2.3.2
itsdangerous==2.1.2
Jinja2==3.1.2
MarkupSafe==2.1.3
waitress==2.1.2
Werkzeug==2.3.6Dockerfile:
# Выбираем образ от которого наследоваться
Код:
FROM python:3.10 Код:
ENV PYTHONUNBUFFERED 1 Код:
RUN mkdir /app
WORKDIR /app# Копируем все файлы приложения
Код:
COPY . /app/ Код:
RUN pip install --no-cache-dir -r requirements.txt Код:
CMD [ "python", "main.py" ]Итак, в принципе я комментариями к коду всë расписал, но сделаю акцент на ключевых словах
1) from - импорт образа, на базе которого ты будешь деплоить своë приложение
2) run - выполнение команды в bash
3) workdir - выбор рабочей директории
4) copy - копирование (почему не через bash, потому что она не имеет доступ к памяти вне контейнера)
5) CMD - что-то типо финальной команды для запуска всего приложения
Хм, а как это запустить?
Легко!
Код:
bash:
docker build
docker run -p 9753:9753 my-first-imageВ таком случае поможет docker-compose, конечно, есть ещё Kubernetes. Но это уже для продвинутых и нереальное сложных систем, где может быть несколько одинаковых микросервисов запущенных на разных серверах, нагрузка между которыми балансирует Nginx, а запускается этим самым Kubernetes.
Продолжим, мы рассматриваем концепцию, где у нас несколько контейнеров и они общаются между собой. Мы бы могли каждый из них отдельно запускать bash командой, или же все сразу одной, но ооооочень длинной. Разумеется, если мы упрощаем архитектуру, то деплой это тоже должно затронуть.
Сейчас создай файлик docker-compose.yaml. В нём будет храниться конфигурация параметров, с которыми будет развёрнуто наше приложение. Короче конфиг для контейнеров.
Вы должны ответить в тему или нажать кнопку 'Мне нравится' для возможности просмотра скрытого содержимого.
На этом всё, спасибо всем кто дочитал и надеюсь, что найдëтся хоть одна заблудшая душа, которая пересядет с монолита на микросервисы (пусть даже в рамках одного пет проекта). Я не так часто пишу статьи, хотелось бы уменьшить интервал между ними, материала для них ооочень много, а времени у меня на него мало. Мне нравится совершенствоваться как программист и я желаю всем перейти наконец от sqlite и говнокода к postgres и продуманным архитектурам с чистым кодом.
