Backand-1 Flashcards
Backand-1
Что такое клиент-серверная архитектура?
Представляет собой модель взаимодействия между программными компонентами, где один компонент (клиент) обращается к другому компоненту (серверу) для получения данных .
Что такое клиент?
Клиент – это устройство или приложение, которое отправляет запросы на сервер для получения данных или выполнения определенной задачи. Клиент может быть написан на разных языках программирования и работать на разных устройствах.
Что такое сервер?
Сервер предоставляет данные или услуги клиенту. Он обрабатывает запросы, выполняет определенные функции и отправляет обратно ответы на запросы клиенту. Сервер обычно работает на мощном выделенном оборудовании и имеет специальное программное обеспечение для обработки запросов.
Приведи примеры клиентов
Клиенты в клиент-серверной архитектуре представляют собой программные компоненты или устройства, которые обращаются к серверам для получения данных или услуг. Рассмотрим несколько примеров клиентов в различных областях.
Веб-браузеры: Браузеры, такие как Google Chrome, Mozilla Firefox, Safari и другие, являются клиентами, которые обращаются к веб-серверам для загрузки веб-страниц, изображений, файлов стилей и другого контента.
Postman - это популярный инструмент для тестирования API. Также является клиентом, так как запрашивает данные с сервера.
Swagger - то же самое, как и с постманом, но сваггер - это документация для API, предоставляемая разработчиками.
Что такое API?
API - это сокращение от Application Programming Interface (интерфейс прикладного программирования). Это набор определенных правил, протоколов и инструментов, которые позволяют различным программным приложениям взаимодействовать между собой. API определяет способы, с помощью которых приложения могут отправлять запросы друг к другу для получения данных или выполнения определенных операций. Это позволяет разным системам обмениваться информацией и функциональностью без необходимости раскрытия своей внутренней реализации.
Некоторые из основных правил общения, которые могут быть частью API
API определяет набор правил и инструкций, которые определяют способы взаимодействия между разными программами или компонентами программного обеспечения. . Рассмотрим некоторые из основных правил общения, которые могут быть частью API.
Форматы данных:
Определение того, какие форматы данных используются для запросов и ответов. Например, данные могут передаваться в формате JSON, XML. В будущем мы поговорим об этом подробнее.
Методы запросов:
Указание доступных действий или операций, которые можно выполнить с помощью API. Например, GET для получения данных, POST для отправки данных на сервер, PUT для обновления существующих данных и DELETE для удаления. В будущем мы поговорим об этом подробнее.
Аутентификация и безопасность:
Правила для защиты доступа к API, такие как использование токенов, ключей доступа, аутентификации по паролю или другим методам, чтобы только разрешенные пользователи могли использовать API и его функциональность.
Описание эндпоинтов:
Эндпоинты - это конечные точки в API, определяющие конкретные адреса или URL, по которым можно отправлять запросы для выполнения определенных действий или получения определенных данных.
Документация и справочные материалы(Swagger):
API часто сопровождаются документацией, объясняющей, как использовать его функции, как формировать запросы и как обрабатывать ответы.
Что такое эндпоинты?
Эндпоинты - это конечные точки в API, определяющие конкретные адреса или URL, по которым можно отправлять запросы для выполнения определенных действий или получения определенных данных.
Что такое HTTP?
Это протокол передачи данных, который используется для обмена информацией между клиентами и серверами в сети Интернет.
Что такое монолитная архитектура?
Монолитная архитектура — это традиционная модель программного обеспечения, которая представляет собой единый модуль, работающий автономно и независимо от других приложений.
Преимущества и недостатки монолитной архитектуры?
Преимущества монолитной архитектуры
1. Простое развертывание. Использование одного исполняемого файла или каталога упрощает развертывание.
2. Разработка. Приложение легче разрабатывать, когда оно создано с использованием одной базы кода.
3. Производительность. В централизованной базе кода и репозитории один интерфейс API часто может выполнять ту функцию, которую при работе с микросервисами выполняют многочисленные API.
4. Упрощенное тестирование. Монолитное приложение представляет собой единый централизованный модуль, поэтому сквозное тестирование можно проводить быстрее, чем при использовании распределенного приложения.
5. Удобная отладка. Весь код находится в одном месте, благодаря чему становится легче выполнять запросы и находить проблемы.
Недостатки монолитной архитектуры
1. Снижение скорости разработки. Большое монолитное приложение усложняет и замедляет разработку.
2. Масштабируемость. Невозможно масштабировать отдельные компоненты.
3. Надежность. Ошибка в одном модуле может повлиять на доступность всего приложения.
4. Препятствия для внедрения технологий. Любые изменения в инфраструктуре или языке разработки влияют на приложение целиком, что зачастую приводит к увеличению стоимости и временных затрат.
5. Недостаточная гибкость. Возможности монолитных приложений ограничены используемыми технологиями.
6. Развертывание. При внесении небольшого изменения потребуется повторное развертывание всего монолитного приложения.
Что такое микросервисная архитектура?
Микросервисная архитектура (или просто микросервисы) представляет собой метод организации архитектуры, основанный на ряде независимо развертываемых служб. У этих служб есть собственная бизнес-логика и база данных с конкретной целью. Обновление, тестирование, развертывание и масштабирование выполняются внутри каждой службы. Микросервисы разбивают крупные задачи, характерные для конкретного бизнеса, на несколько независимых баз кода.
Преимущества и недостатки микросервисной архитектуры?
Преимущества микросервисов
1. Гибкость. Продвигайте гибкие методы работы среди небольших команд, которые регулярно выполняют развертывание.
2. Гибкое масштабирование. Когда микросервис достигает предельной нагрузки, можно быстро выполнить развертывание новых экземпляров данной службы в сопутствующем кластере и снизить нагрузку. Теперь мы работаем с несколькими держателями и без сохранения состояния, а клиенты распределены по различным экземплярам. С таким подходом мы можем поддерживать экземпляры гораздо большего размера.
3. Непрерывное развертывание. Теперь у нас есть регулярные и ускоренные циклы релиза. Раньше мы выпускали обновления раз в неделю, а теперь можем делать это примерно два-три раза в день.
4. Легкость обслуживания и тестирования. Команды могут экспериментировать с новыми функциями и возвращаться к предыдущей версии, если что-то не работает. Это упрощает обновление кода и ускоряет выпуск новых функций на рынок. Кроме того, в отдельных службах легко находить и исправлять ошибки и баги.
5. Независимое развертывание. Микросервисы представляют собой отдельные модули, поэтому с ними можно легко и быстро выполнять независимое развертывание отдельных функций.
6. Гибкость технологий. При использовании архитектуры микросервисов команды могут выбирать инструменты с учетом своих предпочтений.
7. Высокая надежность. Развертывая изменения для конкретной службы, можно не бояться, что приложение выйдет из строя целиком.
Недостатки микросервисов
1. Разрастание процесса разработки. Микросервисы усложняют работу по сравнению с монолитной архитектурой, поскольку в различных местах возникает все больше служб, созданных несколькими командами. Если разрастание не контролируется должным образом, оно приводит к замедлению разработки и снижению операционной эффективности.
2. Экспоненциальный рост расходов на инфраструктуру. У каждого нового микросервиса может быть своя стоимость комплекта тестов, инструкций по развертыванию, инфраструктуры хостинга, инструментов мониторинга и т. д.
3. Дополнительные организационные расходы. Командам требуется дополнительный уровень коммуникации и сотрудничества, чтобы координировать работу над обновлениями и интерфейсами.
4. Проблемы при отладке. У каждого микросервиса свой набор журналов, что усложняет отладку. Кроме того, дополнительные затруднения могут возникать в том случае, когда один бизнес-процесс выполняется на нескольких машинах.
5. Отсутствие стандартизации. Без общей платформы может возникнуть ситуация, в которой расширяется список языков, стандартов ведения журналов и средств мониторинга.
6. Отсутствие ясности в вопросах владения. По мере появления новых служб увеличивается и количество работающих над ними команд. Со временем становится сложнее определить, какие службы команда может использовать и к кому следует обращаться за поддержкой.
