Архитектура микросервисов
Архитектурный паттерн микросервисов быстро завоевывает позиции в индустрии как жизнеспособная альтернатива монолитным приложениям и сервис-ориентированным архитектурам. Поскольку этот архитектурный паттерн все еще развивается, в отрасли существует много путаницы относительно того, что это за паттерн и как он реализуется. В этом разделе отчета вы узнаете о ключевых концепциях и базовых знаниях, необходимых для понимания преимуществ (и компромиссов) этого важного архитектурного паттерна и того, подходит ли он для вашего приложения.
Описание паттерна
Независимо от выбранной вами топологии или стиля реализации, существует несколько общих базовых концепций, применимых к общему архитектурному шаблону. Первая из этих концепций - понятие отдельно развертываемых единиц. Как показано на рисунке 4-1, каждый компонент архитектуры микросервисов развертывается как отдельная единица, что позволяет упростить развертывание за счет эффективного и оптимизированного конвейера доставки, повысить масштабируемость и обеспечить высокую степень разделения приложений и компонентов внутри вашего приложения.
Возможно, наиболее важной концепцией, которую необходимо понять в рамках этого паттерна, является понятие сервисного компонента. Вместо того чтобы думать о сервисах в архитектуре микросервисов, лучше думать о сервисных компонентах, которые могут варьироваться по гранулярности от отдельного модуля до большой части приложения. Сервисные компоненты содержат один или несколько модулей (например, Java-классы), которые представляют собой либо одноцелевую функцию (например, предоставление погоды для определенного города или поселка), либо независимую часть большого бизнес-приложения (например, размещение акций или определение тарифов автострахования). Разработка правильного уровня гранулярности сервисных компонентов - одна из самых сложных задач в архитектуре микросервисов. Более подробно эта проблема рассматривается в следующем подразделе, посвященном оркестровке сервисных компонентов.
Еще одна ключевая концепция архитектуры микросервисов заключается в том, что это распределенная архитектура, то есть все компоненты архитектуры полностью отделены друг от друга и доступны через какой-либо протокол удаленного доступа (например, JMS, AMQP, REST, SOAP, RMI и т. д.). Благодаря распределенной природе этого архитектурного паттерна достигаются превосходные характеристики масштабируемости и развертывания.
Один из интересных моментов в архитектуре микросервисов заключается в том, что она развилась из проблем, связанных с другими распространенными архитектурными паттернами, а не была создана как решение, ожидающее возникновения проблемы. Стиль архитектуры микросервисов естественным образом развился из двух основных источников: монолитных приложений, разработанных с использованием паттерна многоуровневой архитектуры, и распределенных приложений, разработанных с использованием паттерна сервис-ориентированной архитектуры.
Эволюционный путь от монолитных приложений к архитектуре микросервисов был проделан в первую очередь благодаря развитию непрерывной доставки (continuous delivery) - концепции непрерывного конвейера развертывания от разработки до производства, которая упрощает развертывание приложений. Монолитные приложения обычно состоят из тесно связанных компонентов, которые являются частью одного развертываемого блока, что делает изменение, тестирование и развертывание приложения громоздким и сложным (отсюда и возникновение распространенных циклов "ежемесячного развертывания", типичных для большинства крупных ИТ-компаний). Эти факторы обычно приводят к появлению хрупких приложений, которые ломаются каждый раз, когда развертывается что-то новое. Архитектурный паттерн микросервисов решает эти проблемы путем разделения приложения на несколько развертываемых единиц (сервисных компонентов), которые можно разрабатывать, тестировать и развертывать по отдельности, независимо от других сервисных компонентов.
Другой путь эволюции, который привел к шаблону архитектуры микросервисов, связан с проблемами, возникающими в приложениях, реализующих шаблон сервис-ориентированной архитектуры (SOA). Хотя паттерн SOA очень мощный и предлагает беспрецедентные уровни абстракции, гетерогенную связность, оркестровку сервисов и обещание согласовать бизнес-цели с возможностями ИТ, он, тем не менее, сложный, дорогой, повсеместный, трудный для понимания и внедрения и обычно избыточен для большинства приложений. Стиль архитектуры микросервисов решает эту проблему путем упрощения понятия сервиса, устранения необходимости в оркестровке и упрощения подключения и доступа к компонентам сервиса.
Топологии паттерна
Хотя существуют буквально десятки способов реализации архитектуры микросервисов, наиболее распространенными и популярными являются три основные топологии: топология на основе API REST, топология на основе приложений REST и топология централизованного обмена сообщениями.
Топология на основе API REST полезна для веб-сайтов, которые предоставляют небольшие, самодостаточные отдельные сервисы через некий API (интерфейс прикладного программирования). Эта топология, показанная на рисунке 4-2, состоит из очень тонких компонентов сервисов (отсюда и название "микросервисы"), которые содержат один или два модуля, выполняющих определенные бизнес-функции независимо от остальных сервисов. В этой топологии доступ к таким мелкодисперсным компонентам сервисов обычно осуществляется с помощью интерфейса на основе REST, реализованного через отдельно развернутый веб-уровень API. Примерами такой топологии могут служить некоторые распространенные одноцелевые облачные RESTful веб-сервисы Yahoo, Google и Amazon.
Топология на основе REST-приложений отличается от подхода на основе API REST тем, что клиентские запросы поступают через традиционные экраны веб-приложений или толстых клиентов, а не через простой слой API. Как показано на рисунке 4-3, слой пользовательского интерфейса приложения развертывается как отдельное веб-приложение, которое удаленно обращается к отдельно развернутым компонентам сервисов (бизнес-функциональность) через простые интерфейсы на основе REST. Компоненты сервисов в этой топологии отличаются от компонентов в топологии на базе API-REST тем, что эти компоненты сервисов, как правило, крупнее, более крупнозернистые и представляют собой небольшую часть всего бизнес-приложения, а не мелкозернистые сервисы с одним действием. Такая топология характерна для бизнес-приложений малого и среднего размера, которые имеют относительно низкую степень сложности.
Еще одним распространенным подходом в рамках паттерна архитектуры микросервисов является топология централизованного обмена сообщениями. Эта топология (рисунок 4-4) похожа на предыдущую топологию приложений на основе REST, за исключением того, что вместо REST для удаленного доступа в этой топологии используется легкий централизованный брокер сообщений (например, ActiveMQ, HornetQ и т. д.). При рассмотрении этой топологии крайне важно не путать ее с паттерном сервис-ориентированной архитектуры и не считать ее "SOA-Lite". Легкий брокер сообщений в этой топологии не выполняет никакой оркестровки, трансформации или сложной маршрутизации; скорее, это просто легкий транспорт для доступа к удаленным компонентам сервисов.
Топология централизованного обмена сообщениями обычно встречается в крупных бизнес-приложениях или приложениях, требующих более сложного контроля над транспортным уровнем между пользовательским интерфейсом и компонентами сервиса. Преимуществами такой топологии по сравнению с простой топологией на базе REST, о которой говорилось ранее, являются усовершенствованные механизмы очередей, асинхронный обмен сообщениями, мониторинг, обработка ошибок, а также лучшая общая балансировка нагрузки и масштабируемость. Проблемы единой точки отказа и узких мест в архитектуре, обычно связанные с централизованным брокером, решаются с помощью кластеризации брокеров и федерации брокеров (разделение одного экземпляра брокера на несколько экземпляров брокера для распределения нагрузки на пропускную способность сообщений по функциональным областям системы).
Перевод книги "Software Architecture Patterns".