Когда ваша серверная система начинает «непослушаться», возможно, пришло время поговорить о том, как микросервисы могут укорениться.

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

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

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

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

Добавьте «механическую блокировку» в микросервисы

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

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

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

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

Некоторые люди могут спросить: «Будут ли такие уровни защиты замедлять работу системы?»

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

мощностьПрактика показала, что правильно спроектированная система безопасности обычно может контролировать влияние задержки в пределах 5% в обмен на значительное снижение частоты сбоев и вероятности взлома. Это хорошая сделка.

От «может работать» к «стабильно работает»: чувство безопасности — это пользовательский опыт

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

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

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

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

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