Архітектури ІТ

🏗 Що таке архітектура ІТ?

Архітектура ІТ — це концептуальна модель, яка визначає структуру, компоненти, інтерфейси та принципи взаємодії елементів інформаційної системи. Вона охоплює як апаратне забезпечення (процесори, пам'ять, шини), так і програмне (додатки, сервіси, бази даних). Правильно обрана архітектура визначає масштабованість, продуктивність, надійність та вартість підтримки системи.

Історія архітектур почалася з фундаментальних моделей фон Неймана (1945) та Гарварда (1937), еволюціонувала через монолітні додатки (1980-2000-і), сервісно-орієнтовану архітектуру SOA (2000-і), і досягла сучасних підходів: мікросервіси, serverless, event-driven, мікрофронтенди та service mesh. Кожен етап вирішував проблеми попереднього: масштабованість, гнучкість, швидкість розгортання та відмовостійкість.

🔧 Класичні апаратні архітектури

🔹 Архітектура фон Неймана (Princeton)

Запропонована Джоном фон Нейманом у 1945 році в доповіді «First Draft of a Report on the EDVAC». Це фундаментальна модель комп'ютера, що використовується досі в більшості процесорів (x86, ARM). Її ключова особливість — спільна шина для даних і команд.

• Принципи: програма зберігається в пам'яті (stored-program), послідовне виконання команд, двійкова система числення, адресація пам'яті.
• Вузьке місце (bottleneck): через спільну шину процесор не може одночасно читати команду і дані — це обмежує продуктивність (von Neumann bottleneck).
• Застосування: персональні комп'ютери, сервери, смартфони, вбудовані системи.

🔹 Архітектура Гарварда

Розроблена Говардом Ейкеном у Гарвардському університеті (1937-1944) для комп'ютера Mark I. Головна відмінність — роздільні шини та пам'ять для команд і даних, що дозволяє паралельний доступ.

• Пам'ять програм (Program Memory) та пам'ять даних (Data Memory) — фізично розділені.
• Процесор може одночасно отримувати команду і дані — вища продуктивність на тактовій частоті.
• Застосування: мікроконтролери (ARM Cortex-M, AVR, PIC), цифрові сигнальні процесори (DSP), кеш-пам'ять сучасних CPU (L1 instruction cache + L1 data cache — модифікована Гарвардська архітектура).

📦 Монолітна архітектура

Моноліт — це класичний підхід, коли весь додаток (UI, бізнес-логіка, доступ до даних) зібраний в єдиний виконуваний файл або розгорнутий як один процес. Це був домінуючий підхід до 2010-х років.

• Переваги: простота розробки та тестування, легке налагодження (debugging), швидкість внутрішніх викликів (in-process), просте розгортання (один артефакт), цілісність транзакцій (ACID у межах однієї БД).
• Недоліки: складність масштабування (треба масштабувати все разом), тісне зчеплення компонентів (tight coupling), ризик «великого вибуху» при деплої, обмеження технологічного стеку (всі модулі на одній мові/фреймворку), довгий час збірки та тестування.
• Приклади: традиційні Java EE додатки (EAR/WAR), Ruby on Rails, Django, Laravel, .NET Framework додатки до появи .NET Core.

🔧 Мікросервісна архітектура

Мікросервіси — це підхід до побудови додатка як набору невеликих, слабко пов'язаних сервісів, кожен з яких відповідає за конкретну бізнес-задачу та спілкується з іншими через мережеві протоколи (HTTP/gRPC/повідомлення). Популяризований Netflix, Amazon, Uber.

Ключові характеристики:

• Single Responsibility — кожен сервіс виконує одну бізнес-функцію (наприклад, «кошик», «оплата», «користувачі»).
• Незалежне розгортання (Independent Deployability) — оновлення одного сервісу не вимагає перезбірки всього додатка.
• Поліглотність (Polyglot) — кожен сервіс може використовувати свою мову, фреймворк та базу даних (Node.js + MongoDB для одного, Go + PostgreSQL для іншого).
• Відмовостійкість (Fault Isolation) — падіння одного сервісу не обов'язково призводить до падіння всього додатка (якщо реалізовано circuit breaker, fallback).

Виклики:

• Розподілені транзакції — складно забезпечити ACID між сервісами. Використовують Saga pattern (choreography або orchestration), eventual consistency.
• Мережеві затримки — кожен виклик між сервісами це HTTP/gRPC запит (~1-50 мс), на відміну від in-process виклику (<1 мкс).
• Складність моніторингу та налагодження — потрібні distributed tracing (Jaeger, Zipkin), централізоване логування (ELK, Loki), метрики (Prometheus, Grafana).
• Data Consistency — кожен сервіс має власну БД, дані дублюються (denormalization), потрібна синхронізація через event sourcing або CQRS.

☁ Serverless та FaaS

Serverless (безсерверні обчислення) — модель, при якій розробник пише код, а хмарний провайдер повністю керує інфраструктурою: автоматичне масштабування, патчинг ОС, балансування навантаження, моніторинг. Розробник не бачить і не керує серверами.

FaaS (Function as a Service)

Найпопулярніша форма serverless. Код розбивається на окремі функції, кожна з яких запускається у відповідь на подію (HTTP-запит, завантаження файлу, повідомлення з черги, таймер). Після виконання функція «засинає» — ресурси звільняються.

• AWS Lambda — піонер FaaS (2014). Підтримує Python, Node.js, Java, Go, C#, Ruby, Rust. Максимальний час виконання: 15 хвилин.
• Azure Functions, Google Cloud Functions, Cloudflare Workers, Vercel Functions — альтернативи з різними особливостями.
• Cold Start — затримка при першому запуску функції (100 мс — 3 с), коли провайдер ініціалізує середовище виконання.

BaaS (Backend as a Service)

Ще один різновид serverless, де провайдер надає готові backend-сервіси: аутентифікацію (Auth0, Firebase Auth), бази даних (Firebase Firestore, AWS DynamoDB, Supabase), файлове сховище, push-сповіщення. Фронтенд-розробник може побудувати повноцінний додаток без написання backend-коду.

⚡ Event-driven архітектура

Event-driven архітектура (EDA) — це парадигма, при якій компоненти системи реагують на події (events) замість прямих синхронних викликів. Подія — це факт, що сталася (користувач зареєструвався, замовлення створено, платіж пройшов). Компоненти не знають один про одного — вони знають лише про брокер повідомлень.

Ключові компоненти:

• Event Producers — джерела подій (веб-додаток, IoT-датчик, база даних).
• Event Broker / Message Bus — посередник, що отримує, зберігає та розподіляє події. Приклади: Apache Kafka, RabbitMQ, AWS SNS/SQS, Google Pub/Sub, NATS, Redis Streams.
• Event Consumers — обробники, що підписані на певні типи подій і виконують бізнес-логіку.

Патерни:

• Pub/Sub (Publish-Subscribe) — продюсер публікує подію в топік, всі підписники отримують її. Приклад: сповіщення всім користувачам про нову публікацію.
• Event Sourcing — замість зберігання поточного стану об'єкта зберігається журнал усіх подій, що з ним трапилися. Стан відтворюється replay всіх подій. Приклад: банківський рахунок = сума всіх транзакцій.
• CQRS (Command Query Responsibility Segregation) — розділення моделей для читання та запису. Команда змінює стан і генерує подію, а запит читає оптимізовану read-модель.

📐 Мікрофронтенди

Мікрофронтенди — це розширення ідеї мікросервісів на фронтенд. Замість одного великого SPA (Single Page Application) додаток розбивається на незалежні фронтенд-модулі, кожен з яких розробляється, тестується та розгортається окремою командою. Термін популяризував ThoughtWorks у 2016 році.

Підходи до інтеграції:

• Build-time інтеграція — модулі збираються в один bundle під час збірки (npm-пакети, monorepo). Мінус: втрачається незалежне розгортання.
• Run-time інтеграція через iframe — кожен мікрофронтенд завантажується в окремий iframe. Плюси: повна ізоляція (CSS, JS). Мінуси: складність комунікації, проблеми з доступністю, SEO.
• Run-time через Web Components — кожен модуль експортує власний custom element (<user-profile>, <shopping-cart>), які монтуються в DOM host-додатка. Плюси: нативний стандарт, стилі можна інкапсулювати через Shadow DOM.
• Module Federation (Webpack 5) — динамічне завантаження віддалених модулів під час виконання. Кожен модуль — окремий deploy, але вони діляться загальними залежностями.

Виклики:

• Консистентність UI — різні команди можуть використовувати різні дизайн-системи. Рішення: shared component library (Storybook), Design Tokens.
• Роутинг — навігація між мікрофронтендами має бути безшовною. Рішення: shell-застосунок (host) керує роутингом верхнього рівня.
• Продуктивність — кожен модуль може тягнути свою копію React/Vue/Angular. Рішення: shared dependencies через Module Federation, singleton бібліотеки.

🕸 Service Mesh

Service Mesh — це інфраструктурний шар, що керує всією комунікацією між сервісами в мікросервісній архітектурі. Замість того щоб кожен сервіс сам реалізовував retry, timeout, circuit breaker, mTLS, observability — ці функції виносяться в прозорий проксі (sidecar), який працює поруч з кожним сервісом.

Ключові можливості:

• Traffic Management — розподіл трафіку (canary deployment, A/B testing, blue-green), retry, timeout, fault injection (хаос-інжиніринг).
• Security — автоматичне mTLS (mutual TLS) між усіма сервісами, політики доступу (authorization policies), аутентифікація (JWT validation).
• Observability — автоматичний збір метрик (latency, error rate, throughput), distributed tracing (кожен запит проходить через sidecar, який додає span'и), логування.

Популярні реалізації:

• Istio — найпотужніший і найскладніший. Працює поверх Envoy proxy. Підтримує Kubernetes, VMs. Розроблений Google, IBM, Lyft.
• Linkerd — легкий, орієнтований на простоту. Написаний на Rust. Кращий вибір для початку роботи з service mesh.
• Consul Connect — від HashiCorp. Інтегрується з Consul service discovery. Підтримує як sidecar, так і native integration.

📈 Порівняння архітектур

Таблиця нижче узагальнює ключові характеристики розглянутих архітектур для швидкого вибору підходу під конкретний проєкт.

🎯 Підсумок

Архітектура ІТ — це не статичний вибір, а еволюційний шлях. Фундаментальні моделі фон Неймана та Гарварда заклали основи сучасних процесорів, а програмні архітектури еволюціонували від монолітів до розподілених систем. Кожен підхід має свої компроміси: моноліт — простота, мікросервіси — масштабованість, serverless — економія, event-driven — гнучкість, мікрофронтенди — організаційна масштабованість, service mesh — інфраструктурна надійність.

Ключове правило: не гнатися за модою, а обирати архітектуру під команду, домен та етап розвитку продукту. Моноліт — чудовий старт. Мікросервіси — коли домен зрозумілий і команда зросла. Serverless — для змінного навантаження. Event-driven — для асинхронних процесів. Мікрофронтенди — коли фронтенд-команд багато. Service Mesh — коли сервісів більше 20 і потрібна уніфікована observability та security.

Майбутнє архітектур: поєднання підходів (polyglot architecture), AI-driven оптимізація інфраструктури, квантові обчислення (вимагатимуть нових архітектурних патернів), edge computing (розподілені мікросервіси ближче до користувача), та поступовий перехід до platform engineering — коли внутрішній DevEx-портал абстрагує складність всіх цих архітектур від розробників.