Семь заблуждений разработки распределенных вычислительных приложений были придуманы в 1997 году человеком, по имени Peter Deutsch. Позже, восьмой был придуман Джеймсом Гослингом (отцом Java).
Эти заблуждения имеют непосредственное отношение к нам, PHP разработчикам, так как мы строим распределенные приложений каждый день. Мы строим гибридные приложения, которые взаимодействуют с аутентификацией пользователей с помощью Facebook, Google, Twitter или API, получают информацию из удаленных баз данных и служб кэширования и т.д. Не делайте ошибки, на построениях распределенных компьютерных приложений.
Учитывая, что мы строим распределенные приложения, важно, что мы понимаем ошибки и как они влияют на нас. Я приведу несколько подобных заблуждений.
1. Интернет надёжен
Справедливости ради стоит сказать, что это, очевидно, не соответствует действительности. Несмотря на задержки в сети снизилась и пропускная способность, заметно выросла из года в год с 1995 года, чтобы сказать, что сеть является надежным, это является ложным.
Давайте предположим, что мы установим простое приложение, которое не использует слишком много услуг — основные приложения PHP, который использует MySQL как в серверной БД. Если подумать, то не так много, что может там пойти не так. Тем не менее, давайте предположим, что позже мы решили найти отдельного
Мы слышим очень много о доступности 99,999%, но даже это никогда не бывает 100%. С распространением услуг, полосы пропускания на сегодняшний день могут быть легко забиты, что когда-то у данного
Как вы объясните провал услуги в вашем приложении?
2. Задержка является нулевой
Хотя задержка может быть низкой, действительно ниже, чем это было несколько лет назад, она никогда не равна нулю. По словам Arnon Rotem-Gal-Oz в своих заблуждениях распределенных вычислений разъяснено сообщение:
Чтобы отправить пинг от Европы до США и обратно, она всегда будет не менее 30 мс, даже если обработка будет осуществляться в режиме реального времени.
Разве это плохо? И да, и нет. В зависимости от того, как мы структурируем наше приложение и ресурсы, имеющиеся у нас, мы можем в значительной степени смягчить проблемы задержки.
Вместо того, чтобы наши приложения, развернутые в одном центре обработки данных, мы можем перевести его услуги, в такие Web-сервисы, как Amazon и использовать S3, так что у нас есть данные, расположенные в нескольких регионах мира, приближая его к нашим конечным пользователям и задержка сокращается в сети. Но даже если мы можем сократить время ожидания, мы не можем его удалить. Мы можем использовать ряд методов и архитектуры, чтобы уменьшить его влияние на нас, но независимо от того, что мы делаем, она всегда будет присутствовать.
Рассматривали ли вы это, когда вы разработали приложение?
3. Пропускная способность бесконечна
Может пропускная способность действительно быть бесконечной? Если да, то какой ценой она бесконечна? Если учесть, что сеть все чаще становится мобильной, всё старое становится новым.
Сейчас я не говорю, что мы начинаем от скорости dial-up, и до новых сетей 4G. 4G быстрее, чем раньше старые 2G и 3G. Но тем не менее, даже их пиковая скорость передачи данных в настоящее время меньше, чем у стандартного широкополосного соединения.
Кроме того, с ростом поглощения мобильного широкополосного доступа, количество возможных пользователей, стремящихся воспользоваться нашими услугами (все мы хотим, быть популярным и иметь по крайней мере некоторые успехи) растет с феноменальной скоростью. Рассмотрим эти статистические данные из mobithinking:
Есть 5900000000 абонентов мобильной связи.
Есть 1200000000 мобильных пользователей Сети с покрытием 3G.
Мобильные устройства составляют 8,49 процентов мировых хитов.
Справедливо сказать, что хотя пропускная способность и проникновение ее во всем мире растет, темпы роста пользователей служат, чтобы сбалансировать её. Двигаясь дальше, с массивной гибкостью, обеспечивают мобильный широкополосный доступ, ясно, что потребления услуг естественно растет.
Готовы ли вы к большим объемам потенциальной нагрузки на службу? Можете ли вы сказать, что вы готовы к этому?
4. Интернет безопасен
Я думаю, справедливо будет сказать, не вдаваясь в слишком много деталей, что это всегда будет не правдой. Если у Вас возникли сомнения, может быть, вам следует поговорить с разработчиками LinkedIn.
Когда мы проектируем наши приложения, как много внимания мы уделяем безопасности?
Благодаря SecurityAffairs, нам сообщили, что:
3000% увеличенного вредоносного трафика ориентированно на сектор финансовых услуг.
На 19.1TB данных и 14 млрд. пакетов вредоносного трафика в сфере финансовых услуг в 4 квартале 2011 года, увеличенного в течение 2012 года.
65TB данных и 1100000000000 пакетов, которые были выявлены в 2012 году, в 80 раз больше, чем в 2011 году.
Учитывая, что сеть не является безопасной, мы должны быть уверены, что мы используем передовую практику безопасности, как нечто само собой разумеющееся. Учитывая множество полезных советов в основе PHP безопасности, трудно не знать, что нужно делать, чтобы обезопасить наши приложения.
Какие методы обеспечения безопасности вы знаете? Как вы думаете, безопасен ли ваш проект на все 100%?
5. Топология не изменяется
Не так ли это? Разве она не изменяется, или мы просто не знаем об этом? Когда мы подключаем наши приложения к другим сервисам, мы просто не знаем, если поставщик перенастраивает свои центры обработки данных, обновляет их, или перенастраивает их по каким-либо причинам, не избежать изменений топологии.
С учетом статистики, увеличена скорость использования смартфонов, топология часто меняется. С точки зрения пользователя и поставщика, топология может меняться почти каждый день!
Если изменения в топологии и внешней службы, которая приведёт последствия, таким как, отключением доступ к базе данных, это уже проблема. Но если у нашего провайдера что-то меняется, а приложение продолжает работать, то это не может быть проблемой.
Как вы устраняете сбои в разработке приложений, и считаете ли, что это допустимо от лиц
Автор: unrealphp