LINUX.ORG.RU

Golang в крупных проектах

 , ,


1

7

Здравствуй, уважаемый форум!

Предыстория: Наша компания заказала web-проект. Он был написан на Tornado на Python 2. Проект является достаточно крупным и является бэкендом веб-портала, который включает в себя элементы взаимодействия с другими системами компании, различные мастера заказа и т.п. Всего база данных состоит из ~200 таблиц. Т.е. это проект с достаточно сложной бизнес-логикой.

Далее уже в нашей компании поставленный нам проект стал дорабатываться и постепенно переписываться с Python 2 на Python 3 и затем Python 3.5 (3.5 из-за лучшей поддержки асинхронной работы).

В последне время отдельные части системы стали переписываться на Golang.

Проблема: Начальство поставило задачу переписать всю систему на Golang (Но, разумеется, не 100%, где-то Python может остаться). Причина: борьба с растущей нагрузкой. При этом сейчас следует определиться с основными архитектурными вопросами при использовании Golang-а.

Проблема точнее: Смущает, что сложно найти подобные проекты реализованные на Golang. Конечно, все слышали о различных инструментах типа Docker, гугловский Vitess, сервис загрузки для гугла. Но при этом все они являются отдельными инструментами, реализованными на Golang, а не целыми веб-проектами со сложной бизнес-логикой. Основное отличие нашего проекта от тех, в которых сейчас используется Golang я вижу в том, что нам нужно:

  • Достаточно продвинутое ООП для реализации сложной логики
  • Хорошие инструменты для работы с базой данных (ORM)
  • Организовать проект, состоящий из множества файлов так, чтобы максимально легко вносить изменения

Что смущает в Golang:

  • Нету примеров архитектуры сложных веб-проектов (под сложностью я бы понимал работу со сложной структурой базы данных)
  • Слабая поддержка ООП в языке
  • Отсутствие устоявшихся технологий

Вопросы:

  • Есть ли у кого-либо опыть использования Golang в столь сложных проектах?
  • Может ли кто-нибудь подсказать примеры столь сложных проектов с открытым исходным кодом?
  • Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?
  • Может ли кто-то рассказать, как решить те проблемы, которые были мной выше описаны в Golang?

Есть ли у кого-либо опыть использования Golang в столь сложных проектах?

Бекенд, 25К строк кода, 25 таблиц (число мало, поскольку мы на микросервисах и данные разбросаны). Сойдет?

Может ли кто-нибудь подсказать примеры столь сложных проектов с открытым исходным кодом?

Не видел

Есть ли у кого-нибудь веские аргументы не делать этот переход на Golang?

Есть проблемы, но в целом с ними жить можно и они устраивают. Питон по моему мнению хуже.

Может ли кто-то рассказать, как решить те проблемы, которые были мной выше описаны в Golang?

Ну, самая главная ошибка, которая возникала — хотелось больше «сокрытия реализации», поэтому сначала пытались разбивать все на кучу пакетов. Но, как известно, в go нельзя циклически импортировать пакеты и идея провалилась. Если посмотреть на даже больше опенсорц-пакеты — там тоже практически все находится буквально в нескольких пакетах. Это не неудобно, просто другой способ организации.

Структура проекта выглядит как-то так: http://storage5.static.itmages.ru/i/16/0921/h_1474438233_4783744_64393b43f3.png

Во-вторых, ORM. Используем gorm (https://github.com/jinzhu/gorm), и у него есть добрая куча проблем. В целом жить можно, но если упор на производительность, то я бы взял https://github.com/go-pg/pg (вроде, оно, точно не помню) и реализовать плюшки gorm поверх. Но с проблемами go-pg/pg я не знаком, поэтому точно сказать не могу.

Достаточно продвинутое ООП для реализации сложной логики

Продвинутое ООП != сложая логика. Придется использовать несколько другие паттерны, я полагаю. Сам не любитель терминального ООП головного мозга, поэтому с этим проблем не было.

Еще про микросервисы: из-за них по-полной сейчас огребаем с транзакциями (и из-за gorm тоже), но в целом жить можно. Деплой удобен, сервисы маленькие, поддерживаемые и независимые, правда, ядро у нас толстовато. В качестве шины используем grpc и nats, первый — зрел и прекрасен.

На качество гитхаболиб я бы не полагался — в целом они ужасно, ужасно жирные (за немногими хорошими исключениями), и чаше лучше реализовать что-то самостоятельно.

Возможность рефлексии в языке совращает, но лучше сразу копипастить/использовать кодогенерацию, поскольку это место придется переписывать. Но в целом с использованием interface{} проблем нет, я про более продвинутые случаи. Относится и к дефолтным json и protobuf-энкодерам — нужно заменять на версии с кодогенерацией для адекватной производительности (например, https://github.com/pquerna/ffjson).

Задавайте свои вопросы.

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 2)

+ еще дополнения.

Для сборки используется gb и он ужасен. Из-за этого всё перенесли в один большой репозиторий с одним gb-проектом.

derlafff ★★★★★ ()

В GO нету ООП, вообще нету.. Технологии ? Какие? Все, что там есть вполне устоялось. ОРМ есть, тот же gorm, однако для меня понятия сложный, нагруженный противоречат слову ORM.

Что касается структуры проектов, тут все просто, смотри как пример тот же revel и юзай модули для его расширения. От того же Django или Flask слабо отличается.

Valor ()

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

anonymous ()

Слабая поддержка ООП в языке

Я бы не сказал, что она слабая. Она нетрадиционная. И перетачивать мозги с привычного ООП может оказаться проблематичным.

uuwaan ★★ ()
Ответ на: комментарий от Valor

Однако для меня понятия сложный, нагруженный противоречат слову ORM.

Суть в том, что нужно писать код, а не возиться с базовыми вещами, которые в ORM уже есть. Поди напиши ОС на языке ассемблера — можно, но не нужно. Так же с ORM.

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

4.2

Ты бы свой пост выше перечитал, очень похоже на мышонка, жрущего кактус.

Гошники все такие. Вместо того чтобы решать настоящую проблему: «борьба с растущей нагрузкой», они считают ее «причиной» и быренько повязывают красные галстуки и бросают зигу дедушке. Срамота.

A1 ()
Ответ на: комментарий от derlafff

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

Вся суть Go.

Kilte ★★★★★ ()
Последнее исправление: Kilte (всего исправлений: 1)
Ответ на: комментарий от A1

«борьба с растущей нагрузкой», они считают ее «причиной» и быренько повязывают красные галстуки и бросают зигу дедушке. Срамота.

Где ты увидел это, клоун?

derlafff ★★★★★ ()
Ответ на: комментарий от A1

В ОП посте. Ты даже не придал этому значения, лол. Гошник, такой гошник.

ОП в посте решает проблему «python нормально не может в многопоточность». Сколько не оптимизируй, ничего дельного в этом плане на пистоне не получишь.

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 1)

Уважаемый ТС, если вы надеетесь, что на го будут писать инженеры, которые способны решать проблемы, то сильно ошибаетесь. Сейчас в наличии только оголтелая пионэрия.

A1 ()
Ответ на: комментарий от derlafff

Фишка orm, это абстракция над спецификой используемой бд, оптимизация суть использования этой специфики. Так что или «нужно писать код» или быстро.

Valor ()
Ответ на: комментарий от derlafff

Спасибо большое за ваш ответ!

Раз Вы уже так много написали, не могли бы Вы еще ответить, решается ли у вас как-то проблема с err != nil? Стали вы использовать в основном panic-и все-таки для обработки исключений или везде err != nil?

RedRus ()
Ответ на: комментарий от derlafff

Бекенд, 25К строк кода

Для Го это очень маленький проект. Большая часть — боллерплейт и примитивные конструкции.

anonymous ()
Ответ на: комментарий от derlafff

ОП в посте решает проблему «python нормально не может в многопоточность»

Ни один крупный проект не упирается в CPU по всей кодовой базе. А упирается в кривые руки. В среднем по больнице, руки кривее у молодежи, которая хайпит за го.

A1 ()
Ответ на: комментарий от Valor

Фишка orm, это абстракция над спецификой используемой бд, оптимизация суть использования этой специфики. Так что или «нужно писать код» или быстро.

Не обязательно. Выше я показывал привязанный к постгресу ORM. Суть в объектной модели, т.е. работа идет с объектами и действиями над ними. ORM вполне может использовать спицифику определенной БД.

derlafff ★★★★★ ()
Ответ на: комментарий от anonymous

Ну, да. Писался полутора программистами за несколько месяцев.

Большая часть — боллерплейт и примитивные конструкции.

Всякий сгенерированный protobuf и затычки старался выкидывать.

derlafff ★★★★★ ()
Ответ на: комментарий от RedRus

не могли бы Вы еще ответить, решается ли у вас как-то проблема с err != nil?

Это не проблема. Нужно привыкнуть к этом, оно даёт классную возможность писать ужасно надежный код

Стали вы использовать в основном panic-и

Нет, не нужно и не рекомендуется. Паники не для этого.

Везде err != nil.

derlafff ★★★★★ ()
Ответ на: комментарий от A1

Держи пятюню, брат, тоже наелся говна?

Ну, мой опыт с го довольно позитивен, потому что пишем на нём малюсенькие демоночки типа 'взять из очереди сообщение и отправить в чьё-то апи, только делать это с 4к рпс'.

Для чего-то посложнее страшно юзать

anonymous ()
Ответ на: комментарий от KRoN73

Обратных примеров, когда уходили с Golang, пока, вроде, не встречал

А они есть. Обычно на раст.

https://medium.com/@robertgrosse/my-experience-rewriting-enjarify-in-rust-723...

Это конечно не готовый проект, но отзывы на HN и reddit не в пользу Go.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от derlafff

ядро у нас толстовато

Не могли бы Вы тут сказать подробнее? Что у вас является «ядром» и почему оно «толстовато»?

RedRus ()
Ответ на: комментарий от RazrFalcon

Вроде, случаи в основном связаны с проблемой поставки зависимостей. Для десктопного софта мало подходит — большой размер бинарей со статической линковкой, раскиданные по гитхабам либы, которые и пакетить отдельно сложно, и вендорить не хочется.

derlafff ★★★★★ ()
Ответ на: комментарий от RedRus

Микросервисы. Ядро — сервис, в котором находятся основные модели и админка. Собственно, из-за админки (http://www.qorkit.com) и толстовато: она прибита гвоздями к gorm и пустить это по RPC сложно.

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

Ааа... А какие там проблемы? Он же в статику собирается.

На rust таких проблемы нет. Cargo сам все зависимости скачает и соберёт в статику. Одна строчка и всё готово.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Ааа... А какие там проблемы? Он же в статику собирается.

В сборке как раз.

Cargo сам все зависимости скачает и соберёт в статику. Одна строчка и всё готово.

Да тут так же. Но мейнтейнеры пытаются каждую из сотни либ опакетить отдельно и получают dll hell, lol.

По крайней мере, видел такие жалкие попытки.

derlafff ★★★★★ ()
Последнее исправление: derlafff (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

А они есть.

Что-то я там не заметил ссылок на масштаб проекта. ИМХО, что-то персонального уровня... Ну и сам факт выбора Rust в качестве замены... :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Начнём с того, что масштабных проектов на Go, не больше чем на Rust.

Ну и я говорил не о самой статье, а об отзывах. Хороших отзывов о Go там мало.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от derlafff

В сборке как раз.

В Go не бум-бум. Можно поподробнее?

мейнтейнеры

Мейнтейнеры чего? Дистров? Так это их проблемы.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от derlafff

Лорчую, всё так. Равзе, что у нас нету ORM и прост используем маппер на структуры.

anonymous ()
Ответ на: комментарий от anonymous

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

плюсану анонимуса. медленный кусок переписать на го - ок, но не весь проект.

kelyar ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Начнём с того, что масштабных проектов на Go, не больше чем на Rust.

У Rust есть что-то масштаба хотя бы Docker? :) На Rust сидят инфраструктуры таких монстров, как DigitalOcean?

Ну и я говорил не о самой статье, а об отзывах. Хороших отзывов о Go там мало.

Пока это мнение отдельных пользователей — это субъективщина чистой воды. Таких негативных отзывов можно найти сколько угодно по абсолютно любому языку :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от derlafff

О других неуспешных попытках писать утилиты на go. Довольно неудобно пакетить и распространять, короче.

В последнее время всё больше утилит именно на Golang встречается. Он всё активнее встречается там, где раньше работал Python.

KRoN73 ★★★★★ ()
Ответ на: комментарий от derlafff

В сборке как раз.

А чего там с ней ? Мне пока что только это и подкупает в Go, что я могу без заморочек собирать в один бинарник. В отличие от того же питона, где без pip-а сторонние библиотеки ставить целая проблема. (Оче полезно когда один из рабочих компов (основной) без интернета, а на серваках даже не везде питон установлен)

Ещё доставила работа с потоками. Давно пора научить языки создавать потоки по простенькому ключевому слову, а не городить системы пулов, какие-то там объекты с определенными методами и тд. Но вот в плане скорости я пока что не заметил прироста. Я конечно же написал пару hello world-ов, но вот запиханые в горутины GET-реквесты выполнялись в 4 раза дольше чем, аналогичные в python 3.5 + aiohttp

ЗЫ допускаю, что я просто сделал что-то не так, но задачка была максимально упрощена, не представляю где там можно было накосячить

Dred ★★★★★ ()
Ответ на: комментарий от Dred

не городить системы пулов

с рутинами медленней

вместо создания десятка рутин-воркеров сделал по рутине на каждый запрос?

derlafff ★★★★★ ()

Если у вас там

борьба с растущей нагрузкой

, то

переписать всю систему на

— просто акт идиотизма.

А надо было провести анализ и внести соответствующие изменения, как в сам проект, так и в стратегию его поддержки и развития.

Всего база данных состоит из ~200 таблиц. Т.е. это проект с достаточно сложной бизнес-логикой

Я вас огорчу: двести таблиц это детсадовская херня. Сложная бизнеслогика это от десяти тысяч.

Бизнес совет: проведите наконец исследование (и не просто исследование кода, а исследование перспектив, в том числе и бизнесовых) и найдите узкое место. И потом уже думайте что с ним делать. А производительности питона как минимум достаточно чтобы выгодней было просто пару лезвий докупить, чем переписывать хоть на ассемблере, даже если у вас там контора уровня международной фондовой биржи.

Goury ★★★★★ ()
Ответ на: комментарий от derlafff

Не спорю, но в данном случае имеет место процент недостатков.

Kilte ★★★★★ ()
Ответ на: комментарий от Kilte

Dropbox (по крайней мере, на момент нагугленной записи) в основном на go сейчас, только некоторые сервисы на rust'е.

derlafff ★★★★★ ()
Ответ на: комментарий от derlafff

ну само собой, Hello world же на реддите мне по этому поводу сказали только не замерять скорость time (будто я своими глазами не вижу разницу, хех)

Dred ★★★★★ ()

1) для больших и сложных проектов go не берут. по крайней мере, не в моей конторе. небольшие тулзы/сервисы, где куцость го не столь страшна

2) работающие проекты именно из-за нагрузки переписывают редко, просто добавляют сервер и балансируют нагрузку

3) в случае второго питона можно было бы поэксперементировать с pypy и pyston. pypy есть и для третьего питона, но работает оно медленнее, чем для второго

Ford_Focus ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.