Б Бёрнс - Распределенные системы. Паттерны проектирования

‰ ‰ 99-й процентиль производительности системы в Scatter/ Gather-системах имеет существенно большее значение, не-жели в других классах систем, так как один пользователь-ский запрос превращается во множество запросов к сервису. «Эффект отстающего» влияет и на доступность системы. Если запрос распределяется на 100 терминальных узлов, а вероят-ность отказа любого из узлов равна 1 %, то почти наверняка ни один из запросов пользователей не будет успешно обра-

ботан.

132Часть II. Паттерны проектирования обслуживающих систем Масштабирование

Scatter/Gather-систем с учетом надежности и производительности Как и в случае с другими шардированными системами, наличие единственной копии шардированной Scatter/Gather-системы — не лучшее архитектурное решение. Если в единственном экзем-пляре шарда происходит отказ, все Scatter/Gather-запросы будут отклоняться на время его недоступности, поскольку в рамках паттерна Scatter/Gather все запросы должны обрабатываться всеми терминальными узлами. Модернизация системы также сделает часть узлов временно недоступными, а значит, обновить систему при наличии запросов от пользователей тоже не полу-чится. Наконец, вычислительная мощность системы в целом будет ограничена вычислительными возможностями каждого отдельного узла.

В конечном итоге все указанные факторы ограничивают мас-штабируемость вашей системы. Как уже было рассмотрено в предыдущих разделах, нельзя просто увеличить количество шардов, чтобы повысить вычислительную мощность системы, построенной на основе паттерна Scatter/Gather. С учетом проблем с надежностью и масштабируемостью кор-ректным будет реплицировать каждый отдельный шард. Таким образом, терминальные узлы будут реализованы не в виде от-дельных шардов, а в виде реплицированных сервисов. Схема реплицированного шардированного паттерна Scatter/Gather изображена на рис. 7.4.

Нагрузка на терминальный узел системы равномерно распре-деляется между исправными репликами шарда. Это значит, что отказ реплик шарда не приведет к видимому отказу сер-виса. Кроме того, в каждом реплицированном шарде можно Глава 7. Паттерн Scatter/Gather 133

Рис. 7.4. Scatter/Gather-система с шардированием и репликациейобновлять по одной реплике за раз, а значит, систему можно обновлять и под нагрузкой. В зависимости от того, насколько быстро нужно выполнять обновление, можно даже параллельно обновлять несколько реплик, находящихся в разных шардах. 8 Функции и событийно-ориентированная

обработка

До настоящего момента мы рассматривали проектирование длительно работающих систем. Серверы, обрабатывающие пользовательские запросы, работают постоянно. Такой подход годится для высоконагруженных приложений, требующих большого объема памяти или фоновой обработки данных. Есть класс приложений, которые запускаются нена-долго — для обработки одного запроса или для того, чтобы отреагировать на конкретное событие. Такой запросно- или событийно-ориентированный подход к проектированию при-ложений начал в последнее время получать распространение по мере того, как крупные провайдеры стали предлагать продукты типа «функция как сервис» (function-as-a-service, FaaS). С не-давних пор реализации FaaS начали работать на оркестраторах кластеров в частных облачных и физических средах. В этой Глава 8. Функции и событийно-ориентированная обработка 135главе описываются новые архитектуры, возникающие в рамках данного подхода. В большинстве случаев FaaS представляет собой компонент более крупной архитектуры, а не самостоя-тельное решение.

бессерверные вычисления применимы к широкому спектру сервисов. К примеру, многопользовательские оркестраторы контейнеров («контейнер как сервис») являются бессер-верными, но не являются событийно-ориентированными. И наоборот, FaaS-сервис с открытым исходным кодом, работающий на кластере физических компьютеров, при-надлежащих вам и управляемых вами, является событийно-ориентированным, но не является бессерверным. Понима-ние этого различия позволяет вам определить, подходит ли для вашего приложения событийно-ориентированная

Как определить, когда полезен подход FaaS

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