Почему все используют микросервисы? Неужели это так полезно?

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

В чем проблема?

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

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

Какую пользу приносят микросервисы?

Первая привлекательность: независимость.

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

Вторая особенность: эластичное масштабирование.

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

Третья прелесть: технологическая свобода.

Никто не требует, чтобы все сервисы разрабатывались одними и теми же инструментами. Некоторые из них подходят для быстрой итерации в Python, а некоторые требуют, чтобы Java поддерживал высокий уровень параллелизма. Базу данных также можно выбрать по требованию — эта использует MySQL, та — MongoDB. Команды могут выбирать наиболее удобный стек технологий для служб, за которые они отвечают, точно так же, как выбирают наиболее подходящую модель двигателя для каждого сустава роботизированной руки, и больше не ограничиваются принципом «один размер подходит всем».

Так есть ли в этом головная боль?

Конечно, есть. При таком большом количестве услуг координация становится проблемой. Раньше запрос вызывался между внутренними функциями, но теперь он может охватывать несколько служб в сети. Это приводит к проблемам с задержкой, проблемами с надежностью сети и согласованностью данных — служба A работает успешно, но служба B терпит неудачу. Как выполнить откат? Мониторинг и отладка также усложнились. Вам необходимо иметь четкую карту обслуживания, чтобы знать, по каким путям прошли запросы.

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

Что действительно волнует людей, когда они делают выбор?

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

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

Чем это странно похоже на проектирование аппаратного обеспечения?

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

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

Итак, в каких сценах он действительно сияет?

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

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

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

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