Русский
Русский
English
Статистика
Реклама

Связанность

Выбор архитектурного стиля (часть 2)

17.09.2020 12:16:31 | Автор: admin
Привет, хабр. Сегодня я продолжаю серию публикаций, которую написал специально к старту нового потока курса Software Architect.



Введение


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

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

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

Компонентно-ориентированная архитектура


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

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

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

Самая главная проблема такого монолита заключается в том, что разделение на модули является чисто логическим и может быть легко нарушено разработчиками. Может появиться модуль core, который постепенно превращается в помойку, может расти граф зависимостей между модулями и так далее. Для избежания таких проблем разработка должна вестить либо очень зрелой командой, либо под руководством архитектора, который на full time занимается code review и бьет нарушающих логическую структуру разработчиков по рукам.

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

Сервис-ориентированная архитектура


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

Сервис-ориентированная архитектура (SOA = service oriented architecture) решает все обозначенные проблемы монолита: при изменении затрагивается только одна служба, а четко определенный API поддерживает хорошую инкапсуляцию компонент.

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

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

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

Пик популярности сервис-ориентированной архитектуры приходился примерно на 2008 год, после чего она пошла на спад, который стал существенно более резким после появления микросервисов (~2015 год).

Заключение


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

Подробнее..

Выбор архитектурного стиля (часть 3)

28.09.2020 02:15:18 | Автор: admin
Привет, Хабр. Сегодня я продолжаю серию публикаций, которую написал специально к старту нового потока курса Software Architect.



Введение


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

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

Сейчас мы наконец определим основные характеристики микросервисной архитектуры.

Отношение архитектур


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

Характеристики микросервисной архитектуры


Основными характеристиками микросервисной архитектуры являются:

Организация в соответствии с бизнес-возможностями
(Organized around Business Capabilities)
Продукты, а не проекты (Products not Projects)
Умные точки входа и глупые каналы (Smart endpoints and
dumb pipes)
Децентрализованное управление (Decentralized Governance)
Децентрализованное управление данными (Decentralized
Data Management)
Автоматизация инфраструктуры (Infrastructure Automation)
Страховка от сбоев (Design for failure)
Архитектура с эволюционным развитием (Evolutionary
Design)

1-ый пункт приходит от сервис-ориентированной архитектуры, потому что микросервисы являются частным случаем сервисов. Другие пункты заслуживают отдельного рассмотрения.

Организация в соответствии с бизнес-возможностями (Organized around Business Capabilities)


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

Если мы говорим про монолиты и микросервисы, то в том случае, если разработка организована по функциональным отделам (бэкенд, фронтенд, администраторы баз данных), то получается классический монолит.

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

Продукты, а не проекты (Products not Projects)


Проектный подход при котором команда передает разработанную функциональность другим командам в случае микросервисной архитектуры совершенно не подходит. Команда должна поддерживать систему на протяжении всего ее жизненного цикла. Компания Amazon, один из флагманов внедрения микросервисов, заявляла: вы создаете продукт, и вы же запускаете его (you build, you run it). Продуктовый подход позволяет команде почувствовать потребности бизнеса.

Умные точки входа и глупые каналы (Smart endpoints and dumb pipes)


SOA архитектура большое внимание уделяла каналам связи, в частности Enterprise Service Bus (сервисная шина предприятия). Что зачастую приводит к Erroneous Spaghetti Box, то есть сложность монолита переходит в сложность связей между сервисами. В микросевисной архитектуре используются только простые способы взаимодействия.

Децентрализованное управление (Decentralized Governance)


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

Децентрализованное управление данными (Decentralized Data Management)


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

Автоматизация инфраструктуры (Infrastructure Automation)


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

Страховка от сбоев (Design for failure)


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

Архитектура с эволюционным развитием (Evolutionary Design)


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

Заключение


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



Читать часть 2
Подробнее..

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

12.10.2020 16:11:28 | Автор: admin
В конце октября запускаем новую группу курса Архитектура и шаблоны проектирования и приглашаем всех специалистов на бесплатный Demo-урок Шаблон адаптер, который проведёт Матвей Калинин главный разработчик в одном из крупнейших банков страны.




Введение


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

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

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

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


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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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


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


Заключение


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

image
Подробнее..

Выбор архитектурного стиля (часть 1)

28.08.2020 14:05:29 | Автор: admin
Привет, хабр. Прямо сейчас в OTUS открыт набор на новый поток курса Software Architect. В преддверии старта курса хочу поделиться с вами своей авторской статьёй.



Введение


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

Немного истории


Если вы попробуете задать вопрос разработчикам: Зачем нужны микросервисы?, то вы получите самые различные ответы. Вы услышите, что микросервисы улучшают масштабирование, упрощают понимание кода, улучшают отказоустойчивость, иногда можно услышать, что они позволяют очистить код. Давайте обратимся к истории, чтобы понять, какую цель приследовало появление микросервисов.

Если говорить вкратце, то микросервисы в нашем текущем понимании возникли следующим образом: в 2011 Джеймс Льюис, анализируя работы различных компаний, обратил внимание на появление нового паттерна micro-app, который оптимизировал SOA с точки зрения ускорения развертывания сервисов. Несколько позже, в 2012 году, на архитектурном саммите паттерн был переименован в микросервис. Таким образом, первоначальной целью внедрения микросервисов было улучшение пресловутого time to market.

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

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

Монолит


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

Размер


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

Связанность


Монолит представляет из себя большой комок грязи (big ball of mud), изменения в котором могут привести к непредсказуемым последствиям. Внося изменения в одном месте, можно повредить монолит в другом (то самое ухо почесал, *@ отвалилась). Связано это с тем, что компоненты в монолите имеют очень сложные и, главное, неочевидные взаимосвязи.

Развертывание


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

Масштабируемость


Модули монолита могут иметь конфликтующие потребности в ресурсах, из-за чего необходимо искать компромисс с точки зрения железа. Представьте себе, что у вас монолит состоит из сервисов A и B. Сервис A требователен к размеру жесткого диска, а сервис B к оперативной памяти. В таком случае, либо машина, на которую ставится монолит, должна поддерживать требования обоих сервисов, либо придется руками, искуственно один из сервисов отключать.

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

Надежность


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

Косность


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

Заключение


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



Читать ещё:


Подробнее..

Перевод Мониторинг и управление потоком задач в рамках взаимодействия микросервисов

14.01.2021 14:20:31 | Автор: admin


Ключевые тезисы:

  • Взаимодействие между компонентами напрямую друг с другом может привести к неожиданному поведению, в котором сложно будет разобраться разработчикам, операторам и бизнес-аналитикам.
  • Чтобы обеспечить устойчивость бизнеса, вам нужно видеть все возникающие в системе взаимодействия.
  • Добиться этого позволяют разные подходы: распределённая трассировка, обычно не учитывающая бизнес-аспекты; озёра данных, требующие заметных усилий по настройке получаемых срезов данных; отслеживание процессов, когда вам приходится моделировать интересующий поток задач; контроль и анализ процессов (process mining), позволяющие исследовать поток задач; и вплоть до оркестрации, в которой прозрачность процессов уже имеется.
  • Мы поговорим о том, что вам нужно балансировать между оркестрацией и хореографией микросервисной архитектуры, чтобы понимать, управлять и менять свою систему.


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

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


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


Хореографируемый поток событий.

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


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

Потеря прозрачности потока событий


Я хочу сосредоточиться на вопросе, возникающем чаще всего, когда я участвую в обсуждениях этой архитектуры: Как избежать потери прозрачности (и, вероятно, контроля) потока событий? В одном из исследований сотрудники Camunda (где я работаю) спрашивали об использовании микросервисов. 92 % респондентов как минимум рассматривали их, а 64 % уже использовали в том или ином виде. Это уже не хайп. Но в том исследовании мы также спрашивали и о трудностях, и получили чёткое подтверждение наших опасений: чаще всего нам говорили о потере сквозной прозрачности бизнес-процессов, задействующих многочисленные сервисы.


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

Обеспечение прозрачности


Что можно сделать в такой ситуации? Следующие подходы помогут вам вернуть прозрачность, но у каждого из них есть свои достоинства и недостатки:

  1. Распределённая трассировка (например, Zipkin или Jaeger).
  2. Озёра данных или аналитические инструменты (например, Elastic).
  3. Контроль и анализ процессов (process mining) (например, ProM).
  4. Отслеживание с помощью автоматизации потоков задач (например, Camunda).

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

Распределённая трассировка


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


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

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

  • В трассировке трудно разобраться неспециалистам. Все мои попытки показать трассировки людям, далёким от техники, с треском провалились. Оказалось гораздо лучше потратить время на перерисовку той же информации в виде блоков и стрелок. И даже если вся эта информация о вызовах методов и сообщениях очень полезна для понимания схем взаимодействия, она оказывается слишком подробна для понимания ситуации с межсервисными бизнес-процессами.
  • Для управления избыточным объёмом подробных данных в распределённой трассировке применяется так называемое сэмплирование. Это означает, что собирается лишь небольшая доля запросов, и обычно больше 90 % всех запросов вообще не регистрируется. Об этом хорошо написано в статье Three Pillars with Zero Answers towards a New Scorecard for Observability. Так что у вас никогда не будет полной картины происходящего.

Озёра данных или аналитические инструменты


Итак, сама по себе трассировка вряд ли нам подходит. Логично будет обратиться к схожему подходу, но с учётом нашей конкретной задачи. Обычно это означает сбор не трассировок, а важных бизнес- или тематических событий, с которым вы, возможно, уже и так сталкивались. Часто решение сводится к созданию сервиса, который слушает все события и сохраняет их в базе, что может повышать нагрузку на систему. Сегодня многие используют для этого Elastic.


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


Пример интерфейса мониторинга событий.

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


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

Инструменты для контроля и анализа процессов (process mining)


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

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


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


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

Отслеживание с помощью автоматизации потоков задач


Другой интересный подход моделирование потоков задач с последующим развёртыванием и исполнением посредством модуля управления. Эта модель особенная в том смысле, что она только отслеживает события, а сама ничего активно не делает. То есть ничем не управляет только регистрирует. Я рассказывал об этом на Kafka Summit San Francisco 2018, используя для демонстрации Apache Kafka и open source-модуль управления рабочими процессами Zeebe.


Эта возможность особенно интересна. В сфере модулей управления немало инноваций, что приводит к появлению инструментов, которые компактны, удобны для разработки и высокомасштабируемы. Я писал об этом в статье Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation. К очевидным недостаткам относится необходимость предварительного моделирования потока задач. Но зато эту модель можно исполнять с помощью модуля управления процессами, в отличие от мониторинга событий. По сути, вы запускаете экземпляры процессов для входящих событий или соотносите события с каким-либо экземпляром. Также это позволяет проверить, соответствует ли реальность вашей модели.

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


Пример мониторинга потока задач.

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

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

Перспективы для бизнеса


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

От отслеживания к управлению


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

Например, вы можете начать с мониторинга таймаутов в сквозных процессах. Когда происходит таймаут, автоматически выполняется некое действие. В примере ниже, спустя 14 дней мы уведомим клиента о задержке, но всё ещё будем ждать. А через 21 день отменим заказ.


Любопытно, что здесь отправка команды на отмену заказа это оркестрация, которая часто обсуждается в противоречивой манере.

Оркестрация


Я часто слышу, что нужно избегать оркестрации, поскольку она приводит к связанности или нарушает автономность отдельных микросервисов, и конечно, её можно плохо реализовать. Но можно реализовать и так, чтобы оркестрация соответствовала принципам микросервисов и приносила бизнесу большую пользу. Я подробно говорил об этом на InfoQ New York 2018.

Для меня оркестрация означает, что один сервис может скомандовать другому что-то сделать. И всё. Это не тесная связанность, а связанность иного рода. Вспомним наш пример с заказом. Может оказаться целесообразным, чтобы кассовый сервис всего лишь генерировал заказ и клал его в шину событий, не зная, кто его обработает. Сервис заказов подхватывает событие о появившемся заказе. Получатель узнаёт о событии и решает что-нибудь сделать в связи с этим. То есть связанность присутствует на стороне получателя.

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

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


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

Однако в этой статье я хотел сосредоточиться на прозрачности. И у оркестрации, использующей модуль управления потоками задач, есть очевидное преимущество: модель это не просто код для исполнения оркестратором, её можно использовать для обеспечения прозрачности потока.


Заключение


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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru