1 Зачем нужна согласованность данных между сервисами
Как инженер-исследователь интернет-компании, архитектурная идея микросервисов не чужда читателям и друзьям. Большинство из нас более или менее испытали на себе процесс разделения системы и перехода от монолитных приложений к микросервисам. В соответствии с бизнес-функциями и характеристиками огромной системы мы постепенно разделяем ее из одного большого приложения на множество подсистем, которые взаимодействуют друг с другом для выполнения бизнес-функций, и даже некоторые службы разделенной подсистемы могут использоваться повторно. сервисы подсистемы детализации. Между разделенными службами осуществляется все больше и больше соединений с использованием метода вызова PRC. Впоследствии проблема непротиворечивости данных между межсистемными сервисами будет становиться все более актуальной. Например, выдача и списание баллов и купонов в системе маркетинговой деятельности в системе электронной коммерции, например, основная ссылка основного заказа в системе электронной коммерции, каскадный поток на главной странице, сведения о бизнесе. страница, страница заказа и т. д. Согласованность и т. д., чтобы поддерживать реализацию этих бизнес-функций, часто может потребоваться полагаться на возможности чтения и записи данных, предоставляемые N различными службами бизнес-системы.
2 Как добиться согласованности данных между сервисами
Когда дело доходит до темы согласованности данных, наиболее распространенным и знакомым методом решения проблем, о котором мы можем думать, является обработка транзакций. Цель его существования — обеспечить, чтобы все данные в системе соответствовали ожиданиям, и не было бы противоречий между данными в отношениях, то есть непротиворечивость состояния данных. Концепция транзакций возникла из баз данных, и сегодня она используется почти во всех бизнес-системах. Особенно в некоторых больших и сложных распределенных системах концепция транзакций не ограничивается базами данных, но также может быть расширена на все сценарии приложений, требующие согласованности данных, включая, помимо прочего, базы данных, транзакционную память, кэши, очереди сообщений, распределенное хранилище. и т. д., все из которых могут использовать обработку транзакций.
Сегодня мы обсудим тему согласованности данных между сервисами. Конечно, в реальном производстве существует множество возможных решений для различных условий бизнеса, каждое из которых имеет свои преимущества и недостатки и применимые сценарии. Мы выбираем одну или две конкретные реализации и говорим о некоторых связанных проектах и практиках.
3 основных существительных
Чтобы помочь учащимся, читающим эту статью, прочитать и понять последующее содержание, мы сначала объясним и согласуем семантику нескольких существительных, используемых в статье:
Система на стороне бизнеса: относится к системной службе, которая инициирует и выполняет бизнес-операции, и может быть просто понята как потребитель.
Платформенная система: относится к стороннему системному сервису, который предоставляет базовые возможности для инициирования и выполнения бизнес-операций и может быть просто понят как сервисный участник.
Выполнение бизнес-операций: относится к тому факту, что операции чтения и записи данных должны полагаться на координацию нескольких системных служб для завершения, бизнес-система инициирует, а система на стороне платформы выполняет окончательные операции чтения и записи данных. В таком сценарии обычно возникают проблемы согласованности данных между службами (Примечание: система на стороне бизнеса и система на стороне платформы являются логической концепцией, и им не обязательно иметь соответствующие специальные службы приложений).
Идентификация бизнес-операции: относится к идентификации типа бизнеса или бизнес-сценария, к которому должна принадлежать бизнес-операция. Он создается и управляется системой на стороне платформы, а затем передается в систему на стороне бизнеса. Система на стороне вызывает систему на стороне платформы для предоставления идентификационной информации о возможностях служб. Идентификация услуги может быть разработана как одноуровневая или многоуровневая структура, которая должна соответствовать только требованиям текущей системы и бизнеса.
Уникальный идентификатор бизнес-операции: относится к уникальному идентификатору конкретной бизнес-операции, выполненной один или несколько раз. В производственной практике это обычно реализуется и управляется настройкой службы бизнес-системы или может быть реализовано настройкой службы бизнес-системы с ограничениями ограничительных и удобных правил управления, предоставляемых платформой. боковая система.Последний является рекомендуемым способом.
Таблица записи бизнес-операций: относится к таблице потока журналов, в которой записываются бизнес-операции. В производственной практике он обычно создается и управляется службой бизнес-системы.
4 Решение 1: Система бизнес-стороны гарантирует окончательную согласованность
4.1 Основная идея
Окончательная согласованность данных гарантируется с помощью служб бизнес-системы.Основная идея заключается в том, что бизнес-система записывает информацию журнала выполнения каждой конкретной бизнес-операции и инициирует проверку согласованности данных выполнения для изменения. результаты, которые не всем удается.Проверьте работу.
4.2 Принципы проектирования
Системные службы на стороне платформы предоставляют интерфейсы, поддерживающие базовые возможности служб для выполнения бизнес-операций. В частности, здесь представлен идемпотентный дизайн интерфейса, который необходимо реализовать на основе идентификатора бизнес-операции и уникального идентификатора бизнес-операции. Почему у нас есть уникальный идентификатор и все еще нужен идентификатор бизнес-операции? Потому что в реальной производственной практике на фоне различных внутренних и внешних факторов необходимо учитывать стабильность системы и гибкость бизнес-итераций, и сгенерировать абсолютный глобальный уникальный идентификатор сложно. В большинстве случаев необходимо только обеспечить глобальную уникальность в рамках определенной бизнес-системы, которая также является системным дизайном, соответствующим реальной ситуации. Подобные идеи решения проблем также имеют очень высокую справочную ценность в других сценариях проектирования систем.
Системная служба на стороне платформы предоставляет интерфейс для запроса результатов после выполнения бизнес-операций и поддерживает возможности запросов на основе идентификаторов бизнес-операций и уникальных идентификаторов бизнес-операций.
Таблица записей бизнес-операций поддерживает запись и идентификацию идентификаторов бизнес-операций и уникальных идентификаторов для каждого выполнения. Системная служба бизнес-стороны инициирует проверку и проверку согласованности данных в таблице записей бизнес-операций, а также способ проверки, такой как синхронная проверка и проверка в реальном времени, асинхронная проверка и проверка в квазиреальном времени, асинхронная проверка и проверка запланированных задач и т. д., чтобы обеспечить окончательную согласованность данных между собой и системой на стороне платформы.
4.3 Блок-схема
4.3.1 Проверка согласованности данных. Процесс выполнения синхронизации
4.3.2 Проверка непротиворечивости данных и проверка ссылки на асинхронную проверку
5 Решение 2. Платформенная система гарантирует окончательную согласованность
5.1 Основная идея
Окончательная непротиворечивость данных гарантируется с помощью служб системы на стороне платформы Основная идея заключается в том, что каждый раз, когда данные системы на стороне платформы изменяются, она активно ищет систему на стороне бизнеса, чтобы подтвердить, является ли результат этого изменение данных соответствует ожиданиям.
5.2 Основные принципы проектирования:
Платформенная система предоставляет интерфейс, поддерживающий базовые сервисные возможности выполнения бизнес-операций, и ее необходимо проектировать идемпотентно в соответствии с идентификатором бизнес-операции и уникальным идентификатором. Он аналогичен принципу непротиворечивости схемы 1 и здесь повторяться не будет.
Система на стороне платформы предоставляет SPI обратного вызова для подтверждения результата выполнения бизнес-операции, который может быть удобно реализован системой на стороне бизнеса в соответствии с идентификатором бизнес-операции и уникальным идентификатором бизнес-операции. Система бизнес-стороны предоставляет реализацию обратного вызова, которая оценивает согласованность данных на обеих сторонах на основе идентификатора бизнес-операции и уникального идентификатора бизнес-операции.
5.3 Блок-схема
5.3.1 Проверка непротиворечивости данных Проверка синхронизации Проверить ссылку
5.3.2 Проверка непротиворечивости данных и проверка ссылки на асинхронную проверку
6 Делимся опытом на практике
В этой части я сделаю несколько простых расширений некоторых деталей дизайна интерфейса между системой на стороне платформы и системой на стороне бизнеса. Я надеюсь предоставить некоторые идеи для ваших последующих исследований и разработок. В последующих статьях некоторые конкретные решения будут рассмотрены более подробно.
Прежде всего, будет объяснен идемпотентный дизайн интерфейса со следующих точек зрения: структура данных, хранилище состояний, обработка исключений, уникальный возвращаемый результат и т. д., чтобы сделать некоторые выводы и поделиться.
6.1 Дизайн структуры данных
Дизайн идемпотентности интерфейса реализуется на основе идентификации бизнес-операции (здесь называемой тегом) и уникального идентификатора бизнес-операции. Дизайн логотипа бизнес-операции может быть однослойным или многослойным. Среди них многоуровневый дизайн, отвечающий требованиям сложных бизнес-систем и множественных бизнес-сценариев. Метод генерации уникального идентификатора для бизнес-операций может быть неповторяемым идентификатором без бизнес-значения и самовозрастающей тенденцией, например самовозрастающий идентификатор первичного ключа MySQL, генератор распределенного идентификатора и т. д., или это может быть определенный метод бизнес-система.Некоторые специфические бизнес-поля, такие как userId пользователя, orderId заказа, spuId, skuId продукта и т. д. На практике мы рекомендуем последний метод, с помощью которого можно добиться высокой степени соответствия бизнес-системе без усложнения системы и использования дополнительных ресурсов.
6.2 Дизайн хранилища состояний
При нормальных обстоятельствах рекомендуется использовать хранилище MySQL в качестве предпочтительного хранилища. MySQL предоставляет очень полную возможность гарантии согласованности данных. Самый простой способ — разработать совместный уникальный индекс на основе базы данных и бизнес-уникальный ключ нескольких уровней Тег + уникальный идентификатор . Но есть и недостатки, такие как собственные узкие места в производительности MySQL и высокая стоимость хранения. Для узких мест производительности вы можете увеличить проверку идемпотентности для доступа к Redis перед доступом к идемпотентной проверке MySQL. Если проверка не пройдена, будет выдано исключение. После прохождения идемпотентной проверки MySQL данные будут асинхронно сброшены в Redis. Убедитесь, что что проверка MySQL должна пройти, пока пройдена проверка Redis. Мы можем принять неточность идемпотентной проверки Redis, просто ожидая, что она станет верхним уровнем воронки трафика и возьмет на себя роль фильтрации трафика для MySQL.Конечно, вы можете иметь другие решения для этого или даже комбинировать вверх и использовать. Вы также можете увеличить стратегию подбазы данных и подтаблицы, чтобы устранить узкое место производительности MySQL. Стоимость хранения MySQL относительно высока. Мы можем архивировать исторические данные и хранить только часть горячих данных. В принципе, количество строк данных в одной таблице должно быть в пределах 500–1000 Вт. В то же время он может также поддерживает определенное количество исторических запросов количества. В то же время этот процесс также должен учитывать проблему безблокировочной обработки и фрагментации пространства MySQL.
6.3 Схема обработки исключений
Первый шаг — уточнить, каковы причины исключения? Как правило, их можно разделить на несколько категорий, таких как сетевые аномалии, ошибки формата данных и аномалии бизнес-логики. На втором этапе мы делаем соответствующие решения для конкретных типов задач. Например, наш механизм повторных попыток, управление частотой повторных попыток, управление временем затухания цикла повторных попыток и восходящий механизм обработки аномальных данных в конечном состоянии обработки данных и т. д.
6.4 Возвращаемый результат уникален
Мне нужно убедиться, что данные, возвращаемые интерфейсом, после повторных вызовов и выполнений точно такие же. Мы можем вернуть тот же код состояния на основе управления потоком конечного автомата или проверить некоторые основные бизнес-параметры и вернуть определенный код исключения в случае сбоя. Кроме того, дизайн базового интерфейса возможностей, предоставляемого системой на стороне платформы, требует от наших студентов-исследователей думать и учитывать больше, например проблемы задержки согласованности, проектирование конечного автомата, обработку проблем параллелизма, решения недоступности интерфейса и т. д.
6.5 Терпимость к проблемам с задержкой
Можно ли завершить проверку и проверку непротиворечивости данных в ожидаемый момент времени системной службы бизнес-стороны? Какая задержка, если есть? Особенно какая задержка в экстремальных сценариях?
Случай: если вы используете запланированное задание, выполните проверку согласованности данных. Например, в одном цикле (при условии, что 1 минута) остается много данных, которые не были проверены, сколько осталось и влияние на бизнес-систему. Идеи решения: 1. Оценить и спроектировать разумный размер цикла 2. Выбрать между полной проверкой и инкрементной проверкой 3. Увеличить стратегию проверки диапазона отсканированных данных 4. Инкрементная проверка гарантирует, что непроверенные данные не будут потеряны и т. д. .
Случай: если мы используем сообщения MQ, мы можем столкнуться с проблемой несогласованности данных, вызванной проблемами MQ, такими как накопление и потеря сообщений.
Случай: если вы используете метод синхронного ожидания, вы можете уменьшить задержку согласованности данных до 0, но пропускная способность и доступность системы не могут быть гарантированы, что также является результатом выбора компромисса.
6.6 Проектирование на основе конечного автомата
В проекте на основе конечного автомата должно быть начальное состояние и конечное состояние, а это значит, что работа по проверке данных имеет начало и конец. Что касается промежуточного состояния, то промежуточных состояний может быть несколько, а может быть только одно промежуточное состояние, это связано с реальными потребностями и фоном и может гибко контролироваться. Среди них, как правило, есть не только один вид конечного состояния, но две категории: успешное конечное состояние, означающее, что данные достигают окончательной согласованности, и другое, неудачное конечное состояние, означающее, что оно не должно к непреодолимым факторам, что приводит к несогласованности данных. Окончательное состояние отказа также может создавать различные состояния в соответствии с фактическими потребностями. Например, многократные повторные попытки перехода из начального состояния в конечное, занимающие много времени, и доля работы по проверке и обнаружению данных в состоянии сбоя представляют в определенной степени терпимость бизнес-системы к задержкам согласованности данных. Это должна быть основная информация индикатора, на которую мы должны обращать внимание.
6.7 Проблемы параллелизма
Когда мы создаем начальную запись журнала состояния, это операция вставки MySQL (при условии, что вы выбрали MySQL в качестве хранилища), и нам нужно избегать создания нескольких записей с уникальным идентификатором для бизнес-операций. Самым простым и грубым способом можно полагаться на совместный уникальный индекс БД. Однако необходимо учитывать проблемы с производительностью и пропускной способностью, возникающие при большем параллелизме, и даже проблему невозможности создать состояние инициализации.
Для проблемы одновременной записи одних и тех же данных мы успешно выполнили оператор вставки, который в большинстве случаев может соответствовать ожиданиям нашей бизнес-системы. Мы можем использовать такие методы, как блокировка, постановка в очередь, группировка и постановка в очередь, чтобы ограничить количество параллелизма в подобных сценариях. Таким образом, при развитии и расширении бизнеса пропускной способности системы может не хватить для поддержки бизнеса.
Чтобы решить вышеупомянутую проблему снижения пропускной способности, мы можем подумать об использовании MQ для сокращения пиков и заполнения провалов, потому что в реальной производственной практике проблемы с параллельной записью часто вызываются мгновенным скачком системы. Использование метода MQ может обеспечить пропускную способность системы на стороне платформы для создания журнала начального состояния.
На основании вышеизложенного мы все же можем принять метод изоляции и разделения, например, изоляцию уровня разделения интерфейса службы, изоляцию разделения темы MQ и т. д., а также способ координации с различными системами защиты. такие стратегии, как ограничение тока и слияние и т. д. Различные системные ресурсы наклоняются и т. д. для решения проблем с производительностью системы на стороне платформы.
6.8 Необходимо устранить недоступные
Размыкание цепи и ограничение тока, изоляция ресурсов, диверсифицированные стратегии перехода на более раннюю версию и т. д. — это средства обеспечения доступности системы, с которыми все хорошо знакомы, и эта часть соответствующего содержания не будет описываться снова.
6.9 Необходимость обеспечения визуализации и наблюдения
Улучшите механизм оповещения, например аварийное оповещение о ненормальном состоянии, пороговое оповещение и т. д., чтобы учащиеся в соответствующей бизнес-системе и платформенной системе могли быстро обнаруживать проблемы и вмешиваться для их решения.
Построение системы мониторинга, такой как MySQL, Redis, MQ, а также мониторинг состояния работы по проверке данных и т. Д., Все это требует от нас поэтапного построения.
Инструменты для локализации и устранения неполадок.Сложность системы после раскола возрастает в геометрической прогрессии.Этот аспект тоже очень важен.
7 резюме
В этой статье излагаются два решения проблемы непротиворечивости данных, подробно объясняются основные идеи, принципы проектирования, процесс взаимодействия систем и т. д., а также сравниваются два решения, каждое из которых имеет свои преимущества и недостатки, а также свои особенности. собственные преимущества и недостатки Применимая сцена. Решение 1, бизнес-система для обеспечения согласованности данных больше подходит для бизнес-сценариев, которые имеют относительно сильную зависимость от согласованности данных и должны полагаться на результаты выполнения бизнес-операций для принятия решений и выполнения различных последующих действий. выполнение логических ветвей. Случай: один и тот же продукт запускает асинхронное обновление полных данных кэша продукта в измерении одного продукта кэша C-стороны в разных записях для изменения информации о продукте (изменение разных полей, изменение полей разных таблиц). измененная транзакция завершена после успешного завершения отправки. , последующее построение кэша, соответствующее этому изменению, может быть выполнено. Решение 2, система на стороне платформы обеспечивает согласованность данных, которая больше подходит для системы на стороне бизнеса.Основное внимание уделяется бизнес-сценарию конечного результата выполнения данных.Кейс: результаты выполнения вычета запасов и отката запасов на входе разные бизнес-сценарии. Наконец, упоминая об итогах и обмене некоторым опытом и решениями в процессе производственной практики, каждый пункт заслуживает дальнейшего обсуждения.
Рекомендуемые офлайн-активности
Время: 10 июня 2023 г. (суббота) 14:00-18:00
Тема: Салон технологий Dewu №18 - Беспроводные технологии №4
Место: Учебный класс на 12-м этаже научно-исследовательского центра Dewu Hangzhou, № 77 Xueyuan Road, район Сиху, Ханчжоу (выход G со станции Wensan Road линий метро 10 и 19)
Основные моменты мероприятия: Этот салон беспроводной связи посвящен последним тенденциям и практикам в области технологий и представит вам четыре интересные темы выступления в Ханчжоу / онлайн, в том числе: «Инструмент создания Douyin — мониторинг и оптимизация энергопотребления iOS», «Платформа соблюдения конфиденциальности Dewu». Практика строительства», «Netease Cloud Music — ежедневная практика гарантийной программы для клиентов с массовым трафиком», «Компиляция и оптимизация Dewu Android». Я считаю, что эти темы будут полезны для вашей работы и учебы, и мы с нетерпением ждем возможности обсудить с вами эти интересные технические материалы!
Способ регистрации: Нажмите, чтобы зарегистрироваться Салон беспроводных технологий
Отсканируйте QR-код, чтобы добавить помощника WeChat.
Если у вас есть какие-либо вопросы или вы хотите узнать больше технической информации, пожалуйста, добавьте помощника WeChat:
Текст: коф ван
Эта статья является оригинальной статьей Dewu Technology. Другие интересные статьи можно найти на официальном веб-сайте Dewu Technology.
Категорически запрещается перепечатывать без разрешения Dewu Technology, в противном случае юридическая ответственность будет расследована в соответствии с законом!