Когда ваш проект микросервисов выглядит как набор разрозненных частей

Был ли у вас когда-нибудь такой момент? Глядя на мою тщательно спроектированную микросервисную архитектуру, я вдруг почувствовал, что она похожа не на гибкую систему, а скорее на разобранную машину с дистанционным управлением — каждая часть может двигаться, но работать вместе она просто не может. Мы часто слышим жалобы команд: «Сервисы демонтированы, но почему мне всегда кажется, что чего-то не хватает?»

Что именно определяет «телосложение» микросервисов?

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

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

Это граница сервиса — речь не идет о том, чтобы нарисовать ее там, где вы хотите.

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

Кроме того, существует механизм связи, а не просто отправка сообщений.

Как мы разговариваем друг с другом? Это определяет скорость нейронной реакции всей системы. Некоторым людям нравится использовать синхронный HTTP API, который, по их мнению, прост; некоторые люди предпочитают асинхронные очереди сообщений, говоря, что они полностью отделены друг от друга. На самом деле, какой из них выбрать, зависит от сцены. Оплата заказа может потребовать немедленного подтверждения, поэтому подойдет синхронизация; не имеет значения, что уведомление о доставке задерживается на несколько секунд, так проще пройти через очередь сообщений.

Автономность данных — у каждого сервиса должен быть свой небольшой склад.

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

Есть еще незаметные, но важные «опорные части».

Например, обнаружение служб. В сети появился новый сервис. Как сообщить другим братьям, где он находится? Вы не сможете каждый раз настраивать адрес вручную. Другой пример — управление конфигурацией. Сервисов десятки, каждый со своими настройками. Нужно ли менять их по одному? Эти поддерживающие компоненты подобны винтам и шайбам в машинах. Они кажутся маленькими, но без них вся конструкция была бы рыхлой.

Возникает вопрос: как собрать эти компоненты в скоординированную систему?

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

Вам необходимо выбрать правильный протокол связи. Например, выбор сигнала управления для сервопривода, ШИМ или последовательной команды? Разные сцены требуют разного ритма. Вызовы внутренних служб могут выполняться быстрее с помощью gRPC, а REST более универсален для внешних API. Не существует абсолютного добра или зла, есть только подходящее или нет.

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

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

От частей к целому: более простой процесс сборки

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

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

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

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

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