что такое микросервисы в разработке программного обеспечения

«Магия строительных блоков» в мире программного обеспечения: давайте поговорим о том, что такое микросервисы

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

На самом деле это старая проблема многих традиционных программных архитектур. Они похожи на гигантские твердые блоки цемента, в которых все склеено. Это так называемая «монолитная архитектура». Звучит довольно солидно, не так ли? Но иногда основательность также означает жесткость.

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

Что такое микросервисы?

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

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

Чем это отличается от традиционной модели «большого дворца»?

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

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

Почему все об этом говорят? Какие болевые точки это решает?

Поговорив об этом, вы можете спросить, это звучит немного абстрактно, каковы конкретные преимущества? Давайте почувствуем это, используя несколько сценариев, которые могут быть вам знакомы.

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

Сценарий 2: Точное расширение мощностей без потерь. Внезапно объем заказов на ваше программное обеспечение резко возрастает из-за определенной рекламной акции. В монолитной архитектуре можно лишь расширить мощности всего серверного «дворца». Независимо от того, используют ли другие функции столько ресурсов или нет, деньги приходится тратить. Но в сообществе микросервисов сразу видно, что «кабина обработки заказов» и «кабина платежей» находятся под большим давлением. Вам нужно лишь временно добавить к этим двум хижинам несколько «комнат» (вычислительных ресурсов), а остальные сервисы останутся прежними. Разве этот тщательный расчет не похож на экономку, которая знает, как прожить хорошую жизнь?

Сценарий 3: Свобода технического выбора. В «Большом дворце» все стены, вода и электричество должны быть изготовлены из единых материалов и с одинаковыми характеристиками. Хотите изменить окраску стен вашей спальни на более красивую? К сожалению, это может быть несовместимо с общей структурой. Сообщество микросервисов гораздо более открыто. Комната, ответственная за анализ данных, может быть удобнее использовать Python; шлюзовая комната, которая обрабатывает много одновременных запросов, может использовать язык Go для повышения производительности. Каждая небольшая команда может выбирать наиболее подходящие инструменты и технологии исходя из своих конкретных задач, не ограничиваясь единым стеком технологий.

Так подходит ли он всем? Не вызовет ли это новых проблем?

В мире нет ничего идеального, то же самое касается и микросервисов. Разделение большого дома на более мелкие, естественно, сопряжено с некоторыми новыми проблемами.

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

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

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

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

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

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