Чтобы в него по 10 лет не залазить он изначально должен быть написан добротно.
Без явных багов и "красивый код" — понятия очень разные и обычно не пересекающиеся
только обертку поменять не заглядывая во внутрянку
Я там на 3 абзаца расписал, что обертку менять вообще не нужно. Плохая архитектура — если ее нужно постоянно менять…
пока пхп7 не отменит конструкторы пхп4стайл
Ну живет отдельный сервис у вас нас php4. Он же жить вам не мешает — пусть живет и дальше. Нужно будет в нем правки делать — и php обновим и говнокод перепишем. Работает — не трож. Тем более можно и не трогать. Трогают обычно от желания поучиться вместо того чтобы поработать.
расширение протокола всё сломает
Ну вот я привел пример почты — протокол 40 лет не меняется. Нормальные люди его сделали. Грамотные в архитектуре. SMTP. Потом появился ESMTP — но он не противоречит старому и целиком и полностью его поддерживает.
Это больше к вопросу выбора решений — не нужно выбирать сырое, что еще много раз поменяется.
Не только в монолите — он нужен там где его реально будут менять. т.е. пусть у вас модуль или сервис который постоянно переписывается — он должен быть "красив", прост и понятен. Верстка та же, стили и прочее — оно постоянно меняется. там должен быть порядок.
А вот из каких тряпок и грязи собрали модуль отправки писем — не важно, главное что отправлял в соответствии с ТЗ. Если он верно написан — шаблонов писем в нем не будет. И менять там впринципе нечего — почта она вон 40 лет не меняется.
Ну а что там внутри модуля — это дело конкретной реализации конкретной задачи. Хоть там белые мыши на трубе играют. Не важно в целом. На это кстати целый термин в ООП придумали. Инкапсуляция.
А композиция в терминах архитекутуры — это несколько расширенное понятие полиморфизма.
Суть архитектуры — разделять код. модуль от модуля, сервис от сервиса. Хороший код, от времянок и говнокода. Тогда архитектура помогает разрабатывать.
По поводу масштабов — вопрос размера решения. Если оно маленькое — архитектура работает на уровне модулей. Если большое — на уровне сервисов.
Т.е. не нужно делать ее многоуровневой. Какие могут быть модули в сервисе? никаких — он одну фичу делает. одну функцию. Как может быть архитектура внутри модуля в монолите? тоже никакой.
Вложенные модули в модули и прочее — адское зло и в целом противоречит идеям композии, переиспользования. А в целом — еще и порождает массовые зависимости между модулями. Чего в хорошей архитектуре быть вообще не должно.
Сначала привыкает делать так у себя на десктопе, потом делает так на сервере. А потом этот сервер достается другому человеку. И мучайся потом с вашими make install, libc6 из сырцов и прочими попытками админить не по документации к ОС.
Не говорите слово docker. Он настолько адски сырой, что его и трогать пока страшно.
P.S. потрогал, посмотрел, попользовал — отложил в ящик, через 1-2 года достану.
Ну странный у вас /var/log какой то, что его за полчаса забило.
Да и умные люди делают по умному — один сервис — одна виртуалка. И пусть она хоть упадет.
Ну наверное попытася взлететь назад — это первое что должно случится с сервисом. А мониторинг никто и не отменял. Ну придет админ через полчаса, увидит, что сервис работает — пойдет курить дальше. Или увидит что не работает, но полчаса ничего не испортят. А пытатся взлететь надо.
А мониторить это совсем легко и просто. Есть отличная метрика — сколько новых pid появилось по сравнению с предыдушим состоянием и сколько пропало. Я эту метрику собираю со всех машин — для разных ролей машин конечно движуха разная, например на машинах с nginx пиды почти не меняются, а вот с php-fpm или postfix есть регулярная ротация. Главное корректно настроить Alert в мониторинге.
цепочки сигналов (чтобы прибивать процессы которые повисли разными способами с таймаутами)
А это вообще может быть очень чревато и печально, особенно если SIGKILL, особенно если на высокой нагрузке.
серверов маков и линуксов и тупо не получиться пользоватся systemd по причине того что он не везде есть и его нельзя поставить
Ну проблема разрозненной инфрастуктуры… В ней обычно не systemd и не какое то другое решение виноваты. Это обычная ситуация в российском IT, ну как проблема с дорогами в РФ.
Административно, мне кажется, что включать/выключать сервисы все же лучше силами сисадмина с рутом, который знает что делает, чем силами команд разработки. Они же все равно потом побегут к админу, но только что бы чинить.
т.е. если Ваша задача просто запускать демон от юзера — то все что написано выше в /lib/systemd/system/ только добавить опцию User= в секцию Service. Или я Вас не понял
Без явных багов и "красивый код" — понятия очень разные и обычно не пересекающиеся
Я там на 3 абзаца расписал, что обертку менять вообще не нужно. Плохая архитектура — если ее нужно постоянно менять…
Ну живет отдельный сервис у вас нас php4. Он же жить вам не мешает — пусть живет и дальше. Нужно будет в нем правки делать — и php обновим и говнокод перепишем. Работает — не трож. Тем более можно и не трогать. Трогают обычно от желания поучиться вместо того чтобы поработать.
Ну вот я привел пример почты — протокол 40 лет не меняется. Нормальные люди его сделали. Грамотные в архитектуре. SMTP. Потом появился ESMTP — но он не противоречит старому и целиком и полностью его поддерживает.
Это больше к вопросу выбора решений — не нужно выбирать сырое, что еще много раз поменяется.
А вот из каких тряпок и грязи собрали модуль отправки писем — не важно, главное что отправлял в соответствии с ТЗ. Если он верно написан — шаблонов писем в нем не будет. И менять там впринципе нечего — почта она вон 40 лет не меняется.
А композиция в терминах архитекутуры — это несколько расширенное понятие полиморфизма.
говнокода. Тогда архитектура помогает разрабатывать.По поводу масштабов — вопрос размера решения. Если оно маленькое — архитектура работает на уровне модулей. Если большое — на уровне сервисов.
Т.е. не нужно делать ее многоуровневой. Какие могут быть модули в сервисе? никаких — он одну фичу делает. одну функцию. Как может быть архитектура внутри модуля в монолите? тоже никакой.
Вложенные модули в модули и прочее — адское зло и в целом противоречит идеям композии, переиспользования. А в целом — еще и порождает массовые зависимости между модулями. Чего в хорошей архитектуре быть вообще не должно.
Сначала привыкает делать так у себя на десктопе, потом делает так на сервере. А потом этот сервер достается другому человеку. И мучайся потом с вашими make install, libc6 из сырцов и прочими попытками админить не по документации к ОС.
IDE — vim
Тестирование в браузерах — BrowserStack, виртуалки на сервере.
Ftp-клиент — mc/ftp
А пакет собрать? За make install надо наказывать.
P.S. потрогал, посмотрел, попользовал — отложил в ящик, через 1-2 года достану.
Да и умные люди делают по умному — один сервис — одна виртуалка. И пусть она хоть упадет.
А мониторить это совсем легко и просто. Есть отличная метрика — сколько новых pid появилось по сравнению с предыдушим состоянием и сколько пропало. Я эту метрику собираю со всех машин — для разных ролей машин конечно движуха разная, например на машинах с nginx пиды почти не меняются, а вот с php-fpm или postfix есть регулярная ротация. Главное корректно настроить Alert в мониторинге.
И это есть в systemd
Не очень понял в чем суть
И это может systemd
А это вообще может быть очень чревато и печально, особенно если SIGKILL, особенно если на высокой нагрузке.
Ну проблема разрозненной инфрастуктуры… В ней обычно не systemd и не какое то другое решение виноваты. Это обычная ситуация в российском IT, ну как проблема с дорогами в РФ.
Административно, мне кажется, что включать/выключать сервисы все же лучше силами сисадмина с рутом, который знает что делает, чем силами команд разработки. Они же все равно потом побегут к админу, но только что бы чинить.
User=<username to run as>т.е. Вам интересно запускать демон от имени пользователя или заменить nohup… &?
Так что, для Вас тема раскрыта ;-)