Про архитектуру программного обеспечения

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

Базис

• Разработкой архитектуры программного обеспечения занимается архитектор ПО.
  Если в команде нет архитектора, эту роль на себя может взять ведущий разработчик, реже — системный аналитик.
• Архитектуру ПО описывают в виде набора диаграмм и текстовых документов.
• Помимо перечня компонентов, из которых состоит ПО, архитектура ПО определяет, какие компоненты могут взаимодействовать между собой, с какой целью, кто может быть инициатором взаимодействия.
• Каждый компонент делится на составные части — модули, пакеты, классы и так далее.
• Модули, в свою очередь, могут дробиться дальше — на более мелкие составляющие.
  Всё это — разные уровни детализации архитектуры.
• Системный аналитик, как правило, работает с одним или двумя верхними уровнями детализации архитектуры ПО.
  Уровни ниже тесно связаны с деталями реализации программного кода, поэтому находятся в зоне ответственности архитектора ПО и разработчиков.
• Разделить приложение на составные части можно по-разному.
  Можно делить, например, на компоненты. А можно по функциональному принципу.

Монолитная и микросервисная архитектуры

• Микросервисная архитектура — это способ построения приложения в виде набора слабо связанных между собой компонентов (микросервисов).
  У микросервисного приложения может быть несколько маленьких серверов приложений и серверов баз данных.
• В монолитной архитектуре не выделяют микросервисы, всё приложение реализуется цельным "куском".
  У монолитного приложения единый сервер приложений, один сервер баз данных.

Микросервисную архитектуру отличают два основных принципа — слабая связанность и единая ответственность.

Принцип слабой связанности (Low сoupling)

• Один микросервис не должен зависеть от реализации другого. Микросервис предоставляет другим микросервисам API.
• API правильно спроектированного микросервиса должен содержать все нужные запросы и возвращать в ответе нужные данные.

Принцип единой ответственности (Single-responsibility principle)

• Микросервис решает только одну задачу. И решает её в полном объёме.
• В микросервисе не должно быть функциональности, которая никак не связана с решаемой задачей.

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

• Трудности с координацией работы команды.
  Если 10 разработчиков вместе работают над программным кодом приложения, их работу можно организовать так, чтобы никто друг другу не мешал. Как только эту работу выполняют 100 разработчиков, организовать их уже гораздо сложнее.
• Снижение надёжности.
  Ошибка в одном месте может привести к неработоспособности всего приложения. Чем больше приложение, тем больше у него уязвимых мест, где можно допустить ошибку.
• Изменения технологий и языков программирования.
  Если приложение разрабатывалось на каком-нибудь устаревшем сегодня языке программирования (например, Per), то чтобы развивать приложение в современных реалиях придется сменить язык, а значит — переписать приложение целиком.
• Затраченное время.
  У большого монолитного приложения процедуры сборки и установки могут занимать десятки минут — это очень долго.

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

• Для обработки запроса пользователя потребуется в определённом порядке вызвать несколько микросервисов.
  Для этого в архитектуре приложения возникают новые компоненты, которые управляют порядком вызова микросервисов при обработке запросов пользователей. Увеличение числа компонентов и правил их взаимодействия усложняет архитектуру приложения.
• Усложнение процедуры установки приложения.
  Не получится ограничиться одним сервером приложений и одним сервером баз данных, понадобится много — для каждого микросервиса. Без DevOps-инженера не обойтись.
• Микросервисное приложение может работать лишь частично.
  Микросервисное приложение состоит из десятков или сотен независимых микросервисов, и некоторые его части могут не функционировать, не влияя на работу других. Чтобы оперативно выявлять проблемы, нужны специальные средства мониторинга, которые ещё сильнее усложняют архитектуру приложения.
• Возможность разрабатывать микросервисы на разных языках программирования может стать недостатком.
  При отсутствии контроля проект может превратиться в лоскутное одеяло. Необходимость реализации компенсирующей логики.

Особенности работы системного аналитика при разработке в микросервисной архитектуре

Одна из типовых задач — переход от монолитной к микросервисной архитектуре ПО.
Перевод происходит поэтапно: из приложения один за другим выделяют микросервисы.
При этом важно не нарушать работу приложения — оно всё время должно быть доступно для пользователей.

В такой ситуации работа приобретает примерно следующие особенности:

• Работа становится "двухслойной".
  Нужно проектировать как всё приложение в целом (из каких микросервисов оно состоит и как они взаимодействуют между собой для решения задач пользователя), так и каждый отдельный микросервис (как он устроен и что делает).
• Увеличивается количество задач по проектированию API и порядку взаимодействия микросервисов между собой и со сторонними приложениями.
• Необходимо глубже погружаться в архитектуру приложения.
  Нужно понимание из каких микросервисов оно состоит и как они взаимодействуют между собой.
• Нужно больше думать об ошибках и нештатных ситуациях.
  Если в монолитных приложениях есть стандартные решения для их обработки, то в микросервисных — вариантов решения много.