Этот браузер больше не поддерживается.
Выполните обновление до Microsoft Edge, чтобы воспользоваться новейшими функциями, обновлениями для системы безопасности и технической поддержкой.
В этой статье представлен ключевой шаблон для критически важных архитектур в Azure. Примените этот шаблон при запуске процесса проектирования, а затем выберите компоненты, которые лучше всего подходят для ваших бизнес-требований. В этой статье рекомендуется использовать подход к проектированию на севере star и другие примеры с общими технологическими компонентами.
Рекомендуется оценить ключевые области проектирования, определить важные потоки пользователей и системы, использующие базовые компоненты, и разработать матрицу ресурсов Azure и их конфигурации, учитывая следующие характеристики.
| Характеристика | Рекомендации |
|---|---|
| Время существования | Каково ожидаемое время существования ресурса относительно других ресурсов в решении? Должен ли ресурс перелистать или использовать время существования для всей системы или региона, или он должен быть временным? |
| Состояние | Какое влияние будет оказывать сохраняемое состояние на этом уровне на надежность или управляемость? |
| Охват | Требуется ли глобальное распределение ресурса? Может ли ресурс взаимодействовать с другими ресурсами, расположенными глобально или в пределах этого региона? |
| Зависимости | Каковы зависимости от других ресурсов? |
| Ограничения масштабирования | Какова ожидаемая пропускная способность для этого ресурса? Какой масштаб предоставляется ресурсом в соответствии с потребностями? |
| Доступность и аварийное восстановление | Каково влияние на доступность в результате аварии на этом уровне? Вызовет ли это системный сбой или только локализованную проблему емкости или доступности? |
Важно!
Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected . Если вы не знакомы с этой серией, рекомендуем начать с критически важной рабочей нагрузки?
Некоторые ресурсы глобально совместно используются ресурсами, развернутыми в каждом регионе. Распространенными примерами являются ресурсы, которые используются для распределения трафика между несколькими регионами, хранения постоянного состояния для всего приложения и отслеживания ресурсов для них.
| Характеристика | Рекомендации |
|---|---|
| Время существования | Ожидается, что эти ресурсы будут долгоживущей (неэфемерной). Их время существования охватывает или более длительный срок службы системы. Часто ресурсы управляются с помощью обновлений данных на месте и уровня управления, предполагая, что они поддерживают операции обновления без простоя. |
| Состояние | Поскольку эти ресурсы существуют по крайней мере на протяжении всего времени существования системы, этот уровень часто отвечает за хранение глобального геореплицированного состояния. |
| Охват | Ресурсы должны быть глобально распределены и реплицированы в регионы, в которых размещаются эти ресурсы. Рекомендуется, чтобы эти ресурсы взаимодействовали с региональными или другими ресурсами с низкой задержкой и требуемой согласованностью. |
| Зависимости | Ресурсы должны избегать зависимостей от региональных ресурсов, так как их недоступность может быть причиной глобального сбоя. Например, сертификаты или секреты, хранящиеся в одном хранилище, могут иметь глобальное влияние, если произошел сбой в регионе, где находится хранилище. |
| Ограничения масштабирования | Часто эти ресурсы являются одноэлементными экземплярами в системе, и они должны иметь возможность масштабироваться таким образом, чтобы они могли обрабатывать пропускную способность системы в целом. |
| Доступность и аварийное восстановление | Региональные ресурсы и ресурсы меток могут использовать глобальные ресурсы. Очень важно, чтобы глобальные ресурсы были настроены с высоким уровнем доступности и аварийного восстановления для работоспособности всей системы. |
Метка содержит приложение и ресурсы, участвующие в выполнении бизнес-транзакций. Метка обычно соответствует развертыванию в регионе Azure. Хотя регион может иметь несколько меток.
| Характеристика | Рекомендации |
|---|---|
| Время существования | Ожидается, что ресурсы будут иметь короткий (временный) жизненный цикл с намерением динамически добавлять и удаляться, пока региональные ресурсы за пределами метки продолжают сохраняться. Эфемерный характер необходим для обеспечения большей устойчивости, масштабирования и близости к пользователям. |
| Состояние | Так как метки являются временными и будут уничтожаться при каждом развертывании, метка должна быть как можно больше без отслеживания состояния. |
| Охват | Может взаимодействовать с региональными и глобальными ресурсами. Однако следует избегать взаимодействия с другими регионами или другими метками. |
| Зависимости | Ресурсы меток должны быть независимыми. Ожидается, что они имеют региональные и глобальные зависимости, но не должны полагаться на компоненты в других метках в том же или других регионах. |
| Ограничения масштабирования | Пропускная способность устанавливается путем тестирования. Пропускная способность общей метки ограничена ресурсом с наименьшей производительности. Пропускная способность метки должна оценить высокий уровень спроса, вызванный отработкой отказа на другую метку. |
| Доступность и аварийное восстановление | Из-за временного характера меток аварийное восстановление выполняется путем повторного развертывания метки. Если ресурсы находятся в неработоспособном состоянии, метку в целом можно уничтожить и повторно развернуть. |
В системе могут быть развернуты ресурсы, развернутые в регионе, но не имеющие ресурсов метки. Например, ресурсы наблюдаемости, которые отслеживают ресурсы на региональном уровне, включая метки.
| Характеристика | Оценка |
|---|---|
| Время существования | Ресурсы совместно используют время существования региона, а ресурсы метки — в реальном времени. |
| Состояние | Состояние, хранящееся в регионе, не может превышать время существования региона. Если необходимо совместное использование состояния между регионами, рассмотрите возможность использования глобального хранилища данных. |
| Охват | Ресурсы не должны быть глобально распределены. Прямой связи с другими регионами следует избегать любой ценой. |
| Зависимости | Ресурсы могут зависеть от глобальных ресурсов, но не от ресурсов меток, так как метки должны быть короткими. |
| Ограничения масштабирования | Определите предел масштаба региональных ресурсов путем объединения всех меток в регионе. |
Эти базовые примеры служат рекомендуемой архитектурой северного star для критически важных приложений. В базовом плане настоятельно рекомендуется контейнеризация и использование оркестратора контейнеров для платформы приложений. Базовый план использует Служба Azure Kubernetes (AKS).
См. раздел Хорошо спроектированные критически важные рабочие нагрузки: контейнеризация.
Если вы только начинаете критически важный путь, используйте эту архитектуру в качестве справки. Доступ к рабочей нагрузке осуществляется через общедоступную конечную точку и не требует подключения к частной сети к другим ресурсам компании.
Эта архитектура основана на базовой архитектуре. Эта конструкция расширена, чтобы обеспечить строгие сетевые элементы управления, чтобы предотвратить несанкционированный общий доступ из Интернета к ресурсам рабочей нагрузки.
Эта архитектура подходит, если вы развертываете рабочую нагрузку в корпоративной среде, где требуется интеграция в более широкой организации. Рабочая нагрузка использует централизованные общие службы, нуждается в локальном подключении и интегрируется с другими рабочими нагрузками на предприятии. Он развертывается в подписке целевой зоны Azure, которая наследуется от группы управления Corp.
Эта архитектура расширяет базовые показатели, рассматривая Службы приложений в качестве основной технологии размещения приложений, обеспечивая простую в использовании среду для развертываний контейнеров.
Мы рекомендуем использовать предоставленные рекомендации по проектированию, чтобы перейти к ключевым решениям по проектированию, чтобы достичь оптимального решения. Дополнительные сведения см . в разделе Основные области проектирования?
Ознакомьтесь с рекомендациями по проектированию критически важных сценариев приложений.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по