Ожидается, что порталы B2C в первую очередь будут масштабироваться.
К сожалению, масштабирование слишком часто декларируют вопросом технологии — достаточно выбрать модную технологию и все проблемы решены.
То, что это не так, может проявиться в последнее время уже в производственном режиме (на работающей системе).
Вместо того, чтобы размахивать технологической булавой, я расскажу о том, как разработать высокодоступный масштабируемый портал, используя продуманную архитектуру и осознанный отказ от модели данных.
В первой части будут описаны общие концепции, а затем будут рассмотрены возможные сценарии и их решения.
Первая часть.
Теория.
Когда-то, в темные дни зарождения Интернета, то есть где-то в конце прошлого — начале этого тысячелетия, вопрос выбора правильной архитектуры часто сводился к выбору правильной базы данных.
Когда директор какого-то стартапа поставил перед разработчиками задачу построить новый портал, команда в основном обсуждала, нужно ли покупать Oracle Enterprise Edition , либо можно обойтись стандартной лицензией.
Передовые товарищи экспериментировали Поэт , Версант или другие объектно-ориентированные базы данных.
После этого создавались модели данных, которые в большинстве случаев были моделями баз данных, и все это до того, как задавался вопрос: что именно система должна делать и как? Сегодня, спустя 10 лет и кучу интересных программных разработок, все происходит очень похоже, только вместо того, чтобы выбрать Oracle или Informix, они спорят о том, брать ли Монго , Хадуп или ЭластичныйПоиск .
Без сомнения, это хорошие и очень полезные технологии.
Однако выбор технологии не должен предшествовать выбор архитектуры! Другими словами: технология, какой бы продвинутой она ни была, должна служить архитектуре, выполняя в ее рамках определенные задачи.
Эти задачи должны определяться архитектурой и требованиями к системе.
Подход Технология прежде всего , который часто можно встретить в окопах разработки ПО, очень привлекателен для неподкованного в техническом плане руководства: «Если стартап X использует Mongo, Bootstrap, ElasticSearch и/или Ruby, то этот коктейль мне поможет, а если нет, то мне всегда будет плевать на инвесторов: мол, он использовал все самые модные технологии и это значит не виновен ! К сожалению (для судьбы стартапа и к счастью для всех остальных), такой подход редко приводит к правильное решение конкретной проблемы .
Я сторонник противоположного подхода: Архитектура прежде всего .
Это значит, что проблема решается прежде всего архитектурно, а технология — лишь способ реализации архитектуры.
Соответственно, технология – это всего лишь часть решения и только когда она принесет конкретная выгода в контексте этого решения.
Вот пример.
Многие годы люди пытались решить все проблемы построения порталов с помощью реляционных СУБД, и многие годы все попытки масштабировать эти порталы заканчивались прахом, как только Схема (Схема базы данных) становилась довольно сложной.
В результате этой катастрофы появилось поколение преемников СУРБД — NoSQL СУБД (являются ли NoSQL базы данных чем-то принципиально новым или просто реанимацией старых идей, в данном контексте не важно).
Интересно другое: успех NoSQL СУБД основан на том, что признали главную проблему СУБД SQL, а именно: Присоединяется , и они просто не поддерживаются.
Но если построить архитектуру так, чтобы обойтись без Джойнов, то есть сознательно отказаться от них , то старые добрые базы данных SQL без проблем масштабируются.
Архитектура – что это?
Прежде чем мы поговорим о том, как найти правильную архитектуру, которая будет поддерживать стандартные требования, такие как гибкость (гибкость), масштабируемость (масштабируемость) и управляемость (управляемость), нужно решить: что же такое архитектура? Здесь мнения расходятся.Некоторые рассматривают архитектуру как очень абстрактный тип описания системных требований, своего рода анализ требований; другие похожи на распределение классов по пакетам.
Большой выбор различных определений понятия «архитектура программного обеспечения» можно найти на сайте эта страница .
Я считаю наиболее удачными следующие:
Архитектура (программного обеспечения) — это структура системы, состоящая из компонентов, видимых свойств этих компонентов и отношений между ними.Другими словами, архитектура имеет дело с компонентами системы и связью между ними.
Это определение основано на концепции компонент , но что такое компонент? Компоненты — это составляющие нашей архитектурной мысли, которые мы определяем по различным критериям: в частности, по ответственности за какой-либо бизнес-процесс или данные.
Отдельный компонент — это совокупность сущностей (например, классов/объектов), выполняющих общую задачу.
Например, MessagingService — это компонент, отвечающий за отправку сообщений и состоящий из нескольких классов (включая сам интерфейс MessagingService).
Размер компонента должен быть как можно меньшим, но достаточным для решения задачи (для Messaging — отправка и получение сообщений).
Возвращаясь к порталам B2C, отметим их общие с архитектурной точки зрения свойства:
- высокое соотношение между операциями чтения и записи: число читающих может быть в 9-10 раз больше, чем пишущих;
- четко различимый функционал – например, внутренние сообщения (обмен сообщениями) или профиль;
- трафик портала подвержен пикам, создающим множество нормальных нагрузок в зависимости от времени суток, недели или года;
- порталы постоянно и быстро меняются.
Это относится к коду, контенту и данным.
Общие архитектурные принципы
Одной из самых популярных архитектур для создания таких порталов является сервис-ориентированная архитектура (SOA).В недавнем прошлом ее репутация пострадала от популярности Веб-сервисы , архитектура, имеющая мало общего с SOA, но которую часто с ней путают. SOA, будучи гораздо более старой и зрелой архитектурой, чем WebServices, при правильном использовании предлагает решение многих проблем масштабирования.
С архитектурной точки зрения компоненты SOA — это сервисы и клиенты, и каждый компонент может быть и тем, и другим одновременно.
Внешне видимые свойства компонента — это интерфейсы, которые он предоставляет. Что касается связей между компонентами, то они бывают двух типов:
- Прямое или синхронное общение — это вызов методов, то есть клиент, вызывающий службу.
- Косвенная или асинхронная связь — это уведомление об изменении состояния (событии), которое компонент публикует «втайне от всего мира», не заботясь о том, есть ли у него конкретные слушатели.
Изоляция до ядра (вплоть до базы данных)
Один из основных и наиболее полезных принципов SOA: изоляция компонентов друг от друга.Помимо прочего, это означает, что каждый компонент является абсолютным хозяином своих данных.
Никто не имеет права менять их, как минимум не проинформировав владельца, а еще лучше не попросив его внести изменение самостоятельно.
Сервис-ориентированная архитектура знает множество gitов, но ее главным преимуществом является отсутствие глобальная модель данных .
Интерфейсы каждого конкретного компонента — это все, что о нем известно «извне».
Его внутренняя жизнь остается делом сугубо личным, никому не известным.
У этого принципа есть не только сторонники — ведь так удобно проводить сложное расследование с помощью одного (трехэтажного) SQL-запроса! Да, это правда, связь данных из разных сервисов на уровне СУБД могла бы принести некоторую пользу при расследованиях, статистическом анализе и интеллектуальном анализе данных( сбор данных , глубокий или интеллектуальный анализ данных).
Но где сказано, что эти связи должны существовать в рабочей среде? Если кому-то нужны данные для анализа, никто не мешает ему регулярно переносить их из рабочей системы в аналитическую, и при этом создавать столько связей, сколько захочется, а также переворачивать данные боком, вверх тормашками или как угодно.
тебе нравится.
Но сама работающая система не должна быть загрязнена этими «побочными продуктами» — балластом, превращающим шуструю, быструю Феррари в тяжелый и неповоротливый Пассат. Добровольный отказ от глобальной модели данных с точки зрения архитектуры системы означает следующее:
- Модель данных заменяется моделью обслуживания.
Это можно было бы назвать Предприятие -модель, если бы это слово не использовалось налево и направо, зачем оно было бы нужно.
Модель сервиса состоит из сервисов в системе, артефактов, которыми они управляют, и отношений между этими артефактами.
- Каждая служба и каждый компонент совершенно свободны в выборе своего постоянства.
Служба, которая управляет хорошо структурированными данными, может записать их в базу данных SQL; служба BLOB-объектов ( капли ), будь то изображения или большие тексты, можно использовать более подходящие методы сохранения.
- Нагрузка на сервисы варьируется внутри системы.
В 2-уровневой (двухуровневой) системе, ориентированной на базу данных, увеличение нагрузки всегда приходится на всю систему.
В SOA легко идентифицировать сервис, нагрузка которого возросла, что дает возможность бороться с ним именно в этом месте, путем оптимизации или масштабирования.
Большие, чудовищные сервисы часто становятся приложением внутри приложения и сами подвергаются тем самым проблемам, которые мы намеревались преодолеть.
Слишком мелко нарезанные сервисы приводят к переизбытку коммуникаций, что убивает всякое масштабирование на корню.
Как найти правильный размер услуги? Самый простой способ сделать это — придерживаться следующих двух парадигм разработки программного обеспечения: Дизайн по ответственности И Изоляция слоев .
Используя последнее, можно определить принципиальные границы ответственности сервиса — что является сервисом (например, бизнес-логика), а что нет (например, логика представления).
Дизайн по ответственности помогает разделить сервисы по вертикали, разделив их по предметной или функциональной специализации (обмен сообщениями, поиск и т. д.).
Схема 1: Правильная нарезка услуг
После правильного определения сервисов нужно подумать о том, как они должны «коммуницировать» друг с другом.
Диаграмма 2: Разрешенные (зеленый) и запрещенные (красный) пути связи.
Как избежать глобальной модели данных?
Общепринятая модель расслоения – вертикальная.Вверху находится уровень представления, внизу — уровень персистентности.
Поэтому разработчики обычно начинают с постоянства и создают глобальную модель данных.
На самом деле в SOA начинать нужно с середина : 
Диаграмма 3: Зависимости между слоями
Таким образом, мы можем создать настоящую модель обслуживания, в которой каждый конкретный ресурс удовлетворяет потребности своего сервиса и только этого сервиса.
Это приводит к строгой изоляции, необходимой для масштабирования: 
Схема 4: Постоянная изоляция
Еще одна парадигма, которой абсолютно необходимо следовать, — это KISS (Keep it Simple, Stupid).
С точки зрения архитектуры программного обеспечения KISS означает, что частью нашей архитектуры должны быть только абсолютно необходимые компоненты.
Все, что не приносит немедленной выгоды, включая модные технологии, должно быть исключено.
Другими словами, только те технологии, которые оправдывают стоимость их поддержки, заслуживают включения в окончательное решение.
У хорошей архитектуры много винтиков.
Но, наконец, настал тот час, когда сервисы спроектированы и написаны, и пора с головой бросаться в амбразуру — то есть под реальную нагрузку реальных пользователей.
Перед запуском мы часто не знаем, какую нагрузку выдержит тот или иной компонент. Конечно, хорошо иметь реалистичный нагрузочный тест. Проблема в том, что для написания хорошего теста нам нужно знать реальное поведение пользователя, а чтобы узнать реальное поведение пользователя, нам нужно.
запустить его.
Впрочем, делать настройку после запуска в рабочем режиме совсем не страшно, ведь все мы хорошо помним, что такое преждевременная оптимизация.
Важно следить (Привет МоСкито !) каждого компонента, чтобы вовремя распознать узкие места и отреагировать до полная перегрузка этого компонента.
Зная о таком узком месте, у нас есть разные варианты реагирования.
Мы поговорим о двух из них, Кэшах и Маршрутизации, в следующие части .
Теги: #архитектура #nosql против sql #soa #архитектура #масштабируемость #масштабируемость #программирование #java #Системный анализ и проектирование
-
Самое Простое Руководство По Иконографии
19 Oct, 24
