Мы живем в компьютерную эру, полную распределенных системных решений, будь то продукты с самым высоким трафиком, такие как Alipay и WeChat, или популярные концепции, такие как блокчейн и Интернет вещей, или бушующая технология экосистемы контейнеров, такая как Kubernetes, ядро технической архитектуры, лежащей в основе неотделим от распределенных систем.
Зачем нужно понимать распределенную архитектуру
Систематическое изучение дизайна распределенной архитектуры очень важно для роста технического персонала.Для разработчиков облачных приложений разработка приложений, соответствующих философии облачного дизайна, часто неотделима от применения знаний и методологии распределенных систем. Как проектировать нативные приложения, которые являются высокоэластичными, настраиваемыми, распространяемыми, высокопроизводительными, отказоустойчивыми, более безопасными, отказоустойчивыми и быстро доставляемыми, часто является важным ориентиром для измерения уровня разработчиков.
Затем распределенная система представляет собой большую концепцию С точки зрения проектирования архитектуры, процесса НИОКР, развертывания эксплуатации и обслуживания, инженерной эффективности и т. д. существуют глубокие знания, которые можно использовать, а стоимость обучения относительно велика. Недавно я разобрал некоторые книги и статьи, связанные с дистрибутивом, которые я читал в прошлом, и поделился собственным опытом в распределенной разработке.Эта статья является началом этой статьи, в которой дается обзор знаний в целом, и будет сочетаться с практикой написания кода в следующих главах. Составление поспешное, а уровень ограничен.Приглашаем всех учиться и исправлять.
Общая картина распределенной системы
1. Дизайн
Режим шлюза, шлюз
Функция
- Маршрутизация запроса, клиент напрямую звонит на шлюз, а шлюз отвечает за маршрутизацию и переадресацию в службу регистрации.
- Регистрация службы, серверная служба регистрирует API, а шлюз отвечает за маршрутизацию.
- Балансировка нагрузки, поддержка нескольких стратегий нагрузки
- round robin
- Алгоритм стохастического выравнивания
- многовесовая нагрузка
- залипание сеанса
- разное
- Функции безопасности, поддержка HTTPS, проверка подлинности учетной записи и поддержка других функций безопасности
- Выпуск в оттенках серого, вы можете сделать выпуск в оттенках серого для таких функций, как версии службы или клиенты.
- Агрегация API, объединение нескольких серверных интерфейсов для уменьшения количества клиентских вызовов.
- Оркестрация API, посредством оркестрации для подключения нескольких API для выполнения конкретного бизнеса.
Очки дизайна
- Доступность, должна обеспечить высокую доступность
- Расширяемость, может быть гибко расширена для поддержки определенных услуг, таких как определенный контроль потока обслуживания
- Высокая производительность, обычно реализуемая с использованием фреймворков модели асинхронного ввода-вывода, таких как Java netty, Go Channel.
- Безопасность, такая как зашифрованная связь, аутентификация, защита от DDOS и т. д.
- Эксплуатация и обслуживание
- Мониторинг приложений, включая емкость, производительность, обнаружение аномалий и т. д.
- Эластичное масштабирование с высокой эластичностью, позволяющее справляться с высокими пиковыми нагрузками при низких затратах.
- Архитектура
- Отделение от бизнеса, предоставление механизма расширения, такого как плагин, бессерверная идея для поддержки внутреннего бизнеса.
- Изоляция служб, шлюзы можно разделить в соответствии с внутренними службами, чтобы разные службы использовали разные шлюзы.
- Шлюз развертывается рядом с серверной частью, чтобы обеспечить минимальные потери сети и оптимальную производительность.
Пограничный режим, SIDECAR
стоимость
- Разделение управления и логики, разделение бизнес-логики и маршрутизации, управление потоком, слияние, идемпотентность, обнаружение сервисов, аутентификация и другие компоненты управления
- Применимая сцена
Очки дизайна
- Стандартный сервисный протокол, Sidebar to Service, Sidebar to Sidebar протокол максимально отделен от языка
- Агрегированная логика управления, такая как управление потоком, плавкий предохранитель, идемпотент, повторная попытка и бизнес-логика сокращения.
- Не используйте навязчивые методы для межпроцессного взаимодействия, такие как семафоры, разделяемая память, и отдавайте предпочтение методам взаимодействия в локальной сети, таким как TPCP или HTTP.
Сервисная сетка, Сервисная сетка
Архитектура микросервисов нового поколения — это, по сути, уровень инфраструктуры для связи между сервисами.
Диаграмма архитектуры
Функции
- Средний уровень связи между приложениями
- Легкий веб-прокси
- Разделенные приложения
- приложение-агностик
Основная структура
Распределенная блокировка
решение
- Распределенная блокировка Redis, значение ключа SETNX, время истечения PX
- генерируется значение, желательно глобально уникальное, такое как TraceID, которое можно сгенерировать с помощью /dev/urandom
- Единица времени истечения составляет миллисекунды, и блокировка с истекшим сроком действия автоматически освобождается Владелец блокировки гарантирует, что расчет будет завершен, конкурируя за ресурсы в течение времени истечения срока действия.
- Пессимистичная блокировка, сначала получить блокировку, а затем работать, пропускная способность низкая
- Оптимистичная блокировка, реализованная по номеру версии, высокая пропускная способность, может возникнуть исключение блокировки, подходит для ситуаций многократного чтения
- CAS, сценарий модификации общих источников данных может заменить распределенные блокировки
Очки дизайна
- Эксклюзивность, только один клиент может получить замок при любых условиях
- Замки имеют автоматические методы разблокировки, такие как разблокировка по тайм-ауту.
- Блокировки должны быть высокодоступными и постоянными.
- Блокировки должны быть неблокирующими и реентерабельными
- Чтобы избежать взаимоблокировки, клиент должен иметь возможность в конечном итоге получить блокировку, и не должно быть нештатной ситуации, когда блокировку нельзя снять.
- Отказоустойчивость кластера, при сбое некоторых машин в кластере операции блокировки по-прежнему доступны
Центр конфигурации
- Статическая конфигурация, конфигурация среды и запуска программного обеспечения
- Динамическая конфигурация, конфигурация, динамически регулируемая во время выполнения, например, переключатель управления потоком, предохранительный выключатель и т. д.
Асинхронная связь
- Запрос-ответ, отправитель отправляет запрос напрямую получателю
- Отправитель активно опрашивает
- Отправитель регистрирует функцию обратного вызова, а получатель перезванивает отправителю после завершения обработки.
- Дизайн, управляемый событиями (EDA)
- Подписка на сообщение, отправитель публикует сообщение, получатель подписывается и использует сообщение
- Брокер-посредник, отправитель публикует сообщения Брокеру, а получатель подписывается на сообщения Брокеру, отделенные друг от друга, например промежуточное ПО RocketMQ.
- Преимущество дизайна, ориентированного на вещи
идемпотентность
- Суть в операции, сколько бы раз она ни выполнялась, результат выполнения всегда один и тот же
- В основе идемпотентности лежит глобальный уникальный идентификатор, а ссылка является идемпотентной на основе глобального идентификатора.В зависимости от сложности бизнеса можно выбрать различные методы реализации.
- Идентификатор автоинкремента базы данных
- Генерировать UUID локально
- Производственный идентификатор Redis
- Алгоритм Twitter с открытым исходным кодом Snowflake
- Идемпотентность HTTP, кроме POST, HEAD, GET, OPTIONS, DELETE, PUT, все идемпотентны
2. Выступление
Распределенный кеш
- режим обновления кеша
- Кэш Помимо общего режима, приложение должно поддерживать аннулирование кеша, попадание, обновление и другие действия.
- Чтение/запись через кэширование, операция обновления базы данных прокси-сервера, только одно хранилище с точки зрения приложения
- Write Behind Cache, один из методов ускорения ввода-вывода, операция обновления завершается только во внутреннем тесте, а база данных обновляется пакетами асинхронно.
Асинхронная обработка
- Модель push, централизованное планирование, высокая сложность
- Вытягивающая модель, отсутствие централизованного планирования, низкая сложность
- Модель «тяни+толкай»
Расширение базы данных
- Фрагментация базы данных
- Вертикальный осколок
- Разбиение полей, разбиение полей с разной частотой изменения на разные таблицы
- горизонтальное разделение
- Хэш-алгоритм для разделения, высокая дисперсия данных, снижение вероятности возникновения горячих точек
- Обеспечение непрерывности данных за счет разделения временного диапазона
- Разделен на бизнес-тип, такой как классификация данных, разделение арендатора и т. Д.
- Основы дизайна шардинга
- Вертикальный осколок
3. Отказоустойчивость
доступность системы
- MTTF, среднее время до отказа, сколько времени в среднем работает система до того, как произойдет сбой, чем дольше, тем лучше
- MTTR, среднее время восстановления, среднее время восстановления, чем короче, тем лучше
- Формула расчета доступности, Доступность = MTTF / (MTTF+MTTR)
понижение уровня обслуживания
- уменьшить согласованность
- Строгая согласованность, переключение согласованности всей синхронизации на конечную согласованность, повышение пропускной способности
- Слабая согласованность, жертвование согласованностью ради общей надежности службы, когда это необходимо
- Отключить второстепенные службы
- Различные приложения, закрыть вторичные приложения, освободить физические ресурсы
- То же приложение, отключите второстепенные функции приложения и дайте больше ресурсов основным функциям.
- Упрощенные сервисные функции
Лимит сервисного тока
- Цель ограничения тока
- Один из методов гарантии SLA
- Реагирование на внезапные всплески трафика, в определенной степени экономия затрат на планирование пропускной способности.
- Одна из стратегий изоляции арендаторов, позволяющая предотвратить использование ресурсов других пользователей одними пользователями, что приводит к недоступности широкого спектра услуг.
- Метод ограничения тока
- понижение уровня обслуживания
- отказ в обслуживании
- решение
- Разделение веса услуг, многопользовательская среда распределяет ресурсы в соответствии с весом, гарантируя ресурсы важных клиентов.
- Обработка задержки обслуживания, присоединитесь к очереди буфера обслуживания, чтобы отсрочить давление обслуживания для снижения пиковых нагрузок.
- Эластичное масштабирование службы, зависимый мониторинг службы, возможности эластичного масштабирования
- Алгоритм управления потоком
- прилавок
- Одна машина или кластер сохраняет количество запросов от пользователя за определенный период времени, и при достижении порога срабатывает управление потоком
- алгоритм очереди
- FIFO-очередь
- Скорость запроса колеблется, скорость потребления одинаковая, очередь заполнена, управление потоком
- весовая очередь
- Разделите приоритетные очереди по сервисам, и разные очереди будут иметь разный вес
- Ключ к разработке алгоритма очереди: предустановка длины очереди очень важна
- Очередь слишком длинная, управление потоком не действует, и служба была убита.
- Очередь слишком короткая, управление потоком срабатывает часто, а опыт оставляет желать лучшего.
- FIFO-очередь
- алгоритм воронки
- По сути, это реализация очереди + текущего ограничителя, а текущий ограничитель обеспечивает равномерную скорость потребления, как отставание синхронизации TCP
- Скорость пересылки даже
- корзина с жетонами
- Посредник выдал токены в корзину с постоянной скоростью, и запрос на обслуживание запустит сервис, когда токен будет получен, иначе он не будет обработан.
- Скорость пересылки неравномерная, трафик накапливается, когда трафик маленький, а расход - когда трафик большой.
- Динамический контроль потока
- Возможности службы вычислений в реальном времени, такие как QPS, по сравнению с сервисным RT, если RT слишком велико, уменьшите QPS.
- прилавок
- Очки дизайна
- Ручной переключатель, активная эксплуатация и техническое обслуживание и аварийное использование
- Отслеживайте уведомления, и заинтересованные стороны должны четко понимать, когда происходит текущее ограничение
- Восприятие пользователя, например возврат конкретного сообщения об ошибке (код ошибки/подсказка об ошибке)
- Идентификация канала, ссылки RPC добавляются к идентификатору текущего лимита, чтобы упростить восходящие и нисходящие сервисы для определения сценариев текущего лимита и выполнения различной обработки.
Слияние дизайна
- Сцены
- Защита от перегрузки, защитная мера, принимаемая для предотвращения сбоев при слишком высокой нагрузке на систему.
- Не позволяет приложениям постоянно пытаться выполнять операции, которые могут привести к сбою
- три состояния
- Закрытое, закрытое состояние, нормальное состояние, системе требуется счетчик ошибок на основе времени, если накопление ошибок достигает порогового значения, она переключится в открытое состояние.
- Открытое, отключенное состояние, все пары сервисов сразу возвращают ошибку на запрос, не вызывая серверный сервис для расчета
- Half-Open, полуоткрытое состояние, позволяет входить и обрабатывать часть трафика запросов, в случае успешного выполнения запроса переходить в состояние Closed по определенной стратегии
- Очки дизайна
- Определите тип ошибки, вызывающей срабатывание автоматического выключателя.
- Все запросы об ошибках, вызывающие срабатывание автоматических выключателей, должны иметь унифицированный вывод журнала.
- Автоматический выключатель должен иметь сервисную диагностику и возможности автоматического восстановления.
- Лучше всего установить ручной переключатель механизма предохранителя для переключения между тремя состояниями
- Для слияния необходимо разделить бизнес и добиться изоляции и слияния бизнеса.
Компенсационная транзакция
- CAP
- Непротиворечивость, доступность, устойчивость к разделам
- BASE
- Базовая доступность, базовая доступность
- Мягкое состояние
- Возможная согласованность, окончательная согласованность
- Design For Failure
- Экспоненциальное отключение, экспоненциальное отставание
4. DevOps
развертывать
- инфраструктура
- облако
- общедоступное облако
- Частное облако
- гибридное облако
- контейнерная технология
- Docker
- Kubernetes
- облако
- Стратегия развертывания
Управление конфигурацией
монитор
КИ и КД
5. Инженерная эффективность
Гибкое управление
Непрерывная интеграция
непрерывная поставка
напиши в конце
Распределенные системы имеют широкий спектр применений в экономике Alibaba.Взяв в качестве примера гибкую техническую команду автора, когда бизнес достаточно масштабируется, все окончательные технические проблемы решаются путем применения концепций проектирования и методов архитектуры распределенной системы.Это Можно сказать, что знание и методология архитектуры распределенной системы является общим решением после масштаба текущих интернет-приложений.
Изучение распределенной системы не является проблемой, необходимо постоянно изучать теоретические знания, а затем применять теорию на практике и, в конечном итоге, максимизировать ценность знаний путем настройки. Заключительная рекомендация автора - первая теория, после практики, тяжелой практики, не компромисса, так называемая бумага злится, понимаете дело и монарх.
«Официальная учетная запись Alibaba Cloud Native WeChat (идентификатор: Alicloudnative) фокусируется на микросервисах, бессерверных технологиях, контейнерах, Service Mesh и других технических областях, фокусируется на популярных тенденциях облачных технологий, практиках крупномасштабного внедрения облачных технологий и является самый знающий облачный разработчик. Технический публичный аккаунт».