Lyosik | Ведущий системный аналитик (SA Lead)

Добро пожаловать в блок статей для начинающих системных/бизнес аналитиков. Здесь мы готовимся к получению заветного оффера вместе

Перед погружением в данную статью настоятельно рекомендую сперва прочитать предыдущую часть про клиент-серверную архитектуру, которая займет всего 4 минутки вашего времени. *Ссылочка ниже:

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

И действительно, клиент с сервером обычно общаются через Интернет (хотя могут работать и в одной локальной сети, и вообще в любых других типах сетей). Общение происходит по такой штуке, как протокол.

Протокол — это набор правил и стандартов, определяющих, как данные передаются и обрабатываются в сети.

Так вот, клиент и сервер взаимодействуют с помощью стандартных протоколов, таких как HTTP, FTP или более низкоуровневых — TCP или UDP. Протокол обычно выбирается под тип услуги, которую оказывают сервера.

На самом деле, взаимодействие клиента с сервером осуществляется не просто посредством сети Интернет. Клиент обращается к серверу согласно определенному контракту (API).

Не пугаемся новых определений и открываем гугл:

Контракт API (Application Programming Interface) — это формальное соглашение, описывающее, как различные компоненты программного обеспечения взаимодействуют друг с другом. Контракт определяет, какие функции доступны, как они вызываются, какие параметры принимаются и какие данные возвращаются.

API устанавливает не только порядок передачи данных. Через него можно передавать конкретную задачу (с помощью методов GET, POST, PUT, DELETE). Так же ответ мы получаем в конкретном виде (структуры json\xml). *Но об этом позднее*

Таким образом, мы подобрались к теме этой статьи. Да, описанное выше, и есть те самые интеграции. Но взаимодействие клиента с сервером — это лишь их частный случай.

Итак, вдох-выдох и поехали.

Понятие интеграции

Интеграция – это обмен данными между системами с возможной последующей обработкой этих данных каждой из систем.

Интеграция может быть, например, между системами, микросервисами, а может быть между фронтом и бэком.

Немного теории

Для начала попробуйте самостоятельно ответить на следующие вопросы:

• Что такое фронт (frontend) и бэк (backend) из вашего опыта?

• С чего начинать писать постановку – с фронта или с бэка?

Фронт и бэк

Скрытый текст

Фронтенд может быть разным. Например, однородным и неоднородным.

И снова обращаемся к хранителю знаний:

Однородный фронтенд — это ситуация, когда все компоненты и технологии в проекте используют одни и те же стандарты и подходы. Например, использование одного фреймворка (например, React или Vue) для всех частей приложения.

Неоднородный фронтенд — это когда в проекте используются разные технологии, фреймворки или библиотеки. Например, часть приложения может быть написана на React, а другая часть — на Angular или Vue.

А может ли бэк также быть неоднородным? Вполне себе. Особенно если речь заходит о микросервисах.

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

Монолит и микросервисы

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

Преимущества: простота E2E тестирования, простота развертки.

Микросервисы — это симметричная архитектура. Каждый сервис имеет свою базу и отвечает именно за бизнес-функцию.

Преимущества: независимость от стека, масштабируемость, простота модульного тестирования.

Лайфхак: никто не догадается о том, что монолит — это монолит, если не допускать людей к кодовой базе!:)

Важно!

Акцентирую внимание на том, что приведенные понятие Монолит и Микросервисы применимы исключительно в рамках клиент-серверной архитектуры! То есть если вы участвуете в разработке автономного приложения, которое осуществляет все вычисления на машине клиента (например, какой-нибудь однопользовательский калькулятор), то называть его монолитом не стоит.

Двигаемся дальше.

Back-office

И вводим еще одно такое чисто логическое понятие, как Back-office. Грубо говоря, если мы берем магазин по продаже чего-либо, то есть веб-часть, куда заходят покупатели (например озон), а внутри озона при этом есть другие приложения (в которых отслеживают заказы, бухгалтерию и т.д), то вот это все вместе и есть Back-office.

Back-office — это объединение всех фронтов, где работают сотрудники заказчика или клиенты

Давайте взглянем на тему интеграций немного под другим углом.

Взаимодействие с точки зрения потока данных

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

Виды потоков данных:

• Вводные – информация поступает в приложение, после чего происходит ее считывание;

• Выводные – программа передает данные с последующей записью в потоки.

Тут же перед нами возникают два новых понятия – Producer и Consumer.

Producer (производитель) — это тот, кто производит/отправляет данные.

Consumer (потребитель) — это тот, кто получает данные.

На схеме ниже видим следующее: Пользователь заполняет форму и отправляет данные. IT System 1 принимает эти данные и сохраняет в базу данных.

Попробуйте ответить на вопрос: кто на этой схеме Producer, а кто Consumer?

Пополним наш айтишный словарный запас еще двумя понятиями:

Transform — это тот, кто изменяет данные.

Storage — это тот, кто сохраняет данные.

Важно!

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

Далее введем такие понятия, как Statefull и Stateless системы.

Stateful — система сохраняет информацию о предыдущих состояниях или сеансах.

Stateless — система не сохраняет информацию о предыдущих состояниях или сеансах.

И зная это, переходим к еще одному понятию - шине данных.

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

Шина данных представляет собой частный случай Stateless систем. Но все же сам принцип Stateless нарушает, т.к хранит в себе данные до момента, пока их не обработали.

По умолчанию шина работает по принципу FIFO.

Да-да, снова что-то новое. Запоминаем:

FIFO и FILO — это аббревиатуры, описывающие два различных метода управления очередями данных.

FIFO (First In, First Out) — это метод, при котором первый элемент, добавленный в очередь, будет первым, который будет извлечен. Очередь работает по принципу "первый пришёл — первый вышел". Примером FIFO может служить очередь в магазине: первые клиенты, пришедшие в очередь, будут первыми обслужены.

FILO (First In, Last Out) — это метод, при котором первый элемент, добавленный в структуру данных, будет последним, который будет извлечен. Очередь работает по принципу "первый пришёл — последний вышел". Примером FILO является стек: последний добавленный элемент будет первым, который будет извлечён.

Кроме обычной шины данных есть еще так называемая шина Native Kafka.

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

Шина Native Kafka по своему уникальна, так как нарушает принцип FIFO и не является Stateless.

Так как Kafka хранит данные дольше, и взаимодействующие с ней системы могут запросить у нее старые сообщения, то необходимо указывать порядок в структуре сообщений. Например:
1.Формирование заказа;
2.Оплата;
3.Доставка.
Таким образом, система, получив сообщение о доставке, будет знать, что необходимо также дождаться сообщений о заказе и оплате.

Вообще брокеры сообщений — очень объемная тема, заслуживающая отдельной статьи. А сейчас, на первых порах, вам достаточно просто знать, что такие штуки тоже есть.

Ну что же, мы подобрались к финишной прямой.

Типы интеграций

1. Файловый обмен. Обмен данными через файлы (например, CSV, XML), которые загружаются или выгружаются.

2. База к базе (или общая база данных). Прямое взаимодействие между двумя или более системами через общую базу данных.

3. Использование HTTP/HTTPS. Обмен данными между различными системами и приложениями через стандартные протоколы передачи данных в сети Интернет.

4. Шины данных. Обмен данными через централизованную платформу.

5. API. Обмен данными через стандартизированные программные интерфейсы.

6. Push-каналы. Обмен данными и событиями в режиме реального времени, где одна система "толкает" (push) информацию в другую систему, без необходимости запрашивать информацию.

7. Использование нативных библиотек. Встраивание готовых программных компонентов напрямую в код приложения, что позволяет приложению использовать функциональность других систем или сервисов без необходимости прямого взаимодействия с их API.

Попробуйте самостоятельно определить, какие из этих типов используют синхронные методы взаимодействия, а какие асинхронные?

Давайте рассмотрим подробнее использование HTTP/HTTPS и API.

HTTP и HTTPS

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

Напомню,

Протокол — это набор правил и стандартов, определяющих, как данные передаются и обрабатываются в сети.

Одними из самых популярных протоколов являются HTTP и HTTPS:

HTTP (англ. HyperText Transfer Protocol) — протокол передачи гипертекста, сетевой протокол прикладного уровня, который изначально предназначался для получения с серверов гипертекстовых документов в формате HTML, а с течением времени стал универсальным средством взаимодействия между узлами как Всемирной паутины, так и изолированных веб-инфраструктур.

HTTPS (англ. HyperText Transfer Protocol Secure) — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности.

Бок-о-бок с темой протокола HTTP идут так называемые статусы ответов.

Статусы ответов в HTTP — это коды, которые сервер отправляет клиенту (обычно веб-браузеру) в ответ на HTTP-запрос. Они помогают определить результат обработки запроса.

Все бы ничего, но у протоколов HTTP и HTTPS есть два основных минуса:

• Connection между системами длится только пока идет сеанс связи. Т.е. одна система делает запрос к другой, устанавливается connection. Пока вторая система не ответит, первая ждет (держится connection). И только после ответа второй системы connection разрывается;

• При http-request в ответе возвращается верстка. Т.е. мы зависим от форматирования, от тегов, от стилей. Соответственно, если поставщик данных поменяет верстку, все поломается.

API

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

API включает в себя:

• саму операцию, которую мы можем выполнить;

• данные, которые поступают на вход;

• данные, которые оказываются на выходе (контент данных или сообщение об ошибке).

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

• XML (Extensible Markup Language):

  • Язык разметки для представления иерархических данных в виде древовидной структуры.

  • Исторически был широко распространен, но сейчас уступает JSON из-за более компактного формата.

  • Пример:

<person>
  <name>John Doe</name>
  <age>35</age>
  <email>john.doe@example.com</email>
</person>

• JSON (JavaScript Object Notation):

  • Это компактный и человекочитаемый формат для представления структурированных данных.

  • Широко используется в современных веб-сервисах и API, так как легко обрабатывается клиентскими приложениями.

  • Пример:

 {
   "name": "John Doe", 
   "age": 35, 
   "email": "john.doe@example.com"
 }

И запомните: в основе любого API лежит http-протокол, т.е. всегда держится connection.

Соответственно,

API – это специальный http-request-response, которым передаются данные без верстки в формате XML или JSON.

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

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