День 2369. #SystemDesign101
Шардинг Баз Данных
Шардинг (или шардирование) — это разделение хранилища на несколько независимых частей, шардов (от англ. shard — осколок). Не путайте шардирование с репликацией, в случае которой выделенные экземпляры базы данных являются не составными частями общего хранилища, а копиями друг друга.
Виды
1. По диапазону
Разделение данных на основе диапазонов определённых значений, например, деление информации о товарах в зависимости от их ценового диапазона.
2. По ключу
Работает на основе использования уникального значения, например идентификатора пользователя, в качестве входных данных для хэш-функции. Хэш-функция вычисляет выходное значение, которое используется для определения сервера, на котором должны храниться данные.
3. По директории
Предполагает наличие таблицы поиска, в которой используется ключ шарда для отслеживания того, в каком шарде хранятся те или иные данные. Подход позволяет более гибко добавлять или удалять серверы, а также изменять схему сегментирования, не влияя на работу остальной части приложения.
Источники:
- https://blog.bytebytego.com/p/a-guide-to-database-sharding-key
- https://habr.com/ru/companies/piter/articles/813133/
Шардинг Баз Данных
Шардинг (или шардирование) — это разделение хранилища на несколько независимых частей, шардов (от англ. shard — осколок). Не путайте шардирование с репликацией, в случае которой выделенные экземпляры базы данных являются не составными частями общего хранилища, а копиями друг друга.
Виды
1. По диапазону
Разделение данных на основе диапазонов определённых значений, например, деление информации о товарах в зависимости от их ценового диапазона.
2. По ключу
Работает на основе использования уникального значения, например идентификатора пользователя, в качестве входных данных для хэш-функции. Хэш-функция вычисляет выходное значение, которое используется для определения сервера, на котором должны храниться данные.
3. По директории
Предполагает наличие таблицы поиска, в которой используется ключ шарда для отслеживания того, в каком шарде хранятся те или иные данные. Подход позволяет более гибко добавлять или удалять серверы, а также изменять схему сегментирования, не влияя на работу остальной части приложения.
Источники:
- https://blog.bytebytego.com/p/a-guide-to-database-sharding-key
- https://habr.com/ru/companies/piter/articles/813133/
1👍15
День 2395. #SystemDesign101
Как Работает SSO?
Технология единого входа (Single Sign-On SSO) — технология, позволяющая пользователю аутентифицироваться один раз, чтобы получить доступ ко множеству связанных сервисов или приложений, без необходимости повторно вводить свои учётные данные для каждого из них.
Рассмотрим типичный процесс входа в SSO.
Шаг 1: Пользователь запрашивает защищённый ресурс в приложении, например, Gmail, которое является провайдером сервиса (Service Provider, SP).
Шаг 2: Сервер Gmail обнаруживает, что пользователь не вошёл в систему, и перенаправляет браузер к провайдеру идентификации (Identity Provider, IdP) компании с запросом на аутентификацию.
Шаг 3: Браузер перенаправляет пользователя к IdP.
Шаг 4: IdP отображает страницу входа, где пользователь вводит свои учётные данные.
Шаг 5: IdP создаёт защищённый токен и возвращает его браузеру. IdP также создаёт сессию для будущего доступа. Браузер перенаправляет токен в Gmail.
Шаг 6: Gmail проверяет токен, чтобы убедиться, что он получен от провайдера идентификации.
Шаг 7: Gmail возвращает защищённые ресурсы в браузер в зависимости от того, к чему пользователю разрешён доступ.
На этом процесс входа с помощью SSO завершается. Теперь посмотрим, что произойдёт, когда пользователь перейдёт в другое приложение с интегрированной системой единого входа, например, в Slack.
Шаги 8-9: Пользователь заходит в Slack, и сервер Slack обнаруживает, что он не вошёл в систему. Slack перенаправляет браузер к провайдеру идентификации с новым запросом на аутентификацию.
Шаг 10: Браузер перенаправляет пользователя к провайдеру идентификации.
Шаги 11-13: Поскольку пользователь уже вошёл в систему провайдера идентификации, процесс входа пропускается и сразу создаётся новый токен для Slack. Новый токен отправляется в браузер, который перенаправляет его в Slack.
Шаг 14–15: Slack проверяет токен и предоставляет пользователю соответствующий доступ.
Источник: https://blog.bytebytego.com/
Как Работает SSO?
Технология единого входа (Single Sign-On SSO) — технология, позволяющая пользователю аутентифицироваться один раз, чтобы получить доступ ко множеству связанных сервисов или приложений, без необходимости повторно вводить свои учётные данные для каждого из них.
Рассмотрим типичный процесс входа в SSO.
Шаг 1: Пользователь запрашивает защищённый ресурс в приложении, например, Gmail, которое является провайдером сервиса (Service Provider, SP).
Шаг 2: Сервер Gmail обнаруживает, что пользователь не вошёл в систему, и перенаправляет браузер к провайдеру идентификации (Identity Provider, IdP) компании с запросом на аутентификацию.
Шаг 3: Браузер перенаправляет пользователя к IdP.
Шаг 4: IdP отображает страницу входа, где пользователь вводит свои учётные данные.
Шаг 5: IdP создаёт защищённый токен и возвращает его браузеру. IdP также создаёт сессию для будущего доступа. Браузер перенаправляет токен в Gmail.
Шаг 6: Gmail проверяет токен, чтобы убедиться, что он получен от провайдера идентификации.
Шаг 7: Gmail возвращает защищённые ресурсы в браузер в зависимости от того, к чему пользователю разрешён доступ.
На этом процесс входа с помощью SSO завершается. Теперь посмотрим, что произойдёт, когда пользователь перейдёт в другое приложение с интегрированной системой единого входа, например, в Slack.
Шаги 8-9: Пользователь заходит в Slack, и сервер Slack обнаруживает, что он не вошёл в систему. Slack перенаправляет браузер к провайдеру идентификации с новым запросом на аутентификацию.
Шаг 10: Браузер перенаправляет пользователя к провайдеру идентификации.
Шаги 11-13: Поскольку пользователь уже вошёл в систему провайдера идентификации, процесс входа пропускается и сразу создаётся новый токен для Slack. Новый токен отправляется в браузер, который перенаправляет его в Slack.
Шаг 14–15: Slack проверяет токен и предоставляет пользователю соответствующий доступ.
Источник: https://blog.bytebytego.com/
👍20
День 2411. #SystemDesign101 #Testing
9 Видов Тестирования API
1. Дымовое (Smoke) тестирование
Проводится после завершения разработки API. Просто проверяется работоспособность API и отсутствие сбоев.
2. Функциональное тестирование
Составление плана тестирования на основе функциональных требований и сравнение результатов с ожидаемыми.
3. Интеграционное тестирование
Тестирование объединяет несколько вызовов API для выполнения сквозных тестов. Тестируются внутрисервисные коммуникации и передача данных.
4. Регрессионное тестирование
Тестирование гарантирует, что исправления ошибок или новые функции не нарушат текущее поведение API.
5. Нагрузочное тестирование
Тестирование производительности приложений путем моделирования различных нагрузок. Затем мы можем рассчитать пропускную способность приложения.
6. Стресс-тестирование
Мы намеренно создаем высокие нагрузки на API и проверяем его работоспособность.
7. Тестирование безопасности
Тестирование API на предмет всех возможных внешних угроз.
8. Тестирование пользовательского интерфейса
Тестирование взаимодействия пользовательского интерфейса с API для обеспечения корректного отображения данных.
9. Фаззинг-тестирование
Этот метод внедряет недействительные или неожиданные входные данные в API и пытается вызвать сбой в его работе. Таким образом, выявляются уязвимости API.
Источник: https://blog.bytebytego.com/
9 Видов Тестирования API
1. Дымовое (Smoke) тестирование
Проводится после завершения разработки API. Просто проверяется работоспособность API и отсутствие сбоев.
2. Функциональное тестирование
Составление плана тестирования на основе функциональных требований и сравнение результатов с ожидаемыми.
3. Интеграционное тестирование
Тестирование объединяет несколько вызовов API для выполнения сквозных тестов. Тестируются внутрисервисные коммуникации и передача данных.
4. Регрессионное тестирование
Тестирование гарантирует, что исправления ошибок или новые функции не нарушат текущее поведение API.
5. Нагрузочное тестирование
Тестирование производительности приложений путем моделирования различных нагрузок. Затем мы можем рассчитать пропускную способность приложения.
6. Стресс-тестирование
Мы намеренно создаем высокие нагрузки на API и проверяем его работоспособность.
7. Тестирование безопасности
Тестирование API на предмет всех возможных внешних угроз.
8. Тестирование пользовательского интерфейса
Тестирование взаимодействия пользовательского интерфейса с API для обеспечения корректного отображения данных.
9. Фаззинг-тестирование
Этот метод внедряет недействительные или неожиданные входные данные в API и пытается вызвать сбой в его работе. Таким образом, выявляются уязвимости API.
Источник: https://blog.bytebytego.com/
👍10
День 2419. #SystemDesign101 #Docker
9 Рекомендаций по Docker, Которые Стоит Знать
1. Используйте официальные образы
Это обеспечивает безопасность, надежность и регулярные обновления.
2. Используйте конкретную версию образа
Тег по умолчанию (latest) непредсказуем и приводит к непредвиденному поведению.
3. Многоэтапные сборки
Уменьшает размер конечного образа за счет исключения инструментов сборки и зависимостей.
4. Используйте .dockerignore
Исключает ненужные файлы, ускоряет сборку и уменьшает размер образа.
5. Используйте пользователя с минимальными привилегиями
Повышает безопасность за счёт ограничения привилегий контейнера.
6. Используйте переменные окружения
Повышает гибкость и переносимость в различных средах.
7. Упорядочивайте задачи для кэширования
Упорядочивайте шаги от наименее к наиболее часто изменяемым для оптимизации кэширования.
8. Маркируйте образы
Это улучшает организацию и помогает в управлении образами.
9. Сканируйте образы
Находите уязвимости безопасности, прежде чем они станут серьезными проблемами.
Источник: https://blog.bytebytego.com
9 Рекомендаций по Docker, Которые Стоит Знать
1. Используйте официальные образы
Это обеспечивает безопасность, надежность и регулярные обновления.
2. Используйте конкретную версию образа
Тег по умолчанию (latest) непредсказуем и приводит к непредвиденному поведению.
3. Многоэтапные сборки
Уменьшает размер конечного образа за счет исключения инструментов сборки и зависимостей.
4. Используйте .dockerignore
Исключает ненужные файлы, ускоряет сборку и уменьшает размер образа.
5. Используйте пользователя с минимальными привилегиями
Повышает безопасность за счёт ограничения привилегий контейнера.
6. Используйте переменные окружения
Повышает гибкость и переносимость в различных средах.
7. Упорядочивайте задачи для кэширования
Упорядочивайте шаги от наименее к наиболее часто изменяемым для оптимизации кэширования.
8. Маркируйте образы
Это улучшает организацию и помогает в управлении образами.
9. Сканируйте образы
Находите уязвимости безопасности, прежде чем они станут серьезными проблемами.
Источник: https://blog.bytebytego.com
👍14
День 2433. #SystemDesign101 #Microservices
Как Выглядит Типичная Микросервисная Архитектура?
Балансировщик нагрузки: устройство или приложение, которое распределяет сетевой или прикладной трафик между несколькими серверами.
CDN (Сеть Доставки Контента): группа географически распределённых серверов, которые обеспечивают быструю доставку статического и динамического контента. С CDN пользователям не нужно загружать контент (музыку, видео, файлы, изображения и т. д.) с исходного сервера. Вместо этого контент кэшируется на узлах CDN по всему миру, и пользователи могут загружать его с ближайших узлов CDN.
API-шлюз: обрабатывает входящие запросы и направляет их соответствующим сервисам. Он взаимодействует с провайдером идентификации и выполняет обнаружение сервисов. См. подробнее.
Провайдер идентификации: отвечает за аутентификацию и авторизацию пользователей.
Регистрация и обнаружение сервисов (Service Registry и Service Discovery): Service Registry — это база данных, которая хранит информацию о сервисах и их экземплярах, а Service Discovery — это механизм, использующий этот реестр для автоматического обнаружения, регистрации и отслеживания доступности сервисов в распределенной системе, что особенно важно для микросервисных архитектур, где сервисы могут динамически масштабироваться. API-шлюз ищет соответствующие сервисы в этом компоненте для взаимодействия с ними.
Менеджмент: этот компонент отвечает за мониторинг сервисов.
Микросервисы: микросервисы разрабатываются и развёртываются в разных доменах. Каждый домен имеет свою собственную базу данных. API-шлюз взаимодействует с микросервисами через REST API или другие протоколы, а микросервисы в пределах одного домена взаимодействуют друг с другом с помощью RPC (удалённого вызова процедур).
Преимущества микросервисов
- Их можно быстро проектировать, развёртывать и горизонтально масштабировать.
- Каждый домен может независимо поддерживаться выделенной командой.
- Бизнес-требования можно настраивать в каждом домене, что обеспечивает лучшую поддержку.
Источник: https://blog.bytebytego.com
Как Выглядит Типичная Микросервисная Архитектура?
Балансировщик нагрузки: устройство или приложение, которое распределяет сетевой или прикладной трафик между несколькими серверами.
CDN (Сеть Доставки Контента): группа географически распределённых серверов, которые обеспечивают быструю доставку статического и динамического контента. С CDN пользователям не нужно загружать контент (музыку, видео, файлы, изображения и т. д.) с исходного сервера. Вместо этого контент кэшируется на узлах CDN по всему миру, и пользователи могут загружать его с ближайших узлов CDN.
API-шлюз: обрабатывает входящие запросы и направляет их соответствующим сервисам. Он взаимодействует с провайдером идентификации и выполняет обнаружение сервисов. См. подробнее.
Провайдер идентификации: отвечает за аутентификацию и авторизацию пользователей.
Регистрация и обнаружение сервисов (Service Registry и Service Discovery): Service Registry — это база данных, которая хранит информацию о сервисах и их экземплярах, а Service Discovery — это механизм, использующий этот реестр для автоматического обнаружения, регистрации и отслеживания доступности сервисов в распределенной системе, что особенно важно для микросервисных архитектур, где сервисы могут динамически масштабироваться. API-шлюз ищет соответствующие сервисы в этом компоненте для взаимодействия с ними.
Менеджмент: этот компонент отвечает за мониторинг сервисов.
Микросервисы: микросервисы разрабатываются и развёртываются в разных доменах. Каждый домен имеет свою собственную базу данных. API-шлюз взаимодействует с микросервисами через REST API или другие протоколы, а микросервисы в пределах одного домена взаимодействуют друг с другом с помощью RPC (удалённого вызова процедур).
Преимущества микросервисов
- Их можно быстро проектировать, развёртывать и горизонтально масштабировать.
- Каждый домен может независимо поддерживаться выделенной командой.
- Бизнес-требования можно настраивать в каждом домене, что обеспечивает лучшую поддержку.
Источник: https://blog.bytebytego.com
👍8