Так много вычислений основано на предположениях. Мы проектируем системы, основанные на ряде допущений. Мы пишем программы и приложения, предполагая, что определенные части их систем будут работать определенным образом. И мы также предполагаем, что некоторые вещи потенциально могут пойти не так, и мы (надеюсь) пытаемся это объяснить.
Одна большая проблема при создании компьютерных вещей заключается в том, что, хотя мы часто имеем дело со сложными системами, мы не всегда способны рассуждать на уровне общей картины. Распределенные системы, безусловно, являются отличным примером этого (вы ведь знали, к чему я клоню, не так ли?). Даже «простая» распределенная система не так проста, потому что по определению она включает в себя более одного узла, а узлы в системе должны обмениваться данными и общаться друг с другом через сеть. Даже в небольших распределенных системах всего с двумя узлами мы делаем определенные предположения о том, как эта система будет работать.
Но вот в чем суть предположений: они могут ошибаться! Оказывается, мы часто делаем несколько распространенных ошибочных предположений о распределенных вычислениях. На самом деле они настолько распространены, что у них есть имя! Я, конечно, говорю о восьми заблуждениях распределенных вычислений. А какие они? Что ж, пора выяснить.
Предположения пошли не так
Восемь заблуждений, какими мы их знаем сегодня, на самом деле начинались как всего четыре заблуждения, которые мы рассмотрим в этом посте. Первые четыре заблуждения были созданы в начале 90-х (где-то после 1991 года) двумя инженерами Sun Microsystems, Биллом Джоем и Дэйвом Лайоном.
Джеймс Гослинг, который в то время был научным сотрудником Sun Microsystems - а позже продолжил создание языка программирования Java, - классифицировал эти первые четыре заблуждения как «Заблуждения сетевых вычислений». Чуть позже в том же десятилетии Питер Дойч, другой сотрудник Sun, добавил заблуждения пять, шесть и семь. В 1997 году Гослинг добавил восьмую и последнюю ошибку. Большая часть работы, проделанной для систематизации этого списка, была вдохновлена работой, которая фактически выполнялась в Sun Microsystems в то время. И хотя Дойчу часто приписывают «создание» восьми заблуждений, очевидно, что это были совместные, групповые усилия (как это часто бывает в вычислительной технике!).
Хорошо, теперь, когда у нас есть некоторая история, давайте рассмотрим некоторые практические аспекты этой проблемы. Давайте сначала начнем с понимания того, о чем мы говорим, когда говорим об «заблуждении» распределенных вычислений. Что это означает?
Что ж, заблуждение - это своего рода предполагаемый факт или убеждение; однако, даже если это считается правдой, на практике это обычно не так. Заблуждение - это просто заблуждение. Но что это означает в контексте вычислений? Что ж, заблуждение о распределенной системе - это предположение о системе, сделанное разработчиками, которое в конечном итоге часто оказывается неточным и неправильным. Другими словами, это плохие предположения.
Мы можем думать о восьми заблуждениях как о восьми распространенных заблуждениях, жертвами которых часто становятся разработчики распределенных систем, которых мы хотим избежать.
Итак, давайте взглянем на эти восемь заблуждений, ладно?
Восемь ошибок распределенных вычислений заключаются в следующем:
- Сеть надежная.
- Задержка нулевая.
- Пропускная способность бесконечна.
- Сеть безопасна.
- Топология не меняется.
- Есть один админ.
- Транспортные расходы нулевые.
- Сеть однородна.
В этом посте мы сосредоточимся только на первых четырех заблуждениях, которые, как мы теперь знаем, были оригинальными «Заблуждениями сетевых вычислений»! Удобно, что все эти первые четыре заблуждения на самом деле привязаны к одному центральному, ключевому персонажу: сети. И, как мы скоро увидим, сеть - хитрый человек. Конечно, сложно иметь распределенную систему без сети, поэтому нам нужно привыкнуть иметь дело с этим хитрым персонажем.
Давайте узнаем, что затрудняет борьбу с сетью и почему некоторые из этих заблуждений легко допустить.
Проблема с сетями
Наши распределенные системы, независимо от того, насколько они сложны или вовлечены, все существуют в сети. Узлы нашей системы должны общаться друг с другом, а также отправлять и получать сообщения для обмена и доставки данных. Поскольку система распределена, ее части будут находиться в разных местах, а сеть является точкой привязки, с помощью которой компоненты системы будут обмениваться данными.
Это приводит нас к первому заблуждению: Сеть надежна. Помните, что это заблуждения, с которыми мы имеем дело, поэтому надежность сети - настоящее заблуждение; сеть ненадежна!
Так много всего в сети может пойти не так. Аппаратное обеспечение может выйти из строя, может отключиться питание, сигнал может стать нестабильным или даже сеть может быть взломана! Может показаться очевидным, что сеть ненадежна, но, как разработчики распределенной системы, мы иногда можем забыть об этом, когда пишем код, который будет работать в распределенной системе. Мы пишем этот код, возможно, исходя из этого предположения, но когда в какой-то момент сеть неизбежно становится ненадежной, мы понимаем, что сделали неверное предположение, и это в конечном итоге отрицательно влияет на нашу систему. Таким образом, наша работа заключается в том, чтобы помнить об этой ошибке и не забывать, что на сеть нельзя полагаться.
Теперь, прежде чем мы слишком углубимся в сети - не говоря уже о связанных с ними заблуждениях, - нам следует изучить некоторые важные термины. Когда мы говорим о сообщениях, отправляемых по сети, мы обычно имеем в виду данные, отправляемые по сети. Но мы можем говорить о данных и способах их отправки двумя разными способами: задержкой и пропускной способностью.
Задержка - это показатель того, насколько задерживаются некоторые данные, в зависимости от того, куда они были отправлены. Мы можем думать о задержке как о скорости, с которой наши данные перемещаются из одного места в другое, или о том, сколько времени требуется, чтобы данные прибыли от узла A к узлу B в нашей системе. Задержка - это концепция, с которой многие разработчики, возможно, уже хорошо знакомы, потому что мы часто говорим о задержке данных в контексте миллисекунд. Например, если для обслуживания запроса от сервера (узел A) к клиенту (узел B) потребовалось 400 миллисекунд, мы можем сказать, что задержка отправки этих данных была задержана на 400 миллисекунд или что это заняло 0,4 секунды для передачи сообщения от сервера к клиенту. Многие разработчики, ориентированные на производительность, часто думают о задержках, когда думают, что оптимизировать или улучшить в своих приложениях или системах.
Пропускная способность, с другой стороны, является мерой того, сколько данных может быть отправлено из одной точки в другую за определенный период времени. Мы часто говорим о пропускной способности в контексте скорости Интернета (например, мегабит в секунду или Мбит / с), потому что мы говорим о том, сколько данных может быть отправлено по нашей конкретной сети, или о способности нашей сети отправлять некоторый объем данных. в заданный промежуток времени.
В то время как задержка - это фактическая скорость, с которой данные попадают в пункт назначения через сеть, пропускная способность - это способность сети отправлять определенный объем данных в пункт назначения. Понимание разницы между этими двумя концепциями важно для понимания второй и третьей заблуждений, поэтому давайте узнаем об этих двух следующих!
Некоторые заблуждения причиняют больше вреда, чем другие
Теперь, когда мы знаем, что на самом деле означает «задержка», мы лучше подготовлены к пониманию второй ошибки: Задержка равна нулю. К сожалению, это тоже заблуждение.
Это, возможно, легкое заблуждение, чтобы стать жертвой, поскольку в наших локальных средах или в среде разработки мы можем испытывать гораздо меньшую задержку; Другими словами, мы, вероятно, столкнемся с небольшой задержкой, когда дело доходит до отправки или получения данных. Однако такая низкая локальная задержка не точно отражает задержку того, что могут чувствовать другие части системы, особенно с учетом разных сетей.
Мы уже узнали о локальных сетях (LAN) и глобальных сетях (WAN). Мы знаем, что в глобальной сети данные должны перемещаться от одного узла к другому, поскольку сеть может охватывать большие географические расстояния. Это отличается от локальной сети, которая представляет собой сеть с устройствами в одном здании или комнате, и, таким образом, передаваемые данные имеют гораздо меньшее расстояние для перемещения.
Мы не можем предположить, что наша система всегда будет работать в локальной сети (на самом деле, большинство распределенных систем работают в глобальной сети), и поэтому мы знаем, что наши данные должны перемещаться на физическое расстояние. По доверенности мы не должны предполагать, что не будет «задержки» или нулевой задержки между отправкой некоторых данных и получением этих данных. Например, запрос, который должен путешествовать по миру из Портленда в Париж, будет иметь большую задержку, чем запрос, отправляемый с машины в одной комнате в другую.
Некоторая задержка - это ограничение сети; мы должны проявить мудрость, чтобы не строить систему, которая предполагает, что такой задержки не существует. Такое ложное предположение наверняка укусит нас в будущем.
Третье заблуждение аналогично этому ложному предположению: Пропускная способность бесконечна. Точно так же, как задержка не равна нулю, пропускная способность сети для отправки данных не безгранична. По мере того, как вычислительные технологии с годами совершенствовались - и, конечно же, с начала 90-х, когда были придуманы заблуждения, - пропускная способность наших сетей становится все лучше и лучше, и мы можем отправлять больше данных через наши данные за определенный промежуток времени. .
Однако даже с этими улучшениями сети по-прежнему не обладают неограниченной емкостью и не могут отправлять бесконечно большие объемы данных. Когда мы проектируем распределенную систему, нам следует не предполагать, что какой-либо объем данных может быть отправлен по сети. Например, у нас может быть какой-то пользователь нашей системы, у которого есть сеть с ограниченной пропускной способностью и меньшей пропускной способностью; для этого пользователя отправка большого количества данных (например, больших изображений или зависимых файлов от поставщиков) будет означать, что мы отправим гораздо больше данных, чем их сеть могла бы отправить по сети за разумный промежуток времени.
Наконец, мы подходим к четвертому заблуждению, которое лично мне больше всего нравится: Сеть безопасна. Существует просто так много способов, которыми сеть может быть атакована или взломана, от незашифрованных сообщений до уязвимостей в зависимости от открытого исходного кода или даже просто ошибки в стороннем программном обеспечении, от которых может зависеть наша система (не говоря уже об ошибках в наших собственных системах!).
Заблуждение о том, что сеть «безопасна», трудно преодолеть, поскольку, если мы действительно начнем задумываться об этом, ни одна сеть не может быть действительно безопасной. Действительно, единственный способ по-настоящему защитить наши сети и быть на 100% безопасным - это просто не подключаться к сети! Конечно, поскольку мы имеем дело с распределенными системами ... это действительно непросто, поскольку мы знаем, что для связи между узлами в нашей системе требуется сеть.
Итак, что нам делать? Что ж, мы можем попытаться вспомнить, что истинная безопасность - это заблуждение, и что мы можем просто делать все, что в наших силах, чтобы попытаться предотвратить взломы и атаки, когда мы проектируем, строим и тестируем наши системы. Надеюсь, по крайней мере, это на какое-то время позволит избежать проблем с безопасностью.
Во второй части этого поста мы рассмотрим оставшиеся четыре заблуждения. Я обещаю, что эта грустная голубая сетевая капля вернется! Мы еще не закончили с этим.
Ресурсы
О заблуждениях распределенных вычислений достаточно хорошо написано, и вы можете найти несколько хороших ресурсов, посвященных их различным интерпретациям для разных технологий. Если вам интересно узнать больше, ознакомьтесь с приведенными ниже ресурсами!
- Объяснение ошибок распределенных вычислений, Арнон Ротем-Гал-Оз
- Понимание 8 заблуждений распределенных систем, Виктор Чирку
- Разоблачение 8 заблуждений распределенных систем, Рамиль Альфонсо
- Ошибки распределенных систем, Уди Дахан
- Заблуждения возрождения распределенных вычислений: эпоха облачных вычислений, Брайан Долл
- Заблуждения Дойча, 10 лет спустя, Ингрид Ван Ден Хуген
