🖥 Модель TCP/IP: Краткий обзор и сравнение с OSI

Модель TCP/IP — это стек протоколов, которые задают правила передачи данных по сети (локальной(LAN), корпоративной, Интернет и пр.).

Основой являются протоколы TCP и IP. На них построен весь Интернет:

🕹 TCP (Transmission Control Protocol)—управляет отправкой данных и следит, чтобы они были гарантированно приняты получателем.

🔗 IP (Internet Protocol) —отвечает за адресацию: выделяет IP-адреса устройств, связывает устройства друг с другом, нарезает данные на пакеты для удобной отправки, строит маршруты доставки пакетов

📶 Уровни модели TCP/IP

4️⃣ Прикладной (Application)
Протоколы: HTTP, SMTP (Simple Mail Transfer Protocol).
Здесь находятся приложения, предоставляющие сетевые службы. Протоколы обеспечивают взаимодействие между программами на удаленных компьютерах.

3️⃣ Транспортный (Transport)
Протоколы: TCP, UDP (User Datagram Protocol)
Отвечает за надежную передачу данных между устройствами. TCP обеспечивает управление потоком и надежность, UDP — более быструю, но менее надежную передачу.

2️⃣ Сетевой (Internet)
Протоколы: IP, ICMP (Internet Control Message Protocol).
Управляет передачей данных между узлами в сети. IP обеспечивает маршрутизацию, ICMP используется для диагностики и сообщений об ошибках.

1️⃣ Канальный (Link)
Протоколы: Ethernet, Wi-Fi.
Тут происходит организация физического соединения между устройствами в пределах одной сети. Эти протоколы работают с физическими адресами (MAC-адресами) устройств.

⚙️ Процесс работы TCP/IP

▫️Перед отправкой данные разбиваются на пакеты
▫️Каждый пакет получает IP-адрес (уникальный идентификатор устройства в сети), который указывает на конечный пункт назначения.
▫️На транспортном уровне TCP следит за тем, чтобы все пакеты дошли без потерь и в правильном порядке. Также управляет потоком данных, предотвращая перегрузку сети.
▫️На сетевом уровне (IP), каждый пакет получает информацию о том, какие узлы (маршруты) нужно использовать для достижения конечного пункта.
▫️На канальном уровне (например, Ethernet), каждый пакет получает физический адрес (MAC-адрес) для доставки пакета на устройство в пределах сети.
▫️Пакеты отправляются в сеть, проходят через различные маршрутизаторы и коммутаторы, следуя указанным путям.
▫️По достижению конечного устройства, они собираются в правильном порядке и восстанавливают данные.

🛜Применение TCP/IP

🔹Интернет: TCP/IP - фундаментальный стек протоколов. Каждое устройство, подключенное к интернету использует IP-адрес и коммуницирует посредством TCP или UDP.
🔹Локальные сети: Часто используется в локальных сетях офисов и домов. Это обеспечивает согласованное взаимодействие между компьютерами.
🔹Коммуникация между приложениями: Протоколы прикладного уровня, такие как HTTP для веб-сервисов, FTP - передачи файлов и SMTP - почты, работают поверх TCP/IP.

🛠Модель TCP/IP vs OSI

Обе модели описывают архитектуру сетевых взаимосвязей.
OSI имеет более подробное разделение сетевых функций по уровням, см картинку
▪️Применение
OSI: Используется в обучении и теории, но редко применяется на практике.
TCP/IP: Широко применяется в реальных сетях, включая интернет.
▪️Управление потоком данных:
OSI: Уровень сеансов и транспортный уровень могут управлять потоком данных.
TCP/IP: Управление потоком осуществляется только на транспортном уровне (TCP).
▪️Сетевые протоколы:
OSI: Протоколы, определенные на каждом уровне, не всегда вписываются в четкую структуру. Например, отдельные уровни для сеансов, представления и прикладного уровня.
TCP/IP: Протоколы тесно связаны с каждым уровнем, что делает их более интегрированными.

⭐️ Подборки материалов по этой и другим темам доступны в закрытом каналезакрытом канале

#сети

Ищем крутых системных аналитиков в свою команду!
Предлагаем sign-in бонус и возможность выиграть AirPods и IPhone. А еще топовые проекты, удаленку, конкурентную зарплату и расширенный соцпакет.

Интересует? Тогда участвуй в Hiring month от компании Aston.

До 15 июня отправляй свое резюме по ссылке. Там же можно узнать подробнее о вакансиях и проектах.

Что по бонусам?
AirPods Pro 2nd Generation разыграем среди каждых 50 резюме от системных аналитиков;
IPhone 15 ProMax разыграем среди всех системных аналитиков, которые участвуют в Hiring month;
Sign-in бонус до 150К руб. гросс получишь после старта на проекте.

А конкурентная зарплата, расширенный соцпакет, интересные проекты и возможность работать удаленно — это бонусы, которыми пользуется каждый сотрудник компании Aston. Кроме того, у нас действует прозрачная система Performance Review и повышения зарплаты. Также доплачиваем за участие в дополнительных активностях, помогаем учиться и развиваться.

Присоединяйся к нашей команде. Будем расти вместе!

Реклама. ООО "Астон" ИНН 9715350151. Erid: 2VtzqwWiU9Q

🧪 Требования ACID: Краткий обзор

ACID (Atomicity, Consistency, Isolation, Durability) — набор характеристик, обеспечивающих надежность транзакций в базах данных.

Транзакция в БД — логическая операция, состоящая из одного/нескольких запросов, которые выполняются как единое целое.

💩💩Атомарность: Транзакция рассматривается как "неделимая" единица работы. Транзакция либо полностью выполняется, либо вообще не выполняется. Нет промежуточных состояний.

💩Согласованность: Транзакция должна переводить базу данных из одного согласованного состояния в другое (например, в каждом столбце значения имеют нужный тип данных, сохранена ссылочная целостность, операции выполнены по порядку). Если БД была в согласованном состоянии до транзакции, она должна остаться такой и после.

💩Изолированность: Другие транзакции не должны видеть промежуточных результатов текущей транзакции. Каждая транзакция должна быть изолирована от других: ее выполнение не должно влиять на другие транзакции.

💩💩Долговечность (надёжность): После успешного завершения транзакции изменения в БД должны сохраняться даже в случае сбоев системы. Данные, внесенные в БД, должны быть долговечными.

Когда применяется ACID:
✅ В финансовых, банковских, бухгалтерских приложениях, где точность данных является критически важной точность данных является критически важной
✅ В системах управления заказами и инвентарем, управления ресурсами (таких как авиабилеты, номера номеров и т.д.)

ACID не актуальны, когда:
➖ производительность имеет большее значение, чем полная гарантия целостности данных
➖ часто выполняются параллельные операции и где допустимы некоторые компромиссы в обмен на повышенную производительность
➖ данные имеют низкую ценность или могут быть легко восстановлены
➖ данные имеют высокую степень избыточности или дублирования.

ACID в реляционных/нереляционных СУБД

🔹Большинство традиционных реляционных БД поддерживают требования ACID

🔸В распределенных БД связанные данные находятся на нескольких узлах. Транзакции в NoSQL затруднены и в большинстве СУБД требования ACID не удовлетворяются. Но некоторые NoSQL СУБД (например, графовая Neo4j и документоориентированная MarkLogic) могут обеспечивать свойства ACID.

Пример

Пусть есть БД с информацией о банковских счетах Алисы и Боба. Рассмотрим две транзакции:
➕Перевод денег: Боб переводит Алисе 100$ со своего счета.
🔻Покупка печенек: Алиса покупает на 50$ со своей банковской карты.
У Алисы изначально 0 на счету. У Боба 110$

Применение ACID гарантирует:
💩А: Покупка печенек завершится ошибкой т.к баланс 0$, деньги не будут списаны. Отмена всей транзакции.
💩💩С: После обеих транзакций у Алисы должно остаться 50$ (0 + 100 - 50), а у Боба 10$. Операции выполнены в правильном порядке. Данные по клиентам корректно отражены
💩💩I: Если покупка происходит в то время, когда перевод еще не завершился, в БД не появится несогласованных данных. Блокировки и версионирование в БД изолируют транзакции во избежание путаницы в значениях.
💩💩D: Если обе транзакции завершились успешно, изменения (перевод и покупка) будут сохранены в базе данных даже в случае сбоев системы.

Как связаны ACID и CAP-теорема

Это две разные концепции, касающиеся транзакций в распределенных системах. Они не противоречат друг другу.
💩Цель ACID — обеспечить надежность в транзакционных БД , где данные обрабатываются в рамках централизованнойцентрализованной системы.
💩CAP-теорема рассматривается там, где система распределенараспределена между несколькими узлами, что создает потенциальные проблемы согласованности и доступности.

🔹🔹 Подробнее про CAP-теорему в нашем посте

⭐️ Подборки материалов по этой и другим темам доступны в закрытом каналезакрытом канале

#бд

Репост:

🪧Методы трассировки требований

Трассировка требований — процесс отслеживания и документирования связей между требованиями различного уровня абстракции (бизнес-требования, пользовательские требования, системные требования).

Трассировка требований позволяет:
1️⃣ Обеспечить соответствие функциональности системы исходным бизнес-требованиям
2️⃣ Отслеживать изменения требований на протяжении всего жизненного цикла разработки
3️⃣ Управлять изменениями: позволяет оценить влияние изменений требований на другие артефакты и всю систему в целом
4️⃣ Упрощает тестирование: позволяет покрыть бизнес-требования тест-кейсами и не упустить важное

Для обеспечения прослеживаемости каждое требование должно уникальным образом идентифицироваться, например, иметь ID.
Каждая версия требования должна быть прослеживаема, т.к изменение неизбежны и нужно ими управлять.

Помимо ID, требования могут иметь следующие атрибуты:
💩статус
💩дата создания
💩версия
💩автор
💩владелец
💩приоритет
💩источник
💩обоснование
💩релиз
💩контактное лицо или ответственный за принятие решений по внесению изменений в требование
💩критерии приёмки

Виды трассировки

↕️Вертикальная—связи между высокоуровневыми элементами проекта ( бизнес-требованиями) и низкоуровневыми (техническими требованиями или кодом)
↔️Горизонтальная—связи между элементами одного уровня. Например, трассировка между функциональными требованиями или между разными компонентами архитектуры системы.

✏️ Методы трассировки требований

💫💫 Матрица трассировки (Requirements Traceability Matrix)

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

Примеры возможных связей
—Один к одному: один элемент дизайна реализуется в одном модуле кода;
—Один ко многим: одно функциональное требование (ФТ) проверяется множеством тест-кейсов;
—Многие ко многим:  общие или повторяющиеся элементы дизайна могут удовлетворять нескольким ФТ. На практике данным видом трассировки сложно и трудно управлять

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

💫💫 Дерево требований

Структурированное дерево, показывающее иерархию требований от общих к более детальным.

Пример
Техническое требование
—> Архитектурное требование
——>Требование к БД
——>Требование к интерфейсу

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


Плюсы и минусы трассировки

➕➕Четкое представление о требованиях к системе и их взаимосвязях
➕➕Отслеживание изменений требований

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

#требования

▶▶ Способы асинхронного взаимодействия в API

Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.

Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.

Зачем это нужно
👩‍🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑‍🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨‍🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер


Способы асинхронного взаимодействия в API

1⃣1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ ПримерПример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис

2⃣2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡  ПримерПример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса

3⃣3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡  ПримерПример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ

4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу

5⃣5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот


⭐️ Подборка материалов доступна в закрытом каналезакрытом канале

#интеграции #async

Репост:

Git. Обзор и подборка материалов

В связи всё более широким распространением подхода Docs as Code самое время изучить Git.

GitGit — это система контроля версий, которая помогает отслеживать изменения в проекте. Этот инструмент можно использовать как для индивидуальной, так и для командной работы.

Git позволяет:
💩Хранить историю изменений проекта. Git может определить, кто и в какой момент внёс изменения.
💩Параллельно работать над файлами. Все изменения затем сливаются воедино.
💩Откатиться к предыдущим версиям проекта, если что-то пойдёт не так.

Принцип работы Git

1️⃣Разработчик создаёт свою ветку от главного проекта, куда вносит свои изменения
2️⃣В своей ветке разработчик делает необходимые изменения в коде или документации, которые затем фиксируются в истории изменений.
3️⃣После того как работа в ветке завершена, разработчик сохраняет изменения, создавая коммиты. Коммиты отражают историю изменений и могут быть просмотрены в любой момент.
4️⃣Слияние изменений. Когда изменения готовы, создаётся Merge Request, чтобы влить изменения в мастер-ветку. До этого момента все изменения всё ещё находятся в отдельной ветке проекта. После слияния с мастер-веткой изменения вступают в силу для всего проекта.
5️⃣Контроль версий Git позволяет отслеживать все изменения, предоставляя возможность возвращения к любому предыдущему состоянию проекта, если это необходимо.


Курсы (бесплатные)

1. «Основы работы с Git» от Яндекс.Практикума. 16 часов обучения, свободный график, теория и тесты для самопроверки, поддержка специалистов, электронное свидетельство о прохождении курса, доступ после авторизации через Яндекс ID
2. Git для начинающих от Слёрм. Доступ придет на указанную почту после регистрации, закрытый Telegram-чат, теория и практические задания, без сертификата
3. Введение в Git от Хекслет. Видеоуроки, лекции, тренажеры с практикой, бессрочный доступ к теории, асинхронный формат обучения, без сертификата, доступ после регистрации
4. Основы Git из Степика. Много практики
5. Git. Базовый курс от GeekBrains. 13 видеоуроков, без сертификата, доступ после записи

⏯⏯ Видосы с Ютуба
1. GIT - Полный Курс Git и GitHub Для Начинающих — одно видео на 4 часа полного погружения
2. Что такое Git для Начинающих — GitHub за 30 минут
3. Уроки по Git и GitHub от ITDoctor
4. Базовый курс по Git от Devcolibri

🕹 Интерактивные гайды на русском
1. Git How To — это интерактивный тур, который познакомит с основами Git
2. LearnGitBranching — веб-приложение по интерактивному погружению в Git

📄 Полезные статьи
1. Что такое GitHub и как он работает
2. Как начать работать с GitHub: быстрый старт
3. Про стратегии ветвления в Гите
4. 19 советов по повседневной работе с Git
5. Как настроить работу с Git в Intellij IDEA

✍️ Шпаргалка по командам Git

📖 Книга
Pro Git — основное чтиво по гиту от Скотта Чакона и Бена Штрауба

#подборка

Event Driven Architecture: краткий обзор

Event-Driven Architecture (EDA) — архитектурный подход, при котором система строится вокруг событий.

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


Компоненты EDA
💩 Событие – любое изменение состояния некой сущности или возникновение новой.
💩Производитель события – сервис, который создаёт событие.
💩Обработчик события – сервис, который получает событие и обрабатывает его, после чего порождается новое событие – результат обработки события.
💩Маршрутизатор события – промежуточный слой, который обеспечивает. доставку события от производителя до обработчика. Обычно это брокер сообщений.

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


Модели доставки событий в EDA

1⃣Pub/Sub
1. Производители генерируют события и отправляют брокеру.
2. Брокер направляет события потребителям, которые на них подписались.
3. После отправки события удаляются.
ПримерПример – RabbitMQ.

2⃣Потоковая передача
1. Производители генерируют события и отправляют брокеру.
2. Брокер сохраняет события у себя в журнале.
3. Потребители считывают события из любой части журнала в любой момент времени. События не удаляются брокером.
ПримерПример – Kafka.


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

✅ Преимущества EDA

➕Слабая связность и гибкость: можно масштабировать, обновлять и развертывать сервисы независимо друг от друга.

➕➕Скорость: в EDA каждое событие может быть обработано независимо, что позволяет системе использовать параллельную обработку. А ещё можно эффективнее распределять нагрузку между обработчиками событий с учётом текущей загруженности узлов.

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


⛔️ Недостатки EDA

💩💩Сложность разработки и тестирования вследствие распределённой архитектуры и асинхронного взаимодействия.

💩💩Отсутствие транзакционности. Поскольку компоненты обработчика событий сильно разобщены и распределены, очень трудно поддерживать транзакции между ними. Если нужно разделить один шаг процесса работы между обработчиками событий, то есть вы используете отдельные обработчики событий для чего-то, что должно быть неделимой транзакцией — вероятно, EDA тут не подходит.

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

💩💩Дополнительные затраты на инфраструктуру. Реализация EDA требует больше производительности вычислительных ресурсов, нужно больше хранилищ данных, растут расходы на поддержку и управление инфраструктурой.


⭐️ Подборка материалов доступна в закрытом каналезакрытом канале

#архитектура #проектирование