Шаблоны проектирования

Монолитный

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

Клиент — сервер

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

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

Сервисы

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

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

В то время как архитектуры на основе сервисов становились очень популярны в качестве архитектур cloud native, для проектирования сервисов потребовалось время.

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

Микросервисы

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

объем услуг и методы соединения.

Микросервисы предназначены для дальнейшей специализации сферы услуг.

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

Другой ключевой особенностью микросервиса является метод связи. SOA часто связывается с разнородными протоколами через ESB, где микросервисы предо ставляют API, который может вызываться любым сервисом-потребителем. Такое предоставление доступа к API позволяет разрабатывать сервис на любом языке, на который не будут влиять другие сервисы, их язык разработки или подход. Благодаря тому что слой API является отдельным компонентом, изменения в логике сервиса часто не требуют координации между потребительскими сервисами, и даже когда сам API модифицируется, необходимо уведомлять только сервисы-потребители, что часто можно выполнить посредством динамической идентификации конечной точки API и навигации.