Семь ошибок разработки распределенных вычислительных приложений были придуманы в 1997 году Питером Дойчем. Позже восьмое было придумано Джеймсом Гослингом (отцом Явы).
Эти ошибки напрямую связаны с нами как с разработчиками PHP, так как мы создаем распределенные приложения каждый день. Мы создаем гибридные приложения, приложения, которые взаимодействуют со службами SOAP и REST, проверяют подлинность пользователей через API Facebook, Google или Twitter, извлекают информацию из удаленных баз данных и служб кэширования и т. Д. Не заблуждайтесь, мы создаем распределенные компьютерные приложения.
Учитывая, что мы создаем распределенные приложения, важно понимать восемь ошибок и их влияние на нас.
1. Сеть надежна
Справедливо сказать, что это явно не соответствует действительности. Хотя задержка сети уменьшилась и пропускная способность заметно увеличилась год от года с 1995 года, говорить о надежности сети неверно.
Допустим, мы настроили простое приложение, которое не использует слишком много сервисов — базовое приложение PHP, которое использует MySQL в качестве своего бэкэнда. Там, возможно, не так много, что может пойти не так. Однако предположим, что позже мы решим пойти с поставщиком хостинга для MySQL, таким как Xeround, для обеспечения потребностей нашей базы данных. Несмотря на хорошую масштабируемость и высокую доступность, что, если что-то пойдет не так в их конце? Что если их инфраструктура подвергается DDoS-атаке или имеет простои из-за внутренней проблемы?
Мы слышим довольно много о 99,999% безотказной работы, но даже это никогда не бывает 100%. С распространением услуг и обычно высокой доступностью пропускной способности, доступной сегодня, можно легко забыть, что ничто не является идеальным.
Как вы объясняете сбой службы в вашем приложении?
2. Задержка — ноль
Хотя задержка может быть низкой, даже ниже, чем несколько лет назад, она никогда не равна нулю. Цитирую Арнона Ротем-Гал-Оза в его Объясненных Ошибках Распределенных Вычислений :
При скорости примерно 300 000 километров в секунду (3,6 * 10E12 тераангстром в две недели) отправка пинга из Европы в США и обратно всегда будет занимать не менее 30 миллисекунд, даже если обработка будет выполняться в режиме реального времени.
Это плохая вещь? Ну да и нет. В зависимости от того, как мы структурируем наше приложение и доступные нам ресурсы, мы можем в значительной степени смягчить проблему задержки.
Вместо того, чтобы развертывать наши приложения в одном центре данных, мы можем разместить его в таком сервисе, как Amazon Web Services, и использовать S3, так что у нас есть данные, расположенные в нескольких регионах по всему миру, что приближает их к нашим конечным пользователям и сокращает задержка приложения по сети. Но даже если мы можем уменьшить задержку, мы не можем ее устранить. Мы можем использовать ряд методов и архитектур, чтобы уменьшить его влияние на нас, но независимо от того, что мы делаем, он всегда будет присутствовать.
Рассматривали ли вы это, когда разрабатывали приложение?
3. Пропускная способность бесконечна
Может ли пропускная способность быть бесконечной? Если да, то по какой цене оно бесконечно? Когда мы считаем, что Интернет становится все более мобильным, все старое снова становится новым.
Теперь я не предполагаю, что мы начинаем с скорости дозвона, и более новые сети 4G заметно быстрее, чем более ранние сети 2G и 3G. Но, тем не менее, даже их пиковые скорости передачи данных в настоящее время меньше, чем у стандартного широкополосного соединения.
Кроме того, с ростом популярности мобильной широкополосной связи количество возможных пользователей, стремящихся использовать наш сервис (мы все хотим быть популярными и, по крайней мере, иметь часть успеха Facebook), растет феноменальными темпами. Рассмотрим эту статистику от mobithinking :
- Есть 5,9 миллиардов абонентов мобильной связи.
- 1,2 миллиарда пользователей мобильного Интернета имеют покрытие 3G.
- На мобильные устройства приходится 8,49 процента мировых хитов.
Учитывая это, справедливо сказать, что, несмотря на то, что скорость пропускной способности и ее проникновение во всем мире увеличивается, скорость увеличения пользователей служит для ее балансировки. Если пойти дальше, то благодаря огромной гибкости, которую обеспечивает мобильная широкополосная связь, естественным образом достигается явное временное потребление услуг.
Готовы ли вы к огромному объему потенциальной нагрузки на ваши услуги? Можете ли вы справиться со скачком, который может обеспечить такая доступность?
4. Сеть безопасна
Я думаю, что было бы справедливо сказать, не вдаваясь в подробности, что это и всегда будет ложью. Если у вас есть какие-либо сомнения, возможно, вам следует поговорить с участником LinkedIn или eHarmony .
Когда мы разрабатываем и внедряем наши приложения, как много внимания мы уделяем безопасности как в месте размещения приложения, например, в Rackspace , PagodaBox или cloudControl , так и в дизайне самого приложения?
По данным SecurityAffairs , Prolexic сообщает:
- По сравнению с предыдущим кварталом на 3 000% увеличился объем вредоносного трафика, направленного на сектор финансовых услуг.
- 19,1 ТБ данных и 14 миллиардов пакетов вредоносного трафика в секторе финансовых услуг в 4 квартале 2011 года, увеличившись в течение 2012 года.
- 65 ТБ данных и 1,1 триллиона пакетов, которые были идентифицированы и смягчены в 2012 году, в 80 раз больше, чем в 2011 году.
Учитывая, что сеть не защищена, мы должны быть уверены, что мы используем хорошие методы обеспечения безопасности как само собой разумеющееся. Учитывая множество полезных советов из таких источников, как блог Криса Шифлетта , Essential PHP Security , консорциум PHP Security и другие, трудно не знать, как и зачем внедрять безопасность в ядро наших приложений.
Каковы ваши меры безопасности? Вы оцениваете поставщиков, с которыми вы развертываете?
5. Топология не меняется
Не так ли? В самом деле? Это не изменится, или мы просто не знаем об этом? Когда мы размещаем наши приложения с другими, мы просто не знаем. Если провайдер перенастраивает свой центр обработки данных, обновляет его, корректирует его, по какой-либо причине меняется топология.
Учитывая более раннюю ссылку на увеличение использования смартфонов, топология часто меняется. С точки зрения пользователя и поставщика, топология может меняться почти ежедневно!
Если топология меняется и внешняя служба, на которую она опирается, больше не может быть достигнута, в результате чего, скажем, нет доступа к базе данных, то, конечно, это проблема. Но если внутри нашего провайдера все изменится, а приложение продолжит функционировать, тогда это может не быть проблемой.
Конечно, легко написать маленькое приложение, размещенное в простой конфигурации. Но приложения меняются, а те, что набирают популярность, тем более. Считаете ли вы изменения в топологии в вашем дизайне? Как вы учитываете или обрабатываете сбои в разработке приложений и разработке развертывания?
6. Есть один администратор
«Но мое приложение размещено у одного поставщика услуг. Они обеспечивают поддержку ОС, базы данных и веб-сервера », — говорите вы. Хорошо, если предположить, что это ваше приложение, есть ли один администратор? И если бы на самом деле был только один администратор, вы бы действительно доверили провайдеру свое приложение? Я не хотел бы думать, что может не так, если они заболели или уехали в отпуск.
Обычно администраторов будет по крайней мере несколько, хотя у каждого из них может быть разный уровень подготовки и проницательности, как в техническом, так и в более широком смысле. Должны существовать политики, такие как обнаружение вторжений в сеть и другие политики безопасности, но нет гарантии, что они будут следовать им с одинаковым уровнем тщательности и старательности.
Учитывая огромное количество хостинг-провайдеров, доступных сегодня, и малое время, необходимое для обновления DNS-записей, у нас есть большой выбор и гибкость в том, что если один провайдер не отвечает нашим потребностям и ожиданиям, мы можем перейти от него к другому.
Рассматривали ли вы, как это влияет на вас? Что если вы не в состоянии легко сменить продавца? Что делать, если у вас есть большое количество поставщиков, или это будет дорогостоящим для перемещения? Что если архитектура вашего приложения недостаточно гибкая? Что вы можете сделать, чтобы уменьшить такие риски?
7. Транспортные расходы — ноль
Как и во всех утверждениях, обоснованность этого также крайне маловероятна. Если серверы, поддерживающие наше приложение, находятся в одной стойке в одном и том же центре обработки данных, транспортные расходы могут быть значительно снижены, но с точки зрения затрат времени. Как насчет денежных затрат?
Да, мы можем бесконечно увеличивать и уменьшать масштаб по мере необходимости, и мы можем хранить данные для наших приложений в географически расположенных центрах обработки данных, чтобы они были максимально приближены к конечному пользователю, но какой ценой?
Какова архитектурная композиция вашего приложения или сервиса? Это приближается к нулю в отношении стоимости или времени? Если бы вы могли уменьшить один, это увеличивает другой?
8. Сеть является однородной
В отличие от других заблуждений, я думаю, что именно это мы, как разработчики PHP, по своей сути понимаем. Мы размещаем наши приложения на серверах Windows, Linux, Solaris, BSD и Mac OS X. Мы используем MySQL, SQLServer, SQLite, PostgreSQL, mongoDB, Hadoop и Oracle для хранения данных. Мы используем внешние сервисы через XML или JSON, требующие различных интерфейсов. Как сообщество с несколькими операционными системами и мультисервисными сервисами, возможно, с самого начала, мы никогда не ожидали создания однородной сети.
Но вопрос все еще нужно задать, вы гибки в своем подходе? Можете ли вы работать с несколькими базами данных и источниками данных? Используете ли вы соответствующие шаблоны проектирования, такие как абстрактная фабрика , для использования данных из различных источников и типов с прозрачным интерфейсом кода? Или ваш код ломается, если вам нужно сделать что-то такое же простое, как переход с XML на JSON?
В заключение
Я думаю, как разработчики PHP, восемь ошибок распределенных вычислений так же актуальны, как и прежде. Учитывая огромное количество информации и доступных ресурсов, мы можем понять их и снизить риски, связанные с верой в них.
Как вы думаете? Вы учитываете их при разработке приложений и услуг? Как вы думаете, как восемь ошибок влияют на ваше приложение?
Дальнейшее чтение
- Насколько актуальны ошибки распределенных вычислений сегодня?
- Новая реликвия — заблуждения распределенных вычислений возрождается: эпоха облаков
- Сеть против заблуждений
- CarbonFive — ошибка распределенных вычислений iPhone № 1: сеть надежна
- Распределенные системы: принципы и парадигмы
- Введение в проектирование распределенных систем
- Netflix — 5 уроков, которые мы усвоили с помощью AWS
Изображение через Perrush / Shutterstock