Pull to refresh
3
0
Николай Рыбин @koluchiy01

DEV

Send message
Все верно, завершать работу, должна уметь горутина.
На этот случай есть контекст, через который можно потушить дочерние горутины. Родительская горутина, которая всех запустила узнает об ошибке и через контекст тушит остальных
«Конечно, нейросеть качество не улучшит» вот тут конечно не конечно )
«Как связать Monolog и ELK» очень странная статья. Рэбиты, гельфы, зачем так сложно? Монолог пишет json, filebeat отправляет данные в logstash, где очень простой конфиг, logstash в elastic.
А вообще идеология спанов может быть использована в простом логировании, но мы пока не придумали как это красиво сделать (
Промежуточным решением для связывания логов разных сервисов может быть пробрасывание в запросах некоторого идентификатора и добавление его во все логи, но все равно кибана не позволяет красиво и быстро понять кто кого куда и почему так долго.
На жукери тоже реалтайм бывает)
А вот и руби в зоопарк из пых, голангов и прочих ларавелей )
Я тут не очень компетентен, но кейс очень странный. Машины мы продаем дилерам.
Могли, но что-нибудь из бизнесовых фич тогда не сделали бы. Вопрос приоритетов, если документация до сих пор генерится через битрикс, значит она не настолько болит, чтобы ее переписать, отложив другие фичи. Да и «несколько лет» слишком сильное высказывание, компании всего 3 года.
В основном каждый php сервис это 2 контейнера: контейнер nginx + контейнер fpm. Безусловно можно не ставить отдельный nginx над каждым php. Но отдельный nginx позволяет всю логику и настройки сервиса (тут могут быть и настройки nginx например) держать обособлено от остальных сервисов, а при масштабировании появляется выбор: масштабировать пару nginx+fpm или же масштабировать только fpm.
Это убытки карпрайса, поэтому грамотный первичный осмотр — очень важная задача.
Битрикс случился исторически, мелкие сервисы на нем писать мягко говоря не удобно, поэтому появился ларавель. Переписать весь битрикс на ларавель быстро и без потери бизнес производительности не представляется возможным. Переход на сервисы позволяет удобно отдельную функциональность переводить на более подходящий инструмент, который в свою очередь ускоряет процесс развития этой функциональности (тут похоже я очевидную вещь написал). Итоговый ответ на вопрос «зачем?», это чтобы быстрее бежать и меньше спотыкаться.
Апи в Ларавеле, Ларавель в докере, Докер в кластере, если коротко) Сервисы между собой общаются по внутреннему json API. Для авторизации в api используются jwt токены, которые генерятся и проверяются через отдельный сервис, написанный на Go и имеющий огромный запас по производительности. По развертыванию: из тега в гите строится контейнер, который едет в реджистри, из реджистри контейнер после тестирования едет в прод ансиблом (обновляем тег контейнера). По нагрузке бенчмарки не найду, в целом большинство микросервисов сильно не нагружены, а общая производительность кластера увеличивается за счет добавления серверов.
У Вас вызывает отторжение использование больше одной технологии на проект? Или что-то конкретное?
На главной: хотелось бы иметь возможность выбрать слайд во время прокрутки (поменять цель).
«гуглоненавистники» — а вот и причина :)
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity