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

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

Задумывались ли вы когда-нибудь о том, что узким местом могут быть не вычисления, а поток данных туда и обратно?

Кэширование: не необязательное украшение, а скрытый двигатель производительности

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

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

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

Почему ваше решение для кэширования может работать не так, как должно?

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

Например, «проникновение в кэш» — кто-то продолжает запрашивать данные, которых вообще нет, и их нет в кэше. Запрос каждый раз попадает в базовую базу данных, перегружая базу данных. Другой пример — «лавина кэша» — одновременно выходит из строя большое количество кэшей, все запросы мгновенно устремляются к базе данных, и система может быть парализована на месте. Существует также более тонкая проблема «согласованности данных»: служба A обновляет данные, но кэш службы B все еще имеет старую версию, и информация, которую видит пользователь, противоречива.

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

Идея дизайна, более интегрированная в текстуру.

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

Это требует поддержки инструментов, но также требует изменения мышления. Инструменты должны помочь вам реализовать эту идею, а не добавлять новую сложность.

Как это работает в реальном сценарии?

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

Что, если будет введен разумный уровень кэширования? Информация о пользователе может храниться в кэше в течение 12 часов, состояние запасов — в течение 30 секунд, а цены и отзывы — в течение 5 минут. Разные сроки действия соответствуют разной частоте изменения данных. Время загрузки страницы может быть сокращено с сотен миллисекунд до десятков миллисекунд. За этим изменением стоит значительное снижение нагрузки на базу данных и повышение общей гибкости системы.

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

Куда следует смотреть при выборе?

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

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

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

Он должен выдержать испытание реальным трафиком. Само решение не может стать новой единой точкой отказа. Он должен иметь конструкцию высокой готовности и быть в состоянии оставаться стабильным под давлением.

сделать шаг вперед

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

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

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

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