Когда ваша серверная система начинает «говорить»: о чем спорят веб-сервисы, микросервисы и API?

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

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

1. Возникает вопрос: почему машинам нужно «обслуживание»?

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

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

Но подождите — на рынке часто можно услышать несколько слов: веб-сервисы, микросервисы, API. Они звучат как три брата, немного похожи, но у них совершенно разные темпераменты.

• Веб-сервисыКак постоянный дворецкий. Он использует набор стандартных «этикетов» (таких как SOAP или REST) ​​для отправки и получения информации в сети, благодаря чему разные системы, даже если одна написана на Java, а другая — на C++, могут понимать друг друга. Ему нравится делать вещи формальными и стандартизированными.
• МикросервисыЭто как группа гибкого спецназа. Он разбивает большое программное приложение на множество независимых небольших сервисов, и каждый небольшой сервис фокусируется только на выполнении одной задачи (например, на конкретной обработке проверки положения или конкретном управлении состоянием двигателя). Они общаются друг с другом в легкой форме. Какой из них нуждается в обновлении или имеет проблемы, не повлияет на других «членов команды».
• И API(Интерфейс прикладного программирования) — это наиболее простой «список диалогов». Он определяет: «Если вы хотите, чтобы я (какое-то программное или аппаратное обеспечение) что-то сделал, вы должны позвонить мне в этом формате и с использованием этих ключевых слов». Это замочная скважина для доступа к функции.

Вы можете спросить: «Какой из них мне нужен? Или все?»

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

2. Позвольте правильному «сервису» делать правильные вещи

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

• Если вам нужно, чтобы статус данной сортировочной установки отображался в режиме реального времени на большом экране компьютера в удаленном офисе, или вам нужно, чтобы она получала задания из центральной системы заказов компании, тоВеб-сервисыТакой стандартный метод межплатформенной коммуникации очень полезен. Это поможет вам построить надежную «магистраль данных» от мастерской до офиса.
• Если вся ваша система сортировки особенно сложна, с роботизированным управлением манипулятором, визуальным распознаванием, планированием пути и журналами ошибок, независимыми друг от друга и требующими частых настроек или отдельных обновлений, тогда используйтеМикросервисыАрхитектура для создания частей программного обеспечения значительно облегчит последующее обслуживание и расширение. Если какую-то функцию необходимо улучшить, вы не сможете повлиять на все это.
• иAPI, почти везде. Это «команда быстрого доступа», которая позволяет сервоприводу быстро получить доступ к программе верхнего уровня управления. напримермощностьНекоторые из ее продуктов-драйверов предоставляют понятные и стабильные API-интерфейсы, позволяющие напрямую отправлять точные инструкции движения с использованием языков высокого уровня (таких как Python) без необходимости вникать в базовые сложные адреса регистров. Благодаря этому интеграция ощущается как строительные блоки.

Как видите, они не заменяют друг друга, а часто работают вместе. Веб-службы или микросервисы часто вызывают друг друга через понятные API.

3. Почему «хороший разговор» так важен для механических проектов?

При выборе правильной «сервисной» архитектуры преимущества ощутимы:

1. Повышенная гибкость. Сегодня я хочу добавить в роботизированную руку обратную связь по датчику силы, а завтра хочу подключить всю станцию ​​к заводскому Интернету вещей. Модульная архитектура сервиса позволяет добавлять функциональные возможности в виде плагинов, а не изобретать велосипед.
2. Техническое обслуживание простое. В каком модуле возникла проблема, объем работ по устранению неполадок и ремонту будет более целенаправленным. При обновлении одной службы другие службы будут работать в обычном режиме, и риск простоя системы значительно снижается.
3. Итерация происходит быстрее. Вы можете поручить разным командам параллельно разрабатывать разные микросервисы и, наконец, объединять их для тестирования. Скорость развития функций продукта, естественно, будет идти в ногу со временем.
4. Интеграция стала более гладкой. Благодаря стандартным API и методам связимощностьЗа счет объединения усовершенствованной сервосистемы, сторонних датчиков технического зрения и собственного управляющего программного обеспечения технический порог и время отладки будут снижены.

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

4. Куда нам следует сделать первый шаг?

Если вы планируете или преобразуете проект механической автоматизации, вы можете подумать о следующих моментах:

• провести границу: Какие функции в вашей системе тесно связаны и должны работать как единое целое? Какие из них относительно независимы и могут разрабатываться и развертываться независимо? Те, которые независимы, являются кандидатами на микросервисы.
• Определить диалог: Какой информацией необходимо обмениваться между этими независимыми функциями? Как часто? Сколько данных? Четкое определение этого «содержания диалога» и «правил» — это процесс разработки API.
• Выберите протокол: Для частей, требующих удаленного и межсетевого взаимодействия, следует ли нам использовать облегченный протокол, такой как RESTful API, или нам следует использовать протокол, который требует более строгих гарантий транзакций? Это определяет стиль веб-служб.
• посмотри на своего партнера: обратите внимание на поддержку, предоставляемую выбранным вами поставщиком оборудования. Например, понимание того, какие удобные интегрированные интерфейсы и коммуникационную поддержку Kpower предоставляет в экосистеме продуктов, может помочь вам получить вдвое больший результат, прилагая вдвое меньше усилий.

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

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

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