Просто зачем каждый раз городить огород, если можно использовать ту же кодовую базу?
С таким успехом монолитом нельзя считать 2 системы, работающие на одном фреймворке. :)
А вообще какая разница что это: отмасштабированный монолит / чистейший микросервис.
Разве отмасштабированный монолит не может в придачу общаться посредством очереди кроме балансировки по урл?
Главное, чтобы задачи решало.
У кого-то микросервисы могут ходить в одну базу / писать/читать одни и те же файлы.
У кого-то все изолировано (как при использовании сторонних API).
Везде нужно подходить с умом.
А то заставь дурака богу молиться. :)
>Например, входящие API-запросы, фронтэнд панели управления и фоновые задачи могут находиться в одной кодовой базе, но не обязательно на каждой машине обрабатывать все три типа запросов.
Оба представленные способы неправильные. :)
Первый — на ровном месте писать код, который ничего не делает.
https://hsto.org/getpro/habr/post_images/9fa/b88/49a/9fab8849a56fd96c3e4f02a998ecad37.png
Второй — шаблонизатор на ровном месте, когда можно обойтись нативным js.
>Мы выносим всех битрикс-клиентов в отдельные сервера, которые специально сконфигурированы и оптимизированы именно под битрикс.
Чем же они отличаются от других высокопрожорливых? :)
>ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно
Перейти с арендованного SAS на арендованный SSD.
>Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях
Возможно.
>С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Это было 5 лет назад? Ок.
Если архитектура гнилая, то, когда она упрется в один сервер, ее трудно будет масштабировать.
>Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности,
Я не понимаю, как оно мигрировало, что недомигрировало.
Если недомигрировало, то хостеру нужно начитстить место, который он ест.
Если же оно домигрировало, то мои предыдущие опыты говорят, что хостером все удалялось нафиг (может они сохраняли инфу какое-то время у себя, хз).
>Речь идет о фактах
Я о самом утверждении «облака решат все ваши проблемы».
Также вы не ответили об отличиях облаков от классических технологий.
>Всех наших битрикс-клиентов мы выносим в отдельные сервера, где есть только битрикс-клиенты.
Какая разница, кто где есть? :)
>Первоначально была идея на наших серверах перейти с SAS-дисков на SSD, но, просчитав стоимость такого перехода, мы поняли, что гораздо выгоднее нужные мощности арендовать.
Блеать, вы же жили в арендованном сервере…
>Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
+ рисунок внизу.
Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
Не проще было сразу на SSD перейти?
Попахивает рекламой хостера. :)
>Вот это падение на отечественном хостинге «всего лишь на 3 минуты» выстраивало большую очередь к нашей БД, подвисали все пользователи и система 1С могла за эти 3 минуты выбить блокировку
У вас просто гнилая архитектура.
С ростом эта проблема опять вернется :)
>было заметно, что хостер не рассчитывал на то, что все клиенты единовременно будут на все 100% использовать арендуемые ими мощности.
Можно подумать, там одни юрики хостят свои бизнес-процессы. :)
Какие именно мощности вы арендовали?
>Комментарий от SIM-Networks
Такие задержки, чаще всего происходят, когда на сервер рассчитанный, скажем на 5 клиентов провайдер размещает 10 клиентов, в (наивной) надежде, что они никогда не будут использовать все свои (уже купленные ими!) мощности. Мы считаем, что если клиент купил место, купил запас мощности – то пустует оно или нет – это уже клиента, и он может делать с ресурсами все что захочет.
Скорее всего перепроданный сервер будет дешевле.
Но не факт.
>И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.
Но вы же на ссд переехали только у своего любимого иностранного хостера…
>Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).
Хм, пару раз проводились миграции.
Никогда никакого подтверждения хостеру, что все ок не давал, а он никогда не говорил, что вдруг что, есть старая.
Нужно было самим мигрировать.
>В воскресенье в обед реструктуризация новой полки еще не была закончена
Что это такое?
>Перефразируя эту мысль можно сказать: если вы развиваетесь – считаем что нужно идти в облака.
Хватить толкать маркетинговый бред.
>Мы снова хотим расширяться, так как нам уже не хватает мощности, и серьезно рассматриваем вариант с облаком.
Вы же уже в облаке, нет?
П.С.
Дочитал до конца, это хостер сам себя хвалил :)
С таким успехом монолитом нельзя считать 2 системы, работающие на одном фреймворке. :)
А вообще какая разница что это: отмасштабированный монолит / чистейший микросервис.
Разве отмасштабированный монолит не может в придачу общаться посредством очереди кроме балансировки по урл?
Главное, чтобы задачи решало.
У кого-то микросервисы могут ходить в одну базу / писать/читать одни и те же файлы.
У кого-то все изолировано (как при использовании сторонних API).
Зачем 2?
>Настраивать сервер как Вы уже поняли, будем первый раз, поэтому о актуальности статьи можно будет судить из комментариев.
Корелляции тут 0. :)
>Установим кодировку по умолчанию:
charset utf-8;
Вряд ли так стоит делать…
>Перенаправить запрос Apache:
proxy_pass http://localhost:8080/;
проксировать следует только php.
>Читать заголовок запроса клиента не более 10 секунд:
client_header_timeout 10;
Мобилки могут сказать привет :)
>client_body_timeout 25;
и
client_max_body_size 8m;
У клиента должна быть скорость интернета от 2,6 mbps.
>Если клиент не принимает ответ более 8 секунд, сбрасываем соединение:
send_timeout 8;
Опять мобилки :)
Забыли прописать хост по умолчанию… :)
>Отключаем обработку большого количества запросов в одном соединении:
KeepAlive Off
Почему?
>Подключить mimetypes:
<IfModule mime_module>
TypesConfig /etc/mime.types
Зачем, статику ж отдает nginx?
>Закрываем доступ к .htaccess:
<Files ".ht*">
Require all denied
Лучше на nginx закрыть…
А то заставь дурака богу молиться. :)
>Например, входящие API-запросы, фронтэнд панели управления и фоновые задачи могут находиться в одной кодовой базе, но не обязательно на каждой машине обрабатывать все три типа запросов.
На самом деле это микросервис :)
Объясните, пожалуйста, почему в последнее время стало модно говорить, что DOM тормозит?
Что вы такого с ним делаете? :)
А всякие AngularJS и ReactJS, якобы борясь с DOM тормозами, сами тормозят еще больше :)
Вся эта возня — псевдопрограммирование, когда вместо решения текущей задачи занимаются решением большего количества проблем от ее псевдорешения.
В PHP не в произвольную, есть разумные ограничения.
>Вот теперь заказчик сам вам сказал, где следует породить исключение в написанной для него программе
Не в этих ли случаях их использовали, давая указанные вами пояснения? :)
Первый — на ровном месте писать код, который ничего не делает.
https://hsto.org/getpro/habr/post_images/9fa/b88/49a/9fab8849a56fd96c3e4f02a998ecad37.png
Второй — шаблонизатор на ровном месте, когда можно обойтись нативным js.
Это как заставить дурака молиться богу. :)
Он на порядок (-ки) быстрее распрасит, и памяти меньше жрет.
Но парсер нужно почти писать самому. :)
При этом в результирующий массив пихаем только то, что реально нужно, а не весь мусор.
Партите с помощью xml_parser_create()? Какой размер файла?
Да и куча их появилась в последнее время. Их же кто-то написал. Или их написали идиоты, которых потом уволили за это? :)
А как же микросервисы и зоопарк из сопутствующих технологий тому же Реакту? :)
В чем вообще трудность? :)
Клиенту выделяется ВДС или это шаред хостинг?
Чем же они отличаются от других высокопрожорливых? :)
>ответ в статье, клиент просчитывал стоимость перехода, и понял что это не выгодно
Перейти с арендованного SAS на арендованный SSD.
>Очевидно, большинство ваших комментариев вызвано тем, что возможно в статье не так четко обозначено то, что у клиента не вся инфраструктура целиком и сразу была на арендуемых мощностях
Возможно.
>С ростом у клиента проблема не возвращается, и мы сделаем все, чтобы не вернулась:) 5 лет роста это подтверждают.
Это было 5 лет назад? Ок.
Если архитектура гнилая, то, когда она упрется в один сервер, ее трудно будет масштабировать.
>Тут можно поспорить, но тут становится актуальным вопрос клиентоориентированности,
Я не понимаю, как оно мигрировало, что недомигрировало.
Если недомигрировало, то хостеру нужно начитстить место, который он ест.
Если же оно домигрировало, то мои предыдущие опыты говорят, что хостером все удалялось нафиг (может они сохраняли инфу какое-то время у себя, хз).
>Речь идет о фактах
Я о самом утверждении «облака решат все ваши проблемы».
Также вы не ответили об отличиях облаков от классических технологий.
И чем оно отличается от вдс/выделенного сервера.
Какая разница, кто где есть? :)
>Первоначально была идея на наших серверах перейти с SAS-дисков на SSD, но, просчитав стоимость такого перехода, мы поняли, что гораздо выгоднее нужные мощности арендовать.
Блеать, вы же жили в арендованном сервере…
>Главной задачей было – убрать эти очереди к БД, и на тех мощностях которые мы сейчас арендуем у провайдера SIM-Networks – удалось решить эту наболевшую для нашего бизнеса задачу.
+ рисунок внизу.
Искали облако, но поперлись к тому самому хостеру, а еще смотрели других хостеров.
Не проще было сразу на SSD перейти?
Попахивает рекламой хостера. :)
>Вот это падение на отечественном хостинге «всего лишь на 3 минуты» выстраивало большую очередь к нашей БД, подвисали все пользователи и система 1С могла за эти 3 минуты выбить блокировку
У вас просто гнилая архитектура.
С ростом эта проблема опять вернется :)
>было заметно, что хостер не рассчитывал на то, что все клиенты единовременно будут на все 100% использовать арендуемые ими мощности.
Можно подумать, там одни юрики хостят свои бизнес-процессы. :)
Какие именно мощности вы арендовали?
>Комментарий от SIM-Networks
Такие задержки, чаще всего происходят, когда на сервер рассчитанный, скажем на 5 клиентов провайдер размещает 10 клиентов, в (наивной) надежде, что они никогда не будут использовать все свои (уже купленные ими!) мощности. Мы считаем, что если клиент купил место, купил запас мощности – то пустует оно или нет – это уже клиента, и он может делать с ресурсами все что захочет.
Скорее всего перепроданный сервер будет дешевле.
Но не факт.
>И только после года таких мучений, компания хостер согласилась купить специально под нас SSD-полку в свой дата-центр.
Но вы же на ссд переехали только у своего любимого иностранного хостера…
>Провайдер обещал осуществить миграцию всего за сутки. В воскресенье в обед реструктуризация новой полки еще не была закончена и мы начали просить все вернуть как было, на что получили ответ, что на старой арендуемой нами мощности наших данных уже нет (- а мы перенесли, смотрим система поднялась и поэтому старую БД удалили – сказал хостер), хостер решил удалить эти данные, так как считал, что миграция уже произошла и их хранить уже не обязательно ( — Они сошли с ума!? – подумали мы).
Хм, пару раз проводились миграции.
Никогда никакого подтверждения хостеру, что все ок не давал, а он никогда не говорил, что вдруг что, есть старая.
Нужно было самим мигрировать.
>В воскресенье в обед реструктуризация новой полки еще не была закончена
Что это такое?
>Перефразируя эту мысль можно сказать: если вы развиваетесь – считаем что нужно идти в облака.
Хватить толкать маркетинговый бред.
>Мы снова хотим расширяться, так как нам уже не хватает мощности, и серьезно рассматриваем вариант с облаком.
Вы же уже в облаке, нет?
П.С.
Дочитал до конца, это хостер сам себя хвалил :)
Поэтому и использовал xml_parser_create.
Это ж ООП.
Чего вы хотели :)
>Затем им надо создать продукт, который очень понравится пользователям. Только после этого они должны сфокусироваться на росте.
Как же они растут, если они не нравятся пользователям? :) Реклама?
Сэм Альтман — родня Семену Альтману? :)