Что такое монолитная архитектура?

# Монолитная архитектура (Monolithic Architecture)

Определение

Монолитная архитектура — это стиль разработки приложения, в котором все компоненты системы (UI, бизнес-логика, база данных) объединены в одно большое приложение, развертываются как единый блок и работают в одном процессе.

Основные характеристики

1. Единое приложение

┌─────────────────────────────────────┐
│         МОНОЛИТНОЕ ПРИЛОЖЕНИЕ       │
├─────────────────────────────────────┤
│  UI слой                            │
│  └─ React, Vue, Angular             │
├─────────────────────────────────────┤
│  Бизнес-логика                      │
│  └─ Service Layer, Controllers       │
├─────────────────────────────────────┤
│  Слой данных                        │
│  └─ ORM, Repository Pattern          │
├─────────────────────────────────────┤
│  База данных                        │
│  └─ PostgreSQL, MySQL               │
└─────────────────────────────────────┘

Все развертывается как ОДИН контейнер
Все работает в ОДНОМ процессе

2. Общее хранилище кода

project/
├── frontend/
│   ├── components/
│   ├── pages/
│   └── styles/
├── backend/
│   ├── api/
│   │   ├── users.py
│   │   ├── posts.py
│   │   └── comments.py
│   ├── models/
│   ├── services/
│   └── database/
└── database/
    ├── migrations/
    └── schema.sql

3. Единая база данных

Все микросервисы (если они бы были) используют одну БД и часто одну схему.

# Все в одном месте
class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    name = Column(String)

class Post(Base):
    __tablename__ = "posts"
    id = Column(Integer, primary_key=True)
    user_id = Column(Integer, ForeignKey("users.id"))
    content = Column(String)

class Comment(Base):
    __tablename__ = "comments"
    id = Column(Integer, primary_key=True)
    post_id = Column(Integer, ForeignKey("posts.id"))

Пример монолитного приложения на FastAPI

from fastapi import FastAPI, HTTPException
from sqlalchemy import Column, Integer, String
from sqlalchemy.orm import Session

app = FastAPI()

# ========== MODELS ==========
class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)

class Post(Base):
    __tablename__ = "posts"
    id = Column(Integer, primary_key=True)
    user_id = Column(Integer, ForeignKey("users.id"))
    title = Column(String)

# ========== SERVICES ==========
def get_user(db: Session, user_id: int):
    return db.query(User).filter(User.id == user_id).first()

def create_post(db: Session, user_id: int, title: str):
    post = Post(user_id=user_id, title=title)
    db.add(post)
    db.commit()
    return post

def get_user_posts(db: Session, user_id: int):
    return db.query(Post).filter(Post.user_id == user_id).all()

# ========== API ENDPOINTS ==========
@app.get("/users/{user_id}")
def read_user(user_id: int, db: Session = Depends(get_db)):
    user = get_user(db, user_id)
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return user

@app.post("/users/{user_id}/posts")
def create_user_post(user_id: int, title: str, db: Session = Depends(get_db)):
    user = get_user(db, user_id)
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return create_post(db, user_id, title)

@app.get("/users/{user_id}/posts")
def read_user_posts(user_id: int, db: Session = Depends(get_db)):
    return get_user_posts(db, user_id)

# ========== DEPLOYMENT ==========
# docker run -p 8000:8000 my-monolith:latest
# Все работает в одном контейнере!

Плюсы монолитной архитектуры

1. Простота разработки (особенно вначале)

# Легко добавить новый функционал
@app.get("/reports")
def get_reports(db: Session = Depends(get_db)):
    users = db.query(User).all()
    posts = db.query(Post).all()
    return {"users_count": len(users), "posts_count": len(posts)}

# Просто переменные, просто запросы, просто разворот

2. Легко тестировать (на ранних стадиях)

from fastapi.testclient import TestClient

client = TestClient(app)

def test_get_user():
    response = client.get("/users/1")
    assert response.status_code == 200
    assert response.json()["name"] == "Alice"

3. Хорошая производительность (при малых объемах)

Монолит:
- Нет сетевых задержек между сервисами
- Прямые вызовы функций в памяти
- Одна БД, нет синхронизации

4. Упрощенное развертывание

# Один докер-образ, один контейнер
docker build -t myapp .
docker run -p 8000:8000 myapp

# Вместо:
# - Микросервис пользователей
# - Микросервис постов
# - Микросервис комментариев
# - API Gateway
# - Message Queue

5. Проще с базой данных

# ACID транзакции работают автоматически
def transfer_money(user_from_id: int, user_to_id: int, amount: int, db: Session):
    try:
        user_from = db.query(User).filter(User.id == user_from_id).first()
        user_to = db.query(User).filter(User.id == user_to_id).first()
        
        user_from.balance -= amount
        user_to.balance += amount
        
        db.commit()  # Атомарная операция
    except Exception as e:
        db.rollback()
        raise

Минусы монолитной архитектуры

1. Сложность при масштабировании

Проблема:
┌────────────────┐
│    МОНОЛИТ     │  CPU: 80%, Memory: 75%
└────────────────┘

Нужна масштабируемость:
┌────────────────┐
│    МОНОЛИТ     │  CPU: 80%
├────────────────┤
│    МОНОЛИТ     │  CPU: 80%
├────────────────┤
│    МОНОЛИТ     │  CPU: 80%
└────────────────┘

Проблема: 1 слабое место (например, API отчетов) замораживает весь монолит!

2. Сложность в разработке при большой команде

Команда из 50+ разработчиков в одном монолите:
- Конфликты в git
- Разные стили кодирования
- Сложная координация изменений
- "Мой код сломал твой код"

При микросервисах:
- Команда A: сервис пользователей
- Команда B: сервис постов
- Команда C: сервис комментариев
- Независимая разработка!

3. Технологический долг и медленные деплои

# Монолит постарел:
# - Django (старый Python фреймворк)
# - PostgreSQL (медленный для конкретного модуля)
# - ORM (не оптимальна для аналитики)

# Обновление:
# Нужно обновить ВСЕ на новые версии
# Риск сломать всё приложение
# Медленно тестировать на всё приложение

# Вместо:
# Микросервис аналитики: Node.js + MongoDB (новая технология)
# Микросервис API: FastAPI (новый фреймворк)
# Независимые обновления!

4. Оптимизация производительности

# Монолит:
# Если медленная БД для одного модуля, 
# это влияет на всё приложение

# Решение для микросервисов:
# - Микросервис пользователей: PostgreSQL (для ACID)
# - Микросервис аналитики: ClickHouse (для OLAP)
# - Микросервис поиска: Elasticsearch (для полнотекста)

5. Сложность в тестировании при росте кода

# Монолит на 1 млн строк кода:
def test_create_post():
    # Нужно мокировать 50+ зависимостей
    # Полный запуск тестов занимает 2+ часа
    # CI/CD медленный
    pass

# Микросервис с 100k строк:
def test_create_post():
    # Мокируем 5-10 зависимостей
    # Запуск тестов: 2-3 минуты
    # Быстрая обратная связь
    pass

Когда использовать монолитную архитектуру

✅ Монолит подходит для:

1. Стартапы и MVPs

   • Неизвестны требования
   • Быстро нужны результаты
   • Маленькая команда

2. Малые проекты (до 50k строк кода)

   • Простая логика
   • 5-10 разработчиков
   • Стабильные требования

3. Прототипирование

   • Нужно быстро проверить идею
   • Потом переписать на микросервисы

❌ Монолит плохо для:

1. Большие системы (1млн+ строк кода)
2. Большие команды (50+ разработчиков)
3. Различные технологические требования
   • Один модуль нужен на Node.js
   • Другой нужен на Python
4. Разные требования к масштабируемости
   • Поиск требует очень высокой нагрузки
   • Аналитика требует специального хранилища

Монолит vs Микросервисы

Вывод

Монолитная архитектура — это простой и практичный подход для малых и средних проектов. Это хороший выбор для стартапов и MVPs, когда скорость разработки критична. Однако при росте приложения (больше 500k строк, 30+ разработчиков) монолит становится узким местом, и стоит рассмотреть переход на микросервисы или модульный монолит. Помни: начни с монолита, масштабируйся когда понадобится.