sa-lessons/modules/module1/sections/09-architecture-examples.md

Примеры архитектур известных систем

Навигация

• 🏠 Главная страница курса
• 📚 Модуль 1

---

Twitter

Обзор системы

Twitter - социальная сеть для микроблогинга, где пользователи публикуют короткие сообщения (твиты) до 280 символов.

Архитектурный стиль

• Микросервисная архитектура с event-driven подходом
• Гибридная архитектура: комбинация микросервисов и монолитных компонентов
• CQRS (Command Query Responsibility Segregation) для разделения чтения и записи

Архитектурная диаграмма

graph TB
    subgraph "Twitter Architecture"
        subgraph "Client Layer"
            Web[Web App]
            Mobile[Mobile App]
            API_Client[API Clients]
        end
        
        subgraph "API Gateway"
            LB[Load Balancer]
            Gateway[API Gateway]
        end
        
        subgraph "Core Services"
            Timeline[Timeline Service]
            Tweet[Tweet Service]
            User[User Service]
            Search[Search Service]
            Media[Media Service]
        end
        
        subgraph "Data Layer"
            MySQL[(MySQL)]
            Redis[(Redis)]
            ES[(Elasticsearch)]
            S3[(AWS S3)]
        end
        
        subgraph "Message Queue"
            Kafka[Apache Kafka]
        end
    end
    
    Web --> LB
    Mobile --> LB
    API_Client --> LB
    LB --> Gateway
    
    Gateway --> Timeline
    Gateway --> Tweet
    Gateway --> User
    Gateway --> Search
    Gateway --> Media
    
    Timeline --> Redis
    Timeline --> MySQL
    Tweet --> MySQL
    Tweet --> Kafka
    User --> MySQL
    Search --> ES
    Media --> S3
    
    Kafka --> Timeline

Основные компоненты

1. Timeline Service

• Назначение: Генерация персональных лент пользователей
• Технологии: Scala, Finagle
• Особенности:
  • Реалтайм генерация лент
  • Кэширование популярного контента
  • Асинхронная обработка

2. Tweet Service

• Назначение: Создание, хранение и распространение твитов
• Технологии: Scala, MySQL, Redis
• Особенности:
  • Fan-out паттерн для распространения
  • Шардирование по user_id
  • Event sourcing для аудита

3. User Service

• Назначение: Управление пользователями и профилями
• Технологии: Scala, MySQL
• Особенности:
  • Аутентификация и авторизация
  • Управление подписками
  • Профильная информация

4. Search Service

• Назначение: Поиск по твитам и пользователям
• Технологии: Elasticsearch, Scala
• Особенности:
  • Индексирование в реальном времени
  • Полнотекстовый поиск
  • Геопространственный поиск

5. Media Service

• Назначение: Обработка изображений и видео
• Технологии: Scala, AWS S3
• Особенности:
  • Загрузка и оптимизация медиа
  • CDN для быстрой доставки
  • Метаданные медиафайлов

Качественные атрибуты

Производительность

• Время отклика: < 200ms для timeline
• Пропускная способность: 6,000 твитов/сек
• Метрики:
  • 99.9% запросов < 1 секунды
  • Кэш hit rate > 95%

Масштабируемость

• Горизонтальное масштабирование: Все сервисы масштабируются независимо
• Шардирование: Данные разделены по user_id
• Кэширование: Многоуровневое кэширование (Redis, CDN)

Надежность

• Доступность: 99.9% uptime
• Отказоустойчивость: Graceful degradation при сбоях
• Резервирование: Multi-region deployment

Безопасность

• Аутентификация: OAuth 2.0
• Шифрование: TLS для всех соединений
• Аудит: Логирование всех действий

Архитектурные решения

1. Fan-out Pattern

// Упрощенный пример fan-out для твитов
class TweetFanoutService {
  def fanoutTweet(tweet: Tweet, followers: List[UserId]): Unit = {
    followers.par.foreach { followerId =>
      timelineService.addToTimeline(followerId, tweet)
    }
  }
}

2. Event Sourcing

// События для аудита твитов
sealed trait TweetEvent
case class TweetCreated(tweetId: String, userId: String, content: String) extends TweetEvent
case class TweetDeleted(tweetId: String, userId: String) extends TweetEvent
case class TweetLiked(tweetId: String, userId: String) extends TweetEvent

3. CQRS Implementation

// Command side - запись
class TweetCommandHandler {
  def createTweet(command: CreateTweetCommand): Unit = {
    // Валидация и создание твита
    val tweet = Tweet(command.content, command.userId)
    tweetRepository.save(tweet)
    eventBus.publish(TweetCreated(tweet.id, tweet.userId, tweet.content))
  }
}

// Query side - чтение
class TimelineQueryService {
  def getTimeline(userId: String): List[Tweet] = {
    // Чтение из оптимизированного read store
    timelineRepository.findByUserId(userId)
  }
}

---

Netflix

Обзор системы

Netflix - стриминговая платформа для видео контента с более чем 200 миллионами подписчиков по всему миру.

Архитектурный стиль

• Микросервисная архитектура с cloud-native подходом
• Event-driven architecture с Apache Kafka
• Serverless компоненты для обработки медиа

Архитектурная диаграмма

graph TB
    subgraph "Netflix Architecture"
        subgraph "Client Layer"
            Web[Web Browser]
            Mobile[Mobile App]
            TV[Smart TV]
            Console[Gaming Console]
        end
        
        subgraph "CDN Layer"
            CloudFront[AWS CloudFront]
            OpenConnect[Open Connect]
        end
        
        subgraph "API Gateway"
            Zuul[Zuul Gateway]
            Eureka[Eureka Registry]
        end
        
        subgraph "Microservices"
            User[User Service]
            Content[Content Service]
            Recommendation[Recommendation Service]
            Playback[Playback Service]
            Billing[Billing Service]
        end
        
        subgraph "Data Layer"
            Cassandra[(Cassandra)]
            Elasticsearch[(Elasticsearch)]
            Redis[(Redis)]
            S3[(AWS S3)]
        end
        
        subgraph "ML Pipeline"
            Spark[Apache Spark]
            TensorFlow[TensorFlow]
            Kafka[Apache Kafka]
        end
    end
    
    Web --> CloudFront
    Mobile --> CloudFront
    TV --> OpenConnect
    Console --> CloudFront
    
    CloudFront --> Zuul
    OpenConnect --> Zuul
    
    Zuul --> Eureka
    Eureka --> User
    Eureka --> Content
    Eureka --> Recommendation
    Eureka --> Playback
    Eureka --> Billing
    
    User --> Cassandra
    Content --> Elasticsearch
    Recommendation --> Redis
    Playback --> Redis
    Billing --> Cassandra
    
    Content --> S3
    Playback --> S3
    
    Recommendation --> Spark
    Spark --> TensorFlow
    Kafka --> Recommendation

Основные компоненты

1. API Gateway

• Назначение: Единая точка входа для всех клиентов
• Технологии: Zuul, Spring Cloud Gateway
• Особенности:
  • Маршрутизация запросов
  • Аутентификация и авторизация
  • Rate limiting и throttling

2. User Service

• Назначение: Управление пользователями и подписками
• Технологии: Java, Spring Boot, Cassandra
• Особенности:
  • Профили пользователей
  • Управление подписками
  • Предпочтения контента

3. Content Service

• Назначение: Управление каталогом контента
• Технологии: Java, Spring Boot, Elasticsearch
• Особенности:
  • Метаданные фильмов и сериалов
  • Поиск и фильтрация
  • Многоязычная поддержка

4. Recommendation Service

• Назначение: Персональные рекомендации
• Технологии: Python, TensorFlow, Apache Spark
• Особенности:
  • Machine Learning модели
  • A/B тестирование
  • Real-time рекомендации

5. Playback Service

• Назначение: Воспроизведение видео
• Технологии: Java, Spring Boot, Redis
• Особенности:
  • Управление сессиями просмотра
  • Адаптивная потоковая передача
  • Аналитика просмотров

6. CDN (Content Delivery Network)

• Назначение: Доставка видео контента
• Технологии: AWS CloudFront, Open Connect
• Особенности:
  • Глобальная сеть серверов
  • Кэширование популярного контента
  • Оптимизация для мобильных устройств

Качественные атрибуты

Производительность

• Время отклика: < 100ms для API
• Пропускная способность: Миллионы запросов в минуту
• Видео качество: Адаптивная потоковая передача

Масштабируемость

• Горизонтальное масштабирование: Все сервисы масштабируются автоматически
• Multi-region: Развертывание в нескольких регионах AWS
• Auto-scaling: Автоматическое масштабирование на основе нагрузки

Надежность

• Доступность: 99.99% uptime
• Fault tolerance: Circuit breaker pattern
• Disaster recovery: Multi-region backup

Безопасность

• DRM: Защита контента от пиратства
• Аутентификация: OAuth 2.0 + JWT
• Шифрование: End-to-end шифрование

Архитектурные решения

1. Circuit Breaker Pattern

@Component
public class RecommendationServiceClient {
    
    @CircuitBreaker(name = "recommendation-service")
    @Retry(name = "recommendation-service")
    public List<Movie> getRecommendations(String userId) {
        return recommendationService.getRecommendations(userId);
    }
}

2. Event-Driven Architecture

// Событие просмотра фильма
@Component
public class PlaybackEventHandler {
    
    @EventListener
    public void handleMovieWatched(MovieWatchedEvent event) {
        // Обновление рекомендаций
        recommendationService.updateUserPreferences(
            event.getUserId(), 
            event.getMovieId()
        );
        
        // Аналитика
        analyticsService.recordView(event);
    }
}

3. Caching Strategy

@Service
public class ContentService {
    
    @Cacheable(value = "popular-movies", key = "#region")
    public List<Movie> getPopularMovies(String region) {
        return contentRepository.findPopularByRegion(region);
    }
    
    @CacheEvict(value = "popular-movies", allEntries = true)
    public void updateMoviePopularity(String movieId) {
        // Обновление популярности
    }
}

---

Uber

Обзор системы

Uber - платформа для заказа поездок, которая соединяет водителей и пассажиров в реальном времени.

Архитектурный стиль

• Микросервисная архитектура с domain-driven design
• Event-driven architecture для real-time обработки
• CQRS для разделения команд и запросов

Архитектурная диаграмма

graph TB
    subgraph "Uber Architecture"
        subgraph "Client Layer"
            Rider[Rider App]
            Driver[Driver App]
            Web[Web Dashboard]
        end
        
        subgraph "API Gateway"
            LB[Load Balancer]
            Gateway[API Gateway]
        end
        
        subgraph "Core Services"
            Dispatch[Dispatch Service]
            Trip[Trip Service]
            Payment[Payment Service]
            User[User Service]
            Notification[Notification Service]
            Map[Map Service]
        end
        
        subgraph "Data Layer"
            PostgreSQL[(PostgreSQL)]
            MongoDB[(MongoDB)]
            Redis[(Redis)]
            PostGIS[(PostGIS)]
        end
        
        subgraph "Message Queue"
            Kafka[Apache Kafka]
        end
        
        subgraph "External Services"
            Maps[Google Maps API]
            Payment_Gateway[Payment Gateway]
            SMS[SMS Service]
            Push[Push Notification]
        end
    end
    
    Rider --> LB
    Driver --> LB
    Web --> LB
    LB --> Gateway
    
    Gateway --> Dispatch
    Gateway --> Trip
    Gateway --> Payment
    Gateway --> User
    Gateway --> Notification
    Gateway --> Map
    
    Dispatch --> Redis
    Dispatch --> Kafka
    Trip --> PostgreSQL
    Trip --> Kafka
    Payment --> PostgreSQL
    User --> MongoDB
    Notification --> Kafka
    Map --> PostGIS
    Map --> Redis
    
    Map --> Maps
    Payment --> Payment_Gateway
    Notification --> SMS
    Notification --> Push
    
    Kafka --> Notification
    Kafka --> Trip

Основные компоненты

1. Dispatch Service

• Назначение: Сопоставление водителей и пассажиров
• Технологии: Go, Redis, Kafka
• Особенности:
  • Real-time геолокация
  • Алгоритмы сопоставления
  • Load balancing

2. Trip Service

• Назначение: Управление поездками
• Технологии: Java, Spring Boot, PostgreSQL
• Особенности:
  • Жизненный цикл поездки
  • Расчет стоимости
  • Отслеживание статуса

3. Payment Service

• Назначение: Обработка платежей
• Технологии: Java, Spring Boot, PostgreSQL
• Особенности:
  • Интеграция с платежными системами
  • Расчет комиссий
  • Обработка возвратов

4. User Service

• Назначение: Управление пользователями
• Технологии: Go, MongoDB
• Особенности:
  • Профили водителей и пассажиров
  • Аутентификация
  • Рейтинги и отзывы

5. Notification Service

• Назначение: Отправка уведомлений
• Технологии: Go, Kafka, Firebase
• Особенности:
  • Push уведомления
  • SMS и email
  • Персонализация

6. Map Service

• Назначение: Картографические данные
• Технологии: Go, Redis, PostGIS
• Особенности:
  • Геокодирование
  • Маршрутизация
  • Трафик в реальном времени

Качественные атрибуты

Производительность

• Время отклика: < 50ms для dispatch
• Пропускная способность: Миллионы запросов в минуту
• Real-time: Обновления каждые 3 секунды

Масштабируемость

• Горизонтальное масштабирование: Все сервисы масштабируются независимо
• Sharding: Данные разделены по регионам
• Caching: Агрессивное кэширование геоданных

Надежность

• Доступность: 99.9% uptime
• Fault tolerance: Graceful degradation
• Data consistency: Eventual consistency

Безопасность

• Аутентификация: Multi-factor authentication
• Геолокация: Защита персональных данных
• Платежи: PCI DSS compliance

Архитектурные решения

1. Event Sourcing для поездок

// События поездки
public class TripEvent {
    private String tripId;
    private String eventType;
    private LocalDateTime timestamp;
    private Map<String, Object> data;
}

// Обработчик событий
@Component
public class TripEventHandler {
    
    @EventHandler
    public void handleTripStarted(TripStartedEvent event) {
        // Уведомление водителя и пассажира
        notificationService.notifyTripStarted(event.getTripId());
        
        // Обновление статуса
        tripService.updateStatus(event.getTripId(), TripStatus.IN_PROGRESS);
    }
}

2. CQRS для геоданных

// Command side
@Service
public class LocationCommandService {
    
    public void updateDriverLocation(String driverId, Location location) {
        // Обновление в write store
        locationRepository.updateDriverLocation(driverId, location);
        
        // Публикация события
        eventBus.publish(new LocationUpdatedEvent(driverId, location));
    }
}

// Query side
@Service
public class LocationQueryService {
    
    public List<Driver> findNearbyDrivers(Location passengerLocation) {
        // Чтение из оптимизированного read store
        return locationReadRepository.findNearbyDrivers(passengerLocation);
    }
}

3. Saga Pattern для поездок

@Component
public class TripSaga {
    
    @SagaOrchestrationStart
    public void startTrip(TripRequestedEvent event) {
        // 1. Найти водителя
        dispatchService.findDriver(event.getPassengerId())
            .thenAccept(driver -> {
                // 2. Создать поездку
                tripService.createTrip(event.getPassengerId(), driver.getId());
            });
    }
    
    @SagaOrchestrationStep
    public void handleDriverAccepted(DriverAcceptedEvent event) {
        // 3. Подтвердить поездку
        tripService.confirmTrip(event.getTripId());
    }
}

---

Сравнительная диаграмма архитектурных паттернов

graph TB
    subgraph "Architectural Patterns Comparison"
        subgraph "Twitter - Event-Driven + CQRS"
            T1[Timeline Service]
            T2[Tweet Service]
            T3[User Service]
            T4[Search Service]
            T5[Media Service]
            TK[Kafka Events]
            TR[Redis Cache]
            TM[MySQL]
        end
        
        subgraph "Netflix - Cloud-Native + ML"
            N1[User Service]
            N2[Content Service]
            N3[Recommendation Service]
            N4[Playback Service]
            N5[Billing Service]
            NC[CDN]
            NK[Kafka]
            NCass[Cassandra]
        end
        
        subgraph "Uber - DDD + Real-time"
            U1[Dispatch Service]
            U2[Trip Service]
            U3[Payment Service]
            U4[User Service]
            U5[Notification Service]
            U6[Map Service]
            UK[Kafka]
            UPG[PostgreSQL]
            UMG[MongoDB]
        end
    end
    
    T1 -.-> TK
    T2 -.-> TK
    T3 -.-> TM
    T4 -.-> TM
    T5 -.-> TM
    
    N1 -.-> NK
    N2 -.-> NCass
    N3 -.-> NK
    N4 -.-> NCass
    N5 -.-> NCass
    
    U1 -.-> UK
    U2 -.-> UK
    U3 -.-> UPG
    U4 -.-> UMG
    U5 -.-> UK
    U6 -.-> UPG

Сравнительная таблица архитектур

Система	Архитектурный стиль	Основные технологии	Особенности
Twitter	Микросервисы + CQRS	Scala, MySQL, Redis	Fan-out pattern, Event sourcing
Netflix	Микросервисы + Cloud-native	Java, Spring Boot, AWS	CDN, ML рекомендации
Uber	Микросервисы + DDD	Go, Java, PostgreSQL	Real-time геолокация, Saga pattern

---

Диаграмма ключевых архитектурных паттернов

graph TB
    subgraph "Key Architectural Patterns"
        subgraph "Microservices Pattern"
            MS1[Service A]
            MS2[Service B]
            MS3[Service C]
            MS4[Service D]
            MSG[API Gateway]
            MSL[Load Balancer]
        end
        
        subgraph "Event-Driven Pattern"
            ED1[Event Producer]
            ED2[Event Bus/Kafka]
            ED3[Event Consumer A]
            ED4[Event Consumer B]
            ED5[Event Consumer C]
        end
        
        subgraph "CQRS Pattern"
            CQRS_C[Command Side]
            CQRS_Q[Query Side]
            CQRS_WS[(Write Store)]
            CQRS_RS[(Read Store)]
            CQRS_E[Event Bus]
        end
        
        subgraph "Caching Strategy"
            CACHE_L1[L1 Cache<br/>Application]
            CACHE_L2[L2 Cache<br/>Redis]
            CACHE_L3[L3 Cache<br/>CDN]
            CACHE_DB[(Database)]
        end
    end
    
    MSL --> MSG
    MSG --> MS1
    MSG --> MS2
    MSG --> MS3
    MSG --> MS4
    
    ED1 --> ED2
    ED2 --> ED3
    ED2 --> ED4
    ED2 --> ED5
    
    CQRS_C --> CQRS_WS
    CQRS_C --> CQRS_E
    CQRS_E --> CQRS_Q
    CQRS_Q --> CQRS_RS
    
    CACHE_L1 --> CACHE_L2
    CACHE_L2 --> CACHE_L3
    CACHE_L3 --> CACHE_DB

Ключевые паттерны и решения

1. Микросервисная архитектура

• Преимущества: Независимое развертывание, масштабируемость
• Недостатки: Сложность, network latency
• Применение: Все три системы используют микросервисы

2. Event-Driven Architecture

• Преимущества: Слабая связанность, масштабируемость
• Недостатки: Сложность отладки, eventual consistency
• Применение: Twitter (твиты), Netflix (просмотры), Uber (события поездок)

3. CQRS (Command Query Responsibility Segregation)

• Преимущества: Оптимизация для чтения и записи
• Недостатки: Сложность, eventual consistency
• Применение: Twitter (timeline), Uber (геолокация)

4. Caching Strategies

• Redis: Для быстрого доступа к данным
• CDN: Для статического контента
• Application Cache: Для часто используемых данных

5. Database Patterns

• Sharding: Разделение данных по ключам
• Read Replicas: Для масштабирования чтения
• Event Sourcing: Для аудита и восстановления

---

Диаграмма процесса анализа архитектуры

flowchart TD
    A[Выбор системы] --> B[Изучение документации]
    B --> C[Анализ технических блогов]
    C --> D[Изучение open-source компонентов]
    
    D --> E[Определение доменов]
    E --> F[Выделение сервисов]
    F --> G[Анализ взаимодействий]
    
    G --> H[Оценка производительности]
    H --> I[Анализ масштабируемости]
    I --> J[Проверка надежности]
    J --> K[Оценка безопасности]
    
    K --> L[Изучение паттернов]
    L --> M[Анализ технологий]
    M --> N[Выявление trade-offs]
    
    N --> O[Создание диаграммы]
    O --> P[Документирование решений]
    P --> Q[Финальный отчет]
    
    style A fill:#e1f5fe
    style Q fill:#c8e6c9
    style O fill:#fff3e0

Рекомендации для анализа

1. Выберите систему

• Изучите публичную информацию о архитектуре
• Проанализируйте технические блоги компании
• Изучите open-source компоненты

2. Определите компоненты

• Выделите основные домены
• Определите границы сервисов
• Проанализируйте взаимодействие

3. Оцените качественные атрибуты

• Производительность (метрики, нагрузки)
• Масштабируемость (как система растет)
• Надежность (обработка сбоев)
• Безопасность (защита данных)

4. Изучите архитектурные решения

• Паттерны проектирования
• Технологические выборы
• Trade-offs и компромиссы

---