Выбор архитектурного стиля. Часть 4

    В конце октября запускаем новую группу курса «Архитектура и шаблоны проектирования» и приглашаем всех специалистов на бесплатный Demo-урок «Шаблон адаптер», который проведёт Матвей Калинин — главный разработчик в одном из крупнейших банков страны.




    Введение


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

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

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

    Проблема выбора


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

    Независимое развертывание


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

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

    Улучшение отказоустойчивости


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

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

    Гибкость и ясность


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

    Но, независимость разработчиков приводит к эффекту колодца, когда никто не видит картины целиком.

    Варьирование технологического стека


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

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

    Техническая сложность


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

    Распространенные заблуждения


    С микросервисной архитектурой связан ряд заблуждений. Вот некоторые из них:
    1. Код будет чище. Код не будет чище, если не будут предприняты усилия, чтобы код стал чище.
    2. Писать модули, решающие одну задачу — легче.
      Не легче, поскольку у таких модулей будет очень много интеграций.
    3. Это работает быстрее, чем монолит.
      Монолит работает быстрее из-за меньшего количества сетевых вызовов.
    4. Инженерам проще, если не нужно работать с единой кодовой
      базой.
    5. Это самый простой способ обеспечить автоматическое
      масштабирование.
    6. И тут где-то замешан Докер.


    Заключение


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

    image
    OTUS. Онлайн-образование
    Цифровые навыки от ведущих экспертов

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое