Архитектура цифрового мира. Андрей Николаевич Трушкин
Чтение книги онлайн.

Читать онлайн книгу Архитектура цифрового мира - Андрей Николаевич Трушкин страница 10

СКАЧАТЬ релизными циклами. Многие из этих систем требовали специфических компетенций для развития. При этом компетенции требовались не только технического, но и методологического характера. В результате выпуск продукта зависел от системы с максимально длительным релизным циклом. На фоне успехов стартапов, ряд которых к началу 2010-х годов уже стали технологическими гигантами, сложившаяся ситуация не могла устраивать представителей традиционных секторов экономики (пример, приведенный в настоящей книге для финансовой организации, является характерным для традиционных секторов экономики в целом). Тенденции, сформировавшиеся после экономического кризиса 2008-го года, также требовали повышения эффективности всех отраслей человеческой деятельности. Возникла необходимость в новом революционном переходе.

      Первым этапом нового революционного перехода стала концепция микросервисной архитектуры, в соответствии с которой приложения представлялись в виде набора минимально зависимых (в идеальной ситуации независимых) модулей (микросервисов), каждый из которых представлял собой полноценную единицу развертывания с самостоятельным жизненным циклом. При этом взаимодействие микросервисов предполагалось осуществлять исключительно посредством API, что исключало необходимость владения информацией об особенностях исполнения контрагентов. Данная концепция соответствовала практикам гибкой разработки и DevOps. Пример предлагавшейся концепции представлен на Рисунке 8.

      Рисунок 8. Пример концепции микросервисной архитектуры

      Показанные на Рисунке 8 микросервисы и межсервисные взаимодействия представлены в качестве примера.

      При проектировании решений на основе микросервисной архитектуры учитывались следующие характеристики и качества микросервисов:

      • Трудоемкость. Разработку микросервиса должна вести одна команда, сформированная в соответствии с гибкими практиками разработки.

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

      • Бизнес-ориентированность. Микросервисы должны решать конкретные прикладные задачи заказчиков.

      • Простота интеграции. Для реализации взаимодействия микросервисов не требуется использования отдельных программных компонентов (по примеру рассмотренного выше ESB решения).

      • Учет возможных ошибок. Принимая во внимание возможность возникновения ошибок при выполнении жизненного цикла информационной системы, при проектировании последней в парадигме микросервисной архитектуры следует учитывать потенциальную недоступность каждого СКАЧАТЬ