Когда мы создаем цифровую систему, нам может понадобиться подключить данные к другим системам, а цифровым системам других людей также может потребоваться подключить данные к нашей системе, или мы можем разработать разные веб-сайты, и небольшие приложения для веб-сайтов должны быть подключены. . Так как же должна работать стыковка данных? Как мы можем лучше синхронизировать данные? Как решить проблему межсистемной согласованности данных? Эта статья призвана обобщить опыт решения проблем в работе с осадками и разобраться в эмпирических методах решения проблемы несогласованности данных между системами с помощью единой простой платформы интеграции облачных данных.
1. Решить проблему согласованности данных в разных системах
Когда дело доходит до согласованности данных, мы можем легко думать об операциях транзакций в базе данных. Атомарность и устойчивость транзакций могут гарантировать, что в рамках транзакции обрабатываются несколько фрагментов данных, либо все успешно, либо все терпят неудачу. Таким образом, внутри системы мы можем естественным образом использовать транзакции базы данных для обеспечения согласованности данных. Но в современных микросервисах, когда операция включает в себя несколько баз данных в нескольких системах, невозможно выполнить ее с помощью одной транзакции базы данных. Другая распространенная ситуация заключается в том, что существуют системные службы, зависящие от ситуации, такие как бизнес-конец и пользовательская часть (бизнес-конец отвечает за создание данных, а пользовательская часть отвечает за отображение данных), что требует синхронизации данных для обеспечить согласованность данных между системными службами.Какой метод синхронизации данных используется для обеспечения своевременности применения данных, очень важно.
Чтобы выполнить стыковку данных, нам нужно рассмотреть, является ли это односторонней стыковкой данных или двусторонней стыковкой данных.Если это односторонняя стыковка данных, нам нужно только рассмотреть получение данных, то есть от цели цифровая система или другие цифровые системы.Получить данные из нашей цифровой системы, мы получаем или передаем данные другой стороне через API. Если данные участника, зарегистрированные в нашей цифровой системе, необходимо синхронизировать с другой стороной, данные участника, зарегистрированные на стороне другой стороны, и измененные данные участника также необходимо синхронизировать, чтобы обеспечить обновление данных обеих сторон в режиме реального времени. это сделать двустороннюю стыковку данных. Мало того, что мы должны передавать данные, но и другая сторона также должна передавать нам данные, но для этого не требуется, чтобы мы предоставляли API-интерфейс другой стороне, и другая сторона также предоставляет API-интерфейс нам, только API-интерфейс одной стороны необходим для сбора и передачи данных. Этот тип двустороннего соединения для передачи данных будет использоваться на многих платформах.Когда мы устанавливаем соединение, нам также необходимо учитывать, нужно ли нам получать данные или нам нужно передавать данные. Если необходимо добиться двусторонней стыковки, а мы рассматриваем только одностороннюю стыковку, то будут проблемы с данными. Например, данные участника, зарегистрированные на другой стороне, были синхронизированы с нами, но данные участника, зарегистрированные на нашей стороне, не были синхронизированы, и клиенты не могут войти в систему и использовать их в цифровой системе другой стороны.
2. Анализ проблем согласованности
Чтобы лучше описать и понять проблему непротиворечивости данных, для иллюстрации используется случай:
При наличии системы заказов и системы инвентаризации требуется подключение данных между Kingdee Cloud ERP и системой WMS.В реальном бизнесе создание заказов будет сопровождаться сокращением запасов складского модуля системы. Две системы развертываются отдельно, и данные их приложений также хранятся в независимой базе данных, и две системы взаимодействуют через сетевой интерфейс API.
Как сделать стыковку данных, в основном это делается через API, то есть провайдер данных пишет интерфейсные документы, и сообщает стыковочной стороне, какие поля и формы нужно использовать для получения данных. При построении цифровой системы для стыковки данных необходимо учитывать не только получение данных, но и передачу данных.Конкретная используемая форма зависит от требований обеих сторон к данным. Если необходимо не только получить, но и передать, то необходимо учитывать подключение данных в этом аспекте, иначе после подключения будут проблемы с данными, это главное внимание. У других, пока есть интерфейс API, проблем с докингом в принципе не будет.
2.1 Принципы CAP для платформы интеграции данных
CAP являются взаимоисключающими, и для обработки могут быть выбраны только два из них, CA, AP и CP имеют свои сценарии применения, и выбор должен осуществляться в сочетании с реальной ситуацией.
- Поскольку CA не учитывает устойчивость к разделам, все его операции должны выполняться в одном и том же процессе (то есть в том, что мы часто называем одним приложением);
- Поскольку AP отказывается от согласованности данных, он подходит для проектов с низкими требованиями к данным, но с упором на взаимодействие с пользователем, таких как блоги, новости и т. д.;
- Напротив, CP отказывается от удобства использования и подходит для транзакционных систем с высокими требованиями к данным, таких как банковские транзакции, транзакции заказов электронной коммерции и т. Д. Даже если пользователи ждут в течение длительного времени, целостность и надежность данных должны быть гарантированы. .
Применение принципа CAP в реальных проектах нецелесообразно для интернет-приложений, если полностью отказывается от согласованности данных в угоду пользовательскому опыту, ведь данные — это основа приложений.
Как платформа интеграции данных должна решить взаимное исключение CAP?
Существует множество мер для обеспечения окончательной согласованности, в основном в том числе: распределенная транзакция и схема согласованности TCC. На самом деле в MySQL используется схема распределенных транзакций с двухфазной фиксацией (MySQL XA), но эта схема имеет серьезные проблемы с производительностью.
Например, может быть 10-кратная разница в производительности транзакции XA между одной транзакцией базы данных и несколькими базами данных. Кроме того, при обработке транзакции XA она будет занимать ресурсы блокировки в течение длительного времени, поэтому мы не рассматривали это решение в начале.
3. Практика схемы синхронизации данных системы высокой доступности
Описание проблемы: возвращаясь к предыдущему сценарию интеграции данных, необходимо синхронизировать данные из облака Kingdee и звездной системы в систему Wangdiantong. Система заказов синхронизирована с системой инвентаризации.
Для обеспечения согласованности данных обычно используются три типа решений для синхронизации данных: синхронизация в реальном времени, временная синхронизация и ручная синхронизация. Основные особенности дизайна платформы интеграции данных:
• Унифицированное управление API-интерфейсами интеграции данных в режиме реального времени
• Инструменты визуальной настройки
• Реализация интеграционных решений с минимальным кодом
• Ненавязчивость
• Слабосвязанная интеграция
• Отсутствие вторжения в существующие бизнес-системы
• Гибкая доставка из коробка
• Интеграционное решение на основе расширенного сценария
Платформа интеграции данных, разработанная с использованием шаблона архитектуры асинхронной сопрограммы с помощью Message Queue (MQ), промежуточного программного обеспечения очереди сообщений. MQ реализует асинхронность и разъединение приложений путем разделения отправки и получения сообщений.В то же время MQ защищает базовые сложные протоколы связи и определяет набор более простых протоколов связи на уровне приложений. При проектировании бизнес-систем у нас часто есть системная платформа Kingdee, которая связана и синхронизируется со многими системами (система Jushuitan, Fanwei, MES и т. д.). Использование MQ может очень хорошо решить проблемы стыковки системы и синхронизации данных, и в то же время можно игнорировать такие требования, как стабильность системы стыковки.