Что такое архитектура
Аналогия: архитектура — это план здания. Не цвет стен и не мебель, а как устроены комнаты, коридоры и коммуникации.
В IT архитектура — это то, как продукт разделён на части и как эти части связаны.
Снаружи пользователь видит один сайт или приложение. Внутри это может быть:
- одна большая система;
- или много маленьких сервисов, которые работают вместе.
От архитектуры зависит: куда «падает» ошибка, как быстро выкатывают фичи и насколько сложно искать причину бага.
Что такое серверы и клиенты
Аналогия: клиент — это посетитель, который делает заказ. Сервер — кухня/касса, которая заказ принимает, обрабатывает и отвечает.
Почти любой сайт и приложение работают по схеме «клиент ↔ сервер».
- Клиент — то, чем пользуется человек: браузер, мобильное приложение, программа на компьютере. Он отправляет запросы.
- Сервер — компьютер (или несколько) в интернете/облаке, где живут логика и данные. Он принимает запросы и отвечает.
Упрощённо
клиент ↔ сервер
[ Клиент ]
браузер / приложение
↓ запрос: «покажи заказы»
[ Сервер ]
логика + база данных
↓ ответ: список заказов / ошибка
[ Клиент показывает результат на экране ]
Какими бывают клиенты
«Клиент» — не только человек. В IT клиент = программа, которая обращается к серверу.
- Веб-клиент (браузер) — Chrome, Safari, Firefox. Самый частый вариант для сайтов.
- Мобильный клиент — приложение на iOS / Android.
- Десктоп-клиент — программа на компьютере (Windows, macOS, Linux).
- Планшет / TV / киоск — отдельное устройство со своим приложением или браузером.
- Другой сервис как клиент — один сервер ходит в другой по API. Для оплаты, SMS, аналитики это нормально.
- Боты и скрипты — автоматические программы, которые тоже делают запросы.
Какими бывают серверы (очень просто)
- Веб-сервер — отдаёт страницы и принимает HTTP-запросы.
- Сервер приложения — считает бизнес-логику: создать заказ, проверить пароль.
- Сервер базы данных — хранит данные.
- Файловый / CDN — раздаёт картинки, видео, статику ближе к пользователю.
На практике «сервер» часто говорят про всю «бэкенд-часть» сразу. Для новичка достаточно: клиент спрашивает — сервер отвечает.
Важно для тестирования: баг может быть на клиенте (криво нарисовалось, кнопка не отправила запрос) или на сервере (запрос ушёл, но ответ неправильный / 500). Поэтому полезно смотреть и экран, и Network в DevTools.
Монолит
Аналогия: монолит — как один большой супермаркет. Всё в одном здании: касса, склад, отдел доставки, поддержка.
Монолит — когда почти весь продукт живёт как одно целое:
- один основной код / одно большое приложение;
- часто одна общая база данных;
- релиз обычно выкатывает сразу большую часть системы.
Упрощённо
монолит
[ Сайт / приложение ]
↓
[ Одна большая система: заказы + оплата + пользователи + отчёты ]
↓
[ Одна база данных ]
Плюсы простыми словами
- Проще начать и понять «где всё лежит».
- Меньше «переписок» между разными сервисами.
- Для маленькой команды часто удобнее.
Минусы
- Большая система тяжелее менять: затронул одно — можете задеть другое.
- Релиз иногда «тяжёлый»: выкатываете много сразу.
- Если монолит упал — может упасть почти всё.
Микросервисы
Аналогия: микросервисы — как торговый квартал. Отдельный магазин заказов, отдельная касса, отдельная доставка. Каждый отвечает за своё, но вместе дают сервис клиенту.
Микросервисы — когда продукт разделён на несколько независимых частей (сервисов). Например:
- сервис пользователей;
- сервис заказов;
- сервис оплаты;
- сервис уведомлений.
Они общаются друг с другом через API, очереди и другие интеграции.
Упрощённо
микросервисы
[ Сайт / приложение ]
↓
[ users ] · [ orders ] · [ payments ] · [ notify ]
каждый сервис может иметь свою базу / логику
Плюсы простыми словами
- Можно развивать и выкатывать части отдельно.
- Ошибка в одном сервисе не всегда валит весь продукт.
- Разным командам проще делить ответственность.
Минусы
- Сложнее понять «где именно сломалось».
- Больше интеграций = больше мест для сбоев.
- Тестировать труднее: нужно проверять не только экран, но и связи между сервисами.
Чем отличаются
|
Монолит |
Микросервисы |
| Как устроен |
Одно большое целое |
Много маленьких частей |
| Релизы |
Часто одним пакетом |
Можно по частям |
| Падение |
Может затронуть почти всё |
Чаще ломается отдельный кусок |
| Поиск бага |
Ищите внутри одной системы |
Нужно понять, какой сервис и какая связь |
| Когда удобно |
Старт, небольшой продукт |
Крупная система, много команд |
Важно: не бывает «всегда лучше». Монолит не «плохо», микросервисы не «круто по умолчанию». Это разные способы собрать продукт.
Что это значит для тестирования
Снаружи баг выглядит одинаково: «кнопка не работает», «заказ не создался». Но причина зависит от архитектуры.
В монолите чаще думайте так
- Сломалась общая логика или общая база.
- Новая фича задела соседний модуль.
- Регресс может всплыть «далеко» от места изменений.
В микросервисах чаще думайте так
- Какой сервис отвечает за шаг сценария?
- Дошёл ли запрос до оплаты / уведомлений / заказов?
- Не «потерялось» ли сообщение между сервисами?
- Не рассинхронились ли данные в разных частях?
Пример
один симптом — разные причины
Симптом на UI:
«Заказ создан, но письмо не пришло»
В монолите:
возможно, ошибка в модуле писем внутри одной системы
В микросервисах:
orders создал заказ → notify не получил событие / упал / ответил ошибкой
Поэтому тестировщику полезно спрашивать команду: «У нас монолит или сервисы? Какие границы?» — это ускоряет поиск причины.
Мини-практика на 15–20 минут
- Выберите знакомый сервис: интернет-магазин, доставка еды, банковское приложение.
- Назовите, кто здесь клиент, а кто сервер. Перечислите 2–3 возможных клиента (браузер, мобильное приложение…).
- Разложите серверную часть на модули: пользователи, каталог, корзина, оплата, уведомления.
- Нарисуйте два варианта: всё в одном блоке (монолит) и отдельные блоки (микросервисы).
- Придумайте баг «оплата прошла, заказ не отобразился» и опишите, где искать причину: на клиенте, на сервере, в связи между сервисами.
Если можете объяснить на бытовом примере — день 6–7 пройден.