Comments 25
Большое спасибо за статью.
Насколько детально должен системный аналитик задуматься о поддержании целостности данных, когда он рисует диаграмму последовательности по взаимодействию микросервисов? Либо этот вопрос оставим для архитектора/разработчиков?
Спасибо за комментарий.
Не совсем поняла вопрос: целостность данных должна поддерживаться при проектировании БД. Диаграмма последовательности описывает вызовы к сервисам. Или Вы что-то другое имели в виду? Может, есть пример?
Видимо, тут вопрос про что-то вроде распределенных транзакций и непротиворечивость данных.
В случае с транзакциями: при отмене заказа в сервисе orders должен измениться незарезервированый остаток в сервисе stock (навскидку, все совпадения случайны).
В случае непротиворечивости данных: должно ли при изменении наименования товара А в сервисе goods изменяться название товара в заказе сервиса orders.
Ну и плюсом: микросервисная архитектура накладывает свои ограничения, боттлнеки - чья головная боль, аналитика или архитектора?
Спасибо. Такие задачи часто определяются бизнес-требованиями и непосредственно влияют на функционал. Так что аналитику как минимум нужно знать о их реализации. В моей практике это описывал аналитик в требованиях (не обязательно прямо всё в диаграммы вставлять, они так становятся тяжело читаемыми). А команда подхватывала и задавала неудобные вопросы/тест-кейсы для проверки полноты, непротиворечивости и пр.
Но в принципе нет какого-то универсального свода обязанностей для любого члена команды разработки. В agile-командах люди договариваются и сами решают, как им удобнее работать. То есть команда может решить, что аналитику лучше заниматься общением с заказчиком и разработкой процессов, а все эти предохранители, повествования, взаимосвязи данных и пр. - задача разработчиков. И на конкретном продукте это действительно может быть эффективно.
По поводу архитекторов: тут, на мой взгляд, тоже зависит от конкретики. То есть если все процессы плохо работают из-за низкой доступности сервисов и синхронного обмена между ними - это скорее коллегиальная задача, лидируемая архитектором. А если в вашем апи-шлюзе перегружен какой-то метод - вроде можно и самим решить вопрос. В целом, мне кажется, что любая проблема системы/продукта - это общая головная боль, каждый должен подключаться к решению по мере своих возможностей и компетенций.
Думаю, что когда аналитик проектирует диаграммы последовательности, то уже начинает понемногу вторгаться на территорию архитектора из-за учёта нефункциональных требований. Ну а когда в требованиях появляется указание использовать асинхронное взаимодействие и отдать обработку ошибок на откуп брокеру, то без проработки возможных последствий, а в особенности недостижимого консистентного состояния в общем случае, это вторжение не пройдёт незамеченным. И речь тут вообще не про роли в agile, а про последствия для системы.
В целом да, когда кто-то выполняет работу, для которой у него недостаточно компетенций - это чревато проблемами. Однако не факт, что аналитик не в состоянии качественно проработать "возможные последствия". Особенно если речь идет о конкретных процессах системы, а не об общих арх. подходах.
Архитектор может дать арх.шаблон и общие рекомендации по реализации процессов. Аналитики же прорабатывают конкретные взаимодействия и все возможные последствия. На мой взгляд, это нормальный работающий процесс. Конечно, при условии достаточного уровня компетенций как у аналитиков, так и у архитектора.
Спасибо, что уточнили. Этот вопрос и подразумевал.
В качестве аналитика, я бы вместо последовательности вызовов (диаграмма "Процесс OfflineSale") описал бы зависимости - что нужно вызывать после чего. И все микросервисы заставил бы слушать шину сообщений. Чтобы например, управление запасами работало не синхронно, а по событию об оплате, в свою очередь генерируя событие Purchase - тем более что у вас все равно message broker уже присутствует. Если захочется - все эти события можно пересылать еще и клиенту - держа его в курсе происходящего.
Это позволит избежать многих проблем - от простейших, когда ответ не возвращается пока функция-обработчик запроса не закончит работу - до более сложных, когда все обработчики ждут "притормознувший" микросервис, отказывая клиентам в обслуживании других запросов.
И разбираться в этом гораздо проще - по логам брокера сразу видно, что происходило и когда.
Спасибо за комментарий. Там ниже написано про возможные проблемы с доступностью и что в идеале взаимодействия между микросервисами лучше делать через брокер. Но аналитик не всегда принимает такие решения и иногда просто работает с тем, что есть. А бывают и прямые вызовы микросервисами друг друга. Поэтому на диаграмме указала разные варианты взаимодействия.
Подскажите, а в каким формате Вы бы описывали зависимости?
Не слышал, чтоб менеджеры очередей были серебряной пулей. У них там свои беды, кажется
Большое спасибо за статью! Схемы к статье в какой программе прорисовывались (process offline sale, интеграция с внешним сервисом и т.д.) - очень эффектные получились для восприятия (BPM процесс я так поняла в Camunda Modeler)? Спасибо.
Спасибо) Это https://excalidraw.com. А bpmn в Camunda Modeler, да.
Спасибо. Добавил статью в закладки. Буду шарить аналитикам с монолитным сознаним.
На бизнес вы зря наговариваете) Сейчас продуктовые команды обычно содержат достаточно прошаренный бизнес. У нас, например, даже архитектуру прорабатывают с архитекторами )
Было бы интересно узнать подробнее про последовательность и форматы документации.
Делаете ли модель потоков данных? Когда/как разбиваете на процессы? Диаграммы последовательностей, что еще создаете?
Ох, это тема для отдельной статьи. Ну и как и писала, пока у меня и коллег не получилось внедрить систему документации, которая бы закрывала все вопросы.
DFD не делали: верхнеуровнево эти данные на схемах бизнес-процессов отображали, а ниже уже на сиквенсах. Процессы формируются в соответствии с бизнес-задачами (то есть задача реализовать такой вот процесс) или по сути являются вариантами использования.
Документировать стараюсь начиная с описания бизнес-процесса (схема/BRD/use cases). Далее есть шаблон для описания микросервиса и его API, схемы bpmn для Camunda. Диаграммы sequence, activity, state в основном.
По поводу диаграмм также хочу отметить, что в ситуации, когда процесс правят много команд, иногда лучше вообще не рисовать диаграмму. Потому что кто-то обязательно забудет ее изменить и она станет неактуальной. А лучше никакой документации, чем неактуальная, выдающая себя за актуальную.
Вот кстати хороший шаблон для описания микросервиса: https://github.com/cer/microservice-canvas
Одной из проблем тех, кто работает с Сервисами, является неправильное структурирование. Вот на этом ресурсе https://www.opengroup.org/soa/source-book/soa_refarch/p5.htm описана 10 уровневая модель. Эта модель широко применяется в мире. Более того, примерно тоже самое, что описано на этом сайте, но с небольшими отличиями является стандартом ISO/IEC 18384 части 2 и 3. Хороший пример практического применение 10 уровневой модели - это любимый многими Kubernetes, он с небольшими оговорками полностью ложится в эту модель.
Ресурс очень большой. И для того, чтобы прочесть его, не говоря уже о том, чтобы осознать требуется время. Причем, надо сразу понимать, что работа в парадигме SOA требует перестройки сознания. Многое то, что является привычным и банальным в SOA, работает не так. Например, UML имеет расширения. Поэтому я бы советовал начать вот с этого https://www.opengroup.org/soa/source-book/togaf/p4.htm
Если это покажется слишком заумным, то посмотреть на рисунок, описывающий эталонную архитектуру SOA из предыдущей ссылки и прочесть https://www.opengroup.org/soa/source-book/soa_refarch/p4.htm
На возражение Аналитиков, что это все ближе к Архитекторам, чем к Аналитикам хочется возразить, что понимание 10 уровневой модели помогает правильно структурировать сквозной характер событий на уровнях Интеграции (Integration), Качества обслуживания (Quality of Service) и Информационном (Information).
Татьяна, большое спасибо за интересную статью!
Заинтересовал момент о квалификации аналитика и пороге вхождения в проекты с микросервисной архитектурой. В голове родился популистский слоган: "Джунам и новичкам тут нет места!" Но давайте по порядку.
Если смотреть со стороны, то аналитиков и их задачи в проекте с микросервисной архитектурой можно разделить на две роли/категории:
аналитики решения (аналитики кроссервисных задач)
аналитики сервисов
аналитики решения - работают с кроссервисными задачами, включающими интеграции, очереди, балансировки и все остальные прелести, перечисленные автором. Они должны обладать широкими знаниями технологий, опытом и глубоким пониманием системы.
аналитики сервисов - решают задачи, контекст которых локализован внутри отдельных сервисов, и для аналитика это становится просто продуктом, который имеет ряд внешних интеграций.
Таким образом, из различий в решаемых задачах, уровне компетенций и глубине знания продукта вытекает приведенный выше лозунг с небольшим уточнением: "Джунам и новичкам в решении кроссервисных задач нет места".
Обусловлено это тем, что джун, не решавший ранее никаких задач, потеряется в дебрях межсервисных взаимодействий, технологий и бизнес логики, опытный новичок на проекте так же будет плутать без глубоких знаний назначения сервисов.
Однако вопросы роста команды, вместе с ростом количества задач и текучки кадров, всегда будут актуальны, отсюда наиболее эффективным маршрутом адаптации и развития аналитиков видится их первичное привлечение к решению задач в рамках отдельных сервисов с последующим расширением кругозора на всю систему и переходом уже в разряд аналитиков решения.
Интересно услышать ваше мнение на этот счет? =)
Егор, спасибо.
Такого варианта распределения задач не видела. Вот какие соображения есть на этот счет: задачи обычно приходят на процесс в целом, то есть старшему аналитику так или иначе нужно будет прорабатывать общую задачу. Далее старший аналитик декомпозирует большую кроссервисную задачу на более простые подзадачи. В этот момент теоретически старший аналитик может раздавать подзадачи младшим аналитикам. В целом, это хороший способ обучения и распределения задач.
Однако, в реальной жизни часто при проработке подзадач всплывают моменты, из-за которых нужно править другие части большой задачи. То есть в итоге общее время выполнения задач при таком распределении скорее всего будет бОльше, чем если бы старший аналитик все делал сам.
Возможно, есть проекты с относительно стабильным функционалом и исчерпывающей документацией, где микросервисы внутри себя хранят значительные куски бизнес-логики. Кажется, что там эта схема может оказаться рабочей. Но в других случаях это скорее решение для процесса адаптации аналитиков. И при условии, что новый сотрудник будет обучаться достаточно быстро.
Вопрос.
1.Почему вы вместо graphQL не используйте xsd или jdonschema?
2.Также иниересно ваше мнение, всегда ли уместно использовать микросервисы?
Вроде нет в тексте указания, что везде надо использовать GraphQL, на каждом проекте это индивидуально. В принципе GraphQL удобен, когда есть несколько потребителей API, каждый со своей логикой, а также при сложных и разнообразных выборках на фронте.
Конечно, нет, как и любую другую технологию. Все индивидуально определяется в зависимости от продукта и компании. В тексте есть три ссылки на статьи с разбором плюсов и минусов микросервисов.
картинка с добавлением поля discount даже страшнее чем картинка с Чужим
Микросервисы глазами аналитика