smilingcheater

Как понять микросервисы?

Прочитать соответствующую книгу (а лучше ещё парочку про DDD или хотя бы посмотреть этот доклад)

Затем ответить на несколько вопросов:
1. Почему вы решили, что микросервисы что-то вам дадут?
2. Есть ли у вас настоящие причины для микросервисной архитектуры? (А именно: зоопарк технологий с невозможностью написать 99% на одном языке; более тысячи разработчиков; сложность выкатки монолита в виде часов прогонов CI/CD — тестов, билда, деплоя, стопоров выкатки в виде кучи проблем из-за разработчиков; вы такие же большие как гугл, убер, амазон и т.п.). Или вам просто нравится модное слово "микросервисы"?

Не получится создать хорошую микросервисную архитектуру без умения создать хороший модульный монолит. В этом случае вы получите не только все проблемы плохого монолита: высокая связанность, каскадные падения, долгий CI/CD; но и все проблемы микросервисов: их надо оркестрировать (у вас же есть команда, которая будет поддерживать инфраструктуру?); каждому микросервису нужно своё CI/CD (и хорошее); сеть может (и будет) лагать и обрываться; длительность запросов увеличится на порядок(ки) (особенно если выбрать какой-нибудь JSON-RPC over HTTP); нужно предусмотреть failover strategy (например, идемпотентные ретраи. Вы же уже знаете про correlation id, саги и что делать, если прилетел network error на запрос в другой сервис "списать 10 баксов"?) и circuit breakers; трейсы и логи, которые не пришлось бы искать по сотням .log файлов от каждого сервиса; бизнес-логика расползётся по разным микросервисам и нарушит SRP (пофиг, что нарушит, важнее то, что это починить будет сильно сложнее). Список можно продолжать долго.

Использовать подходы Git flow или Github flow

Поддержу Sand : берём Devops Roadmap и подтягиваем скиллы сверху вниз. Если хочется продолжать работать дальше в сетевом администрировании (вакансии Network Engineer с требованием знания Ansible/Salt были и 7 лет назад, только не у нас), то должны научиться раскатывать конфиги из гита и мониторить всё описанное хозяйство со сбором логов.

лол. Написать video streaming платформу с нуля на вебсокетах. Без обид, но одно это предложение уже говорит о том, что вы не сможете этого сделать. Стриминг не делается на tcp никогда. Вообще мало кто сможет такое сделать, а уж в одного так и подавно. Есть простое правило: если стриминг видео является не основой вашего бизнеса (как, например, у твича, юдеми, и тп), а просто каким-то доп функционалом, ни в коем случае не пишите свой велосипед. Берите vimeo и не усложняйте себе жизнь в 1000 раз.

Все что вы задали, это не вопросы по гиту. Это вопросы по SDLC - и на эти вопросы можете ответить только вы.
Гит это просто инструмент версионирования, а не доставки контента.
Тем более, что даже неизвестно сайт у вас крутится на виртуалке или на хостинге, и в принципе там git поставить есть возможность или нет.

Да, гитом тоже можно синхронизировать изменения между разными енвайрнментами, но вот те вопросы которые вы задаете - вы сами должны придумать удобный пайплайн и выбрать инструменты (git, scp, rsync, какой-нить CI/CD инструмент или что угодно)

В чём вопрос? Нужно диагностировать, почему падает сервер.

Раз всё настолько плохо, что даже SSH отваливается - дело не в нгинксе и не в РНР.

Второй вариант это хорошая попытка, но недостаточно полно реализованная. Писать надо хотя бы так

(function() { 
    foreach([true] as $condition) {
        $condition = ($condition) ? true : false; 
        while ($condition) {
            switch (true) {
                case ($this->inComplete(($oldStatus), ($newStatus))):
                case ($this->outComplete(($oldStatus), ($newStatus))):
                    ($this->action());
                    ($this->save());
            }
            break;
        }
    }
})();

В общем, перед тем как задавать вопрос на тостере, надо сесть и хорошенько сначала самому подумать, каких бессмысленных операторов можно добавить в код, кроме switch.

Живой опыт и ощущения.

Год назад брал себе домой 3600 / 32gb ram / 500gb nvme. Работаю в Ubuntu. Бекенд разработчик. Иногда балуюсь фронтом в свободное время.

Считаю, что для задач веб-разработки 3600 за глаза. Ситуации, когда я бы упирался в процессор - очень редки и это были нишевые задачи. Чтобы веб-разработка загрузила современный процессор и уперлась в его производительность это нужно или что-то сделать не так или делать что-то нишевое.

На прошлых машинах в разработке упирался в память или быстродействие накопителя.

Отсюда мое личное мнение, что окончательный выбор нужно делать исходя из других задач. Будет много софта оптимизированного под интел - брать интел. Будут задачи на какой нибудь многопоток аля конвертацию видео - брать там где больше ядер. Если игры - вложить в видяхи. Если нет - то лучше вложиться в лучшую материнку, память, охлаждение, корпус, нежели сходить с ума от синтетических тестов.

Открывай каждый проект в новом окне.

console.log('*РА*')

console.log('**')

P.S: Прошу прощения телепаты сегодня не пришли, поэтому какой вопрос, такое и решение