Комментарии 15
В Go тяжело строить абстракции.

Go способствует писать явно, а не скрывать объекты за абстракциями.

Не понял почему, в Go же есть интерфейсы.
Мне вообще сложно представить как так писать код без абстракций :) Довольно странное заявление автора.
Речь про количество уровней абстракции, которые используются. Мысль была в том, что далеко не все шаблоны проектирования, используемые в PHP, у нас получилось применить в Go. Что и логично. Многое пришлось переосмыслить. В этом и был наш сдвиг парадигмы.
Вы, наверное, имеете ввиду, что в Go нет наследования и это мешает применять множество паттернов, которые основанны как раз на наследовании?
Тут у Go имхо сдвиг как раз к более гибкому подходу, основанному на композиции вместо наследования.
несколько людей переходящих на го говорили, что на го очень тяжело поддерживать всякие бизнес процеесы. допустим какую-нить систему скидок в зависимости от разных товаров или же шедулллер рассылок писем…

вы какой именно функуионал оставляете на php и не планируете переписывать на го?
Да, во многих местах у нас остаётся php и python. Как раз там, где есть развесистая бизнес-логика и её сложное конфигурирование. Чаще всего. Но точно могу сказать (на примере сервиса из статьи) что и на Go можно описать сложную логику, которую потом без боли можно поддерживать и развивать.
Мы используем Json-rpc и генерим обвязку client/server
Что используете для транспорта и «service discovery»?
Json-rpc поверх http. Текстовый протокол для общения между микросервисами это наше осознанное решение. Пока необходимость перехода на бинарный не стоит.

Когда у нас был 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 сервиса и события. Каждый раз на ревью новой спецификации мы обсуждаем как это укладывается в уже существующую картину. В каких местах и какие контексты взаимодействуют. Вот этот контекст лучше разбить на два и в случае необходимости композировать. А вот эти два лучше объединить в один, т.к. есть транзакционная зависимость и разбивать на более мелкие только себе дороже.

В дальнейшем определяем какой профиль использования контекста. Вот здесь нам необходима строгая консистентность и синхронное взаимодействие по сети, скорее всего мы не будем гонять большой агрегат, а сделаем композицию из простых и последовательных. С возможностью компенсации изменений. А вот здесь для масштабирования мы выберем консистентность в конечном итоге и уйдём от синхронных запросов, передавая контекст сообщением через шину событий.

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

А можете порекомендовать почитать что-то о технических практиках DDD в Go? Может мои проблемы из-за того, что я упорно пытаюсь натянуть практики характерные для Java/Hibernate или PHP/Doctrine на Go/Gorm там где этому упорно мешает Go?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

5 апреля 2011

Местоположение

Россия

Численность

5 001–10 000 человек

Дата регистрации

20 сентября 2018

Блог на Хабре