диаграмма вариантов использования микросервисов

Что делать, когда ваши микросервисы начинают «говорить своими словами»?

Представьте себе: у вас под рукой очень сложный проект, микросервисная архитектура, звучит очень высококлассно, не так ли? Каждый сервис вполне способен, но вместе? Общение похоже на международную конференцию без переводчика. Служба Б не смогла понять данные, сгенерированные службой А; служба C отправила команду, но служба D долгое время не отвечала. Со временем вы обнаружите, что можете тратить больше времени на отладку и обеспечение «понимания» этих сервисов друг друга, чем на разработку самой функциональности.

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

Существует ли «карта», которая с самого начала может четко показать, как эти службы взаимодействуют и кого они обслуживают? Сделать это не только технической диаграммой для разработчиков, но и «раскадровкой», которую сможет понять вся команда — даже друзья, не столь разбирающиеся в технических вопросах?

Может ли фотография сделать сотрудничество более не «угадывающим»?

Именно здесь в игру вступает диаграмма вариантов использования микросервисов. Его не волнует, что используется в вашем коде, его волнует, «кто» (пользователь или внешняя система) хочет «делать» (цель) и «как» ваш микросервис реагирует на эти вещи.

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

Кто-то может спросить: «В чем разница между этой схемой архитектуры системы и схемой архитектуры системы, которую мы нарисовали ранее?» Что ж, давайте воспользуемся аналогией. Архитектурный чертеж больше похож на строительный чертеж водопровода и электропроводки дома. Это очень техничный документ, который рассказывает инженеру, как прокладывать трубопроводы. Диаграмма вариантов использования больше похожа на «диаграмму линии жизни» для домовладельца: готовим здесь, отдыхаем там, а гостиная используется для приема гостей. Он описывает ценность, которую должна обеспечивать система с точки зрения бизнеса и пользователей. Если сначала уточнить, «какую жизнь вы хотите прожить», а затем спланировать, «как проложить трубы», вероятность допустить ошибки зачастую меньше.

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

Идея хорошая, но когда дело доходит до реализации, зачастую первым препятствием становится выбор инструментов. Что вам нужно, так это что-то, что позволит вам сосредоточиться на самом «выражении», а не бороться с громоздкими операциями.

Это должно быть достаточно интуитивно понятно. Вы можете перетаскивать, чтобы соединять роли, варианты использования и отношения так же естественно, как строительные блоки. Это также требует некоторой серьезности и способности следовать некоторым базовым спецификациям UML, чтобы гарантировать, что нарисованное может быть распознано и понято всеми, а не просто случайными граффити. Гибкость также имеет ключевое значение — взаимоотношения между микросервисами иногда бывают довольно сложными. Один вариант использования может включать несколько сервисов, а один сервис может поддерживать несколько вариантов использования. Инструмент должен иметь возможность удобно выражать эту связь «многие ко многим», а не заставлять вас сводить ее к простой связи «один к одному».

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

От чертежной доски к реальности: пусть каждая услуга найдет свое место

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

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

Границы служебных обязанностей были вынуждены проясниться. В процессе рисования вы постоянно будете спрашивать себя: «Какому сервису принадлежит эта функция?» Это может эффективно предотвратить возникновение «серой зоны» дублирования или отсутствия функций между службами. Так же, как и разделение комнаты на функциональные зоны, в гостиной не будет стиральной машины, а на кухне – кровати.

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

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

Итак, что дальше?

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

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

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода.мощностьпредоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.