Блоги: заметки с тегом system-design

Паттерн «Репозиторий»

Bohdan Stefaniuk — Thu, 08 Jul 2021 17:50:13 +0500

Репозиторий один из самых популярных паттернов для доступа к данным. Он используется для абстрагирования от конкретной реализации и нюансов работы с источником данных, внешних сервисов, файловой системой и т. д.

С одной стороны, это очень простой паттерн, который позволяет скрыть сложность работы с БД. Но с другой стороны, спросите 10 программистов описать этот шаблон и вы получите 10 разных реализаций.

Самая большая проблема этого шаблона — множество вопросов, которые возникают при его реализации и дальнейшей поддержки.

Изначально хотел сам расписать проблемы, но за меня это уже сделали, поэтому настоятельно советую прочитать статью: «Проблемы паттерна Репозиторий».

Если кратно, то:

Что делать если репозиториям нужно использовать закрытые методы друг друга?
Можно ли использовать один репозиторий на весь проект или делать репозиторий на каждую сущность?
Нужно ли дублировать методы репозитория в сервис или мы можем напрямую использовать репозиторий в контроллерах?
Нужно ли возвращать IQueryable и как это повлияет на дизайн системы в случае с .NET кодом? Если нет, то как правильно изменять сущности без использования Change Tracking?
Как правильно объединить репозиторий и UoW?

Отдельно также хочу отметить доклад: Денис Цветцих «Repository и UnitOfWork в 2020 году, must have или антипаттерн?». В нем также поднимаются проблемы репозитория, способы их решения и варианты замены этот шаблона на другой.

Репозиторий — хороший паттерн, который должен быть в арсенале любого программиста, но стоит использовать его с умом и учитывать проблемы, которые он может вызвать.

Для себя я решил что репозиторий хорошо подходит, когда вся логика приложения вписывается в CRUD модель. Но если логика более сложная или приложение подразумевает Task Base UI, тогда лучше прибегнуть к подходу CQRS. Он позволяет разбить сложную бизнес логику включая репозитории на независимые объекты, каждый из которых выполняет только одну бизнес задачу или use case.

Я кроме все прочего не люблю репозитории за:

Ограничение функциональности ORM, большенство специфических операций недоступны. В зависимости от реализации можем потерять Change Tracking.
Дополнительный мапинг из доменных объектов в DTO.
Дополнительный слой абстракции, который зачастую просто не нужен. Особенно если речь идет о небольших сервисах где логику нужно делать максимально простой и незамысловатой.
Работает только в простых CRUD сценариях.

Документация

Bohdan Stefaniuk — Thu, 09 May 2019 14:22:39 +0500

Bohdan Stefaniuk:

Ох сколько проблем вызывает документация. И зачастую эти проблемы связаны с ее отсутствием. Почти всегда разработчики считаю что написание документации это: лишнее, бюрократия, скучно. Также часто разработчики приводят в пример цитату из скрам гайда: работающий продукт важнее исчерпывающей
документации.

Я считаю что документация в том или ином виде должна присутствовать. Зачастую ее ценность понимается не сразу, а по прошествию времени. Например так случилось и в нашей команде, когда старые разработчики ушли и новеньким было очень сложно делать экскурс по системе, а она очень большая!

Но я против детально и огромной документации. Для себя и своих личных проектов я придерживаюсь следующего шаблона. Он достаточно компактный и простой в написании. Да это не ГОСТ, не ISO и не IEEE. Но она понятная и ее написание не занимает много времени.

Какие проблемы я пробую решить своим шаблоном:

Для чего нужен данный модуль или архитектура?
Как ее использовать?
Как вносить изменения?
Как осуществлять диагностику или проверку состояния?
Какие были связаны с ней проблемы?
Какими тестами покрыто? (Проблема очень важная, так как часто при планировании изменений приходилось вспоминать/идти проверять какими тестами покрыт функционал, что отнимало иногда много времени).

Шаблон документации

Назначение: для чего нужен этот модуль, какую задачу решает?

Основная задача: ссылка на задачу в трекере в рамках которой разрабатывалась данный модуль.

Диаграмма: графическое отображение архитектуры. Позволит понять что от кого зависит и как взаимодействует с другими частями системы.

Зоны ответственности: кратко описать элементы модуля и за что они отвечают. Смысл приёма в том, чтобы явно выделить назначение класса. Идеальный результат — получить класс, который можно описать одной фразой или даже одним словом.

Пример использования: небольшой пример того как использовать данный функционал.

Обработка ошибок: как обрабатываются ошибки.

Логирование:

В какой файл пишутся логи.
Уровни логирования и какую они могут дать информацию.

Тесты: каким типом тестов покрыта данная функциональность.

FAQ: вопросы и ответы по данной функциональности. Например: как объединить 2 объекта в сущности?

Инциденты и баги: ссылки на баги, которые были найдены в данной функциональности и исправленные.

Статьи по теме

Логирование

Bohdan Stefaniuk — Mon, 29 Apr 2019 22:58:18 +0500

Bohdan Stefaniuk:

Для чего вообще нужно логирование в приложении:

Сказать, что делать система, не прибегая к отладчику.
Найти причины возникновения той или иной ситуации внутри приложения.
Анализ того на что тратится больше всего ресурсов.

Какие есть требования к логерам?

Уровни логирования и фильтрация сообщений.
Ротация лог файлов.
Возможность писать сообщения не только в файл.
Thread safety.
Асинхронное логирование.
Формат и конфигурация логов.

Уровни логирования

TRACE — вывод всего подряд. На тот случай, если Debug не позволяет локализовать ошибку. В нем полезно отмечать вызовы разнообразных блокирующих и асинхронных операций.
DEBUG — журналирование моментов вызова «крупных» операций. Старт/остановка потока, запрос пользователя и т. п.
INFO — обычные сообщения, информирующие о действиях системы. Реагировать на такие сообщения вообще не надо, но они могут помочь, например, при поиске багов, расследовании интересных ситуаций итд.
WARNING — нештатные ситуации. Например непредвиденные параметры, странные форматы запроса. Любая информация, которая должна привлечь внимание. Некритичные ошибки.
ERROR — ошибка в работе системы, требующая вмешательства. Что-то не сохранилось, что-то отвалилось.
FATAL — критическая ситуация, которая требует немедленной реакции. Обычно значит что система в неработоспособном состоянии. Пишем в лог все до чего можем дотянутся.

Замечание! Никогда не отправляйте пустое исключение в лог. Так как обычно не понятно к чему принадлежит этот стэк-трейс, как программа отреагировала на ошибку. Чтобы избежать этого, в дополнение к трейсам прикладывайте и сообщение, которое обьясняет что именно произошло.

Интересные статьи на тему

Шардинг

Bohdan Stefaniuk — Fri, 05 Apr 2019 02:26:34 +0500

Bohdan Stefaniuk:

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

Вертикальный шардинг

Вертикальный шардинг — это выделение таблицы или группы таблиц на отдельный сервер. Например, в приложении есть такие таблицы:

users — данные пользователей
photos — фотографии пользователей
albums — альбомы пользователей

Таблицу users Вы оставляете на одном сервере, а таблицы photos и albums переносите на другой. В таком случае в приложении Вам необходимо будет использовать соответствующее соединение для работы с каждой таблицей

Горизонтальный шардинг

Горизонтальный шардинг — это разделение одной таблицы на разные сервера. Это необходимо использовать для огромных таблиц, которые не умещаются на одном сервере. Разделение таблицы на куски делается по такому принципу:

На нескольких серверах создается одна и та же таблица (только структура, без данных).
В приложении выбирается условие, по которому будет определяться нужное соединение (например, четные на один сервер, а нечетные — на другой).
Перед каждым обращением к таблице происходит выбор нужного соединения.

Совместное использование

Шардинг и репликация часто используются совместно. В нашем примере, мы могли бы использовать по два сервера на каждый шард таблицы

Key-value базы данных

Следует отметить, что большинство Key-value баз данных поддерживает шардинг на уровне платформы. Например, Memcache. В таком случае, Вы просто указываете набор серверов для соединения, а платформа сделает все остальное

Итог

Не следует применять технику шардинга ко всем таблицам. Правильный подход — это поэтапный процесс разделения растущих таблиц. Следует задумываться о горизонтальном шардинге, когда количество записей в одной таблице переходит за пределы от нескольких десятков миллионов до сотен миллионов.

P.S.

Помните, процесс масштабирования данных — это архитектурное решение, оно не связано с конкретной технологией. Не делайте ошибок наших отцов — не переезжайте с известной Вам технологии на новую из-за поддержки или не поддержки шардинга. Проблемы обычно связаны с архитектурой, а не конкретной базой данных

Ссылки

Репликация данных

Bohdan Stefaniuk — Fri, 05 Apr 2019 02:23:42 +0500

Bohdan Stefaniuk:

Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других. Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.

Существует два основных подхода при работе с репликацией данных:

Репликация Master-Slave;
Репликация Master-Master.

Master-Slave репликация

В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных. Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.

Несколько Слейвов

Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.
Тогда из приложения выбирает случайным образом один из Слейвов для обработки запросов, тем самым распределяя нагрузку на БД.

Выход из строя

При выходе из строя Слейва, достаточно просто переключить все приложение на работу с Мастером. После этого восстановить репликацию на Слейве и снова его запустить.
Если выходит из строя Мастер, нужно переключить все операции (и чтения и записи) на Слейв. Таким образом он станет новым Мастером. После восстановления старого Мастера, настроить на нем реплику, и он станет новым Слейвом.

Master-Master репликация

В этой схеме, любой из серверов может использоваться как для чтения так и для записи.

«Ручная» репликация

Некоторые технологии вообще не имеют встроенной репликации. В таких случаях, следует использовать самостоятельную реализацию репликации. В самом простом случае, приложение будет дублировать все запросы сразу на несколько серверов базы данных.

Итог

Репликация используется в большей мере для резервирования баз данных и в меньшей для масштабирования. Master-Slave репликация удобна для распределения запросов чтения по нескольким серверам. Подход ручной репликации позволит использовать преимущества репликации для технологий, которые ее не поддерживают. Зачастую репликация используется вместе с шардингом при решении вопросов масштабирования.

Следует отметить, что репликация сама по себе не очень удобный механизм масштабирования. Причиной тому — рассинхронизация данных и задержки в копировании с мастера на слейв. Зато это отличное средство для обеспечения отказоустойчивости. Вы всегда можете переключиться на слейв, если мастер ломается и наоборот. Чаще всего репликация используется совместно с шардингом именно из соображений надежности.