Как обмениваться данными в организации

Я уверен, что вы предвидели это, "Это зависит".

Это зависит от всего. И решение по обмену данными о клиентах для отдела А может быть совершенно другим для обмена данными о клиентах с отделом Б.

Моя любимая концепция, появившаяся за эти годы, — это концепция «Eventual Consistency». Термин пришел от Amazon, говорящего о распределенных системах.

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

Например, когда запись о клиенте обновляется в системе A, данные о клиентах в системе B становятся устаревшими и не соответствуют друг другу. Но «в конце концов» запись из A будет отправлена ​​​​в B через какой-то процесс. Итак, в конце концов, два экземпляра совпадут.

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

Чем лучше ваши операции могут работать с данными «EC», тем проще разделить эти системы. Простой пример — хранилище данных, используемое продажами. Они используют DW для запуска своих ежедневных отчетов, но они не запускают свои отчеты до раннего утра и всегда смотрят на данные «вчера» (или более ранние). Таким образом, нет необходимости в том, чтобы ХД в режиме реального времени идеально согласовывалась с системой повседневных операций. Вполне допустимо, чтобы процесс выполнялся, скажем, в конце рабочего дня и перемещал в течение дня транзакции и операции в массовом порядке в рамках одной большой операции обновления.

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

Это крайний, упрощенный и очень грубый пример ЭК.

Но рассмотрим большую систему, такую ​​как Google. Как потребители Поиска, мы понятия не имеем, когда и сколько времени требуется, чтобы результат поиска, который собирает Google, поднялся на страницу поиска. 1 мс? 1с? 10 секунд? 10 часов? Легко представить себе, что если вы попадете на серверы Google на западном побережье, вы вполне можете получить другой результат поиска, чем если бы вы попали на их серверы на восточном побережье. Ни в коем случае эти два случая не являются полностью совместимыми. Но по большому счету они в основном последовательны. И для их варианта использования их потребители на самом деле не страдают от задержек и задержек.

Рассмотрим электронную почту. A хочет отправить сообщение B, но в процессе это сообщение направляется через системы C, D и E. Каждая система принимает сообщение, берет на себя полную ответственность за него, а затем передает его другой. Отправитель видит, что электронная почта отправляется в путь. Получатель на самом деле не упускает его, потому что он не обязательно знает, что он придет. Таким образом, есть большое окно времени, которое может потребоваться для того, чтобы это сообщение прошло через систему, и никто не будет знать или заботиться о том, насколько быстро это происходит.

С другой стороны, А мог разговаривать по телефону с Б. «Я только что отправил его, ты уже получил его? Сейчас? Сейчас? Получил сейчас?»

Таким образом, существует некий базовый, подразумеваемый уровень производительности и отклика. В конце концов, «в конце концов», исходящий ящик А совпадает с почтовым ящиком Б.

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

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

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

Изменить в ответ на первый комментарий.

Правильно, точно. Игра здесь, например, если B не может изменить данные о клиенте, то какой вред от измененных данных о клиенте? Можете ли вы «рискнуть», что он устареет на короткое время? Возможно, данные о ваших клиентах поступают достаточно медленно, чтобы вы могли немедленно реплицировать их из точки А в точку Б. Скажем, сдача поставлена ​​в очередь, которая из-за небольшого объема легко принимается (‹ 1 с), но даже при этом она будет «вне транзакции» с исходной сдачей, и поэтому есть небольшое окно, в котором А должен был бы данные, которых нет у Б.

Теперь ум действительно начинает вращаться. Что происходит в течение этих 1 с «задержки», каков наихудший возможный сценарий. И можете ли вы спроектировать вокруг него? Если вы можете спроектировать задержку в 1 секунду, вы сможете спроектировать задержку в 5 секунд, 1 минуту или даже больше. Какую часть данных о клиентах вы на самом деле используете в B? Может быть, B — это система, предназначенная для облегчения комплектования заказов со склада. Трудно представить себе что-то большее, чем просто идентификатор клиента и, возможно, имя. Просто что-то, чтобы грубо определить, для кого заказ, пока он собирается.

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

Хитрость заключается в том, чтобы разбить системы и сосредоточиться на важных данных, необходимых для задачи. Данные, которые вам не нужны, не нужно реплицировать или синхронизировать. Людей раздражают такие вещи, как денормализация и сокращение данных, особенно когда они из мира моделирования реляционных данных. И не без оснований к этому следует относиться с осторожностью. Но как только вы становитесь распределенным, вы неявно денормализованы. Черт возьми, вы копируете это оптом сейчас. Так что можно и поумнеть.

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

Но самое сложное — разорвать цепочку к центральной БД в самом начале и проинструктировать людей, что они не могут «иметь все», как они могут ожидать, когда у вас есть единое, центральное, идеальное хранилище информации.

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

У меня есть несколько замечаний по поводу некоторых аспектов, которые вы упомянули.

duplicate data

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

well-defined interfaces

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

tight coupling vs loose coupling

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

architectural simplification

Для меня это ключ к борьбе со всеми проблемами, которые вы упомянули в своем вопросе. Мне на ум приходит история SIP и H.323 VoIP. SIP очень упрощен, его легко построить, в то время как H.323, как типичный телекоммуникационный стандарт, пытался предусмотреть все проблемы на планете, связанные с VoIP, и предоставить для них решение. В результате SIP рос намного быстрее. Очень сложно быть совместимым с H.323 решением. Фактически, соответствие стандарту H.323 — это мегаиндустрия.

On a few architectural fads that I have grown up to.

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

Для решения ряда этих проблем мне нравится концепция центральных «концентраторов данных». Концентратор данных представляет собой «единый источник достоверной информации» для конкретного объекта, но хранит только идентификаторы, а не информацию, такую ​​как имена и т. д. Фактически, он хранит только сопоставления идентификаторов — например, они сопоставляют идентификатор клиента в системе A с Номер клиента из системы B и номер клиента в системе C. Интерфейсы между системами используют концентратор, чтобы узнать, как связать информацию в одной системе с другой.

Это как центральный перевод; вместо того, чтобы писать специальный код для отображения из A-> B, A-> C и B-> C, с экспоненциальным увеличением посещаемости по мере добавления большего количества систем, вам нужно только преобразовать в / из концентратора: A- >Концентратор, B->Концентратор, C->Концентратор, D->Концентратор и т. д.