Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Масштабировать легко

Anna | 3.06.2014 | нет комментариев
От B2C-порталов ожидается раньше каждого масштабирование. К сожалению, масштабирование слишком Зачастую объявляется вопросом Спецтехнологии — довольно предпочесть модную спецтехнологию и все задачи решены. То, что это не так, может проявиться, позже каждого, теснее в production mode (на рабочей системе).
Взамен того, Дабы махать технологической булавой, расскажу о том, как при помощи продуманной архитектуры и сознательного отказа от модели данных разработать высоко доступный (highly available), масштабируемый (scalable) портал. Первая часть опишет всеобщие концепты, а допустимые сценарии и их решения последуют.

Часть первая. Теория.

Давным-давным-давно, в темные времена начала интернета, то есть где-то в конце прошлого — начале этого тысячелетия, вопрос выбора положительной архитектуры Зачастую сводился к выбору верной базы данных. Когда директор какого-нибудь стартапчика ставил перед разработчиками задачу возвести новейший портал, команда в основном дискутировала о том, нужно ли приобретать Oracle Enterprise Edition, либо дозволено обойтись стандартной лицензией. Продвинутые товарищи экспериментировали с РоеtVersant либо другими объектно-ориентированными базами данных. Позже этого создавались модели данных, которые в большинстве случаев были моделями баз данных, и всё это еще до того, как задаться вопросом: а что, собственно, система должна делать, и как?

Сегодня, 10 лет и кучу увлекательных разработок в области ПО через, всё происходит дюже схоже, разве что взамен выбора Oracle либо Informix спорят о том, брать ли MongoHadoop либо ElasticSearch. Без сомнения, это отличные и дюже пригодные спецтехнологии. Впрочем выбор спецтехнологии не должен предшествоватьвыбору архитектуры! Другими словами: спецтехнология, какой бы продвинутой она не была, должна служить архитектуре, исполняя определённые задачи в ее рамках. Эти задачи обязаны определятся архитектурой и требованиями к системе.

Подход Technology First, тот, что дозволено Зачастую встретить в окопах разработки ПО, дюже симпатичен для начальства, нехорошо подкованного технически: «Если стартап Х использует Mongo, Bootstrap, ElasticSearch и/или Ruby, то и мне данный коктейль поможет, а если нет, то я неизменно отмажусь перед инвесторами: мол, применял все самые модные спецтехнологии и значит — не повинен!» К сожалению (для судьбы стартапа и к счастью для всех остальных), такой подход редко приводит к верному решению определенной задачи.
Я же ратую за противоположный подход: Architecture First. Это обозначает, что задача решается в первую очередь архитектурно, а спецтехнология является лишь методом реализации архитектуры. Соответственно, спецтехнология — только часть решения и только тогда, когда она приносит определенную пользу в контексте данного решения.

Вот пример.

Длинные годы люди пытались решить все задачи порталостроения при помощи реляционных СУБД, и длинные же годы все попытки масштабирования этих порталов венчались прахом, как только Schema (Схема БД) становилась довольно трудной. В итоге этой беды и возникло поколение преемников РСУБД — NoSQL СУБД (являются ли базы NoSQL чем-то твердо новым либо лишь реанимацией ветхих идей, в данном контексте не суть значимо). Увлекательно другое: триумф NoSQL СУБД основан на том, что они распознали основную задачу SQL СУБД, — а именно Joins, и просто их не поддерживают. Но если возвести архитектуру так, Дабы обойтись без Joins, то есть осмысленно от них отказаться, то и ветхие добродушные базы SQL масштабируются без специальных задач.

Зодчество — что это?

Раньше чем говорить о том, как обнаружить верную архитектуру, которая будет поддерживать такие типовые требования как flexibility (эластичность), scalability (масштабируемость) и manageability (управляемость), необходимо определиться: а что, собственно, является архитектурой? Здесь суждения расходятся. Одни рассматривают архитектуру как дюже отвлеченный вид изложений требований к системе, этакий requirement analysis; другие — как разделение классов по пакетам (packages). Огромный выбор разновидных определений представления «зодчество программного обеспечения» дозволено обнаружить на этой странице.
Я считаю особенно благополучным следующее:

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

Иными словами, зодчество занимается компонентами системы и коммуникацией между ними. Это определение базируется на представлении компонент, а что же такое компонент?
Компоненты — это составляющие нашей архитектурной мысли, которые мы определяем по разным знакам: в частности, я — по ответственности за какой-либо бизнес процесс либо данные.
Обособленный компонент — общность сущностей (скажем классов/объектов), исполняющих всеобщую задачу. Скажем, MessagingService — компонент, отвечающий за отправку сообщений и состоящий из нескольких классов (в том числе и самого MessagingService interface).
Размер компонента должен быть максимально маленьким, но довольным, Дабы решить задачу (для Messaging — отправка и прием сообщений).

Возвращаясь к B2C порталам, подметим их всеобщие, с точки зрения архитектуры, свойства:

  • высокий показатель соотношения между читающими и пишущими операциями: число читающих может быть в 9-10 раз выше, чем пишущих;
  • Отчетливо отличаемые функционалы — скажем, внутренние сообщения (messaging) либо профиль;
  • посещаемость порталов подвержена пикам, которые создают множественное число от типичной загрузки в зависимости от времени дня, недели либо года;
  • порталы непрерывно и стремительно меняются. Это касается и кода, и контента, и данных.
Всеобщие архитектурные тезисы

Одна из самых знаменитых архитектур для построения таких порталов — сервисно-ориентированная (SOA). В недалеком прошлом её реноме пострадало от популярности WebServices, архитектуры, с SOA имеющей немного всеобщего, но которую Зачастую с ней путают. SOA, будучи архитектурой значительно старшей и больше зрелой, чем WebServices, при положительном применении предлагает решение многих задач масштабирования.

С архитектурной точки зрения, компоненты в SOA — это сервисы и заказчики, причем всякий компонент может быть тем и иным единовременно. Наружно видимые свойства компонента — это интерфейсы, которые он публикует. Что касается отношений между компонентами, то их два вида:

  • Прямая либо синхронная коммуникация — вызов способов, то есть обращение заказчика к сервису.
  • Косвенная, либо асинхронная коммуникация — оповещение об изменении состояния (event), которое компонент публикует «по секрету каждому свету», не заботясь о том, есть ли у него определенные слушатели.

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

Изоляция до мозга костей (до базы данных)

Один из основных и особенно пригодных тезисов SOA: изоляция компонентов друг от друга. Помимо прочего, это обозначает, что всякий компонент является безусловным владельцем своих данных. Никто не имеет права их изменять, не поставив, как минимум, владельца в популярность, а отменнее — попросив его сделать модификацию самому.
Сервисно-ориентированная зодчество может много гитик, но основное её преобладание — в отсутствиивсеобщей модели данных. Интерфейсы всякого определенного компонента — это всё, что о нём вестимо «снаружи». Внутренняя же его жизнь остаётся делом сугубо личным, никому не ведомым. У этого правила есть не только последователи — чай провести трудное расследование при помощи одного (трехэтажного) SQL запроса так комфортно! Да, это правда, связь между данными различных сервисов на ярусе СУБД могла бы принести определенную пользу при расследовании, статистическом обзоре и дата майнинге (data mining, глубинном, либо умственном обзоре данных). Но где сказано, что эти связи обязаны существовать в рабочей среде? Если кому-то необходимы данные для обзора, никто не мешает регулярно переносить их из рабочей системы в аналитическую, и при этом создавать сколько желательно и какие желательно связи, а также переворачивать данные боком, вверх головой либо как еще понравится. Но сама рабочая система не должна быть загрязнена этими «субпродуктами» — балластом, делающим из шустрого, стремительного «Феррари» грузный и неповоротливый «Пассат».

Добровольный отказ от всеобщей модели данных с точки зрения архитектуры системы обозначает следующее:

  • Место модели данных занимает модель сервисов. Её дозволено было бы назвать Enterprise-моделью, если бы это слово не применялось направо и налево, для чего придётся. Сервисная модель состоит из сервисов в системе, артефактов, которыми они руководят, и связей между этими артефактами.
  • Всякий сервис и всякий компонент абсолютно свободны в выборе их персистентности. Сервис, тот, что управляет отлично структурированными данными, может записывать их в базу данных SQL; сервис, занимающийся блобами (blobs), будь то картинки либо крупные тексты, может применять больше подходящие способы персистентности.
  • Нагрузка на сервисы варьируется в пределах системы. В 2-tier (двухуровневой) системе, ориентированной на базы данных, рост нагрузки неизменно ложится на всю систему целиком. В SOA же легко идентифицировать сервис, нагрузка на тот, что подросла, что даёт вероятность бороться с ней именно в этом месте, путем оптимизации либо масштабирования.

Дабы в полноте насладиться превосходствами SOA, сервисы обязаны быть грамотно «нарезаны». Крупные, монстроподобные сервисы Зачастую превращаются в «приложениe в приложении», и сами подвержены тем задачам, которые мы собирались побороть. Слишком мелконарезанные сервисы приводят к переизбытку (overhead) коммуникации, которая убивает всё масштабирование в корне. Как же обнаружить верный размер обслуживания?

Проще каждого это сделать, придерживаясь 2-х следующих парадигм разработки ПО: Design by Responsibility иLayer Isolation. С поддержкой последнего дозволено определить основополагающие границы ответственности сервисов — что является сервисом (как business logic), а что нет (скажем, презентационная логика). Design by Responsibility помогает нарезать сервисы по вертикали, разбивая их по предметной либо функциональной специализации (messaging, search и т.д.).

Правильная нарезка сервисов
Схема 1: Верная нарезка сервисов

Позже правильной идентификации сервисов необходимо подумать о том, как они обязаны между собой «общаться».

Разрешенные (зеленые) и запрещенные (красные) пути коммуникации
Схема 2: Разрешенные (зеленые) и запрещенные (красные) пути коммуникации

Как избежать всеобщей модели данных?

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

Зависимости между слоями
Схема 3: Зависимости между слоями

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

Изоляция персистентностей
Схема 4: Изоляция персистентностей

Иная парадигма, следование которой безусловно необходимо — это KISS (Keep it Simple, Stupid). Касательно архитектуры ПО, KISS обозначает, что лишь безусловно нужные компоненты обязаны быть частью нашей архитектуры. Всё, что не приносит непосредственной пользы, и к этому могут относиться модные спецтехнологии, должно быть исключено. Другими словами, лишь те спецтехнологии, которые оправдывают расходы на свою поддержку, заслуживают право входить в финальное решение.

В отличной архитектуре много винтиков

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

Тем не менее, вовсе не жутко заниматься тюнингом теснее позже запуска в рабочем режиме, чай все мы отлично помним, что такое несвоевременная оптимизация (premature optimization). Значимо мониторить (Здравствуй MoSKito!) всякий компонент, Дабы своевременно распознавать «тесные места» и реагировать дополной перегрузки этого компонента. Зная такое «тесное место», у нас есть различные вероятности реагирования. О 2-х из них, Кэшах и Маршрутизации, мы побеседуем в следующих частях.

Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB