The Reactive Manifesto / Реактивный Манифест: Scalable

Масштабируемость

2heoh 26.07.13 в 15:46

Почему это важно

2heoh 26.07.13 в 15:46

Слово масштабируемый как оно определено Мериэм-Вебстер означает "что-то способное быть легко расширеным или улучшеным по запросу". Масштабируемое приложение способно быть расширено в зависимости от его использования. Это может быть достигнуто добавлением гибкости в приложение, по выбору оно может быть увеличено или уменьшено (установка на узел с большим или меньшим количеством процессоров) без изменения дизайна или переписывания приложения. Гибкость делает возможным уменьшение стоимости управления приложением в облачном окружении, позволяя Вам получать выгоду из его виртуальной модели плати-за-то-ты-используешь.

2heoh 26.07.13 в 15:55

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

2heoh 26.07.13 в 15:56

Ключевые блоки

2heoh 26.07.13 в 15:46

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

2heoh 29.07.13 в 12:29

Важно понимать что целью является не попытка использовать прозрачные распределенные вычисления, распределенные объекты или RPC-стиль коммуникации - это было испробовано ранее и оказалось неудачным. Вместо этого нам надо объять сеть включая этот подход прямо в программную модель через асинхронную передачу сообщений. Настоящая масштабируемось гармонично внедряется в распределенное вычисление и с этим внутриузловой коммуникацией, которая означает _traversing the network_, что как мы знает довольно ненадежно. Тем не менее важно создать ограничения, отказы обслуживания и сценарии обработки ошибок сетевого программирования явно в программной модели, вместо того чтобы прятать их в утекающие абстракции которые пытаются все "упростить". Как решение, одинаково важно создавать программные утилиты которые скрывают основные кирпичики для решения типичных задач возникающие в распределенном окружении, как механизмы для достижения результата или абстракции обмена сообщений которые предлагают более высокую степень надежности.

2heoh 29.07.13 в 12:30