1.3.4. Сложности разработки распределенных систем

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

В этой связи еще в 90-х годах прошлого века сотрудник компании Sun Microsystems Питер Дейч в своей статье "Восемь заблуждений относительно распределенных вычислений" сформулировал основные ошибки, которые допускают при создании распределенных приложений. Он писал: "По существу, каждый, кто впервые создает распределенное приложение, делает следующие предположения. Все они, в конце концов, оказываются ложными, и все вызывают большие неприятности. Вот эти восемь заблуждений:

1.Сеть является надежной.

2.Задержки передачи сообщений равны нулю.

3.Полоса пропускания не ограничена.

4.Сеть является безопасной.

5.Сетевая топология неизменна.

6.Систему обслуживает только один администратор.

7.Издержки на транспортную инфраструктуру равны нулю.

8.Сеть является однородной".

Важно отметить, что перечисленные предположения как раз и

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

23