Дизайн-системы: введение
Резюме: Дизайн-система — это набор стандартов для полномасштабного управления дизайном за счет сокращения избыточных элементов, предполагающий создание общего языка и визуального единообразия на разных страницах и каналах коммуникации.
По мере того, как развивался дизайн пользовательского интерфейса, масштаб и скорость создания интерфейсов также увеличивалась. В настоящее время не только существуют миллионы приложений и миллиарды веб-сайтов (и каждый год это количество растет), но и каждое из этих приложений и любой из веб-сайтов могут иметь сотни или тысячи страниц (или экранов). В связи с таким резким ростом в данной сфере у организаций возникла острая необходимость упростить процесс дизайна. Поэтому многие команды дизайнеров используют надежные дизайн-системы для полномасштабного управления дизайн-проектами.
Определение: Дизайн-система — это полный набор стандартов, предназначенных для полномасштабного управления дизайном с применением повторно используемых компонентов и паттернов.
Зачем использовать дизайн-систему?
При правильном внедрении дизайн-системы могут принести команде дизайнеров множество преимуществ:
- Результаты дизайна (и разработки) могут быть быстро созданы и воспроизведены в любом масштабе. Основным преимуществом дизайн-систем является их способность быстро воспроизводить дизайн за счет использования готовых компонентов и элементов пользовательского интерфейса. Команды могут продолжать использовать одни и те же элементы снова и снова, что сокращает необходимость изобретать велосипед и тем самым рисковать получить дизайн с отсутствием единообразия.
- Дизайн-системы снижают нагрузку на дизайнеров и позволяют им сфокусироваться на более крупных и сложных проблемах. Поскольку более простые элементы пользовательского интерфейса уже созданы и могут использоваться повторно, дизайнеры имеют возможность меньше сосредотачиваться на улучшении внешнего вида и больше на сложных проблемах (например, расположение информации в приоритетном порядке, оптимизация рабочего процесса и управление движением пользователя по сайту).
Хотя выгода от использования дизайн-систем может показаться небольшой, когда вы создаете лишь несколько экранов, она становится существенной, когда вы должны координировать усилия десятков команд в отношении тысяч экранов. - Дизайн-системы создают единый язык внутри многофункциональных команд и между ними. Единый язык сокращает затраты времени на дизайн и разработку из-за недопониманий, особенно когда перераспределяется ответственность в процессе дизайна или когда команды территориально рассредоточены. Например, отпадает необходимость обсуждать функциональные возможности или внешний вид выпадающего меню (dropdown menu), поскольку этот термин уже зарезервирован для конкретного элемента в дизайн-системе.
- Дизайн-системы создают визуальное единообразие для разных продуктов, каналов коммуникации и (потенциально разрозненных) частей компании. В частности, когда команды работают несогласованно, а каждый продукт или канал коммуникации функционирует независимо от других, отсутствие дизайн-системы в масштабах организации целиком может привести к отсутствию единообразия во внешнем виде и опыте, который будет казаться разрозненным или не связанным с брендом.
- Дизайн-системы могут служить учебным пособием и справочником для младших дизайнеров и начинающих авторов контента. Четко написанные правила использования элементов и руководства по стилю помогают ввести в курс дела отдельных участников процесса, которые только начинают заниматься дизайном пользовательского интерфейса или созданием контента. Такие правила также служат напоминанием для остальных участников.
Почему не использовать дизайн-систему?
Существуют некоторые потенциальные препятствия и ограничения, которые могут помешать команде дизайнеров использовать дизайн-систему:
- Создание и поддержание дизайн-системы — это длительный процесс, требующий выделения специальной команды. К сожалению, дизайн-системы — это не то решение, которое создается раз и навсегда. В идеале они должны постоянно развиваться на основе обратной связи, собранной командой от тех, кто их использует.
- Требуется время, чтобы научить людей пользоваться дизайн-системой.
В случае с любой дизайн-системой, даже если она была адаптирована из уже существующей, необходимы инструкции по ее использованию. В противном случае существует риск того, что она будет применяться непоследовательно или неправильно на разных экранах или разными командами. - Может сложиться впечатление, что проекты являются статичными, одноразовыми творениями, для которых не требуется внедрение многоразовых компонентов. Правда это или нет, но такое восприятие может сигнализировать об отсутствии единой стратегии реализации проектов и упущенной возможности повысить эффективность работы.
Элементы дизайн-системы
В дизайн-системе есть две важные части:
- дизайн-репозиторий
- люди, которые им управляют
Репозиторий дизайн-системы
Дизайн-репозиторий может принимать различные формы, но зачастую он включает руководство по стилю (style guide), библиотеку компонентов и библиотеку паттернов.
Руководство по стилю (style guide)
Руководства по стилю содержат конкретные рекомендации по имплементации компонентов, изображения с примерами использования и принципы дизайна для создания интерфейсов и иных дизайн-материалов. Наиболее стандартные руководства по стилю, как правило, фокусируются на брендинге (цвет, типографика, товарные знаки, логотипы и печатные материалы), но они также предлагают рекомендации относительно контента (например, тон голоса и используемый язык), а также содержат стандарты визуального дизайна и дизайна взаимодействия (еще известные как фронтенд-руководства по стилю). Эти рекомендации иногда включаются в библиотеку компонентов, чтобы дать соответствующие подсказки в контексте.
Краткость желательна для ускорения коммуникации, особенно в отношении водителей транспортных средств.”Руководство по стилю контента Mailchimp содержит подробные рекомендации о том, как писать различные виды контента, чтобы они соответствовали ценностям компании и тону голоса.Библиотека компонентов
Библиотека компонентов (также известная как дизайн-библиотека) — это как раз то, что многие люди ассоциируют с дизайн-системами: подробные библиотеки содержат заранее определенные элементы пользовательского интерфейса, пригодные для многократного использования. Они служат универсальным источником информации для дизайнеров и разработчиков, которые могут изучать и использовать конкретные элементы. Создание таких библиотек требует значительного времени и ресурсов. Кроме примеров того, как выглядят компоненты, они включают:
- Название компонента: конкретное и уникальное имя компонента пользовательского интерфейса, которое позволяет избежать недопонимания между дизайнерами и разработчиками
- Описание: четкое объяснение того, что это за элемент и как он обычно используется, иногда для лучшего понимания сопровождается рекомендациями о том, как стоит или не стоит использовать компонент
- Атрибуты: параметры, которые могут быть изменены с целью кастомизации или адаптации компонента к конкретным потребностям (например, цвет, размер, форма, текст)
- Состояние: рекомендуемые значения по умолчанию и последующие изменения внешнего вида компонента
- Фрагменты кода: реальный отрывок кода для элемента (некоторые дизайн-системы даже включают несколько примеров и “песочницу” — специальную программную среду, в которой можно опробовать различные настройки компонентов)
- Фронтенд и бэкенд фреймворки для реализации библиотеки (при необходимости), чтобы избежать мучительной излишней коррекции
Дизайн-система IBM Carbon включает рекомендации по использованию, стилю, коду, а также советы относительно доступности и “песочницу” для дизайнеров и разработчиков, позволяющую визуализировать любые настройки элементов перед их реализацией.
Библиотека паттернов
Иногда термины “библиотека компонентов” и “библиотека шаблонов” используются как синонимы, однако эти типы библиотек различаются. Библиотеки компонентов включают отдельные элементы пользовательского интерфейса, а библиотеки паттернов содержат коллекции раскладок страниц (layouts) или примеры группировки этих элементов. Библиотеки паттернов часто считаются менее эффективными, чем библиотеки компонентов, но они могут быть настолько детальными и высокоуровневыми, насколько это необходимо. Обычно они содержат типы структуры контента, раскладки и шаблоны. Как и компоненты, паттерны предназначены для многоразового использования и адаптации.
Дизайн-система Atlassian определяет ряд паттернов для многократного использования, включая шаблон хедера страницы.
Она не просто содержит пример того, как он должен выглядеть, но и выделяет конкретные компоненты, которые должны использовать дизайнеры, а также объясняет, как именно следует использовать каждый из них.
Хотя многим веб-сайтам государственного сектора предстоит еще много работы, US Web Design System (USDWS) является отличной отправной точкой для объединения множества разрозненных отделов и агентств на основе четких руководящих принципов. USDWS включает шаблоны страниц (показаны выше), а также дизайн-принципы, компоненты и спецификации для написания кода.
Команда дизайн-системы
Эффективность дизайн-системы определяется эффективностью команды, которая ей управляет. Созданные или адаптированные дизайн-системы требуют постоянного обслуживания и контроля, чтобы не устареть или не переполнится избыточными элементами и материалами. Численность соответствующей команды может варьироваться, поскольку сами дизайн-системы могут иметь разные размеры и уровни настройки, но, как минимум, в такую команду должны входить 1 дизайнер взаимодействия, 1 дизайнер, отвечающий за визуал, и 1 разработчик, которые будут помогать писать руководства по дизайну взаимодействия, создавать визуальные примеры, а также фрагменты кода и спецификации для реализации элементов.
В идеале в команду также должны входить исследователь, архитектор информационных систем (занятые неполный рабочий день) и автор контента, если эти роли явно определены в вашей организации.
И, наконец, подумайте о том, чтобы нанять исполнительного спонсора (из числа руководителей) для управления разработкой дизайн-системы. Хотя его отсутствие не станет препятствием, спонсоры могут обеспечить деньги и ресурсы, а также донести стратегическую важность создания дизайн-системы до остальных членов организации.
Как подойти к внедрению дизайн-системы
Существует три подхода к использованию дизайн-системы:
- использование существующей дизайн-системы
- адаптация существующей дизайн-системы
- создание собственной кастомной дизайн-системы
У каждого подхода есть плюсы и минусы, но, в целом, чем более индивидуализированную дизайн-систему вы хотите, тем больше времени и денег потребуется для ее реализации. Поэтому использование уже существующей дизайн-системы — это самый дешевый подход, который требует наименьшего времени для осуществления.
(Однако вам все равно придется потратить больше времени, чем в случае, если вы бы продолжили делать дизайн как обычно, потому что вам необходимо будет либо заменить, либо обновить некоторые элементы пользовательского интерфейса, а также согласовать стандарты.)
Инвестиции в кастомную дизайн-систему окупятся, если у организации имеются особые потребности, которые невозможно удовлетворить с помощью дизайн-систем из открытых источников. По мере увеличения количества настроек и изменений в дизайн-системе, объем сэкономленных средств от использования существующей дизайн-системы будет сокращаться, и , в конце концов, наиболее выгодным вариантом для вас может стать создание собственной дизайн-системы. Убедитесь, что вы знаете, что именно нужно вашей организации, прежде чем приступить к разработке дизайн-системы и оцените возможные компромиссы.
Наконец, в случае необходимости проверки концепции или тестирования первоначального прототипа, который, скорее всего, будет меняться, создание полноценной дизайн-системы, вероятно, не окупится быстро. В конце концов, преимущество заключается в возможности воспроизводить дизайн, которая может быть оценена только в будущем. Помните, что дизайн-систему следует рассматривать не как портфолио работ, а как функциональный инструмент или ресурс, позволяющий дизайнерам и разработчикам быстрее выполнять свою работу. Тем не менее, если вы сомневаетесь в полезности дизайн-системы, возможно, стоит подумать о временной шкале, которую вы будете использовать для оценки эффективности дизайнерской деятельности. Дизайн-системы лучше всего себя проявляют в ситуациях, когда компания нацелена на годы серьезной работы в будущем, требующей воспроизведения своего дизайна.
Заключение
Дизайн-системы состоят из множества компонентов, паттернов, стилей и руководящих принципов, которые могут помочь в осуществлении и оптимизации дизайнерской деятельности.
Впрочем, они разрабатываются, управляются и внедряются людьми. Основными факторами, которые следует учитывать при создании дизайн-системы, являются масштаб и воспроизводимость ваших проектов, а также доступные ресурсы и время. В случае плохой реализации и поддержки дизайн-системы могут превратиться в громоздкие коллекции компонентов и кода, но при правильном подходе они могут выступать в качестве инструмента обучения членов команды, помогают оптимизировать работу и позволяют дизайнерам решать сложные UX-проблемы.
Самые популярные дизайн-системы, на которых стоит учиться UX-дизайнерам в 2022 году
Дизайн-системы • 13 июля 2022 г.
Список из 10-ти лучших систем, созданных компаниями с передовым опытом. На эти дизайн-системы вы можете ориентироваться в своих дизайнах.
Читайте нас в Telegram.
За последние несколько лет масштабы и скорость дизайна интерфейсов значительно выросли.
Существуют миллионы мобильных и веб-приложений, и эти приложения могут иметь сотни и тысячи экранов. Нам нужны дизайн-системы для масштабного управления дизайном и оптимизации процесса.
В этой статье я хочу поговорить о дизайн-системах. Поскольку компании во всем мире продолжают инвестировать в цифровую трансформацию, они обнаруживают, что им нужно сократить время создания новых продуктов. Дизайн-система — это один из ресурсов, который помогает сделать это эффективно.
Что такое дизайн-системы?
Работая над этой статьей, я искал в интернете точное и простое определение, но нашел лишь несколько расплывчатых концепций. Похоже, все зависит от того, кого вы спрашиваете.
Ниже привожу два определения, которые показались мне наиболее подходящими:
«Полный набор стандартов проектирования, документации и принципов, а также набор инструментов (UI-шаблоны и компоненты кода) для достижения этих стандартов».
Источник: uxpin.com
«Дизайн-системы — это, по сути, наборы правил и ограничений, реализованных в дизайне и коде.
Эти атрибуты выполняют разные функции и обеспечивают согласованную систему во всем — от кнопок до одностраничных приложений».
Источник: medium.muz.li
Таким образом, дизайн-системы — это наборы стандартов для управления дизайном в масштабе. Они сокращают избыточность и обеспечивают согласованность.
1. Material Design
Это просто клад для простых, элегантных шаблонов дизайна и руководств по стилю. Разработано Google.
https://material.io/2. Fluent Design System
Дизайна-система Fluent, разработанная Microsoft.
https://www.microsoft.com/design/fluent/#/3. Atlassian
Язык дизайна для создания простых, интуитивно понятных и красивых интерфейсов.
https://www.atlassian.com/4. Polaris
Полярис от Shopify. Он объединяет рабочий процесс дизайнера и разработчика.
https://polaris.shopify.com/5. Human Interface Guidelines
Подробная информация и UI ресурсы для разработки отличных приложений, которые легко интегрируются с платформами Apple.
6. Дизайн-система Carbon
Carbon — это система проектирования IBM с открытым исходным кодом для продуктов и цифрового опыта.
https://www.carbondesignsystem.com/7. Mailchimp
Забавная и яркая дизайн-система Mailchimp.
https://ux.mailchimp.com/8. Ауди
Пользовательские интерфейсы от Audi.
https://www.audi.com/ci/en/guides/user-interface/introduction.html#9. Дизайн-система Airbnb
Разработано и поддерживается Airbnb.
https://airbnb.design/10. Дизайн-система Lightning
Готовые к использованию HTML- и CSS-элементы пользовательского интерфейса обеспечивают основу для разработки Salesforce.
https://www.lightningdesignsystem.com/Какие уроки вы можете извлечь, используя дизайн-системы? Предположим, вы разрабатываете сайт электронной коммерции с выпадающим меню для категорий. Не знаете, какого размера должна быть стрелка раскрывающегося списка или как далеко от текста она должна располагаться? Это легко можно уточнить, взглянув на эксперта в области системы покупок, вроде Shopify.
- Дизайн-системы
Присоединяйтесь к нашему сообществу!
Получайте новости об обновлении программных продуктов, редизайнов, ребрендингов, а также множество полезных статей для начинающих дизайнеро раньше всех в нашем телеграм канале.
Подписаться на телеграм канал
Изучение основ проектирования систем
Главная/Блог/Учебное пособие по проектированию систем: изучение основ проектирования систем
28 января 2021 г. — чтение 8 мин. и данные для системы, которая удовлетворяет определенным требованиям. После того, как у вас есть требования к вашей системе, следующим шагом будет преобразование их в технические спецификации , чтобы вы могли построить свою систему.
Здесь на помощь приходит системный дизайн. Системный дизайн дает вам техническое решение, отвечающее вашим требованиям.
Проектирование системы — это итеративный процесс, поэтому в итоге вы можете получить несколько проектов, которые будут соответствовать системным требованиям.
Проектирование систем — обширная тема. У всех разный подход к этому, так как нет пошаговых инструкций. В этой статье мы рассмотрим основы, чтобы дать вам представление о том, что это такое и как это работает.
Мы рассмотрим следующее:
- Что такое проектирование системы?
- Шаг 1: уточнение требований
- Шаг 2: Оценка важных частей
- Шаг 3: поток данных
- Шаг 4: Высокоуровневое проектирование компонентов
- Шаг 5: Рабочий проект
- Шаг 6. Определите и устраните узкие места
- Следующие шаги по проектированию системы
Узнайте о современном системном проектировании
Узнайте, как масштабируемые системы проектируются в реальном мире. Овладейте строительными блоками современного системного дизайна.
Grokking Современный системный дизайн для инженеров-программистов и менеджеров
Что такое системный дизайн?
Проектирование систем — это процесс определения архитектуры, интерфейсов и данных для системы, удовлетворяющей определенным требованиям. Дизайн системы должен удовлетворять конкретные потребности бизнеса или организации посредством согласованной, хорошо работающей системы.
После того, как у вас есть требования, вы изучаете и преобразовываете их в физический проект системы, отвечающий потребностям клиентов. Деятельность по проектированию будет варьироваться в зависимости от того, будете ли вы заниматься индивидуальной разработкой, коммерческими решениями или комбинацией того и другого.
Проектирование систем требует систематического подхода к построению и проектированию системы. Хороший дизайн системы требует, чтобы инженеры думали обо всем в инфраструктуре, от аппаратного и программного обеспечения до данных и способов их хранения.
Проектирование системы включает следующие методы проектирования:
- Архитектурное проектирование: описывает виды, модели, поведение и инфраструктуру системы.
- Логический дизайн: представляет поток данных и входы/выходы системы.
- Физический дизайн: включает то, как пользователи могут добавлять информацию, как система представляет информацию пользователям и как данные моделируются/хранятся.
Различные типы систем
Существуют различные методы, которые можно использовать для удовлетворения требований вашей системы к масштабируемости, надежности, безопасности, производительности и согласованности.
Горизонтальное масштабирование
При горизонтальном масштабировании вы добавляете дополнительные машины параллельно, чтобы справиться с растущими требованиями. Вам понадобится балансировка нагрузки, чтобы распределить нагрузку по системе. Если какой-либо компьютер выходит из строя, запросы перенаправляются на другие компьютеры, и он хорошо масштабируется при увеличении количества пользователей.
Несогласованность данных является недостатком.
Вертикальное масштабирование
Вертикальное масштабирование использует одну огромную машину, которая обрабатывает все ваши запросы и улучшает время отклика и пропускную способность. Хотя он предлагает более быстрые сетевые вызовы, согласованность данных и отсутствие балансировки нагрузки, у вас есть единая точка отказа и аппаратные ограничения.
Приложения Monolith
Это одноуровневые приложения с различными компонентами на одной платформе. Они хороши для небольших команд, поскольку они несложны, не имеют дублирования и имеют более быстрые вызовы процедур. Несмотря на это, их может быть трудно поддерживать, если они становятся слишком большими или сложными.
Микросервисы
Микросервисы позволяют разрабатывать программные системы с однофункциональными модулями, имеющими четко определенные интерфейсы и операции. Они легко тестируются и ремонтопригодны, их можно развертывать независимо. Микросервисы более сложны и требуют культурных изменений в организациях, которые их внедряют.
Шаг 1. Уточнение требований
Это важный шаг, поскольку вам нужно сузить круг до конкретной цели, чтобы не усложнять ситуацию. Уточнение вашей цели помогает сосредоточиться на основных функциях, устранить любые неясности и выявить потенциальные узкие места. Мы можем разделить наши требования на две части:
Функциональные требования
Функциональные требования — это требования, которые должна выполнять система. Это основные цели системы. Функциональные требования включают в себя такие вещи, как бизнес-правила, аутентификация, административные функции, уровни авторизации и т. д.
Нефункциональные требования
Нефункциональные требования ограничивают проектирование системы посредством различных качеств. Их нужно анализировать, и если они не выполняются, они могут навредить бизнес-плану или целям. К нефункциональным требованиям относятся производительность, безопасность, надежность, масштабируемость, ремонтопригодность, доступность и т.
Возьмем Twitter, некоторые функциональных требований могут включать:
- Пользователи должны иметь возможность публиковать новые твиты
- Пользователи должны иметь возможность подписаться на другого пользователя
- Пользователи должны иметь возможность отмечать твиты как избранные
Нефункциональные требования
- Высокая доступность
- Консистенция
- Задержка около 200 мс для генерации временной шкалы
Это некоторые основные требования, которые можно дополнительно расширить, включив в них поиск, ответы на твиты, отметку пользователей, уведомления, актуальные темы и т. д.
Шаг 2: Оценка важных частей
Этот шаг касается масштаба вашей системы. Способ измерения зависит от вашей системы. Вы должны помнить о таких параметрах, как количество запросов в секунду и данные, которые система должна будет обрабатывать.
Для Twitter нам нужно будет учитывать такие параметры, как объем памяти, оценка пропускной способности, общее количество просмотров твитов и т. д. Допустим, у нас около 200 миллионов активных пользователей в день, сто миллионов новых твитов, и каждый пользователь следит примерно за 200 людьми. .
Хранилище
Предположим, что каждый твит состоит из 140 символов, требуется два байта для хранения символа без сжатия и еще 30 байт для хранения метаданных, общее необходимое хранилище будет примерно:
100x(280+30)=30 ГБ/день100x (280+30)= 30ГБ/день100x(280+30)=30ГБ/день
Оценочная пропускная способность
Вход
(100 М/5 фото ∗200 КБ)+(100 М / 10 видео * 2 МБ) = 24 ТБ в день (100 М / 5 фото * 200 КБ) + (100 М / 10 видео * 2 МБ) ~= 24 ТБ/день (100 М/5 фото * 200 КБ) +(100 М/10 видео∗2 МБ) = 24 ТБ в день
Выход
У нас 28 млрд твитов в день, нам нужно показать каждую картинку, но если пользователь видит только каждое третье видео на своей временной шкале, выход будет:
(28Б*280байт)/86400softext=>93MB /s(28B * 280 байт) / 86400s текста => 93MB/s(28B*280bytes)/86400softext=>93MB/s
+(28B/5∗200KB)/86400sofphotos=>13GB/S+ (28B/5 * 200КБ) / 86400s фотографий => 13ГБ/с+(28Б/5∗200КБ)/86400sofphotos=>13ГБ/с
+(28Б/10/3∗2МБ)/86400sofVideos=>22ГБ/с+ (28Б/10/ 3 * 2 МБ) / 86400 видео => 22 ГБ/с + (28 Б/10/3*2 МБ)/86 400 видео => 22 ГБ/с
Всего = 35 ГБ/с.
Всего ~= 35 ГБ/с. Всего = 35 ГБ/с. :
200MDAU∗((2+5)∗20твитов)=>28B/день200M DAU * ((2 + 5) * 20 твитов) => 28B/день200MDAU*((2+5)∗20твитов)=>28B/ день
Продолжайте учиться.
Изучите проектирование системы, не просматривая видео или документацию. Текстовые курсы Educative легко просматриваются и включают живую среду кодирования, что делает обучение быстрым и эффективным.
Grokking Современный системный дизайн для инженеров-программистов и менеджеров
Шаг 3. Поток данных
Это касается модели данных системы и того, как данные будут передаваться между различными компонентами. Выбор системы базы данных также является частью этого. Вы можете выбрать между этими тремя:
1. Реляционные базы данных: Реляционные базы данных хранят данные в виде таблиц, связанных друг с другом в виде первичных и внешних ключей. Это хороший выбор, если:
- Вы создаете первую версию своей системы и не совсем уверены в шаблонах доступа к данным
- Вы хотите поддерживать нулевую избыточность данных.
2. Базы данных NoSQL:
3. Базы данных графов: Базы данных графов — хорошая идея, когда у вас много отношений «многие ко многим».
Возможная схема базы данных для Twitter может быть следующей:
Шаг 4. Проектирование компонентов высокого уровня
Вы не можете спроектировать всю систему за один раз. Вот почему мы разделили его на основные компоненты высокого уровня, а затем на детальный проект, основанный на требованиях. На этом этапе вы делаете набросок основных компонентов вашей системы и того, как они связаны, пока не вдавайтесь в подробности.
Основываясь на наших оценках для Twitter, нам понадобится система, способная справиться со всей этой нагрузкой при эффективном хранении.
Этап 5: Рабочий проект
Теперь, когда вы определили основные компоненты, пришло время углубиться в них. Вы хотите начать с анализа различных подходов к решению данной проблемы и плюсов и минусов каждого потенциального решения.
На этом этапе также важно провести
- Сколько данных нам нужно кэшировать, чтобы ускорить время отклика?
- Где нам нужно использовать балансировщик нагрузки?
- Нужно ли разделять данные для распределения по нескольким базам данных?
6. Шаг 6. Выявление и устранение узких мест
После завершения детального проектирования следующим шагом является определение узких мест в системе и их устранение. Узкие места могут включать в себя трафик, данные, хранилище, доступность, избыточность, резервное копирование и т. д.
Некоторые вопросы, которые следует рассмотреть на этом этапе:
- Есть ли в этой системе единая точка отказа? Как нам это удалить?
- Достаточно ли у вас реплик данных для обслуживания пользователя на случай потери нескольких серверов?
- Достаточно ли у нас копий наших служб, чтобы предотвратить отключение?
Дальнейшие действия по проектированию системы
Вот и все! Очень упрощенное руководство по проектированию системы.
Помните, что ваш дизайн должен быть простым, все не всегда будет идти по вашему сценарию, поэтому вам, возможно, придется вернуться и внести некоторые изменения на ходу.
Следующие темы рекомендуются в качестве следующего шага для понимания конструкции системы:
- Ознакомьтесь с практическими примерами проектирования систем
- Основы микросервисов
- Основы проектирования баз данных
Если вы заинтересованы в дальнейшем изучении этого вопроса, ознакомьтесь с комплексным курсом Educative Grokking Modern System Design for Software Engineers & Managers . Этот курс охватывает все важные концепции веб-приложений, микросервисов и архитектуры AWS, а также практическую среду кодирования и многое другое.
Приятного обучения!
Продолжить чтение о проектировании системы
- Полное руководство по проектированию системы в 2022 году
- Современный системный дизайн Grokking для инженеров-программистов и менеджеров
- Микросервисы в Azure: введение
- Руководство по проектированию баз данных
НАПИСАЛ: Марьям Сулемани
Присоединяйтесь к сообществу, насчитывающему более 1,7 миллиона читателей.
Бесплатное электронное письмо раз в два месяца с обзором лучших статей и советов по программированию на сайте Educative.
Все, что вам нужно для начала работы
Одно дело понять, как работает микроархитектура, и совсем другое — построить и реализовать ее. Вот почему мы хотим сосредоточиться на различных технологиях, доступных вам для всей системы микросервисов. Давайте рассмотрим несколько различных технологических стеков, шаблонов и дизайнов для создания исполняемой микросервисной архитектуры.
Решения по микро- и макроархитектуре
Желательно разделить вашу архитектуру на микро- и макроархитектуру. микроархитектура включает в себя все решения, принятые для каждой микрослужбы. Макроархитектура включает в себя все решения, принимаемые на глобальном уровне, которые применяются ко всем микросервисам.
Можно расширить понятие микро- и макроархитектуры до технических решений. Технические решения могут приниматься в рамках макро- или микроархитектуры.
Например, взгляните на технические решения, которые необходимо принять на микро- и макроуровнях для базы данных:
Micro: Каждая микрослужба может иметь собственный экземпляр базы данных. Если бы базы данных были определены в микроархитектуре, сбой одной базы данных приведет только к сбою одного микросервиса. Это делает все приложение более надежным.
Макрос: База данных также может быть определена как часть макроархитектуры. Несколько микросервисов не должны использовать одну и ту же схему базы данных.
Автономные системы
Автономная система (SCS) — это тип микросервисной архитектуры, определяющий элементы макроархитектуры. Это означает, что они не представляют всю систему. Поскольку SCS является автономным, он предоставляет все необходимое для реализации одной части доменной логики, например, данные журнала и пользовательский интерфейс. SCS также имеют необязательный API.
Например, SCS для оплаты микроуслуг будет хранить информацию, относящуюся к этому платежу, в виде ограниченного контекста. Также будет реализован пользовательский интерфейс для отображения истории платежей, а данные о клиентах будут реплицироваться из других SCS.
Думайте об этом как о сборнике лучших практик; SCS предоставляют точные правила, основанные на установленных шаблонах, предлагая точку отсчета для построения микросервисной архитектуры. Все эти правила гарантируют, что SCS реализует домен, поэтому добавленная функция изменяет только одну SCS.
Мы можем думать о SCS как о микросервисной архитектуре, поскольку ее можно развернуть независимо и разделить систему на независимые веб-приложения. На самом деле одну СКС можно даже разбить на несколько микросервисов. Они отличаются от микросервисов тремя основными моментами: они крупнее микросервисов; они сосредоточены на слабой связанности; у них должен быть пользовательский интерфейс.
Интеграция с внешним интерфейсом
Микросервисы также могут быть интегрированы с веб-интерфейсом.
Разделение внешнего интерфейса на разные модули помогает решить некоторые проблемы, связанные с обращением с ним как с монолитом. Модульный интерфейс состоит из отдельно развертываемых микросервисов. Это может принести много преимуществ вашему интерфейсу.
Например, модульный интерфейс может иметь независимую логику домена, а изменение домена можно реализовать, просто изменив только один микросервис. Чтобы объединить отдельные интерфейсы, они должны быть интегрированы, поэтому необходима система интеграции.
Этого можно добиться с помощью ссылок, когда один интерфейс отображает ссылку, которую другой интерфейс читает и обрабатывает. Это также может быть достигнуто с помощью перенаправлений, например, как OAuth3 обрабатывает интеграцию с интерфейсом. Перенаправления сочетают передачу данных с интеграцией с внешним интерфейсом.
Однако есть несколько исключений, когда внешний интерфейс следует развертывать как монолит. Например, нативные мобильные приложения должны быть монолитами развертывания или если за разработку интерфейса отвечает отдельная команда.
Асинхронные микрослужбы
Синхронные микрослужбы делают запрос к другим микрослужбам во время обработки запросов и ожидания результатов. Протоколы асинхронной связи отправляют сообщения, на которые получатели реагируют, но прямого ответа нет. Микрослужбу можно определить как асинхронную, если она не отправляет запросы к другим микрослужбам во время обработки или отправляет запросы, но не ожидает результатов.
Асинхронные микросервисы предлагают несколько заметных преимуществ по сравнению с синхронными микросервисами и решают многие проблемы распределенных систем. Логика, необходимая для обработки запросов микросервисов, не зависит от результатов, что делает их гораздо более независимыми.
Точно так же, если партнер по связи выходит из строя, это не приводит к сбою всей системы, обеспечивая общую устойчивость вашей системы. Кроме того, обработка и доставка почти всегда гарантированы.
Некоторыми распространенными примерами технологий для асинхронных микросервисов являются Kafka (MOM, обычно используемый для обмена сообщениями), REST и формат данных Atom (для дополнительной инфраструктуры).
