Почему распределенные системы считаются сложными?

Question

Я просто понимаю концепцию распределенной системы и ее преимущества и недостатки. В книге, которую я читаю, обсуждается сложность распределенной системы и что они по своей сути сложны, в ней перечислены следующие потенциальные причины сложности;

• Неоднородность
• Асинхронные связи
• Частичные отказы

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

Answer 1

Этот вопрос можно ответить во многих словах, но я буду стараться варить до первой необходимости:

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

• Быть на разных платформах в разных сетях;
• Различия в их возможностях с точки зрения интеграции;
• Имеют несоответствия в данных, даже данные, относящиеся к одному и тому же домену бизнеса;
• Использование и поддержка различных (иногда даже забытых или неподдерживаемых) технологий и стандартов;
• Имеют разные владельцы (контролируются различными отделами, компаниями).

Все вышеперечисленное добавляет все больше и больше сложности.

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

Частичные сбои - Когда у вас есть процессы, которые связаны с несколькими взаимозависимыми операциями записи, вам необходимо обеспечить транзакции ACID. Необходимость делать это в сценариях, когда задействованы несколько систем, еще сложнее, потому что вы не можете достичь общего контекста транзакций так же легко в гетерогенной распределенной среде, как если бы вы были в пределах одной системы. Часто вам нужно реализовать противоположные операции в службах (или, что еще хуже, реализовать two-phase commit), чтобы иметь возможность компенсировать все предыдущие записи в процессе, если что-то пойдет не так с одной из задач.

Надеюсь, что это немного очистит!

Answer 2

Причина, по которой распределенные системы настолько сложны: время!

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

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

Answer 3

частичный отказ - В случае сделки с участием многих клиентов (@ дополнительным 2ил), метод планирования используются многие из них включают конфликтующие операции в записи и, возможно, писать, в процессе выдачи блокировки Сложности возникают как в случае тупика. Когда менеджер блокировок пытается либо обнаружить, либо избежать или предотвратить, что система может частично провалиться, что приведет к откату всего процесса.