В комментарии выше написано для каких проектов статья. И в каком случае bitrix может переехать в микросервисы. При должном уровне инженеров это утверждение не является верным.
Это, в лучше случае, самообман. Возьмите физический сервер с SSD‑ или NVMe‑дисками, а затем возьмите облачный, и сравните показатели вставки/изменения/удаления записей.
Да вы можете взять физический сервер и получить в нем возможно большие значения чем в облаке. Но будет ли это создавать ощутимую разницу - большой вопрос.
Статья же ведет к проектам, которые уже не могут существовать на монолите и требуют кластеризации. Внедрения кластера БД, распределения запросов, haproxy для отслеживания состояния ноды и какого-нибудь proxySQL для распределения трафика. И вот в этом случае куда проще развернуть облачное решение, чем тянуть его на физических серверах в каком-нибудь ДЦ. При этом облако также несет ответственность за SLA вашего проекта.
Естественно, что если у вас магазин или форум с минимальным количеством трафика, вам не требуется переезжать в облако, вы прекрасно можете существовать на монолите и экономить средства.
Кэширование не решает проблем скорости. Кэширование решает проблемы масштабирования. Если у Вас промахи кэша - это 99 случаев из 100, то кэш бесполезен.
Здесь мы говорим о нашем опыте переезда Битрикс проектов в облачные кластера, и можем вам смело сказать, что потери производительности проекта не было как таковой.
В случае Битрикса это нерелевантно - функционал "из коробки" не имеет микросервисной архитектуры.
Из коробки может Bitrix и не умеет в микросервисную архитектуру. Хотя здесь я не совсем понимаю что вы имеете в виду. Он прекрасно упаковывается в docker контейнеры, перевозится в k8s при должном внимании разработчиков и администраторов, у нас также был и такой опыт в компании.
Здесь все зависит от команд разработки и администрирования, а также требования бизнеса. Если все три понимают, что им нужно масштабирование, то все возможно.
Повторюсь, речь не о проектах, которые имеют минимальный RPS и не имеют потребности в высоком SLA или масштабировании.
Во вторых, в статье довольно лукаво сравниваются цены облачных и физических серверов:
Да, прошу прошения. Исправил цену.
И кстати, кто там говорил, что нужно платить специалисту, который будет админить? Вот в случае облачного сервера вы и будете платить спецу, который будет менять настройку облачного сервера, а с физическим сервером этого не требуется.
Изменения конфигурации занимает 1-5 минут и не требует большой квалификации специалиста. Все делается по нажатию кнопки в личном кабинете.
цены за услуги становятся непредсказуемыми. Потому что за физический сервер обычно платиться $X/месяц, а за облачный - $A за сервер + $B за трафик + $C за API calls + + +
Это все можно просчитать и оплачивать по выставленному счету.
Ограничение на трафик было ранее. Сейчас все Дата Центры отказываются от данного ограничения.
Действительно, формулировка не совсем корректная. В данном случае, говорилось о необходимости изоляции системных сервисов друг от друга, путем выноса их на отдельные виртуальные машины.
В начале своего пути очень много информации, которую трудно переварить моментально. Данные статьи написана простыми словами для обучения новичков. Она не является идеальной. Так, что просим не судить строго)
Если у контейнера не статический ip. То: Когда контейнер пересобирается (Например: необходимо открыть новые порты) ip адрес может измениться, после чего необходимо будет заново настраивать проксирование в nginx, либо указывать новый ip адрес в коде площадки. Все это время площадка будет возвращать ошибку, пока не будет указан новый ip адрес. Также, при переносе на другой сервер ip адреса будут всегда разные и из-за этого необходимо будет всегда править конфигурационные файлы и вписывать правильный ip адрес. Для того, чтоб контейнеры, сервисы могли между собой общаться. Этого всего можно избежать, просто указав статический ip адрес. После чего у контейнера всегда будет один и тот же ip даже если перенести его на другой сервер. Это очень удобно!
В комментарии выше написано для каких проектов статья. И в каком случае bitrix может переехать в микросервисы. При должном уровне инженеров это утверждение не является верным.
Да вы можете взять физический сервер и получить в нем возможно большие значения чем в облаке. Но будет ли это создавать ощутимую разницу - большой вопрос.
Статья же ведет к проектам, которые уже не могут существовать на монолите и требуют кластеризации. Внедрения кластера БД, распределения запросов, haproxy для отслеживания состояния ноды и какого-нибудь proxySQL для распределения трафика. И вот в этом случае куда проще развернуть облачное решение, чем тянуть его на физических серверах в каком-нибудь ДЦ. При этом облако также несет ответственность за SLA вашего проекта.
Естественно, что если у вас магазин или форум с минимальным количеством трафика, вам не требуется переезжать в облако, вы прекрасно можете существовать на монолите и экономить средства.
Здесь мы говорим о нашем опыте переезда Битрикс проектов в облачные кластера, и можем вам смело сказать, что потери производительности проекта не было как таковой.
Из коробки может Bitrix и не умеет в микросервисную архитектуру. Хотя здесь я не совсем понимаю что вы имеете в виду. Он прекрасно упаковывается в docker контейнеры, перевозится в k8s при должном внимании разработчиков и администраторов, у нас также был и такой опыт в компании.
Здесь все зависит от команд разработки и администрирования, а также требования бизнеса. Если все три понимают, что им нужно масштабирование, то все возможно.
Повторюсь, речь не о проектах, которые имеют минимальный RPS и не имеют потребности в высоком SLA или масштабировании.
Да, прошу прошения. Исправил цену.
Изменения конфигурации занимает 1-5 минут и не требует большой квалификации специалиста. Все делается по нажатию кнопки в личном кабинете.
Это все можно просчитать и оплачивать по выставленному счету.
Ограничение на трафик было ранее. Сейчас все Дата Центры отказываются от данного ограничения.
Действительно, формулировка не совсем корректная. В данном случае, говорилось о необходимости изоляции системных сервисов друг от друга, путем выноса их на отдельные виртуальные машины.
Прошу прошение.
Исправил!))
Добрый день.
Постараемся рассказать и объяснить в следующей статье.
Да, все верно.
Вы можете использовать любой smtp 465, либо 587.
Добрый день.
Вы хотите вместо yandex smtp использовать google smtp?
Или настроить точно также, но на стороне google?
Спасибо большое. Учту при написании следующих обучающих статей!
Да, можно так делать. Не был учтен данный момент при написании. Исправлю. Спасибо!
В начале своего пути очень много информации, которую трудно переварить моментально.
Данные статьи написана простыми словами для обучения новичков. Она не является идеальной. Так, что просим не судить строго)
Добрый день.
Да действительно можно не прибивать гвоздями, а использовать переменную.
Постараюсь исправить данный момент в статье. Спасибо!
Спасибо, исправил.
Да, все верно можно так делать.
Но, по нашему опыту обучения стажеров. Лучше на первых этапах обучения работать именно с ip адресами. Для того, чтоб понять весь смысл работы docker.
Привет!
Если у контейнера не статический ip. То:
Когда контейнер пересобирается (Например: необходимо открыть новые порты) ip адрес может измениться, после чего необходимо будет заново настраивать проксирование в nginx, либо указывать новый ip адрес в коде площадки. Все это время площадка будет возвращать ошибку, пока не будет указан новый ip адрес. Также, при переносе на другой сервер ip адреса будут всегда разные и из-за этого необходимо будет всегда править конфигурационные файлы и вписывать правильный ip адрес. Для того, чтоб контейнеры, сервисы могли между собой общаться.
Этого всего можно избежать, просто указав статический ip адрес. После чего у контейнера всегда будет один и тот же ip даже если перенести его на другой сервер. Это очень удобно!
Спасибо, исправил!))
Исправил и добавил информацию по telnet. Спасибо!
Добрый день. Да, действительно перепутал. Спасибо, исправил!