Explore

System Design

Grokking system design interview книга

⁠

https://github.com/donnemartin/system-design-primer⁠

⁠

Internet

Общие протоколы и технологии связи в интернете

OSI Model (Open Systems Interconnection)

По модели процесс передачи данных по сети происходит постепенно от одного уровня к другому. На каждом из них используются информация с прошлого уровня и определенные протоколы.

⁠

Уровень 1: Физический - происходит обмен оптическими, электрическими или радиосигналами между устройствами отправителя и получателя, биты (единицы и нули).

Уровень 2: Канальный - определяет куда направлять информацию, роль адресации. Принимает биты и трансформирует их в фреймы. Работают уже более умные – коммутаторы. Их задачей является передача кадров от одного устройства другому, используя MAC-адреса (Media Access Control).

Уровень 3: Сетевой - маршрутизация трафика, пакетов, состоящих из заголовка и поля данных. Этим занимаются такие устройства, как роутеры или маршрутизаторы. ARP (Address Resolution Protocol) определяет соответствие между логическим адресом сетевого уровня (IP) и физическим адресом устройства (MAC).

Уровень 4: Транспортный - передает пакеты по сети. Установка соединения, надежность и управление потоком. Блоки данных делятся на отдельные фрагменты, размеры которых зависят от используемого протокола.

TCP и UDP⁠

Уровень 5: Сеансовый - отвечает за поддержание сеанса или сессии. Он отвечает за установление, поддержание и завершение связи, синхронизацию задач и сам обмен информацией. Примером для пятого уровня можно назвать созвон в Zoom. В сессии необходимо обеспечивать синхронизированную передачу аудио и видео для всех участников. За это отвечают протоколы сеансового уровня (RPC, H.245, RTCP).

Уровень 6: Уровень представления - подготавливает информацию для 7 и преобразует (сжимает, кодирует, шифрует) их в понятный язык для пользователя или машины. Если вы отправляете картинку, то она приходит в виде битов, а потом трансформируются в JPEG, GIF или другой формат.

Уровень 7: Прикладной - отображает данные в понятном конечному пользователю формате. Сюда входят такие технологии, как

HTTP⁠

, DNS, FTP, SSH и многое другое.

HTTP \ HTTPS

— это протокол передачи гипертекстовой разметки, которая используется для передачи данных в интернете

URL \ URI

URI – имя и адрес ресурса в сети, включает в себя URL и URN

https://wiki.merionet.ru/images/vse-chto-vam-nuzhno-znat-pro-devops/1.png⁠

⁠

URL – адрес ресурса в сети, определяет местонахождение и способ обращения к нему

https://wiki.merionet.ru⁠

⁠

URN – имя ресурса в сети, само название ресурса, но не говорит как к нему подключиться images/vse-chto-vam-nuzhno-znat-pro-devops/1.png

TCP \ UDP \ IP (Internet Protocol)

TCP (Transmission Control Protocol) - при транспортировке данных восприимчивых к потерям, например, трейдинг, web-страницы. Он контролирует целостность информации, ибо потеря какого-то контента заставит - mission critical. Чтобы сделать передачу более эффективной и быстрой, транспортный уровень разбивает данные на более мелкие сегменты.

UDP (User Datagram Protocol) - протокол используется с данными, для которых потери не так критичны, онлайн игры, мультимедиа. Для них более заметна будет задержка, поэтому UDP обеспечивает связь без установки соединения. Во время передачи данных с помощью протокола UDP, пакеты делятся уже на автономные датаграммы. Они могут доставляться по разным маршрутам и в разной последовательности.

DNS (Domain Name System)

Система доменных имен преобразует имена в IP-адреса (www.yandex.ru → 193.11.44.02).

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

понятные имена

возможность менять сетевую инфраструктуру

Недостатки

Быстро увеличивается размер

Сложно вносить изменения

Возможны конфликты имен

⁠

www(имя компьютера).yandex(домен 2-го уровня).ru(домен верхнего уровня).(точка)(корневой)

Типы записей

A – адрес IPv4

AAAA – адрес IPv6

CNAME – псевдоним для доменного имени

MX – адрес почтового сервера

SRV – адреса и порты сетевых сервисов

NS – адреса DNS-серверов, ответственных за зону

PTR – доменное имя для IP-адреса

Другие редко используемые типы записей

Команды: nslookup (Windows), host/dig (Linux)

API (Application Programming Interface)

Программный интерфейс приложения.Интерфейс - контракт между двумя приложениями он определяет, как они взаимодействуют друг с другом, используя запросы и ответы.

⁠

HATEOAS (Hypermedia As The Engine Of Application State)

Не только отдает информацию но и возвращает действия которые доступны на данной странице в виде ссылок.

Единственная самая важная причина для HATEOAS — слабая связь (loose coupling). Применяется очень редко. Клиент должен быть максимально тупым и без дизайнера (он определяет какие ссылки доступны на экране).

В REST клиент зависит от сервера. Если потребителю службы REST необходимо жестко закодировать все URL-адреса ресурсов, он тесно связан с реализацией вашей службы. Вместо этого, если вы вернете URL-адреса, которые он может использовать для действий, он будет слабосвязанным. Нет строгой зависимости от структуры URI, так как она указана и используется в ответе.

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

"_embedded": { //resource

"customerId": "10A",

"customerName": "Jane",

"companyName": "ABC Company",

"_links": {

"self": {

"href": "http://lh.ru:8080/api/cus/10A"

"allOrders": {

"href": "http://lh.ru:8080/api/ord/10A"

}

HAL (Hypertext Application Language) - определяет как должны выглядеть и соотноситься между собой ресурсы и ссылки в рамках ответа.

Links (Ссылки): указано как комбинация

Target (Цель) — указана в качестве URI

Relation (Отношение) — имя

Embedded Resources (Встроенные ресурсы): другие ресурсы, содержащиеся в данном REST ресурсе

State (Состояние): фактические данные ресурса

Open API / Swagger

REST (Representational State Transfer)

Это концепция, парадигма, но не протокол передачи данных.

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

6 принципов REST:

Клиент-серверная архитектура - Отделение клиента от сервера, позволяет добиться масштабируемости.

Stateless - сервер не должен хранить у себя информацию о сессии с клиентом. Он должен в каждом запросе получать всю информацию для обработки. Если каждый запрос содержит в себе весь контекст, то можно, клонировать сервер-обработчик. Если бы они хранили состояние, то либо должны были синхронизироваться, либо мне нужно было бы умело направлять запрос в нужное место.

Масштабируемость сервера

Уменьшение времени обработки запроса

Простота поддержки

Возможность использовать кэширование

Кэширование - Если у сервера часто запрашивают одинаковую информацию. Например, кэширование активно используется на новостных сайтах или в соцсетях. Плюсы:

Уменьшение количества сетевых взаимодействий.

Уменьшение нагрузки на системы (не грузим их дополнительными запросами).

Единообразие интерфейса - HATEOAS одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить.

Layered system - Концепция слоистой архитектуры заключается в том, что ни клиент, ни сервер не должны знать о том, как происходит цепочка вызовов дальше своих прямых соседей.

Code on demand - Идея передачи некоторого исполняемого кода (по сути какой-то программы) от сервера клиенту.

Зрелость REST сервисов, насколько сервис REST или не REST:

⁠

SOAP (Simple Object Access Protocol)

Основанный на формате XML протокол для выполнения запросов к сетевым API. Будучи применяемым чаще всего по HTTP, он стремится к независимости от последнего и избегает использования большинства его возможностей. Вместо этого к нему прилагается масса разнообразных сопутствующих стандартов (фреймворк веб-сервисов, известный под названием WS-*), которые добавляют в него различные возможности. API SOAP веб-сервиса описывается с помощью основанного на XML языка, именуемого языком описания веб-сервисов (Web Services Description Language, WSDL).

Преимущества:

наличие строгой спецификации;

широкая поддержка в продуктах Microsoft,

однозначность.

Недостатки:

сложность реализации;

сложность/ресурсоемкость парсинга XML-данных.

Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):

Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.

Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.

Body. Основной элемент, содержит основную информацию сообщения. Обязательный.

Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.

gRPC (google Remote Procedure Call)

Обеспечивает взаимодействие между удаленными сервисами - когда они находятся на разных серверах в микросервисной архитектуре. С точки зрения пользователя это выглядит, как вызов локальной функции, в качестве транспорта использует HTTP/2

А для описания интерфейса используется Protocol Buffers (protobuf), где описывается структура для передачи, кодирования и обмена данных между представлениями описанными выше. Protocol Buffers проще, компактнее и быстрее, чем XML, поскольку осуществляется передача бинарных данных.

syntax = "proto3";

/* Наименование пакета данных */

message Calculator {

int32 xxx = 1;

int32 yyy = 2;

}

message CalculatorRequest {

Calculator calculator = 1;

}

message CalculatorResponse {

int32 result = 1;

}

/* Наименование сервиса, который будет осуществлять

калькуляцию данных полей xxx и yyy

service CalculatorService {

rpc Calculator(CalculatorRequest) returns (CalculatorResponse) {};

}

JWT (JSON Web Token)

Это строка в следующем формате header.payload.signature. Предположим, что мы хотим зарегистрироваться на сайте. В нашем случае есть три участника — пользователь user, сервер приложения application server и сервер аутентификации authentication server. Сервер аутентификации будет обеспечивать пользователя токеном, с помощью которого он позднее сможет взаимодействовать с приложением.

GraphQL

С помощью запросов GraphQL получает необходимые данные с сервера. Все типы запросов отправляются через POST. Тип запроса Query в GraphQL — аналог GET в REST. Запросы — строки, которые отправляются в теле HTTP POST-запроса. Можно представить что это аналог языка SQL в REST.

В терминологии GraphQL называются просто запросами (query) и относятся к букве R (reading, чтение) акронима CRUD. Запросы второго вида — это запросы на изменение данных, которые в GraphQL называют мутациями (mutation). Они относятся к буквам C, U и D акронима CRUD.

query

{

flavors {

name

desc

}

response

{

"data": {

"flavors": [

{ "id": 1, "name": "Lazy" },

{ "id": 2, "name": "What" },

{ "id": 3, "name": "Gnarl" }

]

}

Architecture

Cohesion (Целостность) - какие задачи выполняются элементами сервиса насколько эти задачи связанны друг с другом, достигают ли одну и туже цель.

Coupling (Зацепление / связность) - насколько сильно выполнение задач микросервиса зависит от других микросервисов.

Latency - задержка от запроса до ответа.

⁠

Варианты системной архитектуры

⁠

Monolith

Microservices

⁠

балансировщик нагрузки (Load Balancer) – распределяет входящий трафик между сервисами

CDN (Content Delivery Network — сеть доставки контента) – группа географически распределенных серверов, содержащих статический контент для быстрой доставки. Клиенты сначала запрашивают данные из CDN и только после этого обращаются непосредственно к сервису

шлюз API (API Gateway) – обрабатывает входящие запросы и передает их соответствующим сервисам. Он общается с провайдером идентификации (Identity Provider – поставщик удостоверений) и другими службами

провайдер идентификации – обработка аутентификации и авторизации пользователей

реестр служб (Service Registry) – отвечает за регистрацию микросервисов для использования другими компонентами системы, такими как шлюз API

управление — мониторинг сервисов

микросервисы – проектируются и разворачиваются в разных доменах (domains). У каждого домена своя база данных. Шлюз API общается с микросервисами через REST или другие протоколы, микросервисы одного домена общаются между собой через RPC

⁠

У каждого микросервиса должно быть свое хранилище данных.

Код каждого сервиса должен быть примерно на одном уровне завершенности.

Каждый сервис должен собираться независимо от других.

У каждого сервиса должно быть своя зона ответственности.

Сервисы должны разворачиваться с помощью контейнеров.

Сервисы не должны хранить состояние (должны быть stateless).

Должен применяться доменно-ориентированный дизайн.

Микрофронтенды.

+Окрестрация сервисов.

SOA

CQRS

Serverless

Problems

Problems

Column 1

Graceful degradation

Throttling

Backpressure

Circuit Bracker

There are no rows in this table

⁠

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.