Комментарии 15
В Go тяжело строить абстракции.
Go способствует писать явно, а не скрывать объекты за абстракциями.
Не понял почему, в Go же есть интерфейсы.
вы какой именно функуионал оставляете на php и не планируете переписывать на го?
Мы используем Json-rpc и генерим обвязку client/serverЧто используете для транспорта и «service discovery»?
Когда у нас был Nomad, то был Consul как service discovery. Но после пары инцидентов с Nomad, мы спешно от него отказались и перешли полностью в K8s. В нём сейчас внутри ходим по dns, а для взаимодействия снаружи используется ingress-nginx.
Уже в следующем году собираемся рассматривать построения service-mesh и там же будем выбирать какой service discovery взять. Необходимость чувствуется уже сейчас.
ему не нужно думать о том, чтобы строить клиенты, слать мониторинги, пробрасывать трейсинги, и настраивать логирование
Судя по всему, кто-то это сделал для него заранее, да?
Интересно, а есть в мире хоть один пхпешник, который в наше время самостоятельно перешёл хотя бы частично на Go и остался доволен? Я вот не доволен, как раз потому что нужно строить клиенты, слать мониторинги, пробрасывать трейсинги, и настраивать логирование. Собственно на логировании уже затнкулся: требование в любых логах указывать requestId и как не кручу всё как-то криво выглядит. Или где-то на уровень доступа в базу пробрасывать чуть ли не полностью http-запрос, начиная с main. Или пробрасывать наверх ошибки, а наверху разгребать регулярками тип ошибки, причём это только для логов ошибок, для дебаг и прочего инфо не работает, то есть пробрасывать параметром requestId на самые низкие уровни… Ну или глобальные переменные какие-то.
Про трейсинг. Это ведь не что-то специфичное для Go, а скорее необходимость в мире распределённых систем.
P.S. Я тот phpшник, который перешёл на Go и остался доволен :)
Судя по всему ("до нас были первопроходцы — непосредственно Go-шная команда, которая подготовила инфраструктуру и инструментарий") вы не сами перешли, и что-то мне подсказывает, что на первых порах они ещё и код ревьювили и говорили что-то вроде "так делать не надо, надо делать так, и вообще вот в этой тулзе это уже реализовано как надо, бери и пользуйся"
Мы активно используем DDD и далеко не всегда вместе с OOP. Больше упор на стратегические паттерны. Другими словами, первое с чего мы начинаем это проектирование контрактов (контекстов) через спецификации. Это может быть и API сервиса и события. Каждый раз на ревью новой спецификации мы обсуждаем как это укладывается в уже существующую картину. В каких местах и какие контексты взаимодействуют. Вот этот контекст лучше разбить на два и в случае необходимости композировать. А вот эти два лучше объединить в один, т.к. есть транзакционная зависимость и разбивать на более мелкие только себе дороже.
В дальнейшем определяем какой профиль использования контекста. Вот здесь нам необходима строгая консистентность и синхронное взаимодействие по сети, скорее всего мы не будем гонять большой агрегат, а сделаем композицию из простых и последовательных. С возможностью компенсации изменений. А вот здесь для масштабирования мы выберем консистентность в конечном итоге и уйдём от синхронных запросов, передавая контекст сообщением через шину событий.
В итоге, это может быть и микросервис и модульный монолит. Главное, оставлять возможность гибко управлять изменениями и взаимодействовать через описанные контексты.
Го в Go! Как команда PHP взялась писать микросервисы