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

Архитектурный паттерн на основе пространства (Spaced-based) - сложный и дорогой в реализации паттерн. Это хороший выбор архитектуры для небольших веб-приложений с переменной нагрузкой (например, сайты социальных сетей, сайты торгов и аукционов). Однако он не очень хорошо подходит для традиционных крупномасштабных приложений с реляционными базами данных и большими объемами оперативных данных.

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

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

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

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

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

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

Топология брокера отличается от топологии посредника тем, что центральный посредник событий отсутствует, а поток сообщений распределяется между компонентами процессора событий по цепочке через легкий брокер сообщений (например, ActiveMQ, HornetQ и т.д.). Такая топология удобна, когда у вас относительно простой поток обработки событий и вам не нужна (или нужна) централизованная оркестровка событий.

Архитектура на основе событий или Событийно-ориентированная архитектура (EDA - Event-Driven Architecture) - это популярный паттерн распределенной асинхронной архитектуры, используемый для создания высокомасштабируемых приложений. Он также обладает высокой адаптивностью и может использоваться как для небольших приложений, так и для больших и сложных. Событийно-ориентированная архитектура состоит из высокоразвязанных одноцелевых компонентов обработки событий, которые асинхронно получают и обрабатывают события.