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

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

//////////

В 20:00 24 октября видео-аккаунт Tencent Cloud Developer «Программисты Goose Factory Face to Face» приглашает вас обсудить «1024: Куда идут программисты в эпоху искусственного интеллекта». Назначьте встречу, чтобы посмотреть и получить возможность. чтобы захватить периферийные подарки Goose Factory!

01. Введение в распределенные системы

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

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

• Отказоустойчивость/высокая доступность：Если тыиз Приложение должно быть на машине（илинесколько машин、сетьиливесь дата-центр）Продолжайте работать даже во время простоя,Вы можете использовать несколько компьютеров для обеспечения избыточности. Когда машина выходит из строя,Другой может взять на себя управление.
• Масштабируемость：Если тыиз Объем данныхили Вычислительные требования превышают требования одной машиныизвычислительная мощность,Вы можете распределить нагрузку между несколькими машинами.
• низкая задержка：Если тыиз Пользователи по всему миру,Возможно, вы захотите установить свой генератор Служить в разных местах по всему миру.,Чтобы каждый пользователь мог получить данные из дата-центра, географически близкого к нему. Это избавляет пользователей от необходимости ждать, пока сетевые пакеты пройдут полмира, чтобы ответить на их запросы.
• Эластичность ресурсов：Если тыиз Приложение занято в определенное время и простаивает в другое время,Облачные развертывания можно масштабировать в большую или меньшую сторону в зависимости от спроса.,Таким образом, вы платите только за те ресурсы, которые действительно используете. Этого сложнее добиться на одной машине.,Потому что его необходимо предварительно настроить на максимальную нагрузку.,Это верно даже при редком использовании.
• Юридическое соответствие：В некоторых странах действуют законы о местонахождении данных.,Требует, чтобы данные лиц, находящихся под его юрисдикцией, хранились и обрабатывались в пределах географического охвата этой страны. Эти правила различаются по объему - например.,в некоторых случаях,Он работает только с медицинскими и финансовыми данными.,Другие более распространены. поэтому,Пользователю, у которого есть пользователи в нескольких таких юрисдикциях, придется распределить свои данные по нескольким серверам.

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

Однако в определении DDIA в основном обсуждается распределение на основе данных и состояния. Однако на реальной практике существует два типа распределенных систем: с сохранением состояния и без сохранения состояния.

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

Связанные теории:

• Теория CAP, теория CAP относится к В системе: ‌Согласованность, ‌Доступность и‌Раздел. Tolerance）Эти три характеристики не могут быть удовлетворены одновременно.。Последовательность означаетизнаходится враспределенныйв системеиз Все ли резервные копии данных одинаковы?изценить；Наличие относится киз Каждый запрос успешен независимо от успехаили На любую неудачу есть реакция；Разделотказоустойчивость Секс относится киздав системепроизвольная информацияизпотерянныйили Сбой не повлияет на системуизпродолжать действовать。
• Теория BASE: Теория BASE представляет собой практическое расширение теоремы CAP.,Акцент на соответствующем смягчении требований к строгой согласованности в распределенной системе.,В обмен на более высокую доступность и производительность системы. Основная идея такова: мы не можем добиться строгой согласованности.,но Каждое приложение можно настроить в соответствии со своими бизнес-характеристиками.,Используйте соответствующие методы для достижения конечной согласованности системы.

лицо без гражданства Функции：

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

В частности, существуют различные структуры, связанные с параллельными вычислениями, такие как:

• Алгоритм MapReduce
• OpenMP
• Структура MPI

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

Большинство текущих сценариев бизнес-приложений (особенно to c Бизнесу) необходимо хранить пользовательские данные и бизнес-данные. Суть все-таки в дата-емкой системе, то есть в наличии. состояниемиз Служить,ТакКак спроектировать хороший презентий состояниемизраспределенный Архитектура,Это распространенная проблема, с которой сталкивается большинство предприятий.,Этому также посвящена данная статья.

Здесь представлен проект, обладающий состоянием распределенной архитектуры, который требует некоторых соображений:

• Надежность данных. Запись данных надежна и в конечном итоге согласована в нескольких копиях.
• Высокая доступность: могут быть достигнуты физические сбои и аварийное восстановление (детализация может включать машины,рамка,Тот же город,по всему городу).
• Лучший пользовательский опыт: постарайтесь сократить время, затрачиваемое на один запрос.,От пользователя к бизнес-машине,Не пересекайте город без необходимости,Если вы пересекаете город,Запрос можно сделать по городу максимум один раз.
• Высокий параллелизм: поддерживает высокопроизводительные операции чтения и записи, а требования к чтению и записи превышают производительность одной машины.
• Сократите затраты на эксплуатацию и техническое обслуживание: поддерживайте горизонтальное расширение и сжатие и максимально используйте машинные ресурсы.

02. Реализовать модель распределенной системы.

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

AO：Инкапсулированное приложениеизбизнес-логикаи Поток обработки。AO В основном отвечает за обработку запросов пользователей и вызов связанных атомарных служб для выполнения конкретных задач. Обычно он располагается поверх микросервисов, взаимодействует с другими объектами и координирует различные функциональные модули.

BO：микросервисы Среднее отношениеизатом Служить,Ответственный за атомизацию бизнеса из Служить,различными AO Звонок в сервис. Функция может быть конкретной бизнес-атомарной функцией или атомарной службой, работающей с данными.

Для реализации системы обычно выделяют три типа:

2.1 Одно приложение

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

преимущество

• ‌Простота：относительномикросервисы Архитектура,Разработка, тестирование и развертывание единой архитектуры проще. Весь Служить можно легко расширить.
• ‌Лучшая производительность‌：Поскольку все функции выполняются в одном процессе,Обычно имеет лучшую производительность и отзывчивость.
• ‌Простота обслуживания‌：всеизкоди Функциявсе в том жекодбиблиотека,Делает обслуживание и модификацию относительно простыми.

Проблемы, с которыми пришлось столкнуться

• Высокая сложность системы‌：С функциейиз Увеличивать,База кода становится большой и сложной,Разработчикам становится сложнее понять всю систему.,Это, в свою очередь, влияет на качество и удобство сопровождения кода.
• Скорость разработки низкая‌：Потому что его нужно скомпилировать、строитьи Протестируйте весь проект,Каждое изменение кода отнимает много времени,Увеличение затрат на разработку.
• Трудно масштабировать‌：Одно приложение Сложно настроить под разные модули.из Нужно быть целенаправленнымиз Расширять,Часто требует общего расширения,Приводит к неэффективному использованию ресурсов.
• ‌Трудно поддерживать‌：между модулямииз Высокая степень сцепления,Изменение требований модуля часто приводит к цепным реакциям.,Влияет на стабильность других модулей.
• Трудности с внедрением новых технологий‌：Проект представляет собой огромныйизобщий,Применение новых технологий становится очень дорогостоящим,Потому что весь проект пришлось рефакторить,Обычно это невозможно.
• Скорость разработки низкая‌：Приложение слишком большое,Каждый стартап занимает много времени,Поэтому цикл от редактирования до сборки, запуска и тестирования занимает все больше времени.
• Сложность развертывания‌：кодразвертыватьиз Цикл очень длинный,И легко ошибиться. Развертывание изменений программы в рабочей среде занимает больше времени,База кода сложна,Так что возможные последствия изменения неизвестны.
• Плохая изоляция неисправностей системы‌：В приложении отсутствует изоляция неисправностей,Поскольку все модули выполняются в одном процессе,Любой частичный сбой может повлиять на стабильность всей системы.,Вызвать простой.

2.2 Архитектура SOA

Архитектура SOA больше ориентирована на изменение способа работы ИТ-сервисов на предприятии. SOA (сервис-ориентированная архитектура) определяет метод, который позволяет повторно использовать программные компоненты через сервисные интерфейсы и достигать их совместимости. Приведем простой пример: использование стандартных сетевых протоколов, таких как SOAP (простой протокол доступа к объектам)/HTTP или Restful HTTP (JSON/HTTP), для предоставления сервисов является разновидностью SOA.

преимущество

• Масштабируемостьигибкость：SOA Архитектура Разделить систему на независимыеиз Служить,Эти Служить можно комбинировать и реорганизовывать по мере необходимости.,Это обеспечивает быстрое расширение и гибкое развертывание системы.
• Улучшение возможности повторного использования системы：каждый Служить Все независимыизфункциональный блок,Может быть повторно использован в различных системах.,Повышение эффективности разработки системы и затрат на ее обслуживание.
• Уменьшите связанность системы：SOA Архитектура через Служить из слабых связей,Уменьшена зависимость между Служить и из,Способствует модульности системы и ее обслуживанию.
• Повышение стабильности и надежности системы：SOA Архитектура использует механизм регистрации и открытия «Служить», балансировку. нагрузка, восстановление после сбоев и другие механизмы улучшают стабильность и надежность системы.

Проблемы, с которыми пришлось столкнуться

• Высокая сложность системы：SOA Архитектурас участием нескольких Служитьмеждуизсотрудничествоикоммуникация,Сложность системы высокая,Затраты на разработку, тестирование и обслуживание относительно высоки.
• Проблемы с производительностью：потому что Служитьмеждуизкоммуникациянуждатьсяпроходитьсетьруководить,Возможны задержки в сети и потери производительности.,Оказывают влияние на производительность системы.
• Безопасность трудно гарантировать：SOA Архитектурас участием нескольких Служитьмеждуизкоммуникация,Требуется шифрование и средства контроля безопасности для передачи данных.,Трудно обеспечить безопасность системы.
• Развертывание, эксплуатация и обслуживание затруднены.：SOA Архитектурас участием нескольких Служитьизразвертыватьиуправлять,Для управления требуется специальная команда по эксплуатации и техническому обслуживанию.,Увеличение сложности системы и затрат на эксплуатацию и техническое обслуживание.

2.3 Микросервисы

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

преимущество

Кроме чего-то похожего на SOA изпреимущество,Также существуют следующиепреимущество

• Независимость‌：каждый Служить Можетбыть независимымразвертыватьивозобновлять,Повышенная гибкость и надежность системы.
• ‌Масштабируемость‌：по требованию,Один Служить можно расширить самостоятельно.,а не все приложение.
• «Отказоустойчивость»：одинокий Служитьиз Неудача не повлияет на других Служить,Улучшена стабильность системы.

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

1. Должен быть уровень доступа：Как показано выше,микросервисы После,Должны быть пользователи, которым необходимо напрямую подключаться к бэкенду.,Тогда в это время вам нужно отсоединить этот кусок,То есть преимущества, обсуждавшиеся выше на уровне доступа.
2. Отказоустойчивость сервиса：Несколько микро Развертывание служба на облаках,Другая материнская машина,Привнесет сложность общения,Проблемы с сетью станут нормой,Итак, как оправиться от катастрофы,отказоустойчивость,Понизить версию,Это также необходимо учитывать.
3. обнаружение службы：когда Служить A Издатель полагается на Служить при увеличении или уменьшении масштаба. A из Служить X Как автоматически обнаружить Служить, продолжая работать A изизменять。Здесь необходимо представить третью сторону.Служить Центр регистрации для достижения Служитьизобнаруживаемость。Такие как Полярис,stark,и как использовать контейнеры,Нативная облачная интеграция.
4. Развертывание службы：Служитьстановитьсямикросервисыпосле,Развертывание децентрализовано,Развертывание независимое,Вам нужно надежное и быстрое развертывание,План расширения и сокращения мощностей,Также включает ci/cd, полная ссылка, возможность наблюдения в режиме реального времени и многомерная видимость и т. д., например тке, Жиян и т. д., к8с Просто чтобы решить такую ​​проблему.
5. Изоляция хранилища данных：Изоляция хранилища данных(Data Storage Segregation, DSS) Принцип, согласно которому данные являются частной собственностью и должны предоставляться текущими микросервисамииз. API Чтобы получить доступ к данным и избежать связи на уровне данных. Для предъявлений Для состояниямикросервисов метод расчета и классификации хранения обычно используется для понижения данных в решение распределенного хранения, тем самым реализуя Служитьлицо в определенной степени. без гражданстваизменять。
6. Межсервисные звонки：Служить A Как позвонить в Служить X, из-за Служить автономию из-за ограничений , из звонков между Служить необходимо использовать язык разработки, независимый от протокола удаленного вызова. Сейчас большая часть отрасли обычно использует IDL （Interactive Data Language, Interactive Data Language) из бинарного протокола взаимодействия, например pb。

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

Ввиду проблем, которые необходимо решить при проектировании микросервисов, давайте обсудим, как 1-5 аспектов, которые необходимо решить микросервисами выше, могут быть реализованы в системе (шестой пункт относительно ясен и здесь не будет обсуждаться). :

03. Какие проблемы решает уровень доступа?

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

1. взрыв ссылок,Внешних измикросервисов столько же, сколько
2. Служитьи Клиент сильно связан,Клиент должен знать, какой запрос на какой адрес отправлен.,Отсутствие единой маршрутизации.

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

1. Уровень доступа к региональной сети：Ответственныйобластьизменятьсеть Доступ,Рядом с пользовательской зоной.
2. Бизнес-шлюз：Ответственный Служитьпрозрачный прокси,Командное слово для пересылки и т.п.

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

3.1 Региональный уровень доступа к сети

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

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

3.2 Бизнес-шлюз

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

• Прозрачный сервисный прокси：Обеспечить единообразие Служить Вход,Сделайте микросервисы прозрачными для стойки регистрации,Обычно через командное слово и серверную часть или Интерфейсы соответствуют.
• Контроль доступа：Проверка статуса входа в конвергенцию,логика пересылки,крашение,Такие функции, как единая организация руководителей предприятий,
• Доступ и изоляция пользовательского трафика,Переадресация трафика,Защита серверной части：Если это долгое соединение Служить,Он также может объединить бизнес ao из ссылки пользователям нужен только доступ к ссылке на слой, вы можете использовать все Служить, а не каждого пользователя и ao ссылка, вызовет ao Нагрузка на Служитьиз относительно высока.
• балансировка нагрузки：Вы можете поместить пользователяиз Балансировка трафика（Некоторые сцены могут быть не полностью сбалансированы,но еще есть функция перенаправления из) запроса ао.
• Текущее предельное понижение：Будет ограничение потока для командных слов.,Разрешить шлюз в крайних случаях,Выполнять случайные сбросы запросов,Чтобы избежать общего схода лавины Служитьиз.
• Получите доступ к ближайшей локации и пересеките город как можно скорее.：Сначала посчитайте как можно больше пользователейизпуть доступа,Например, запрос на чтение,Вы можете напрямую получить доступ к нижнему течению или поблизости.,bo,Написание запросов требует знания пользовательских данных из точки записи.,Вы можете найти кластер точек записи как можно раньше.,Чтобы удовлетворить не более одного перекрестка городаизнуждаться。
  • Если оно не рассчитано вначале,Когда пункт записи находится по всему городу и один запрос требует нескольких написаний,ao Нужно позвонить несколько раз bo,бо Иди снова пересечь город,Город можно пересечь несколько раз.

Основными компонентами сервисного шлюза являются: сервис доступа с прокси-пользователями + сервис переадресации с маршрутизацией.

Реализация маршрутизации состоит из трех частей: сохранение маршрута, расчет маршрута и аварийное восстановление маршрута.

04. Отказоустойчивость микросервисов

4.1 Чередование

Почему отказоустойчивость микросервисов требует этой концепции?

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

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

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

Преимущества использования стрипов:

• ‌Аварийное восстановление в нескольких зонах доступности‌：проходитьраспределены по разным Зона доступностииз Служитьсистема повышения давленияиз Терпимость к стихийным бедствиям‌。поставлять IDC（AZ уровень зоны доступности) и возможность физического аварийного восстановления.
• ‌Улучшите скорость доступа к запросам пользователей‌：проходитьотличныйизменятьсетьструктураиразвертывать Стратегия,Ускорьте обработку запросов пользователей. микросервисы звонок с IDC (AZ Availability Zone),Меньше времени.
• Мультиактивная архитектура‌：проходитьсуществовать IDC（AZ Распределите нагрузку трафика между доступными зонами) для улучшения возможностей обработки системы и использования ресурсов.
• ‌Контроль воздействия неисправностей‌：Влияние сбоя системы можно контролировать в пределах неисправности.из В пределах физического размера частиц,убеждаться Служитьиз Высокая доступность‌。
  • Как правило, также требуется изоляция трафика.,Это может предотвратить проникновение трафика друг в друга и возникновение эффектов диффузии неисправностей при неисправностях.
  • Аварийное восстановление основано на IDC（AZ Зона доступности),Вместо непосредственного управления микросервисами,Значительное снижение затрат на аварийное восстановление и обслуживание.,В то же время это может обеспечить успешность переключения при аварийном восстановлении.

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

Разложите все сверху вниз

Это решение включает в себя все необходимое для бизнеса содержимое при чередующемся аварийном восстановлении, но из вышеизложенного непосредственно видно, что сохраненные данные пользователя не обязательно являются теми, которые подключены к ближайшему бизнес-шлюзу. set,Таким образом, Бизнес-шлюз действительно может быть перенаправлен на другие Служить.,Здесь оно действительно разрушено.чередование。Такая изоляция трафика не достигается. Например, определенный set из ao Затраты времени стали медленнее, все set из Бизнес-шлюз повлияет, это set Это также может повлиять на машину, на которой она расположена, что приведет к этой проблеме. set из ao и bo тоже повлияло. Неудачи будут распространяться.

Кроме того, данное решение имеет следующие недостатки:

• Шлюзу сложно повторно использовать несколько сервисов.：Бизнес-шлюзизуровень Расширятьилогический уровень сцепления, Бизнес-шлюз может только for Единая бизнес-архитектура не может обеспечить повторное использование.
• Переключение аварийного восстановления сложное：нуждатьсяобластьсеть Доступ层и Бизнес-шлюзиз Совместная обработка маршрутизации для переключения при аварийном восстановлении。в случае Бизнес-шлюз Возникает следующая неисправность,Переключение происходит,нужно Бизнес-шлюзиз Переадресация маршрутизации устраняет ошибки установлен, уровень доступа к региональной сети также должен устранить неисправность. set。
• Ограничения связи уровня данных ao и bo Расширение：Чтобы обеспечить согласованность данных,Вам придется пожертвовать всем set из Доступность, что в определенной степени приведет к ao и bo из недоступен. В то же время сложность миграции сегментов данных на уровне данных также будет ограничивать возможности расширения. установить, тем самым влияя ao и bo из Расширение。
  • Кроме того, лицо без гражданстваизмикросервисы Архитектура, сверху вниз - чередование возможно, но в явном виде состояниемизмикросервисы Архитектурав,лицо без гражданства Служить можно чередование, но есть само хранилище данных, если чередование, оно будет существовать CAP Последовательность и доступность и противоречие в теории.
• Бизнес-шлюз Нужно понимать фрагментацию данных：Чтобы гарантировать, что мы сможем пересечь город не более одного раза,Если запрос существует несколько раз для вызова определенного bo Чтобы получить доступ к базе данных, вы должны напрямую знать, где интерфейсу требуются данные. set Возможности маршрутизации.

Распределение под уровнем доступа

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

Недостатки этого решения:

• Ограничения связи уровня данных ao и bo Расширение：Чтобы обеспечить согласованность данных,Вам придется пожертвовать всем set из Доступность, что в определенной степени приведет к ao и bo из недоступен. В то же время сложность миграции сегментов данных на уровне данных также будет ограничивать возможности расширения. установить, тем самым влияя ao и bo из Расширение。
  • Кроме того, лицо без гражданстваизмикросервисы Архитектура, сверху вниз - чередование возможно, но в явном виде состояниемизмикросервисы Архитектурав,лицо без гражданства Служить можно чередование, но есть само хранилище данных, если чередование, оно будет существовать CAP Последовательность и доступность и противоречие в теории.
• Бизнес-шлюз Нужно понимать фрагментацию данных：Чтобы гарантировать, что мы сможем пересечь город не более одного раза,Если запрос существует несколько раз для вызова определенного bo Чтобы получить доступ к базе данных, вы должны напрямую знать, где интерфейсу требуются данные. set возможности маршрутизации
• Бизнес-шлюз можно переключать только между городами：Строго говоря, это не недостаток.,потому что Бизнес-шлюзэтолицо без гражданстваиз Служить, может быть горизонтальным Расширение, или даже илогическим уровень развязки развертывания, учитывайте только ближайшую локацию, развертывайте в нескольких местах, если встретите Аварию в компьютерном зале,После того, как машины в этом компьютерном зале будут уничтожены,,Еще могу нормально говорить,Нет необходимости переключаться между городами.

Только чередование логических слоев

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

Это может решить два вышеупомянутых решения. Ограничения связи уровня данных ao и bo Расширение Из недостатков, но является обеспечение того, чтобы пересечения между городами осуществлялись как можно раньше и минимизация пересечений между городами. Маршрутизация Бизнес-шлюза может быть получена из базы данных. proxy у маршрутизации есть определенные Отношения связи. Попытайтесь сократить маршрутизацию между городами за счет маршрутизации по региону пользователя (хранение данных в регионе пользователя также является лучшим решением) при маршрутизации из Бизнес-шлюз.

Конкретное описание метода связывания:

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

4.1.1 Выбор полосовой детализации

Поскольку микросервисыиз блока аварийного восстановления установлено, решение в основном заключается в неисправности физического уровня, тогда set Детализация Что необходимо учитывать при выборе чередования? Вот справочная таблица:

• Если аварийное восстановление не рассматривается из-за низких результатов ввода-вывода и т. д., обычно требуется как минимум уровень города.
• обнаружение службыподдерживать Городуровень

Как правило, может удовлетворить требования изоляции ветра, огня, воды и электричества.,Также может существовать инфраструктура, совместно используемая близлежащими группами Города.,Поэтому мы обычно выбираем два места, которые находятся далеко друг от друга.,Такие как Шэньчжэнь,ШанхайIDC (зона доступности Аризона)

• Есть ли у бизнеса несколько затрат IDC?,Можно ли физически изолировать
• изIDC бюджет, когда IDC терпит неудачу,Переключение между городами отнимает у бизнеса много времени,Влияние на удобство использования относительно велико.
• обнаружение службыподдерживатьIDCуровень
• Имеется физическая изоляция изIDC,Изоляция от ветра, огня, воды и электричества

рекомендоватьСтойка (шкаф)

• Много ли дел?рамкаизрасходы,Можно ли физически изолировать
• израмка Бюджетрамка В случае неудачи,Переключение IDC отнимает у бизнеса много времени,Влияние на удобство использования относительно велико.
• обнаружение службыподдерживатьрамкауровень
• Иметь физическую изоляциюизрамка,Лучше всего изолировать ветер, огонь, воду и электричество.

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

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

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

05. Открытие службы

Микробизнес Служитьиз звонить друг другу,В основном Бизнес-шлюз найденный набор,set В рамках микросервисовиз обнаруживают друг друга, оба можно найти через Обнаружение. службы Приди и сделай это。

Для обеспечения чередования (физической изоляции, изоляции трафика) и set внутренняя целостность, обнаружение службычас,应该尽量существовать Детализация чередования Внутри Служитьможем узнать друг друга,Детализация чередования внешних Служить не могут обнаружить друг друга (понижение уровня аварийного восстановления должно выполняться set время принятия решения о стратегии аварийного восстановления), мы выбираем изонаружение Компонент службы мониторинга должен поддерживать эту возможность.

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

Централизованныйобнаружение службыи СлужитьсеткаОсновное различие заключается в масштабах решаемых ими задач и способах их реализации. ‌

Служба централизованного обнаружения — это механизм регистрации и обнаружения.,Вся информация, связанная с IP-адресами Служитьиз, управляется через централизованный реестр из Служитьиз. Всякий раз, когда Служить выходит в онлайн и/или отключается от сети,Он отменит свою регистрацию в реестре,При необходимости Другой Служить запрашивает в реестре другие адреса Служить. Таким образом упрощается связь между Служитьиз,но Необходимость вести централизованный реестр из Служить,Может стать единой точкой отказа,И нужно иметь дело с задержками в сети и единой точкой отказа.

Служить сетку — это выделенный уровень инфраструктуры, используемый для управления связью между различными микросервисами в распределенном приложении. Он развернут рядом с приложением Служитьиз прокси (называемым коляска) для обеспечения связи между Служить и обеспечения обнаружения. службы、балансировка нагрузки、Маршрутизация трафика、Аутентификацияи Наблюдаемость и другие особенности。Служитьсетка Волясетькоммуникацияизсложность абстракцииизменять,Позволяет разработчикам сосредоточиться на логике приложения.,Без необходимости иметь дело с базовым сетевым кодом. Обеспечивает Служить посредством распределенногоиз,Единственная точка отказа исключена,И обеспечивает более высокую гибкость и Масштабируемость‌.

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

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

06. Расширение

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

Итак, с точки зрения поддержки чередования, kubernetes 应该нуждатьсяподдерживатьset Внутреннее поперечное направление машины Расширение, комплект Пространство также может быть горизонтальным. Расширение.

Для достижения этой цели обычно необходимы несколько аспектов поддержки:

• Поддержка платформы развертывания：на основе kubernetes Можно выполнять планирование расширения и сжатия контейнера. На практике кластеры ресурсов можно планировать заранее в соответствии с каждой материнской машиной. set Используйте изолированные кластеры ресурсов, чтобы каждый set Содержимое можно расширять и сжимать в зависимости от ресурсов, а также можно set число,Может Расширениеиз set Некоторые департаменты также поддерживают кластеры ресурсов.
• Поддержка динамической маршрутизации шлюза：set междуиз Расширение,Потребуется поддержка шлюза,Вы можете позволить шлюзиз-маршрутизатору распознать наличие подключения и перейти в режим онлайн и оффлайн.,Настройте политику динамической маршрутизации.
• Поддержка аварийного восстановления：Процессор идентификации аварийного восстановления（Можетпроходить Код ошибки интерфейса Приди и сделай это Идентификация аварийного восстановления）Также необходимо признать set Только когда вы выходите в Интернет и офлайн, вы можете идентифицировать set Есть ли неисправность?
• Поддержка разрешений：В принципе,контейнерлицо без гражданстваиз, можно легко расширить и сократить. ip авторизовать, установить Авторизация. Даже если требуется авторизация, это должен быть автоматический шаг по расширению и сокращению емкости.

07. Хранение данных

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

1. Если хранилище данных является глобальным классом (есть только одна точка записи),Итак, для написания,Любой набор на верхнем уровне должен быть доступен.,Должен быть перекресток по городу,При аварийном восстановлении можно полагаться только на само хранилище данных и переключение главный-подчиненный.
2. Если хранилище данных сегментировано, обычно требуется, чтобы верхний уровень set Нижняя точка записи должна быть как можно ближе. Это также предусмотрено выше, если данные разбиты на осколки. set обязательность,максимально близко,но Недостатком являетсяШардинг данных сам по себе ограничит set Из Расширение, верхний уровень также должен знать основную ситуацию с фрагментацией данных.

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

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

Вот руководство:

1. Шардинг данных set Без привязки, через слой данных proxy Развязка set из отношений.
2. Для хранения данных используется распределенная система хранения.,Логический Служить получает доступ к уровню данных через соседний доступ (общий уровень прокси данных).,будут предоставлены распределенные системы хранения).
3. Если существуют строгие требования к географической близости,Базовую систему хранения можно связать с маршрутизатором, чтобы сделать ее максимально близкой. Разделите отношения сегментирования данных и развертывания путем маршрутизации данных.,а не разбрасываться логикой Служить,Сообщите логике Служить о развертывании базового хранилища.

08. Резюме

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

8.1 Анализ аварийного восстановления на каждом уровне

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

Уровень доступа к региональной сети

1. Отказ одной машины：Устранить напрямую CDN。
2. Авария в компьютерном зале：прямой Пучокмашинное отделениеиз Машины исключены CDN。
3. Город Вина：Пучок CDN Временно указать на другой Город

Бизнес-шлюз

1. шлюз Отказ одной машины：областьсеть Доступ层剔除这些机器,Может быть автоматически устранено путем мониторинга ошибок
2. шлюз Авария в компьютерном зале：областьсеть Доступ层剔除Винамашинное отделение,Может быть автоматически устранено путем мониторинга ошибок
3. шлюз Город Вина：областьсеть Доступ层Пучок Движение направлено в обычном режимеиз Город,Устранение ошибочного трафика,В этом случае период отказа,Половина пробок увеличит время, необходимое для пересечения города.,Теоретически автоматическое устранение также может быть достигнуто.,но Эта операция относительно тяжелая,Также необходима тщательная оценка,Рекомендуется резать вручную.

логический уровень

• шлюз Отказ одной машины：Бизнес-шлюз Маршрутизаторы устраняют эти машины,Эти машины можно устранить с помощью компонентов Обнаружение служб мониторинга.,Может быть автоматически устранено путем мониторинга ошибок。
• шлюз Авария в компьютерном зале：Бизнес-шлюзмаршрутизация Пучок Вина set из Балансировка трафика переключается на другой нормальный из установлено, что можно автоматически устранить путем мониторинга ошибок.
• шлюз Город Вина：Бизнес-шлюзмаршрутизация Пучок Вина Городиз set Сбалансированный переход к нормальному состоянию Городиз Теоретически можно добиться и автоматического исключения, но эта операция относительно тяжелая и требует тщательной оценки. Рекомендуется резать вручную.

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

Стратегия перехода на более раннюю версию

Бизнес-шлюз Есть и другие ответы Винаиз Понизить версиюплан,Если в случае общего сбоя системы,,Может Справься с этим таким образом Понизить версию：

• Обеспечьте высокое качество запросов при переходе на более раннюю версию：позволятьшлюзотличный先Пучокресурспоставлять Давать P0 Важное командное слово, другие интерфейсы будут отклонены.
• предотвращение лавин：Разрешить шлюз в крайних случаях,Выполнять случайные сбросы запросов,Чтобы избежать общего схода лавины Служитьиз.

-End-

Автор оригинала｜Хуан Наньцзюй