Архитектура современных информационных систем. Введение

О чем думает мир
Как обрабатывать все запросы?
Где и как хранить данные?
Сколько это будет стоить?

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

Бизнес и разработка
Стремится минимизировать издержки
Полагается на разработчиков в части выбора технологии
Хочет все быстро, качественно и недорого
Одно не может без другого
Стремится облегчить себе сам процесс
Не любит изобретать «велосипеды»
Сложно нормировать время
Творческий процесс
Бизнес
Разработка

Robert Martin, «Clean Architecture»
«Чтобы создать систему, дизайн и архитектура которой способствуют уменьшению трудозатрат и увеличению продуктивности, нужно знать, какие элементы архитектуры ведут к этому»

Что такое архитектура?
Бизнес-задача
Потребители
Доступный бюджет
Что определяет архитектуру приложения?

В чем выражается архитектура?
Трудозатраты при разработке и доработке
Красиво выглядящие схемы приложения (в хорошей архитектуре она даже схематично выглядит красиво)
Скорость, отзывчивость, безопасность, отказоустойчивость
Количество матов разработчиков при доработке (меньше - лучше)
Хорошая или плохая?

Современный мир
Разнообразный стек языков программирования под любые задачи (C#, Java, C++, Go, JS)
Разнообразный стек технологий под эти языки программирования (ASP.Net, Spring, React и т.д.)
Разнообразное ПО для ускорения доставки и развертывания (CI/CD) (Jenkins, Kubernetes)
Разнообразное ПО для хранения и передачи данных (Apache Kafka, RabbitMQ, PostgreSQL, MongoDB)
Что есть для реализации?

Архитектура информационных систем
Архитектура, клиент-сервер

Виды архитектуры и виды ПО
Как может выглядеть ваше приложение?
Только клиент
Клиент-сервер

Для чего нужен клиент?
Ваше приложение не должно коммуницировать с чем либо другим
Ваше приложение если и содержит БД, то ему не нужно синхронизировать её с другими приложениями
Можно пренебречь безопасностью
Когда вам хватить одного компьютера?

Для чего нужен сервер?
Вам нужны какие-либо внешние данные, которые вы не можете получить без внешних систем
Вам нужно синхронизировать данные с внешними системами
Вам нужно контролировать безопасность
Когда нужно подключить сервер?

База данных
Вы будете строго ограничивать роли в БД для каждого пользователя
Вы сможете производить обработку в БД посредством процедур и функций
Маленький проект с небольшим количеством клиентов, которые не могут конфликтовать друг с другом, одновременно меняя внешние данные
Или нет, или есть всего 1-2 внешняя система
База данных может быть сервером, если

Сервис перед базой данных
У вас на сервере должны производится сложные расчеты или обновления данных
У вас может быть бесконечное количество клиентов, которых нужно разводить между собой
Перед базой данных нужно ставить сервис, если
Сервис позволяет
Производить сложные операции обновления данных, сохраняя при этом разграничения пользователей
Делает базу данных независимой от клиента

Сервис как абстракция
S - Single Responsibility - каждая единица системы выполняет только одну и только свою функцию
O - Open-Closed - единица системы открыта для расширения, но закрыта для изменения
L - Liskov substitution - единицы системы должны быть заменяемыми другими с теми же контрактами без нарушения её работы
I - Interface segregation - лучше много маленьких интерфейсов, чем один большой
D - Dependency Inversion - единицы системы должны быть завязаны на абстракциях, а не на конкретной реализации
И причем тут SOLID

Любой клиент, любая база
Главное - контракт
Desktop-приложение
Сайт
Мобильное приложение
Собака. А вдруг.
SQL
NoSQL
Другой сервис
Файловая система

Сервис - узкое место?
Для сервиса нужен особо тщательный подход к архитектуре.
А как расширить?

Монолиты и микросервисы
Выполняют множество функций
Цельный кусок
Легки в развертывании
А что ж лучше?
Каждый сервис - одна функция
Распределяют нагрузку
Сложны в развертывании
Монолит
Микросервисы

Взаимодействие
Клиент общается с сервером

Via Internet
Взаимодействие по протоколу HTTP
Клиент делает запрос — сервер отвечает
Составные части:
Глагол: GET http://google.com/search?query=hello&p=20
URL - GET http://google.com/search?query=hello&p=20
Params: GET http://google.com/search?query=hello&p=20
Headers — заголовки
Body: пустое, файл, текст
HTTP

REST-API
Стандарт взаимодействия по протоколу HTTP
Неофициально принят в мире для упрощения разработчикам — все сервисы по REST-API работают одинаково
Основные глаголы: GET, POST, PUT, DELETE
Путь=ресурс. http://localhost/students — каталог ресурсов, http://localhost/students/1 — ресурс
Вся работа идет только с цельными ресурсами. Никаких http://localhost/addStudent.
Общие положения

REST-API
GET — получение данных с ресурса. GET http://localhost/students — получение списка всех студентов, GET http://localhost/students/1 — получение студента с ID 1, GET http://localhost/students?q='Иванов' — поиск по списку студентов с параметрами. Идемпотентен.
POST — создание нового ресурса. POST http://localhost/students — создание и добавление нового студента в каталог. Неидемпотентен.
PUT — обновление существующего ресурса. POST http://localhost/students/1 — обновляет старого студента с ID 1 по новым данным. Идемпотентен.
DELETE — удаление ресурса. DELETE http://localhost/students/1 — удаляет студента с ID 1. Идемпотентен.
Глаголы

REST-API
HTTP 200 — результат успешно получен
HTTP 201 — создано. Может содержать ссылку на созданный ресурс и редирект.
HTTP 301-302 — ресурс по какой-то причине перемещен навсегда/временно.
Статусы

REST-API
HTTP 400 — некорректный запрос. Ошибка в параметрах.
HTTP 401 — требуется авторизация
HTTP 403 — авторизация прошла, но нет доступа.
HTTP 404 — ресурс не найден
HTTP 405 — нельзя использовать такой глагол
HTTP 408 — время ожидания истекло
HTTP 414 — URL слишком длинный
HTTP 415 — неподдерживаемый тип данных
HTTP 418 — «Я чайник»
HTTP 429 — слишком много запросов
HTTP 451 — «Недоступно по юридическим причинам»
Статусы «Ошибки клиента»

REST-API
HTTP 500 — внутренняя ошибка сервера
HTTP 501 — неверный метод
HTTP 502 — Bad Gateway — ошибка шлюза/прокси
HTTP 503 — Сервис недоступен
HTTP 504 — Gateway Timeout — шлюз/прокси слишком долго ждал ответ
Статусы «Ошибки сервера»

REST-API
Формат JSON — объект (Map, Dictionary) в читабельном человеку формате
Объекты

SOAP
Тот же объект, но формате XML
Строится по XSD-схеме
Используется в webservices
XML как описание объекта

MediaType
Form-data — Формы с веб страниц
X-www-form-urlencoded — кодированные даты с формы
Raw — Text, JSON, XML, HTML
Binary — Файлы
GraphQL

WebSocket
Прямое соединение в Socket.
Работает по принципу тесного взаимодействия и пересылки сообщений по сокету.
Более тесное общение — сокет работает всегда, взаимодействие идет всегда.

Server-Sent Events
Упрощенная версия WebSocket
Слушатель слушает, вещатель отправляет сообщения
Соединение постоянно

Базы данных
Типы, виды, зачем и когда нужны

Базы данных
База данных в данном случае — любое хранилище для любых данных.
Базы данных:
Память приложения
Файлы
СУБД
Общие положения

Базы данных
Система взаимосвязанных таблиц
Данные хранятся по столбцам
Каждая таблица — отдельная сущность
Взаимодействие через SQL-запросы
Ключи, индексы
Представители: MySQL, Microsoft SQL Server, PostgreSQL, OracleDB
Транзакционность — гарантия того, что пока идет взаимодействие — данные не изменятся из-за других источников
Реляционные (SQL)

Базы данных
Данные хранятся в виде полноценных обособленных документов/объектов
Различные форматы хранения — JSON, файлы и т.п.
У каждого документа свой ID (ключ-значение)
Свой язык запросов
Представители: MongoDB, CouchDB, Redis
Документные (NoSQL)

Базы данных
Вызов функции БД для её обработки на стороне БД
Если нужно единоразово собрать данные из множества таблиц/документов, при этом нет возможности сделать это в один запрос.
Если одну и ту же сложную операцию с данными в БД нужно проводить в нескольких приложениях, работающих с этой БД
Функции

Базы данных
Кластеризация — несколько инстансов базы данных даже на разных серверах работают как одна.
Master — главная БД, к которой доступны все операции, как чтения, так и записи
StandBy — вспомогательные БД, которые доступны только для чтения и «зеркалят» данные с master-базы
Позволяет добиться большей производительности — операции записи более «тяжелые».
Кластеризация, Master и StandBy

Базы данных
На случай, если одни и те же данные могут быть обработаны/использованы несколькими приложениями
Механизм: делается запрос на изменение/обработку/взятие данных. Если до этого блокировка не была поставлена — она ставится и данные отдаются в обработку. Если блокировка уже стоит — база отвечает отказом.
Имеет большое значение, когда инстансов приложений становится больше чем 1.
Блокировки данных

Монолиты
Как, когда и зачем

Монолиты
Система едина, поставляется и развертывается целиком
Возможно отключение отдельных функций, при этом сама кодовая база останется той же
Все компоненты системы взаимосвязаны
Упадет одна часть системы — упадет вся система
Самый простой способ сделать систему

Монолиты
Система небольшая
Компоненты системы взаимодействуют слишком тесно и часто, чтобы дробить её
Небольшие бюджеты
Небольшие бюджеты на эксплуатацию, настройку и сопровождение
Когда могут выиграть?

Монолиты
Большие системы
Компоненты взаимосвязаны, хотя не должны
Требуется надежность всей системы
Требуется недопустить ситуации «Упала одна часть системы — упала вся система»
Когда могут проиграть?

Микросервисы
Как, когда и зачем

Микросервисы
Все компоненты системы разделены на мелкие приложения
Компоненты системы общаются между собой через сеть
Одно приложение никак не влияет на другие
Отключение функций ведет к полному отключению отдельных приложений
Самый сложный способ сделать систему

Микросервисы
Система очень большая
Компоненты системы могут работать независимо друг от друга или с минимальной зависимостью
Есть средства и квалификация на архитектуру, развертывание и эксплуатацию
Когда могут выиграть?

Микросервисы
Недостаточная квалификация
Низкий бюджет на эксплуатцию и сопровождение
Система слишком маленькая и её не требуется делить еще сильнее
Когда могут проиграть?

Общие элементы архитектур

Балансировка нагрузки
У системы есть несколько инстансов.
Балансировка нагрузки — некий компонент сам распределяет запросы к инстансам системы и её работу в зависимости от текущей нагрузки инстансов.
Позволяет распределить работу системы равномерно.
Когда нельзя слишком сильно нагружать один компонент

Gateway
У системы есть несколько инстансов.
У системы есть несколько отдельных компонентов.
Идет запрос к http://localhost/API/methodName. В зависимости от API/methodName Gateway сам отправит запрос нужному компоненту, получит ответ и вернет пользователю
Позволяет сделать единую точку доступа ко всем компонентам системы и настраивать её отдельно от приложений
Единый вход во все приложения

Аутентификациия и авторизцаия
Авторизация — проверка подленности, например, по паролю.
Аутетифкация — процесс проверки доступа пользователя к определенному ресурсу.
Как отследить пользователя

Аутентификация и авторизация
Сессия — значение, позволяющие системе определить пользователя, что послал сообщение.
Настраивается и управляется системой. Передается в Header-ах
Токен — сессия, но с условием Token и Refresh Token.
Token — токен, с которым идет обращение к системе. Имеет срок жизни.
После того, как срок жизни Token пройдет — нужно получить новый с помощью Refresh Token, который тоже имеет срок жизни.
После того, как срок жизни Refresh Token пройдет — нужно авторизоваться заново.
Сессии и токены

Брокеры сообщений
Работают по принципу «В компонент отправляется сообщение». И все.
Асинхронная работа. Сообщение отправляется в брокер и компонент забывает о нем.
Компонент не знает, кому и когда и для каких целей нужно это сообщение и будет ли оно доставлено ему и каким образом будет доставлено. Ему достаточен тот факт, что он его отправил
Примеры: Apache Kafka, Rabbit MQ
Что это и зачем нужно
Сервис 1
Сервис 2
Брокер

Контейнеризация
Контейнеризация - процесс упаковки системы в отдельную изолированную ОС.
Ситуация: у вас есть система, которая запускается на Linux. Благодаря контейнеризации вы создаете виртуальную машину под неё на базе Linux, после чего получившийся контейнер можно будет запустить на любой ОС, которая поддерживает контейнеризацию.
Контейнер содержит ТОЛЬКО необходимые для приложения компоненты, без прочих служб
Все контейнеры друг от друга изолированы и независимы
Самый распространенный механизм: Docker