• Суровая оптимизация работы с market data для криптобиржи
    0
    > Прости, но создается впечатление, что ты «сливаешься»… Что «под капотом» это не важно

    Какой-то детский сад. Да, я такого рода «технические дискуссии» вести не умею. Не важно — вот и славно, мне больше спрашивать тут нечего.
  • Суровая оптимизация работы с market data для криптобиржи
    0
    нет, мы решительно не понимаем друг друга. Как можно отметать бенчмарки и «оценивать субьективно» в чем-то, где есть требования по производительности и чем-то больше чем хобби проект на выходной — это никак не поддается моему пониманию.

    Как это «просто append. Я те слово даю» на фоне того, что уже вроде выяснили, что вокруг этого навороченно скриптов с кронами и прочим — тоже. Видимо мы говорим совсем об очень разном видении организации систем. В моем понимании все, что я услышал это любопытный способ доступа к данным, обещающий скорость и простоту. Однако по поводу скорости никаких данных (кроме «пойди потыкай в страничку»), по поводу простоты — я пытался понять есть ли она, и не убедился в этом.
  • Суровая оптимизация работы с market data для криптобиржи
    0
    Ну так ты просто открой две биржи и сравни отзывчивость интерфейса.

    я понятия не имею какие проблемы у конкурентов, какая у них отзывчивость и какой отзывчивости ожидают кленты. Кроме того, я не знаю что за конкуренты. Если тут приводится решения которое должно быть быстрым, я бы ожидал адекватных замеров скорости и собственно самих требований по времени отклика, скорости загрузки и прочее в этом роде. Посылать меня тыкать в конкурентов это неконструктивное предложение.


    Эта модель уже год работает на нашей бирже. Никаких требований на горизонте еще 1 год на изменение нет.

    это хорошо что нет. если есть такая уверенность в стабильности требований (в моей области такое практически не встречается) то это приятно.


    Очевидным является то, что мы не можем влиять на кэш браузера.

    эээ… что? С каких это пор? Мы очень даже можем влиять на то, что в этот кеш попадет и как оно там будет себя вести.


    Можешь привести требования к развертыванию такой инфраструктуры? К компетенции персонала? Давай сравним.

    Я выше уже привел пример. Какие еще требования нужны? И как сравнивать относительно стандартную инфраструктуру с набором самописных инфраструктурных кусков типа "будем просто по крону запускать на ноде скрипт ...". Мне трудно что-то пояснить в таком ключе если тебе кажется что это просто и вообще вся система это "просто append в файл очередной свечи". Даже из твоих не очень подробных пояснений видно, что нет — это не просто append, но ты почему-то отделяешь ту часть, что зовешь девопс в нечто, что к системе не относится.


    Так можно и балансер уже к backend отнести. Что уж мелочиться то…

    Можно, особенно если он с разным партизанством внутри. Вообще бекенды разными бывают, например вся твоя подготовкa свечек это вполне себе backend processor. Вместо некорретного "избавится от бэкенда" я бы сказал, что решение пыталось избавится от реализации своего rest/rpc/whatever части бэкенда.

  • Суровая оптимизация работы с market data для криптобиржи
    0
    Посмотри плз на «наших конкурентов».

    Как же я на них посмотрю, если даже на описанное тобой решение посмотреть невозможно т.к. "Код, естественно, не будет опубликован."


    Это будущее меняется по 40 раз на дню.

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


    В варианте с content-range, второй запрос не будет выполняться к серверу. Этот кусок браузер возьмет из своего кэша. Не профит ли это?

    Возможно профит, а возможно и нет, все зависит от того по каким параметрам мы оптимизируем решение и для чего это делаем. Если цель это экономить размер кеша на серверной стороне, то вполне себе профит. Если на клиенте — то нет. Другой вопрос а надо ли его вообще эконномить в этом конкретном случае? Т.е. что именно было/предполагалось не так при попытке использования традиционных подходов к кешированию? И насколько это важно в данном случае.


    CDN это, Content Delivery Net, ничего нового.
    Ох, опять. Мои вопросы ничего общего с CDN не имееют. Выброси на минуту CDN из этой картины, логику работы CDN перед твоими нодами никак не меняет.

    Но не кажется ли тебе, что это не относится вообще к рассматриваемой сути технологии? Это лишь классическая проблема синхронизации файловой системы которой уже 100 лет. не уж-то есть сомнения в том, что подобные задачи успешно решаются и нужно тут ее вообще рассматривать?

    Конечно есть сомнения и конечно относится к сути технологии. То что "запрос возьмет готовые данные по смещению" переводит ту часть, что эти данные готовит и распределяет по нодам краеугольным камнем предложенной техники. Ну а что касается "классическая проблема синхронизации файловой системы" то эта проблема решается не сама, но десятком способов. Твой вариант с симлинками вовсе не единственный, да и вообще это не такая простая задача если ее решать аккуратно.


    В случае если хартбит одной из нод «протух», что контролируется балансером ...

    Все, что LB может понять в контектсе "протух" это недоступность определенного файла на nginx или timeout запроса, т.к. кроме статики тут ничего нет. Т.е. все что можно отловить это ситуацию полной потери ноды. При традиционном подходе вместо всей этой "включается скрипт, который переключает на прод сервере симлинк на «живую» папку", нода смогла бы отдать статус "временно недоступен" сама исходя из проверок целостности и актуальности данных, состояния ноды и прочее что недоступно из голого nginx. Ну и кроме того, вся эта техника с включением скриптов она несомненно часть того, что я бы назвал backend и который тут никуда не делся. Он просто стал… нетрадиционным.


    Единая точка отказа в сервисах? Ну неужели есть шанс, что криптобиржа создает сервисы без дублирования?

    Да откуда мне знать, как именно в вашей компании пишут системы. Это был первый ответ из всех комментов, который хоть что-то сказал по этому поводу.


    Как я уже сказал, я ничего не имею против упрощния и движения в строну "все отдадим файлами или их частями". Я даже это горячо приветствую и сам подобный подход применяю, где он мне кажется адекватным. Например, в построении сайтов где можно обойтись исключительно статикой. Скажу больше — мы даже как-то в подкасте обсуждали возможность пре-генерации комментариев (в статику на s3) в моей системе remark42 и я вокруг этой идеи эксперементировал пока не убедился, что потеря гибкости не оправдывает подобного изменения.


    Возращаясь к сути — если бы моя цель в подобном проекте была бы в категорическом отказе от своего бэкенда, т.е. то, что сейчас называют serverless, то я бы копал в сторону хранения данных вне ноды (s3, dynamo, aurora, elastic cache ...) и элементарной лямбды с "контроллером". Перед этим всем был бы ALB и, при необходимости географической близости к клиенту, CDN. При этом я бы хранил только один набор свечек с минимальной дискретностью и строил бы свечки другого размера на лету (или отдавал бы из кеша/редиса, если они уже там). Скорее всего я бы не завязывался на такой суровый бинарный формат и отдавал чем-то более гибким. При том, что подобная инфраструктура кажется более сложной с одной стороны, она позволяет избежать большую часть того, что сейчас приходится делать в batch режиме и не городить свои скрипты для обеспечения адекватной надежности и, в сухом остатке, вполне может оказаться даже проще чем предложенная техника надежного построения и отдачи свечей.

  • Суровая оптимизация работы с market data для криптобиржи
    0
    Как ты, возможно, заметил, я не упоминал свою особую компетенность и задавал, как мне кажется, вполне резонные технические вопросы исходя из описанного решения и его заявленных целей, которые может задать любой читатель этой статьи, вне особого опыта с конкретной бизнесс областью. Я вполне ценю желание сделать проще и приветствую инициативу не вводить лишних сущностей сверх необходимого, однако в описанном случае мне это простота видится кажущейся, перекладывающей сложость «на потом» и игнорирующей проблемы, которыми надо заниматься если речь идет о продашен системе, которая больше чем POC, MVP или демо.

    В этом разрезе вопросы о том, что может пойти не так (попроченные файлы, упавший процесс подготовки, потеря сервера подготовки данных, потенциальная синхронизация и/или share диски, варианты с необходимость пере-аграгации свечей ...) — это все не из желания написать «грязный комментарий» (что бы оно для автора не означало) но от вполне резонных сомнений в качестве этого решения. А ответы «это не случится… маловероятно… что может пойти не так ...» мне видятся плохими и неприемлимыми в любом серьезном проекте.

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

    Я не просто так задавал вопросы о том, что это решение оптимизирует и какую проблему оно решает, т.к. это корень в понимании того, насколько принятые trade-offs адекватны, а не попытка поймать собеседника на противоречиях.

    Ну и вообще, я не понимаю при чем тут моя личность и профили. Тут, в этой статье, речь шла о техническом решеннии и, как мне казалось, обуждать стоило именно это решение а не личную историю участников дискуссии. Попытка послать несогласных с решением… «погуглить что таке CDN» и прочие «учить современные WEB технологии» мне видится негодным способом ведения технических дискуссий.
  • Суровая оптимизация работы с market data для криптобиржи
    0
    сайт я вижу, но вопрос про код. Очевидно, не про тот код, что со стороны клиента, но тот код о котором мы говорили, т.е. подготовки данных. Иначе я просто не понимаю что именно я могу увидеть и/или проверить.
  • Суровая оптимизация работы с market data для криптобиржи
    0
    пытаюсь найти ссылку на код и что-то не нахожу в тесте.
  • Суровая оптимизация работы с market data для криптобиржи
    +5
    Если собеседник (я) не согласен с предложенным решением и/или пытается понять, как и насколько это решение адкватно и, самое главное, что именно оно пытается оптимизировать — это вовсе не значит что собеседник не в теме и у него «просто нет достаточного опыта». Это, например, может означать что решение ему кажется неадкеватным задаче, или что решение описано таким образом, когда понять его трудно.

    Посылать меня изучать «что такое CDN» в надежде, что это добавить ясности как ваш внутренний процесс доставки через rsync, который «решает ее легко и непринужденно» вместо ответа на вполне резонные технические вопросы тоже не добавляет уверенности и, даже, вызывает определенные опасения.
  • Суровая оптимизация работы с market data для криптобиржи
    0
    > При всем уважении, комментировать нет смысла. Если вы backend и nginx ставите на один уровень.

    эээ… а что тут не так? оба варианта требуют управления этими процессами. Никакой мистической сложности в таком бекенде (в его разработке) не будет и основное, чем надо будет заниматься в операционном плане (логи, мониторинг, метрики, дистибуция ...) будет отличаться мало чем. Вот если из этого варианта вообще исключить свой server side и обойтить без nginx, то тогда это было бы разного уровня.
  • Суровая оптимизация работы с market data для криптобиржи
    +2
    т.е. это не про оптимизацию вовсе, но про желание избежать написание backend сервера. Во всяком случае такое мое понимание из текста и ответов, т.к. никаких намеков на что именно тут оптимизировалось еще, я не нашел.

    А из чего следует, что «полностью решили вопрос высокой нагрузки при обращении к маркет-дата»? Что такое, в этом контексте, «высокая нагрузка» и как это решение масштабируется горизонтально? Как, в такой схеме, достигается надежность и отсутствие единой точки отказа? Куда кладутся все это файлы вообще, если не на локальную FS? В тексте упоминается «классическая проблема синхронизации файловой системы. Команда DevOps решает ее легко и непринужденно. Например используя rsync.», т.е. видимо таки локальная FS. Однако сказать, что задача «решается лего» это сильное упрощение, ну а при чем тут devops я вообще не понял.

    На мой взгляд, это решние непонятной мне проблемы «как приготовить и распределить данные так, чтоб от бэкенда остался только nginx». Оно, как мне кажется, неопраданно усложняет процесс подготовки данных, прибивает реализацию к nginx гвоздями и критично к любым проблемам на этапе этой подготовки, типа rsync не смог доставить данных, процесс подготовки файлов на мастере завис/упал, да и вообще этот мастер, что файлы строит — это единая точка отказа. Работа с двумя/несколькими мастерами требует каких-то дополнительных решений. Попытки решить все эти проблемы (если они для вас являются проблемами) усложнят систему еще более, возможно до такого уровня, что уже станет понятно — с традиционным бэкендом было бы проще. Ну, например, как этот кластер заставить выбрасывать серверы, на которые не смогли доставить свежие файлы и/или на которых оказались поврежденные файлы? Видимо для этого нужны еще какие контрольные файлы чтоб их использовать для проверок здоровья. И так далее…
  • Суровая оптимизация работы с market data для криптобиржи
    0
    > и решается она через аналитические кубы

    Она решается разными способами. Однако, ее решение, в общем случае, плохо совместимо с предложенной схемой хранения и доступа. Я вполне могу представть случай, когда свечи хранятся за долгий период в какой-то оптимизированной форме, а данные для аналитики хранятся другим образом (за меньший период) и доступаются через другой бэкенд. У меня все примерно так и делается, однако идея хранить десятки тысяч candle файлов за каждый день (количество инструментов * на количество видов свечей) не вызывает оптимизма в мире, где торгуются множественные сущности. Кроме того, становится непонятным главный вопрос — а зачем это было надо? Ответ про меньше размер сам по себе недостаточен (можно не менее эффективно хранить в нормальном сторе) остается только часть «не будет бэкенда», что тоже лукаво, т.к. вместо разработки своего сервиса по отдаче будет настройка nginx на такую отдачу, т.е. nginx будет вполне себе бэкендом который где-то бежит и кем-то мониторится/контролирруется.

    Тут выше спрашивали про бечмарки, которые могли бы хоть намекнуть какую проблему это решение пыталось покрыть. Я с трудом себе представляю суровые трбебования для забора даже минутных свечек, т.е. их просто надо показать так, чтоб было достаточно быстро на стороне UI. С этой задачей справится что угодно, практический любой стор сможет их вернуть быстро хоть в виде бинарных данных, хоть в виде json/proto/bson/msgpack/…
  • Суровая оптимизация работы с market data для криптобиржи
    +1
    Это, видимо какой-то очень узкий случай когда все, что волнует это просто (но быстро) достать свечи за период времени. Тут, конечно можно и файлов нагенирить и доставать их через nginx, если так уж хочется избежать написания своего бекенда. Однако, во всех реальных случаях работы с market data что я видел/участвовал, подобный уровень сервиса очень быстро перестает быть достаточным и любое новое требование плохо укладывается в описанную схему.

    Например, может возникнуть желания перегенрации свечек «на лету» по вполне банальным причинам — не отдавать клиентру слишком много данных. Или, например, поддерживать (для отображения не клиенте) несколько типов интервалов. Такие реагргегации, если их ограничить, можно тоже генерить файликами, однако количество этих видов будет нарастать. Ну а в момент, когда понадобится доставать эти свечи каким-то нетривиальным образом для анализа, наример «взять 10 минутный интервал вокруг daily high price для определенного инструмента», или «вернуть свечи за интервал но отфильтровать по определеному минимальниому vwap» такая схема просто не будет работать.

    Воможно, все эти дополнительные возможности и не нужны для работы с крипто-биржами и все что надо это быстро отдавать свечки. Для настощих бирж я видел несколько решений где разработчики пытались оптимизировать хранение market data в наборе своих велосипедных файлов, но все эти решения со временем превращались в свой собственный типа-nosql с индексами, кэшами, распределенностью и прочим, а начальное желания «поменьше бэкенда, сделаем просто на коленке» скоро забывалось и порождало трудно-понимаемых самописных монстров.
  • Go 1.11 зарелизился — WebAssembly и Нативные модули
    +4
    > Начат процесс ухода от Вендоринга (Vendoring).

    В vgo наоборот добавили поддержку vendor не смотря на то, что изначально была идея использовать кэш/прокси. По настоятельным и вполне резонным замечаниям общества эту поддержку ввели. Я не видел намеков на то, что это временно и «в будущем разработчики Go хотят уйти от этого».
  • Тёмные паттерны Amazon
    0
    Я часто оставляю отзывы на местном (американском) амазоне. Некоторые из них и на 1-2 звезды и за все время был один случай, когда не приняли. Но это, похоже было связано не с review, а с чем-то другим, т.к. отказ пришел прямо в момент нажатия кнопки «submnit».

    Все мои review никогда не пропадали. После того, как я поставил 1 звезду firetv 4k и описал какой это отстой, из амазона позвонили и пытались выяснить, что не так с моим устройством и как помочь. Предложили вернуть деньги если полный сброс на заводские настройки не поможет, ревью не удалили и не просили поменять оценку.
  • О книге Varghese «Web Development with Go»
    +3
    > «т.е. по сути код продолжит выполнятся с той точки, где была вызвана паника»

    это не так работает, как совершенно справедливо заметил astec. И в этом легко убедится самому, например так play.golang.org/p/OVcx_zDjDx
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    0
    ничего не понял. кем отправлятся? что именно слушает клиент? что значит назад?

    Насколько я себе представляю, этот рефреш токен должен быть у клиента и получит он его в момент login, вместе с access token, где его, теоретически можно украсть, например если есть физический доступ к компьютеру жертвы. Потом он (клиент) его будет время от времени посылать auth серверу для получения нового access token. Я не вижу как в этой схеме помешать злодею который завладел этим refresh token.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    0
    > Компрометация refresh tokenа сама по себе еще не обязательно приведет к возможности получения злоумышленником новых токенов

    Вот это мне непонятно. Какой механизм может этому помешать? Передача рефреш токена, как бы она не просиходила, будет идти от клиента к серверу auth и в ответ на валидный refresh token auth server радостно создаст новый access token. Кроме условного «усиления refresh token» путем добавления туда чего-то типа source ip и/или агента или еще нечто в таком роде, я не вижу какой тут механизм помешает.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    +1
    эээ… а это что? «я лишь подчеркнул что это не правильно...», «вы не правильно пишите что application server должен знать секрет ...»

    я не спорю, что для определенных случаев ассиметричный ключ будет безопасней, я всего лишь подчеркиваю, что категоричность приведенных выше цитат не соответствует действительности.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    +1
    > в примере в статье речь о симметричном шифрование и секрет получается один и тот же что на auth сервисе, что на application.

    да, именно об этом и идет речь в статье. И это, повторю в 3й раз, вполне правильная трактовка. С точки зрения JWT нет ничего неправильного в использовании симметричного ключа, это один из легальных способов.

    Что касается «удобней» — это уже вопрос к вашей системе. Я могу придумать случаи когда использование HMAC будет удобней, но суть не в этом, а в том, что это один из нормальных методов подписи и верификации JWT.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    0
    это вполне вполне правильная трактовка. HMAC именно так (общий секрет) и работает.
  • Пять простых шагов для понимания JSON Web Tokens (JWT)
    +6
    Нет, смысл вовсе не в этом. Строго говоря «application server может читать данные из payload без ключа» — это очень плохая идея. Никакого доверия таким данным нет и их можно использовать только после того, как сделана проверка подписи. Это действительно делает application server и он делает это на каждый запрос в котором JWT представлен.

    Какой-то ключ application server должен знать, но это не обязательно должен быть тот же секрет, который использовался при создании токена. А может быть и тот-же, зависит от Signing Method — HMAC (shared key) или RSA/ECDSA (asymmetric).
  • Что такое dinghy или как ускорить docker
    0
    я не вижу никакой проблемы с мounted volumes. Изменения появляются сразу, без всяких костылей с NFS и прочим.
  • Что такое dinghy или как ускорить docker
    0
    > В любом случае — это особенность, которая в «плюсы» точно не попадает.

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

    > если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно

    Опять непонятно, какую именно проблему предложенное решения адресует. Телепатически могу догадаться, что речь идет о volumes (исходя из разных упоминаний NFS).

    > В комплекте идёт прокси — зачем же изобретать свой велосипед,
    Если это используется как среда для локальной разработки, то я могу (с трудом, но могу) представить пользу от подобного. Но если это использование для чего-то более близкого к тому, как докер используют в реальной жизни, то решать «проблему» портов вот этим велосипедом на настощем, боевом сервере — это не самая лушая идея. Для этого есть много разного, готового и проверенного в бою, что умеет делать динамическое проксирование нормальным образом.
  • Что такое dinghy или как ускорить docker
    +1
    > «В качестве слоя виртуализации он использует HyperKit. Недостаток — вы можете использовать только одну виртуальную машину.»

    Что-то я не понимаю, в чем суть этой «проблемы». Почему это вообще рассматривается как проблема? В реальном, боевом использовании, тоже будет «всего один докер на хосте», зачем такая пляска с бубном нужна на рабочей машине чтоб поднять их несколько?

    По поводу «ужасно медленный» — это про что вообще? Про доступ к хостовой FS? Если он «ужасно медленный» то где результаты того, как он станет «прекрасно быстрым», где бенчмарки подтверждающие это?

    Проблема нескольких контейнеров на одном порту — это вовсе не проблема докера и решать ее надо на уровне прокси, который часть вашей системы, а не добавлением магической надстройки над docker-machine.
  • Путешествие за бугор и обратно: как не надо устраиваться работать за рубежом
    +1
    у вас, какая-то очень особая точка зрения не факты. Вы уже 5 раз сказали про «393 доллара ЕЖЕМЕСЯЧНО» но упорно отказываетесь слышать, когда вам говорят что речь идет о «monthly premiums» и, обычно (практически всегда в области IT) 90%, а бывает и 100% платит работодатель.

    Что касается «зачем людям нужна государственная страховка Obamacare» — во первых, она не государственная. Во вторых, если вам кажется, что народ стоит в очередь за этой «государственной страховкой», то оно тоже не так.
  • На пути к Go 2
    +7
    это мне кажется просто классическим примером пожелания, нарушающего все идеи и все методы/подходы принятия решений об изменениях в этом языке. То, что такое предложения вообще возникло, скорее всего означает нарушение первого пункта («используй язык, набирай опыт»). Я не могу себе представить как кто-то, кто разрабатывает на Go предложит настолько радикально и калечаще поменять нечто, что совершенно не важно для тех, кто этот код на самом деле пишет. И тут подходим к нарушению второго пункта — а какую проблему это должно решить? Проблемы тут нет никакой, но есть «мне так приятней/привычней, и вообще — хочу как в питоне».
  • IntelliJ против Eclipse: JetBrains Toolbox или Yatta Launcher?
    +1
    Какая-то, на мой взгляд, бесмысленная тема — «Кто первый сделал запускалку для своих продуктов». Сам смысл этих запускалок не особо ясен, ничего не мешает это сделать 33 другими способами, включая средства ОС и разные универсальные ланчеры типа Alfred. А тут это подается как достижение программистской мысли. Я сильно сомневаюсь, что есть живые люди которые выберут одну IDE вместо другой из за того, что там есть Launcher/Toolbox или нет. Этот фактор, лично для меня, не то что не в первой десятке причин для выбора, но даже и не в первой сотне.
  • Вышел GitLab 8.15
    0
    это не баг, но отсутствие очевидной фичи — https://gitlab.com/gitlab-org/gitlab-ce/issues/17801
  • Микросервис на Golang
    0
    назвать это гордо «интрументом» я бы не решиился. Там весь код это 50-60 строк определяющие структуру параметров, заворачивающие «templates» со всем, что человек туда положил в bindata и делающее по всем файлам в нем filepath.Walk с ExecuteTemplate. Могу, конечно, выложить, просто мне казалось это тривиальным.
  • Вышел GitLab 8.15
    0
    Я нежно люблю и активно исползьую gitlab и этот релиз мне нравится, однако приоритеты разработчиков иногда вводят в ступор. В 8.14 поломали совместимость со всеми текущими версиями git (точнее это git поломал, но результат от этого не меняется) и месяц было невозможно никому пушить в protected branch. Починка там была почти тривиальная, но по непостижимым для меня причинам она ждала 8.15, хотя просто просилась и кричала войти в скорейший, минорный релиз 8.14.х

    То, что авторы прокручивают новые свистелки — это конечнно хорошо, но то, что они стремительно теряют интерес к старым — это грустно. Месяца три как ждем элементарной починки для registry чтоб с ним наконец можно было работать, но нет — новые странные штуки появляются, а допилить то, что было выпущено несколько месяцев назад — никак.

  • Микросервис на Golang
    +2
    насколько я вижу, у тебя это тоже типа middlware, но с нестандартной сигнатурой func(http.ResponseWriter, *http.Request) (http.ResponseWriter, *http.Request). Если поменять на func(h http.Handler) http.Handler то станет как у всех, и самое главное — ты сможешь использовать все подобные, готовые middlware без всяких модификаций.

    Общее замечание: в принципе, идея создания фреймоврка такого рода мнe кажется делом сомнительным. Во первых, есть неплохие и проверенные боем библиотеки, которые это уже делают основнию часть, например chi. Во вторых — идея добавления туда и конфигурации и еще чего мне не кажется полезной. Да, я понимаю, что при создании сервиса хочется упростить начальные телодвижения, однако лично я пошел по другому пути и написал простой кодо-генератор, который делает рабочий скелет приложения с chi, набором middlware для него (у меня в каждом сервисе надо определенный набор, например JWT), логгером, main с флагами и env (github.com/jessevdk/go-flag) перехватчик сигналов и еще по мелочи. Кроме того, оно генерит не только исходный текст, но и все, что надо для сборки и деплоя (Dockerfile, CI yml, ansible yml)
  • Микросервис на Golang
    0
    в очередь я вкладываю понимание, что это queue куда кладут, в общем случае, данные. Кладут и достают последовательно. Конечно, очередь можно использовать мнoго для чего разного, например RPC, но насколько я понимаю, в статье не об этом речь. Конвейер, в моем понимании, это последовательность функциональных шагов для обработки неких данных.

    Для термина middleware в го мире есть довольно четкое соглашение, что это такое, и что люди под этим подразумевают, особенно в контексте http обработок. Например вот это https://github.com/pressly/chi/tree/master/middleware

    по поводу транслятора — по моему мнению лучше это поменять на оригинал до прогона через перводчик. То, что там читать трудно, а понять — невозможно.
  • Микросервис на Golang
    +3
    Удивительно непонятное описание продукта, просто исключительно странное. Даже мое понимание области в которой автор копает, не вносит ясности. Термины используется так, как я нигде не видел. Видимо очередь это не очередь а конвейер? И что за storage, для чего, куда и почему его основное достоинство это авто–дополнение в IDE? Хотя, похоже и storage это не то, что все под этим понимают, т.к. в нем автор предлагает хранить (?) middleware про которое я тоже уже не уверен, что это такое у автора и зачем его там хранить.

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

    Я не для придирок или прочих издевательств, но в попытке понять о чем это было вообще и как оно относится к микросервисам в частности.

  • Языку программирования Go — семь лет
    0
    У меня к вендорингу есть свои претензии, но похоже, что вы называете этим слово что-то такое, что не относится к обычному, появившимся еще в версии 1.5. С этим вендорингом все IDE и продвинутые редакторы работают как должно. Вопрос «каким вендорингом вы пользовались» заставил меня даже посмотреть на дату сообщения — сейчас есть единый и неповторимый vendor, который понимают все тулзы и все IDE и который не требует переписывания импортов.

    Эту часть «хочу работать попроектно (вендоринг), что в каждом проекте был repeatable build (нестандартный вендоринг)» я не понял вообще. Как попроектно относится к вендорингу? Если речь идет о том, что вы хотите все свои зависимости завендорить — ну так они ничем не отличаются от внешних зависимостей и положив их в vendor вы добьетесь repeatable build без всяких плясок и усилий. И «форкнуть какую-нибудь популярную либ, изменить её и использовать мой форк» тоже не проблема. Форкаем, меняем, кладем в vendor.

    «хочу, чтобы моя IDE не была на Java и работала быстро» — и чтоб синенького цвета? Если надо именно IDE то выбора особого нет, только на java. Если надо продвинутый редактор с пониманием Go – то таких есть штук пять.

    «ещё хочу не только билдить локально, но и деплоить на тестовый сервер по нажатию кнопки в IDE» — а это для Go делается каким-то особым и сложным способом? Я не знаю, какой уровень волшебства вы ожидаете, но у меня вообще ничего не надо нажимать и все это делается по коммиту. Ну и в IDE как и в редакторах это делается десятком разным плагинов, на любой вкус.

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

  • Скрипт для тех, кому лень разбираться в Linux
    +18
    Добавлю, что кроме ложной уверенности, это еще и набор вредных и весьма опасных практик, собранный в одном флаконе. Кроме того, что оно должно запускаться под root, оно еще смело загружает по http черт знает что из интернета и потом запускает под тем же самым рутом.

  • Ansible-container: новый шаг в управление контейнерами
    0
    Ну это ведь о другом. У меня тоже ansible используется из контейнера по понятным причинам — все зависимости, что ему нужны там, все скрипты и все ключи доступны и прочее. Тут ansible просто еще одна докерезированная штука которая мало отличается от любого другого сервиса. Мой комментарий относился к идее запускать плейбук и в самом docker контейнере для инициализации/создания этого контейнера и именно такой кейс я назвал диковинным.
  • Ansible-container: новый шаг в управление контейнерами
    +1
    идея запускать плейбук и в самом docker контейнере мне кажется еще более … диковинной, мягко говоря. Если вдруг по каким-то, совершенно непонятным мне причинам, хочется делать такие странные, полуготовые и мутабельные докер контейнеры и деплоить внутрь код с помощью ansible, то совсем непонятно зачем тут docker вообще, и почему бы не делать это прямо на хост.

    > полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry

    С трудом могу себе представить эту ценность. Возможно, для этого нужны какие-то совсем дикие многофункциональные контейнеры, которые муторно и сложно описать обычным образом, но мне это видится кривой дорогой — я за контейнер-на-сервис, а не контейнер-как-легкая-vm.
  • Ansible-container: новый шаг в управление контейнерами
    0
    Dockerfile примерно такой же «shell-script» как и ансибловый yaml. Ну да, там в RUN пиши что надо, но примерно с тем же успехом можно сказать, что и ansible это такой «shell-script» с ssh запускалкой.

    Короче, как по мне, так очень странная затея. Понятно, почему это надо ansible, но как (а главное зачем) этим будут пользоваться живые люди я все еще не могу понять. Мотивация «этот язык описания мне нравится больше» мне кажется какой-то неубедительной для введения такого сомнительного велосипеда в свой процесс построения контейнеров.
  • Ansible-container: новый шаг в управление контейнерами
    +4
    Что-то я упускаю прелесть этой идеи. В моем понимании построение контейнера, это часть построения сервиса/программы, которое создает артифакты в виде docker image и пушит, и все это происходит в CI системе и, строго говоря, никакого отношения к asnible не имеет. Именно тут нужен Dockerfile, и он нужен на уровне сервиса а не на уровне композа, т.е. каждый сервис строится со своим собственным Dockerfile и никакой зависимости с прочими частями, типа nginx ему не надо.

    Сам деплоймент никакого отношения к этим Dockerfile не имеет, он их даже не видит. Все, что ему надо это docker-compose.yml в котором прописано все сервисы, порты, зависимости и прочее. Это (деплоймент) можно делать с помощью ansible (я так и делаю) но никакой хитрости для этого не надо, просто доставить compose файл плюс что надо еще (конфиги, например) и дернуть docker-compose.

    В какой модели удобно использовать подход описанный здесь, я не могу себе представить. Это если строить на боевом сервер контейнер? И в этом, странном случае, это можно делать с помощью compose. Единственный, но на мой взгляд сомнительный, плюс это разбиение на роли для сборки образов, но я не очень вижу зачем, например dumb-init иметь в виде роли, но не базовым контейнером.

    Кроме того, реализация своего сборщика, это дело муторное и требующее постоянной гонки за обновлениями docker. Даже они сами не поспевают с этим, и compose иногда обновляется сильно позже чем та или иная фича добавилась в докер. А тут теперь надо будет ждать пока и ansible это добавит.
  • Запуск cron внутри Docker-контейнера
    0
    ну, строго говоря, мы тут и так городим свой entrypoint.sh. Без особого труда тут можно сделать и какой sed для автоматической замены SHELL на то, что надо, и больше об этом не думать.