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

Следите за разработчиками Tencent Cloud и заранее получайте техническую информацию из первых рук👇

01. Преимущества многослойности

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

Впервые я столкнулся с идеей многоуровневой архитектуры во время моей регулярной защиты через месяц после того, как присоединился к компании. На рисунке ниже представлен архитектурный проект системы доступа wns пространства QQ на заре. В то время судьи оспорили идею дизайна структуры.

Как видно из названий, акк (доступ, управление длинными ссылками), диспетчеризация (маршрутизация), веб-приложение (логический свр, соответствующий понятию bizao в ddd). Возникает вопрос: зачем нужен уровень диспетчеризации? Невозможно перенаправить аккаунт непосредственно в веб-приложение? Ответ на тот момент заключался в том, что планирование аварийного восстановления необходимо через маршрутизацию. Если веб-приложение в Шанхае в фоновом режиме зависает, конфигурация может быть выдана при отправке, и трафик будет перенаправлен в Шэньчжэнь. (На самом деле планирование аварийного восстановления между IDC таким образом не используется. Теоретически каждый уровень может быть катастрофоустойчивым, и Acc также может планировать трафик в Шэньчжэнь. Фактически, во время фактической тренировки аварийной устойчивости клиент перенаправлено напрямую. Ведь если один IDC не работает, то велика вероятность, что все уровни не работают).

Это отражает одно из преимуществ многоуровневого подхода: экранирование сложности и изменений. Другие преимущества многоуровневого распределения каналов суммированы ниже.

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

Сплоченность:Эти сложныеиспользовать Почему логика инкапсулирована в dispatch Отдельный слой, не кладите acc Вместе, потому что функции связаны (это также можно назвать разделением забот, разделением изменений, разделением лёгкого и тяжелого, разделением скорости и медлительности). соотв. Управляет только длинными ссылками и запросами upstream,downstream отправлено, принято multi reactor Модель является стабильным модулем и не вызовет длительных перебоев связи из-за частых перезапусков. dispatch Можно использовать традиционные spp Framework часто вызывает перезапуск конфигурации маршрутизации служб.

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

Экспоненциальное масштабирование — еще один сценарий. Классическая таблица страниц памяти, таблица страниц первого уровня, таблица страниц второго уровня, посредством многоуровневого разделения, хранения m+n, для достижения адресации m*n, аналогичные идеи - это roaingbitmap. Расширение емкости системы, обычно такое как распространение мгновенных сообщений, распространение многоуровневого чтения, распространение записи, расширение емкости системы m*n.

Вот краткое введение в другую иерархическую диффузию чтения и записи, с которой я столкнулся. Например, имеется 1 к Вт пользователей и 1 к Вт книг. Теперь нам нужно указать некоторые ограниченные исключения для некоторых пользователей. В среднем у каждого человека есть 100 000 книг с ограниченным освобождением, и на каждую книгу предоставляются ограниченные исключения 100 000 человек. Если сохраняется односторонняя связь и в памяти хранится идентификатор пользователя-[список идентификаторов книг] или идентификатор книги-[список идентификаторов пользователей], время распространения записи и хранения будет составлять 1 к Вт*10 Вт. Позже будет добавлен дополнительный уровень номера. Пакеты будут разработаны в конструкции хранилища. Это будет идентификатор пользователя памяти - [список номеров пакетов] + идентификатор книги памяти - [список номеров пакетов] + идентификатор пакета с номером автономного хранилища - [идентификатор книги + идентификатор пользователя]. Логика чтения изменяется на одновременное чтение двух связей сопоставления и последующее использование пересечения для определения того, освобождено ли ограничение. Уменьшает распространение онлайн-записи и использование хранилища.

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

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

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

02. Недостатки многослойности

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

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

Производительность/потребление памяти:В сценариях с большим объемом запросов,Добавление еще одного уровня только для реализации логики пересылки также потребует много машин.,В некоторых сценариях с высоким параллелизмом,Нет необходимости наслаивать дизайн,Точно так же, как корпоративный красный конверт WeChat 2015 года.,Уровень доступа обеспечивает логический возврат.

Добавление/перенос зависимостей:Добавить сторонний компонент,Вне зависимости от наличия мест 5 из 9.,Это все внешняя зависимость,Есть риски,И по мере увеличения наслоения,Снижение надежности системы,99,99*99,99=99,98 может изменить вероятность с четырех девяток на три девятки. Вот также некоторые идеи для работы со слоями.,Несмотря на то, что логическое расслоение все еще существует,Уровни каталогов кода все еще могут существовать,Просто та же машина развертывания отдает приоритет локальной маршрутизации,Или скомпилируйте его в единый сервис.

03. Принцип наслоения

Обозначив преимущества и недостатки многослойности, давайте поговорим о принципах многослойности. Если взвесить все преимущества и недостатки, то это ерунда~

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

Здесь мы приводим пример проектирования хранилища данных. Стандартный принцип многоуровневого проектирования хранилища данных следующий: В хранилище данных входят dwd (очищение данных из таблиц потоков, в основном фильтрация недопустимых данных, преобразование формата и т. д.), dwm ( Легкая агрегация многомерных групп по), dm (ориентирована на тематический слой, включая показатели и измерения), app (статистические данные высокого уровня, которые можно экспортировать в отчеты).

Тут будет несколько вопросов. Зачем нужен дим слой? А без дима нельзя? Использование dm для всего также может удовлетворить потребности, поскольку данные в dm полны; необходим ли dwd, если эти текущие данные используются только для подсчета индикатора, кажется разумным, что уровень приложения может проникать в уровень ods? Фактические требования к отчетам уровня приложения впечатляют, и часто приходится рассчитывать данные индикаторов по нескольким различным темам. Как бороться с межтематическим вызовами между одним и тем же уровнем.

Если обобщить общие проблемы многоуровневого слоя, то это то, нужен ли этот уровень, не кажется ли он повторно используемым и кажется ли он слишком продуманным; можно ли его вызывать на нескольких уровнях; разрешено ли ему вызывать один и тот же уровень; Давай поговорим о нашем окончательном плане, dwd и dim Все должно быть сохранено. Помимо преимуществ многоуровневого представления, существует также требование последовательности. Позволяет осуществлять вызовы на нескольких уровнях dwd：app приезжать dwd, dm приезжать dwd 。Не делайте слишком много слоев дизайна для будущих нужд, которых вы еще не увидите, иначе при повторном прохождении исторических миссий произойдет катастрофа.Разрешить настройку того же слояиспользовать,Но приоритетом является корректировка нижних слоев. Потому что чем ниже слой, тем он стабильнее.,Зависимости на одном уровне могут легко образовывать цикл зависимостей.,Или самостоятельность. Окончательный практический вариант выглядит следующим образом:

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

такой же DDD Стандартное распределение микросервисов показано выше. Микросервисы имеют основную концепцию, называемую областью независимости и автономии. Уровень домена должен как можно меньше полагаться на вещи вне домена, чтобы быть достаточно стабильным и соответствовать требованиям более стабильных зависимостей на нижнем уровне. Однако такой дизайн легко следовать образцу модели анемии. являются DDD концепции, но нет DDD Фактическая работа использования. В модельной практике гиперемии,Уровень домена может обеспечивать шлюзование внешних интерфейсов.,Может быть доставлен через асинхронные сообщения.,Слой внутри других областей должен быть отрегулирован. Уровень приложений не имеет бизнес-логики.,Уровень должен отвечать за объединение примера системаиспользовать.,Просто тонкий слой. Большая часть логики переходит на уровень домена приезжать.,А сколько слоев и модулей содержится в доменном слое?,Это зависит от того, можно ли это повторить в соответствии с реальной деловой ситуацией.,Необходимо ли единое суждение,Не будьте жесткими и не придерживайтесь одного модуля на слой.

04. Резюме

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

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

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

-End-

Автор оригинала｜Чжэн Хайбо