Где следует подтянуть люфт? Давайте поговорим о головной боли микросервисов

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

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

Почему ваши микросервисы всегда «дерутся»?

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

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

Поэтому кто-то спросил: стоит ли нам сделать сервис максимально «большим» и сократить количество звонков? Но это означало бы возврат к старому пути монолитной архитектуры. Или разделить услугу на более мелкие части? Затраты на управление снова растут.

На самом деле ответ не «большой или маленький», а «как подключить».

Хорошее соединение похоже на бесперебойную систему передачи

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

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

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

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

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

От «как сделать» к «как выбрать»

Этот метод кажется простым, но при его реализации вы всегда будете сталкиваться с конкретными вопросами с несколькими вариантами ответов. например:

• Для связи между сервисами следует ли нам использовать синхронные вызовы или асинхронные сообщения?
• Должны ли данные предоставляться совместно или храниться отдельно?
• Где находится подходящая граница для функции?

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

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

Когда мы говорим о микросервисах, о чем мы говорим?

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

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

Хорошая микросервисная архитектура стремится именно к этому состоянию – независимому, но не антагонистическому; подключен, но не в комплекте.

Итак, прежде чем удалить службу в следующий раз, спросите себя:

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

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

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

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

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