как соединить два микросервиса

Хорошо, поехали.

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

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

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

Итак, как хорошо судить?

Все начинается с выбора правильного «языка» — протокола связи. MQTT легок и отлично подходит для прерывистых сообщений. HTTP REST прост, знаком, но, возможно, не самый быстрый для постоянной болтовни. Еще есть gRPC, эффективный и строгий, идеально подходящий, когда вам нужна скорость и четкие контракты. Это все равно, что выбирать между рацией, телефонным звонком или рукописной заметкой — каждый из них подходит к разным сценам.

Но протокол – это только начало. Настоящее волшебство – в узорах.

Думайте об этом как о хорошо организованном семинаре. Вы не хотите, чтобы все выкрикивали просьбы через всю комнату. Вы можете настроить очередь сообщений — центральную доску объявлений, где службы оставляют заметки и принимают задачи. Одна служба сбрасывает команду: «ПереместитьсервоприводА на позицию 150». Другая служба захватывает его, когда он готов, выполняет его и отправляет уведомление о завершении. Никаких криков, никаких пропущенных сообщений. Чистый.

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

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

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

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

А как насчет человеческой стороны? Документирование контрактов API, форматов сообщений… это менее гламурно, но пропустите его, и вы построите башню догадок. Общее определение — возможно, с использованием протокольных буферов или OpenAPI — позволяет всем быть на одной волне. Это план, с которым все соглашаются, прежде чем резать металл.

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

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

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

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

В конце концов, каждая великая машина начиналась с того, что две части учились говорить.

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