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

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

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

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

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

Клиент-серверная архитектура

Архитектура клиент-сервер — это архитектура приложения, построенная поверх компьютерной сети и состоящая из клиентов (процессов, инициирующих связь) и серверов (процессов, отвечающих на запросы связи).

В компьютерном мире каждая программа, выполняемая процессором, стала процессом. Таким образом, процесс — это просто работающая программа, и все.

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

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

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

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

Давайте теперь проанализируем, как мы достигаем веб-сайтов, используя приведенную выше информацию. Когда мы используем браузер, это означает, что мы взаимодействуем с процессом (поскольку браузер — это простая программа, а значит, это просто процесс). Когда мы вводим адрес веб-сайта, мы заставляем браузер инициировать соединение с другим компьютером, который прослушивает запрошенный адрес в Интернете, чтобы получить содержимое запрашиваемой веб-страницы. Это означает, что мы заставляем один процесс (браузер) инициировать соединение с другим процессом (серверным компьютером), тем самым делая браузер клиентом, а серверный компьютер — сервером. Иллюстрация ниже значительно облегчит понимание.

Шаблоны клиент-серверной архитектуры

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

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

Существует два широко используемых шаблона архитектуры клиент-сервис:

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

Модель клиент-серверной архитектуры Monolith

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

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

Шаблон монолитной архитектуры клиент-сервер — способ построения клиентов и серверов в архитектуре клиент-сервер, где оба они несут всю необходимую системную бизнес-логику и обеспечивают все ожидаемое поведение.

Плюсы:

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

Минусы:

  • Низкая понятность. Чем больше растет ваше монолитное приложение, тем сложнее оно становится для понимания.
  • Низкая модифицируемость. Сложнее вносить изменения в такое большое и сложное приложение с очень тесной связью. Любое изменение кода влияет на всю систему, поэтому оно должно быть тщательно скоординировано. Это значительно удлиняет общий процесс разработки.
  • Низкая масштабируемость. Вы не можете масштабировать компоненты по отдельности, только все приложение.
  • Низкая переносимость. Крайне проблематично применять новую технологию в монолитном приложении, потому что тогда приходится переписывать все приложение.

Шаблон микросервисной клиент-серверной архитектуры

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

Как мы видим, микросервисы — это просто части монолита, разложенные по какому-то принципу, что дает возможность запускать их в разных процессах на одном или нескольких процессорах.

Плюсы:

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

Минусы:

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