Проблема системы проектирования и архитектуры системы, ответа очень широкое, базовые все технические теории могут быть покрыты. Будучи бэкэндом в течение 10 лет, это просто опубликовано мое мнение.

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

Исходная информация Ключ к проектированию традиционной бизнес-системы — модель предметной области

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

Дизайн модели может ссылаться на классическую книгу «Domain-Driven Design» по моделям предметной области. Благодаря этому вы можете получить более четкое представление о таких понятиях, как определение предметной области, антикоррозийный слой и модель анемии.

Система модельной модели домена в одном приложении также необходимо обратить внимание на налоговую установку домена. Вы видели и поощрили многие контроллер-службы-DAO DAO Code Code Consustres в качестве разработчиков? Часто при совершении рефакторинги это заставляет людей рвать кровь.

Хорошо продуманный дизайн домена здесь - слоистые предложения:

интерфейсный слой

В основном отвечает за взаимодействие и связь с внешними системами, такими как некоторые сервисы dubbo, Restful API, RMI и т. д. Этот уровень в основном включает Facade, DTO и некоторые ассемблеры.

Прикладной уровень Приложение

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

Слой домена

Уровень предметной области является ядром системы модели предметной области и отвечает за поддержку объектно-ориентированной модели предметной области.На этом уровне реализована почти вся бизнес-логика. В основном он включает в себя множество важных компонентов домена, таких как Entity (сущность), ValueObject (объект значения), Domain Event (доменное событие) и Repository (хранилище).

уровень инфраструктуры

В основном он обеспечивает поддержку трех уровней интерфейсов, приложений и доменов. Все реализации, связанные с конкретными платформами и платформами, будут предоставлены в инфраструктуре, чтобы избежать добавления трех уровней, особенно уровня предметной области, в эти реализации, тем самым «загрязняя» модель предметной области. Наиболее распространенным типом средств в инфраструктуре является конкретная реализация постоянства объектов.

Проектирование системы с высокой степенью параллелизма

Часто ли в интервью задают вопрос: как бы вы перепроектировали свою систему, если бы трафик вашей системы увеличился в N раз? Эта проблема с высокой степенью параллелизма может быть решена на различных уровнях, например:

уровень кода

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

уровень базы данных

Различные варианты хранения создаются в соответствии с различными требованиями к хранилищу, от ранних СУБД до NoSql (хранилище KV, база данных документов, механизм полнотекстового индексирования и т. д.), до последней версии NewSql (TiDB, Google spanner/F1 DB) и т. д. Ждать.
Дизайн структуры табличных данных, выбор и различение типов полей.
Дизайн индекса, необходимо обратить внимание на принцип кластеризации индекса и сортировку с исключением охвата индекса и т. д. Что касается самого левого принципа сопоставления, это здравый смысл на улице, некоторые продвинутые механизмы для сортировки с исключением индекса и т. д., разница между B+ дерево и B дерево.
Наконец, обычные средства: суб-библиотека подзаборов, отдельные распределения данных с чтением и записью, данные разделены и столь горячие, очень параллельные точки данных, как правило, делают бочку, что идут глубоко внутри, чтобы сказать, что есть много, например, как для инициализации Баррелы указывают, правила маршрутизации, заключительный этап того, как объединить данные и т. Д., Более классический способ разделен на главный бочон для баррелей + N суб-бочек.

Уровень проектирования архитектуры

Распределенная система как услуга
Поддержка без сохранения состояния для горизонтального эластичного масштабирования
отказоустойчивость на уровне бизнес-логики
Добавление данных точки доступа для ссылки на вызов
Многоуровневая конструкция кэша
Предварительное планирование емкости и многое другое

Проектирование системы высокой доступности

Для систем с очень высокими требованиями к доступности мы обычно говорим о нескольких показателях доступности, например 99,999%.

Перед лицом проектирования системы высокой доступности ее также можно проанализировать с различных аспектов.

Уровень кода: необходимо обратить внимание на проблемы с распределенными транзакциями, теория CAP — это рутинная процедура для собеседований.

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

проблема балансировки нагрузки

Как обеспечить загрузку системы после развертывания нескольких копий программного обеспечения? Как выбрать вызывающую машину? То есть проблема балансировки нагрузки

Балансировку нагрузки в узком смысле можно разделить на следующие виды по типу:

Аппаратная нагрузка: например, F5 и т. д.
Программная нагрузка: например, LVS, Ngnix, HaProxy, DNS и т. д.
Конечно, есть и балансировка нагрузки по алгоритмам кода, таким как Random, RoundRobin, ConsistentHash, обучение взвешенному вращению и другие алгоритмы.

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

Автоматическое открытие неисправных машин
Автоматическое удаление неисправные услуги (предохранитель услуг)
Запросить автоматический повтор
Автоматическое обнаружение восстановления службы

идемпотентная задача проектирования

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

Это можно рассматривать с двух уровней:

уровень запроса

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

бизнес-уровень

Отсутствие идемпотента вызовет очень серьезные проблемы, такие как многократное вознаграждение и повторяющиеся заказы. Идемпотентность на бизнес-уровне — это, по сути, проблема распределенной блокировки, которая будет рассмотрена позже. Как сделать так, чтобы повторных заказов не было? Вот, например, механизм токенов и так далее. Как сделать так, чтобы товар не был перепродан? например, оптимистическая блокировка. Как потребители MQ обеспечивают идемпотентность, часто задают в интервью.

Распределенная блокировка

Идемпотентный дизайн на бизнес-уровне по сути является проблемой распределенной блокировки Что такое распределенная блокировка? Глобально уникальный ресурс блокировок в распределенной среде сериализует запросы, фактически выражает блокировки взаимного исключения и решает проблему идемпотентности на бизнес-уровне.

Распространенным решением является метод setnx, основанный на кеше Redis, но как специалисту должно быть ясно, что все еще существуют единичные проблемы, проблема невозможности продления аренды на основе времени ожидания, проблема асинхронного мастер-сервера. подчиненная синхронизация и т. д., немного глубже, теория CAP, AP Система по существу не может реализовать требование CP, даже RedLock.

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

Надежные решения на основе уровня хранения, такие как:

zookeeper

Доступен CP/ZAB/N+1: на основе реализации временного узла и механизма наблюдения.

ETCD

Доступен CP или AP/Raft/N+1: на основе Restful API; хранилище KV, строгая согласованность, высокая доступность, надежность данных: постоянство; клиентский режим TTL, требуется уникальный идентификатор uuid учетных данных CAS.

автоматический выключатель

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

понижение уровня обслуживания

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

Основные инструменты следующие:

Понижение уровня обслуживания, основные средства

Отклонение некоторых запросов (текущее ограничение), таких как кеширование очередей запросов, отклонение некоторых запросов с длительным временем ожидания, отклонение неосновных запросов в соответствии с заголовком, существуют другие текущие алгоритмы ограничения на общих алгоритмах, таких как токен-база, алгоритм дырявого ведра и т. д. .
Закройте некоторые услуги: например, акция «Двойные 11» закроет услугу обратного возврата в 0:00.
Иерархический даунгрейд: например, автономный даунгрейд сервиса, от шлюза к бизнесу до БД, в соответствии с перехватом и бизнес-правилами, объем нисходящих запросов постепенно уменьшается, что отражается в постепенном снижении мощности обработки сверху вниз .

Понижение уровня данных

Например, при большом трафике запрос на обновление кэшируется только в MQ, запрос на чтение считывается из кэша, а при небольшом трафике выполняется операция заполнения (как правило, если уровень доступа к данным понижен , нет необходимости делать это снова на уровне данных)

Гибкая стратегия доступности

Например, некоторые инструменты ограничения тока, которые задают максимальный поток, или инструменты ограничения тока, основанные на загрузке ЦП и т. д., должны быть гарантированно открыты автоматически, не полагаясь на ручную работу.

Проблемы с доступностью, вызванные методами публикации

Метод публикации также является моментом, который влияет на высокую доступность.Ха-ха, я уже сталкивался с некоторыми случаями прямого отключения онлайн (внутренние банковские системы), но в высоком Интернете в основном используются эти методы публикации: публикация в оттенках серого, сине-зеленые выпуски , канареечные релизы и многое другое.

Дизайн системы согласованности данных

Как правило, некоторые финансовые и бухгалтерские системы предъявляют очень строгие требования к этой части, и ниже в основном представлена согласованность транзакций и алгоритм согласованности, задействованный в этом.

Проблемы согласованности транзакций

На уровне БД согласованность данных, как правило, достигается благодаря жестким транзакциям, главным образом через метод журнала записи Wept own (Wal). Wal (запись вперед) записывает журнал вперед. То есть все модификации файла данных должны быть сначала записаны в журнал, чтобы даже если он сбивает сбои при записи данных, его можно восстановить через файл журнала. Традиционная транзакция базы данных основана на этом механизме (повторение данных Преданная транзакция также требует изменить отказ от отмены незарегистрированных транзакций).

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

Остальные основаны на модели XA двухэтапной фиксации.

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

Режим TCC/или двухступенчатый режим

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

Режим САГА

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

Сообщение транзакции MQ

Это означает сначала отправить halfMsg, а затем отправить сообщение фиксации или отката после обработки, а затем MQ будет периодически спрашивать производителя, может ли halfMsg зафиксировать или откатить, и, наконец, добиться окончательной согласованности транзакции. Фактически компенсационное действие делегировано RocketMQ.

Сегментируйте вещи (обеспечивается асинхронность)

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

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

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

Алгоритм консенсуса

От раннего алгоритма Paxos до более позднего производного протокола zab (см.: Простой полностью упорядоченный широковещательный протокол) он обеспечивает надежное решение для распределенных блокировок. Затем к более позднему алгоритму Raft (в поисках понятного алгоритма консенсуса) также относятся некоторые знания, которые необходимо изучить при проектировании распределенной системы.

Наконец

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

———————————————————————————————————————————

Автор|Юнцзянь

Редактор | Orange Jun

Произведено | Alibaba New Retail Tao Technology