Далеко не всегда. Мой опыт работы кредитным экспертом в банке говорит что далеко не всегда. Больше половины клиентов получавших у нас кредиты от 20к$ до 100к$ не имели учета даже в экселе, а только в тетрадочке.
Это был другой проект. Не магазин. Там была специфичная статистика для прогнозирования закупок. Боксовые решения не учитывали их специфику.
Ой, всё.
Неоднократно всё было пережевано. Мне лень, я сливаюсь.
Правда?))))
Если притянуть все три стороны в агрессивную юрисдикцию вроде РФ или Украины, сделать все бумаги по взаимоотношению ДЦ и провайдера самым худшим образом, то эта история потянет на штраф.
Я вам на пальцах объясню, раз уж вы путаетесь в вопросах оптимизации налогообложения и скрытии налогов, то попроще:
У любого уголовного преступления есть квалифицирующие признаки. Лучше всего они описаны в НПК или его аналогах, но поскольку мошенничество относится к преступлениям против собственности, то нужно чтобы была незаконная выгода одной стороны в ущерб другой стороны, и чтобы для этого был некий обман и т.п.
Пострадавших здесь нет. Да, плохо указывать реквизиты другого юр.лица. Плательщик может иметь другие налоговые последствия (в данном случае указан полнейший оффшор, так что реально хуже некуда, но чисто теоретически). Но здесь нет умысла и т.п. Ущерб от этого действия если и есть, так это упущенная прибыль пейпела, и если правилами палки это запрещено (вебманями запрещено вроде), то они могут ругаться да, но это будет гражданский иск, не уголовный.
А так то "любой юрист" сделает "рукалицо" если его спросить.
С мошенничеством тут тоже слабовато :)
Но вот если скан документа про который вы говорили реально левый, и это можно доказать (реального человека можно найти), то это да, будет явным признаком пачки уголовных статей.
Может и мошенничества.
Те части которых у вас нет вообще? Да, предусмотрена возможность включать капчу и таймаут в моменты пиковой нагрузки. Доли процентов клиентов конечно могут обидится, но это лучше чем вообще деградировать до безбазового кеша.
Единая инфраструктура это что?) Импорт/экспорт с 1С это уже единая инфраструктура. Я же говорю про единую архитектуру. Тут проще. Никто не требует чтобы ваш бекэнд жил на том же сервере что и шоп. Но когда все части системы написаны на одном фреймворке и т.п. - это упрощает поддержку.
И кстати слегка оффтоп конечно, но вы со своей бухгалтерией и складом тоже сильно ограничиваете нишу. У нас сейчас американский клиент - розничная сеть работающая в большинстве штатов. Т.е. не маленькая. Видели бы вы их склад и бухгалтерию - ад кромешный. Но им хватает. Простота бухучета и бюрократия работающая на бизнес а не против - всё сглаживает. А то что всё криво так это наша проблема а не клиента. И то как интегрировать кучу разных сервисов (включая бухгалтерские программы и т.п.) без использования "а тут у нас мальчик в экселе быстренько переконвертирует" - это тоже наши проблемы а не его.
Для всего реально хватает вполне простых решений, и для меньшего размера магазина, не сетевого вполне хватило бы для всего - простенького склада и пары стат.отчетов в боксовом шопе.
Коробки, особенно бесплатные - кривые. С этим мы определились еще в прошлом году. Да, падают при каждом ДДоС. И что?
0.25с это самые узкие места. Которые кешируются. С инвалидацией не по времени а по более разумным критериям. И по частям. Скажем сайдбар закешировали один раз и всем выдаем его. Топменю закешировали один раз, инвалидируем по легкому условию вроде самой свежей даты изменения страницы у которой стоит галочка "выводить в топменю".
Этот запрос "дешев", но в хайлоаде его тоже можно держать в мемкеше. Что у нас еще? Всякая статика типа меню в футере и прочих текстов? Тоже в кеше. Что еще ? Хлебные крошки? Сео-текст, тайтл, мета-дескрипшн? Хлебные крошки делаются одним простым запросом еще на уровне разбора URL, и кешировать их нет смысла. Мета-данные страницы тоже достается запросом. Запрос списка товаров из категории с соответствующими количествами на страницу, сортировками и т.п.? Ну один легкий запрос. Рендеринг превью самих товаров? Так закешировано. Инвалидируем по изменению связанных данных. Сам товар, его атрибуты и т.п. Если зависимости сложные и их много - редкоменяемые связи могут связанным данным поменять некий параметр последнего изменения кеша, чем инвалидировать всех кто связан.
Итого в реальности выйдет каждая десятая страница доходит до пхп (остальное кешируется еще нгинксом), из них 90% страниц или закешированы более чем на 90%, или ладно уж, генерятся за 50-200мс. У реального проекта может быть несколько узких мест, но сходу приходит в голову ТОЛЬКО сложный поиск. Его да, частенько надо защищать. Но под атакой его можно и деградировать или закрыть капчей. У вас же его в принципе быть не может по определению.
У меня где нужно используется кеш, а где нужно - база. Даже если база используется в 0.1% случаев, то она у меня есть. У вас же есть только кеш. Любое изменение у меня это разовый пересчет страницы когда понадобится, у вас же - жди пока будет пересчет.
fail2ban и другие инструменты работают не хуже рук.
Лет 10 назад было с "1000 проксей". Положили да.
Недавно китайцы парсили в 100 потоков. Там была дюжина AS всего. Ничего не делал. Не успел. Минут за 10 сервак их всех побанил и все вернулось.
Еще было пару раз более интеллектуально, по узким местам и все такое. Но сам не разгребал это было на более-менее толстых проектах где были выделенные админы.
Ну и за клудфларе прятаться приходилось пару раз.
Флуд это задача хостера или магистрала или своего админа если сэкономили на хостинге.
Не всякие страницы а только те которые слабые места.
Вы этим форумом пользоваться пробовали?) Поиск даже для авторизованных - именно так и закрыт, и ничего.
А вы? У вас то как раз "только то что в кеше, остальное - не судьба". Сделайте мне поиск по произвольному атрибуту по 100к товаров без базы. Посмотрю на вас)
50 одновременных заходов паука это мелочи. Было как-то за сотню. Лет семь назад. Положил сервер да. Ну тогда там косяк мой был, он таки миллионы страниц "находил" у меня. Очень грубо говоря я ему дал кушать вывод "анонимайзера" (не совсем но похоже).
Но мы ведь не обсуждаем косяки роботс.тхт и экзотические сложные проекты. Crawl-delay никто не отменял. Индексировать служебные страницы и страницы поиска никому не нужно и все такое. В общем - мимо кассы.
Не пугает, поскольку вы в очередной раз боретесь с выдуманными вами ветряными мельницами. Склад отдельно, бухгалтерия отдельно, магазин отдельно. У вас еще и витрина отдельно от основного магазина. Имеет право на жизнь для части простых магазинов, но в среднем - не катит.
А кто сказал что бухгалтерия и склад должны быть в магазине?)
Ваш код который генерирует для вас странички (по 5 секунд Карл!) это и есть бекэнд. И нет ни у кого такого бекэнда. Это часть магазина, просто вы ее держите на другом сервере. Всё. Если оно является отдельным ПО, то ок, если оно встроено в вашу ERP, то... тоже ок. Но... это все равно часть магазина.
Если вы ее реализовали на 1С или на С++ или на бейсике - оно не перестает быть частью магазина. Но это скучно. Вы повторяетесь и мне лень вам это объяснять по 100500 раз.
Вы лучше расскажите как вам удалось 5 секунд на страницу выдать?
Откуда такой ужас. Не подумайте что это "переход на личности".
Реально интересно что же может генерироваться по 5 секунд.
Ну и если Вы такой опытный что используете MVC уже 15 лет как, да еще и ООП знаете, то можете сказать сколько в вашем типичном контроллере строк всего, и сколько методов. В общепринятых терминах (т.е. контроллер это класс контроллера у которого может быть 1 и более action которые в академическом MVC и являются контроллером).
Не, как экзотика оно конечно бывает. Но интересно более-менее распространенный вариант. Так то и с питоном шаредов полно. Но в мейнстриме у нас только пхп. С другой стороны постгри раньше был экзотикой, а сейчас у каждого второго на шареде есть.
Ну IO последнее время редко упирается да. Если есть SSD или сата + ссд, то ИО загрузить сложно. Но вот память - памяти никогда не бывает много. Вся свободная память это кеш.
Да и процессы которые не могут взять всё что им надо из кеша - едят память. Особенно СУБД ее хорошо кушает. Если ВДС берется не по причине специфического софта а по причине нагрузки, и код оптимизирован (чаще всего дешевле тупо докупить серверов, чем улучшать код - вдс-ка завесит десятки баксов, а разработка может и тысячи), то память будет очень даже в цене.
оффтоп: кстати вот раз тут хостеры собрались. бывают мемкеши на шареде? Буквально 8-16мб мемкеша могут поднять производительность на порядок.
Всё. Уже работает. (Строго говоря нет, строго говоря еще в языковых переменных надо написать тексты соответствующие нашим сообщениям. В идеале всем контроллерам, но лично я вот сейчас сделал в одном месте дефолтное значение, и дальше поленился).
Всё работает во всех админках, выводится и для редактирования страниц, и для товаров, и для пользователей. Для всего. Сейчас пока писал комментарий, так быстренько дописал, давно думал, но руки не доходили.
Даже не представляю как вы могли так умудрится. Совсем не представляю. У меня без оптимизаций, без половины индексов, без кеширования, без жадной загрузки и т.п., на сложных страницах выходит в пределах 0.25с. Нет, при сложных запросах статистики с сотнями тысяч записей или еще каких жирных местах - бывает и до двух секунд доходит, но это всё в админке, так что под ДДОС не пойдет.
А при чем тут урлы? Кешируют данные а не урлы, если пачка запросов будет одинаковая, то всё пойдет из кеша. Плюс кешируют не целую страницу а кусочки. Даже у разных страниц куча общих кусков есть. Нет кешируют конечно и целые страницы, и уже сформированный кусочек HTML, но там где это не поможет, там отрбатывает более низкоуровневое кеширование.
Таких мест где не кешируется ответ, да еще и полсекунды на ответ - мало. За ними приглядывают.
При этом все это время приходится на разные элементы системы, нет такого что допустим один проц только и колбасит эту страницу полсекунды. Работает вебсервер, пхп, база данных и т.п. Процессоров много, одновременно все сайты не нагружают, так что пиковые 120 пользователей на сайте одновременно это ни о чем, как для современного сервера. А если у вас сотни пользователей одновременно не пиково, а постоянно то это миллионы (десятки миллионов) хитов в день. Вполне можно и VDS взять при такой нагрузке.
С другой стороны выдавать атаку в сотню IP давящих на слабое место - дорогое удовольствие. Допустим вы выдаете один запрос в 10 секунд. Чаще - забаню буквально со второго или третьего запроса. Тогда это 2000 одновременных IP чтобы держать 100 одновременных сессий. Такую пачку уведут в бан минут за пять. Слишком много сложных запросов на фоне отсутствия мелких... Нереально.
За час у вас улетит весь запас взломанных IP что у вас был). Но час никто держать атаку не будет. Допустим вы лупанули не сотню а тысячу одновременных сессий. Это уже чувствительно. Сервер "понимает" что идет атака, атака тяжелая, и антиДДоС выводит всем у кого нет куки что его проверили заглушку, которая пару секунд грузит клиентский комп, и только после этого проходит дальше. Допустим хеш какой-то генерит пруфовворк. Компы без браузера уже улетели. Компы которые зашли сразу в слабое место бьют - улетели. Те что остались - сильно греются).
В общем цена атаки вырастает до очень заметных сумм. А там уже более серьезная защита работает.
Но повторюсь - сайт который тратит полсекунды на какую-то страницу где нельзя серьезно закешироваться, и это доступно для неавторизованных пользователей - нонсенс.
Вы просто отстали от современных реалий лет на 10.
Так то я тоже там был, но более-менее успешно перешел в современный мир разработки.
В свое время была такая пословица, мол человек изучавший (в школе) Бейсик - потерян для программирования навсегда. Да, было больно, но я это из себя выколупал)
Вы опять толкаете свою ситуацию на всех. Нет никого тонкого магазина. Есть только Толстый бекэнд который у вас уже есть, а у других нет.
Но дело вообще не в этом.
Если у вас действительно современная продуманная архитектура (в бесплатных магазинах я этого не видел в принципе) то даже ооочень большие изменения ТЗ часто требуют микроскопических изменений кода.
Первый принцип который вы намеренно игнорируете это DRY. Это конечно для затравки. Принцип уж очень неконкретный, но обязательно его нужно держать в голове. Вот просто всегда. Любое решение по архитектуре (да и по прикладному коду) должно проходить через фильтр "а не слишком ли я мокро пишу?".
Второй принцип (точнее группа) это SOLID. Этот кусок я даже расшифрую ибо 100% программистов проходят через неверное понимание этого принципа.
1 - Принцип единственной ответственности - говорит нам о том, что один класс (или файл, или набор функций, ООП необязателен, хоть принцип и из ООП) выполняет одну функцию. В частности важнейший шаблон (см. ниже) MVC является примером правильного решения этого принципа. Самый минимум это отделение HTML от логики. (Да, многие всё еще используют такую кашу). Естественно возникает желание отделить еще и SQL в отдельное место. И механизм взаимодействия с базой отделить. Да так, чтобы мы могли поменять его на работу с файлами, вместо базы, и не менять весь код магазина. Примерно так у нас получится зачаточный MVC. Тупой, жирный и все такое, но уже почти MVC.
2 - Принцип открытости/закрытости - очень простой (и очень сложный для понимания) принцип. В ООП мы для каждой задачи делаем класс решающий наш частный случай, наследуясь от класса решающего более общую задачу. Принцип требует чтобы более общие классы (родительские) проектировались так, чтобы их легко было расширять, добавлять новые функции и т.п., при этом дочерние классы должны писаться так, чтобы не переписывать родительский код. Только то, что идет сверху.
3 - Принцип подстановки Барбары Лисков «объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.» Т.е. если мне не подходит поведение скажем класса отвечающего за работу базы данных. Скажем у меня выросли потребности, я решил сделать несколько серверов БД, допустим банальная схема где запись в базу идет на главный узел, а для чтения идут несколько серверов которые автоматом синхрониируются. Ну и мне нужно сделать разделение запросов на чтение и запись, и для чтения сделать балансировку. Я делаю новый класс, который наследуется от старого, и заменяю на него все вызовы (в конфиге сервис-локатора меняется имя класса и везде меняется где он нужен). При этом я не меняю логику обращения к моему классу. Все функции что были у родителя остаются неизменными. Я не могу например потребовать чтобы вместе с запросом мне передавали информацию о том является ли запрос на чтение или на запись. Если изначально не предусмотрел, то менять структуру, благо это тоже просто, но нельзя сделать так, чтобы для односерверной реализации такой параметр не передается, а для многосерверной передается. (Да, я у себя не предусмотрел, и не буду, ибо у меня есть другой класс, общий для всех, где это потом легко делается). Т.о. если у меня 300 разных сущностей (разные виды документов, всякие товары, юзеры, комментарии и т.п.), то нигде ничего не меняется. Только в одном месте.
4 - Принцип разделения интерфейса: Клиенты не должны зависеть от методов, которые они не используют. Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться клиенты, которые этот метод не используют. Не "проще" а раздельно.
5 - Принцип инверсии зависимостей - не очень четко, но смысл в том, чтобы уменьшить взаимные зависимости разных частей. Одна из реализаций этого принципа это то что я писал выше - модули работающие с базой не завязаны на конкретную реализацию, и поэтому изменение в одном месте не требует изменений везде. Я меняю класс базы данных, и все остальные классы этого и не замечают поскольку завязаны на абстракции, а не на реализации.
Принцип MVC - типичный принцип используемый для сайтов. Смысл в том, что весь прикладной код бывает трех типов.
Модели - основной код со всей логикой. Описывают всякие сущности в проекте. Пользователи, товары, категории, страницы, платежные системы, адреса, заказы ит.п. - всё с чем мы работаем это модели. Модель хранит данные и имеет методы для манипуляции с ними. Например комментарий который пишет пользователь, чужие комментарии которые видны в списке, свои комментарии которые мы можем редактировать, комментарии которые видны в админке, комментарии которые ждут модерации - всё это комментарии, и если допустим мы сделаем у него... да пусть признак "автор является топикстартером" (допустим комментарий в форуме), то это свойство будет везде. И мы можем на его основе иначе отображать как пользователям, так и админам, иначе модерировать и т.п. Сразу и везде.
Представления (View) - код отвечающий за внешний вид. Обычно это не только шаблон а именно код, с ним связанный, но бывает логика представления лежит прямо в шаблоне. Возьмем к примеру категорию товара. В админке она выглядит и как строчка в таблице, и как форма с данными и как табличка со значениями. На сайте это красочная страница с кучей плюшек в которой и подкатегории и товары этой категории. А еще может быть у разных категорий совсем разное оформление. Но это одна категория, с одними свойствами, одними методами и т.п. (Модель). Просто выведена в разных представлениях. При этом представление может быть одно даже у разных моделей, например можно для раздела новостей использовать представление такое же как у раздела статей. Или еще момент - у меня есть превью для товара. У него есть картинка, название, текст, плашки новинок/бестселлеров, ссылка на категории, форма быстрого добавления товара в корзину и т.п. Они одинаковые что в разделе товаров производителя, что в поисках, что в списках товаров в категориях, что в списках товаров подкатегорий у "метакатегорий", что на главной в красивых листалках для топпродаж и т.п. Еще есть списки похожих, рекомендуемых товаров, "запчастей" и прочего. В типичном товаре таких мест с дюжину а то и больше. Если у этого блока хорошо с универсальностью, и есть настройки, например в категории мы выводим текст краткого описания а в списке акций на главной - нет и т.п., то мы можем сделать его лишь в одном месте. И если на вдруг нужно будет допустим изменить размер картинки, то мы поменяем его в одном месте, а не в дюжине.
Контроллер - это такая штука которая просто связывает разные части проекта между собой. Типичный пример - форма редактирования (чего-то, не важно чего). Наш контроллер получает от другой части системы информацию о том что именно редактируем (Например ид страницы), получает соответствующую модель, проверяет не передана ли уже информация в форме, если нет, то просто выводит страницу с формой редактирования и исходными данными, если уже что-то введено, то проверяем что оно введено правильно (дергаем у модели метод проверки правильности), если ок, то сохраняем и переадресуем в список товаров или страниц или что редактируем, если неправильно, то берем у модели информацию что неправильно, и сообщаем представлению, которое выведет форму с сообщениями об ошибках.
Пример:
public function updateAction() { $page = $this->preparePage(); // ********************************************************************** $model = $this->model(); // Пробуем обновить данные из POST, если обновили и данные валидны, то сохраним if(s()->post()->update($model) AND $model->isValid()) { $model->save(); $this->redirect(); } else { $page->model = $model; s()->layout()->show($page); } }
Например мы захотели вывести на странице куда будет переадресован пользователь сообщение о том, что объект который он редактировал - отредактировано.
Ок, не вопрос. Добавим одну строчку и получим:
public function updateAction() { $page = $this->preparePage(); // ********************************************************************** $model = $this->model(); // Пробуем обновить данные из POST, если обновили и данные валидны, то сохраним if(s()->post()->update($model) AND $model->isValid()) { $model->save(); s()->alert()->success($this->lang('updatedAlert')); $this->redirect(); } else { $page->model = $model; s()->layout()->show($page); } }
И тем не менее это уже второй человек в этой теме называющий меня вашим клоном :)
