Архитектура

Мы храним и передаём конфигурации, ответы API, выгрузки из базы, прайс-листы — и каждый раз встаёт вопрос «в каком формате». Разберём четыре самых частых — JSON, YAML, CSV и нативный PHP-массив — по делу: чем они отличаются, для чего созданы, где ломаются и когда между ними…

Одиннадцатая, завершающая статья серии «Архитектура и производительность». Мы прошли длинный путь: решили, делить ли приложение на части (Монолит против микросервисов), научили части разговаривать (Проектирование API) и не терять тяжёлые задачи (Очереди сообщений), ускорили ответы (Кеширование), раскидали запросы по серверам (Балансировка нагрузки), навели порядок в метриках, логах,…

Десятая статья серии «Архитектура и производительность». К этому моменту у нас сложилась почти полная картина: сервисы разделили или оставили монолитом (монолит против микросервисов), договорились об интерфейсах (проектирование API), разгрузили тяжёлые задачи (очереди сообщений), ускорили ответы (кеширование), раскидали запросы по серверам (балансировка нагрузки), научились смотреть на цифры…

Девятая статья серии «Архитектура и производительность». Мы уже научились раскладывать нагрузку по серверам (балансировка нагрузки), ускорять ответы из кэша (кеширование) и видеть, где именно всё тормозит, по логам и трассировке (логирование и трассировка). В прошлой серии мы довели клиент до автономности: приложение умело работать без сети…

Седьмая статья серии «Архитектура и производительность» продолжает разговор о наблюдении за системой. В предыдущей — Метрики и мониторинг — мы разобрались, как узнать, что сломалось: доля ошибок 5xx выросла, время ответа p95 уползло вверх, очередь растёт. Но метрика — это число, а число не объясняет причину:…

В предыдущих статьях серии мы научились передавать запрос через API, складывать тяжёлую работу в очередь, держать готовые ответы в кэше, размазывать нагрузку по нескольким серверам, смотреть метрики и находить виновника по логам. Но почти любой запрос в итоге упирается в одно место — базу данных. И…

Пятая статья серии «Архитектура и производительность». Ранее мы разобрали, когда код надо делить на сервисы (монолит против микросервисов), как они общаются (проектирование API) и как ускорять ответы (кеширование). Теперь посмотрим на систему со стороны сети: у вас есть адрес, по которому приходят пользователи, и группа серверов,…

Шестая статья серии «Архитектура и производительность» отвечает на вопрос, который задаёт каждый, чей сайт однажды упал ночью: почему я узнал об этом последним? Пользователи пришли и ушли, а вы узнали только из писем «у вас не работает» утром. Мониторинг нужен ровно для того, чтобы перевернуть эту…

Мы уже разобрались, как устроена система внутри (Монолит против микросервисов), как её части договариваются между собой (Проектирование API) и как не терять тяжёлые задачи в очереди (Очереди сообщений). Пришла пора самой благодарной темы: как сделать так, чтобы сайт отвечал быстрее, почти не меняя код. Ответ почти…

В прошлой статье мы решили, из каких кусков состоит система: Монолит против микросервисов описал, когда всё держать в одном процессе, а когда разносить по отдельным службам. Но разделение само по себе ничего не даёт. Три независимых сервиса бесполезны, пока не научатся передавать друг другу данные —…