Паттерны проектирования - систематизация

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

О масштабируемости систем(ч.3)

Асинхронное взаимодействие

Еще один ключевой момент при потстроении хорошо масштабируемых систем - это асинхронность. Например, если компонент А обращается к компоненту Б посредством синхронного вызова, то А и Б являются тесно связанными, а значит, если нужно будет масштабировать А, то тоже самое придется делать и с Б. Точно так же дело обстоит и с доступностью - если выйдет из строя Б, то А тоже не сможет функционировать нормально. 

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

Такой подход имеет отражение в некоторых научных работах, в частности SEDA(Stage Event-Driven Architecture for highly concurrent server applications). 

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

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

Создание необходимых уровней абстракции

Не буду подробно на этом останавливаться, и так понятно, что все функциональные слои должны иметь свои уровни абстракции - то есть например, работа с БД должна производиться при помощи ORM или иного интерфейса, который возьмет на себя все функции по взаимодействию с БД, распределению нагрузки между серверами БД(в случае распределенных серверов БД, какие были описаны выше) и т.д. Абстрагирование резко упростит жизнь при последующем масштабировании системы, поскольку будет отсутствовать жесткая привязка к конкретным типам системных ресурсов, а так же можно на соответсвующем уровне абстракции организовать управление физическими ресурсами.

Правильный выбор кэшируемых данных

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

Вообще, эффективность кэширования определяется как максимальное cache hit ratio при ограничениях на объем кэшируемой информации, ее доступность и определенным уровнем толерантности к неактуальной информации.

Чаще всего кэшируются по большей части read-only или редко модифицируемые данные, такие как: метаданные, конфиги, словари и т.д. Гораздо более сложными в плане кэширования являются часто обновляемые и часто читаемые данные, поэтому следует хорошо подумать, прежде чем их кэшировать.

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

На днях наткнулся на интересную white-paper, в ней описывается, как снизить нагрузку на сервер БД при использовании Hibernate. Используется технология под названием Terracotta, достаточно известная в настоящее время.

О масштабируемости систем(ч.2)

Отказ от распределенных транзакций

В связи с двумя предыдущими пунктами сразу приходит на ум мысль - как в условии функциональной декомпозиции и горизонтального разбиения будет обеспечиваться поодержка транзакций, ведь практически любая операция влечет за собой изменение более чем одной сущности. Стандартный ответ подразумевает создание распределенной транзакции, которая включает в себя все модифицируемые ресурсы и использование two-phase commit для того, чтобы быть уверенным в том, что транзакция прошла успешно, либо же была отменена для всех вовлеченных в нее сущностей. Однако, у всего есть своя цена, и подобный подход резко ухудшает масштабируемость, производительность и увеличивает время ожидания. Также ограничивается и доступность системы - ведь при создании распределенной транзакции все вовлеченные в нее ресурсы должны быть свободны. Это может привести к тому, что при увеличении нагрузки на систему и росте ресурсов, вовлеченных в распределенные транзакции, система перестанет справляться с обслуживанием клиентов. 

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

Около 10 лет назад профессор Eric Brewer сформулировал CAP-теорему, согласно которой, среди трех требуемых характеристик распределенной системы: consistency(C), availability(A) и performance(P) одновременно можно выбрать только 2 варианта. Для 24x7 доступной веб-системы, работающей под большой пользовательской нагрузкой придетсся выбрать 2 последние, иначе система не сможет выполнять свое предназначение. Следовательно, consistency придется пожертвовать.

Однако если операция работы с данными производится в рамках одного сервера БД, то тогда вполне можно объединять несколько операций в рамках транзакции или разрешить auto-commit для определенных запросов. Конечно, подобное нарушение принципов ACID не гарантирует немедленную consistency среди всех распределенных частей системы, но взамен этого ситема будет доступна большинство рабочего времени.

Естесственно, подобное построение системы влечет за собой определенные нетривиальные технические решения, призванные обеспечить корректность работы в каждом конкретном случае и ни в коем случае не является тривиальным. Однако в распределенных системах это необходимо и consistency уже нельзя рассматривать с позиции "все-или-ничего".

О масштабируемости систем(ч.1)

Масштабируемость - одно из важнейших свойств ИС, которые работают в условиях постоянно растущей нагрузки. Например, это очень важно в web-базированных системах, поскольку нагрузка на них может расти чуть-ли не экспоненциально при росте популярности ресурса. Как пример, можно привести любую систему электронных продаж, электронные аукционы и т.д. Так что же нужно делать, чтобы система была хорошо масштабируемой? 

Система считается масштабируемой, если ее производительность растет как минимум линейно в зависимости от увеличения производительности аппаратной части (увеличили количество серверов вдвое - производительность как минимум вдвое выросла). Чтобы добиться таких показателей, необходимо закладывать определенные архитектурные решения в проект с самого начала. Неправильно спроектированную систему в будущем будет крайне трудно, а то и просто невозможно масштабировать. Рассмотрим основные best-practices, которые мне известны на текущий момент.

Разделение фунциональности

В соответствии с этим необходимо строить систему исходя из того, что отдельные независимые функции системы должны быть автономны друг от друга  и не иметь между собой связей. Подобный принцип реализуется, например, в SOA, и еще именуется принципом функциональной декомпозиции. Это позволит разместить соответствующие части системы на автономные друг от друга группы серверов(например, поиск будет на одном сервере, обслуживание заказов - на другом и т.д.) и регулировать их мощность так же можно будет независимо в зависимости от нагрузки на тот или иной сегмент. Так же это позволит оптимизировать зависимость системы от внешних ресурсов - каждый пул серверов будет иметь доступ только к необходимым для работы ресурсам.

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

Горизонтальное разбиение функциональности

Функциональная декомпозиция позволяет достичь определенного прогресса в масштабируемости, однако это далеко не все. Мы должны также иметь возможность разделять общую входящую нагрузку на функциональный блок системы и иметь возможность сбалансированно ее распределять между серверами пула. Для этого можно использовать стандартный load-balancer на уровне серверов приложений, который распределит нагрузку более-менее равномерно. Подразумевается, что каждый экземпляр сервера приложений содержит идентичную и автономную от других функциональность, так что можно просто увеличивать их количество в случае возросшей нагрузки. На уровне БД все обстоит несколько сложнее. Тут необходимо организовывать данные как т.н. "осколки" (shards). Это значит, что например, данные по пользователям равномерно распределены между N серверами БД, аждый из которых хранит свою часть. При этом есть механизм, который автоматически определяет, к какому серверу необходимо обратиться, чтобы получить нужные данные. Естесственно для сервреров приложений это должно быть совершенно прозрачно и они должны быть абстрагированы от деталей реализации. Есть специальные стратегии построения БД для такой конфигурации серверов, как правило, особым образом формируется первичный ключ таблицы, который идентифицирует, на каком сервере будет храниться запись. Хотя наверняка есть и другие варианты, я пока этим вопросом глубоко не занимался.