Если уж идёт речь о полумерах. Почему бы не заняться агрессивной рекламой даркнетов вроде i2p или tor? Кстати лично я считаю самым большим негативным эффектом от всей этой возни с записью утечку за пределы границ гос-ва всех тех денег, которые у «народа» выгребут. А поползновения с «импортозамещением» и прочим одновременно с этим весельем может создать ситуацию, когда на всю Россию буквально 1.5 провайдера останется.
0) Ещё до написания первых двух сервисов стоит глянуть https://github.com/golang/go/wiki/Projects и присмотреть то, что вам надобно. А ещё убедиться, что golang именно то, что вам нужно для вашей задачи.
Но я могу быть не прав в контексте ваших задач. Мои задачи go решает. Например я больше занимаюсь кодом, который вместо масштабирования вверх и вширь должен использовать существующие ресурсы без фанатизма (и диск и память и cpu). Вплоть до того, что docker это кривой оверхед для меня. С другой стороны я не побоюсь использовать няшный Си и ассембрер, если в этом возникнет крайняя необходимость.
Я не очень понял как отказ от докера в пользу самописных контейнеров или даже каких-то других поможет сэкономить мне время. Докер настолько плох?
Я не говорю, что докер плох (хотя об этом можно поспорить тоже). Я говорю о том, что совершенно не ясно, какие задачи вы пытаетесь им решить. Академическая задача? Так явно напишите об этом.
Вижу только кляксы, симметричные по вертикальной оси. Либо чёрные, либо с несколькими цветами. Некоторые из них слегка похожи на результат сканирования биологических объектов тем или иным способом.
А когда контейнеров становится слишком много, то получается вот так:
Т.е. теперь пованивает не только код, но и вообще всё, включая администрирование. Мы сами себе создали дополнительные проблемы. Ведь для каждого сервиса надо выполнить следующее:
накодить сервис
оттестировать сервис
документировать сервис
оттестировать api сервиса
документировать api сервиса
встроить сервис в систему сервисов
оттестировать работу сервиса вместе с другими сервисами
следить за адом явных и неявных зависимостей одних сервисов от других сервисов
администрировать всё это дело внутри и снаружи
Это сложно.
Нет, я не имею ввиду, что использовать контейнеризацию это плохо. Я имею ввиду, что надо тщательно прорабатывать всю архитектуру, вооружившись такими полезными орудиями труда, как Бритва Оккама, принцип KISS и здравый смысл.
На мой взгляд гораздо лучше использовать большие и толстые сервисы. В вашем случае я бы сделал так:
Nginx
Контейнер приложения × несколько штук во имя возможности обновлять приложение без перезагрузки всего
Одна или несколько DB по вкусу
Это дешевле. Это работает быстро. Это не требует много ума. Это достаточно безопасно. Это неплохо документируется. Это вполне масштабируемо.
В дальнейшем сюда может добавиться контейнер для небезопасного кода. Например дать возможность постить юзерам webm, для чего может потребоваться дырявый ffmpeg или ещё что либо подобное. Или запилить рядом какой либо ещё сервис вроде wiki-платформы или irc-сервера (ну для примера).
Могу предложить примерно такой эврестический алгоритм отделения чего либо в отдельные сервисы:
всё, что небезопасно (например код третьих лиц сомнительного качества) стоит порезать на сервисы
если для поддержки сервиса требуется более 5-15 человек, то подумать о разделении этого на два-три сервиса
если нам нужно симулировать бурную деятельность и/или освоить бюджет (под эту причину вполне подходит статья, которую я комментирую)
Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров. rkt/CoreOS, LXC/LXD, OpenVZ, kvm, OpenStack и другие. Тысячи их. Одно из сравнений можно посмотреть вот тут: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html Не забывайте про вариант с самописной системой контейнеризацией и/или инфраструктурой вокруг этого на том или ином уровне (в конце концов у вас может быть в наличии админ с достаточными знаниями). Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.
Жизнь в России.
Уровень Hard. Получить диплом теолога, отыгрывая за агрессивного атеиста.
Уровень Nightmare. При прохождении уровня заставить поверить всех преподавателей в то, что ты Иисус, а потом доказать им же собственное не существование. За каждого преподавателя, попавшего в психиатрическую больницу начисляются дополнительные очки.
Может по той причине, что gl это всего навсего способ вывода для 2D/3D, но не более.
Сеть, физика, звук, графика всего лишь относительно низкоуровневые инструменты. По мимо этого есть достаточно много других проблем, которые не менее важны. Часть из них вообще находятся в пределах влияния гуманитариев.
Первые три очевидны же. Они даются на откуп внешнему коду, а размер строки в большинстве ЯП передаётся в качестве части строки, либо, если это няшный C, спокойно считается при помощи стандартных функций или просто цикла (ну или передаётся явно).
Все вопросы по строкам относительно этой задачи можно запихнуть в один: в каком формате строка? (предполагая, что она будет в стандартной для данного ЯП)
Остальные вопросы (на мой взгляд) надо задавать в другую сторону:
Достаточно ли мне ascii набора?
Это нормально, если я выброшу исключение для строк, не кратных 2?
Можно я не будут писать комментарии в стиле Капитана Очевидность?
Главное качество программиста (на мой взгляд) — это лень. Меньше кода — меньше проблем. Меньше кода — меньше писать, меньше читать, меньше рефакторить, меньше легаси через N-лет, меньше багов, меньше тестов, меньше оптимизаций. При этом количество проблем кода растёт быстрее, чем линейно от количества этого самого кода. При этом минимум определяется довольно просто: код всё ещё должен соответствовать сегодняшним требованиям. Минимум не означает минимум количества строк. Минимум это минимальное количество когнитивной нагрузки, которую создаёт код. К этому следует стремиться, но без фанатизма конечно. Такие дела.
0) Ещё до написания первых двух сервисов стоит глянуть https://github.com/golang/go/wiki/Projects и присмотреть то, что вам надобно. А ещё убедиться, что golang именно то, что вам нужно для вашей задачи.
1) circuit
3) gin + gorm например
4) https://github.com/golang/go/wiki/Projects#authentication
5) А почему пробрасывать руками это сложно? Лично я так бы и сделал. Один раз написал бы middleware, который за пару-тройку строчек добавляет заголовок и плюётся в какой-либо message queue.
6) https://github.com/golang/go/wiki/Projects#logging-and-monitoring
Но я могу быть не прав в контексте ваших задач. Мои задачи go решает. Например я больше занимаюсь кодом, который вместо масштабирования вверх и вширь должен использовать существующие ресурсы без фанатизма (и диск и память и cpu). Вплоть до того, что docker это кривой оверхед для меня. С другой стороны я не побоюсь использовать няшный Си и ассембрер, если в этом возникнет крайняя необходимость.
Бог или Б-г.
Я не убиваю котят. Да и jpeg-артефактов не особо видно тут. Всё в порядке.
Почему? Почему COBOL?
Я не говорю, что докер плох (хотя об этом можно поспорить тоже). Я говорю о том, что совершенно не ясно, какие задачи вы пытаетесь им решить. Академическая задача? Так явно напишите об этом.
А когда контейнеров становится слишком много, то получается вот так:
Т.е. теперь пованивает не только код, но и вообще всё, включая администрирование. Мы сами себе создали дополнительные проблемы. Ведь для каждого сервиса надо выполнить следующее:
Это сложно.
Нет, я не имею ввиду, что использовать контейнеризацию это плохо. Я имею ввиду, что надо тщательно прорабатывать всю архитектуру, вооружившись такими полезными орудиями труда, как Бритва Оккама, принцип KISS и здравый смысл.
На мой взгляд гораздо лучше использовать большие и толстые сервисы. В вашем случае я бы сделал так:
Это дешевле. Это работает быстро. Это не требует много ума. Это достаточно безопасно. Это неплохо документируется. Это вполне масштабируемо.
В дальнейшем сюда может добавиться контейнер для небезопасного кода. Например дать возможность постить юзерам webm, для чего может потребоваться дырявый ffmpeg или ещё что либо подобное. Или запилить рядом какой либо ещё сервис вроде wiki-платформы или irc-сервера (ну для примера).
Могу предложить примерно такой эврестический алгоритм отделения чего либо в отдельные сервисы:
Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров. rkt/CoreOS, LXC/LXD, OpenVZ, kvm, OpenStack и другие. Тысячи их. Одно из сравнений можно посмотреть вот тут: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html Не забывайте про вариант с самописной системой контейнеризацией и/или инфраструктурой вокруг этого на том или ином уровне (в конце концов у вас может быть в наличии админ с достаточными знаниями). Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.
Wakabamark.
Уровень Hard. Получить диплом теолога, отыгрывая за агрессивного атеиста.
Уровень Nightmare. При прохождении уровня заставить поверить всех преподавателей в то, что ты Иисус, а потом доказать им же собственное не существование. За каждого преподавателя, попавшего в психиатрическую больницу начисляются дополнительные очки.
Может по той причине, что gl это всего навсего способ вывода для 2D/3D, но не более.
Сеть, физика, звук, графика всего лишь относительно низкоуровневые инструменты. По мимо этого есть достаточно много других проблем, которые не менее важны. Часть из них вообще находятся в пределах влияния гуманитариев.
Вот переводы его статей я бы почитал. (Особенно тех, которые закрыты.)
Первые три очевидны же. Они даются на откуп внешнему коду, а размер строки в большинстве ЯП передаётся в качестве части строки, либо, если это няшный C, спокойно считается при помощи стандартных функций или просто цикла (ну или передаётся явно).
Все вопросы по строкам относительно этой задачи можно запихнуть в один: в каком формате строка? (предполагая, что она будет в стандартной для данного ЯП)
Остальные вопросы (на мой взгляд) надо задавать в другую сторону:
Главное качество программиста (на мой взгляд) — это лень. Меньше кода — меньше проблем. Меньше кода — меньше писать, меньше читать, меньше рефакторить, меньше легаси через N-лет, меньше багов, меньше тестов, меньше оптимизаций. При этом количество проблем кода растёт быстрее, чем линейно от количества этого самого кода. При этом минимум определяется довольно просто: код всё ещё должен соответствовать сегодняшним требованиям. Минимум не означает минимум количества строк. Минимум это минимальное количество когнитивной нагрузки, которую создаёт код. К этому следует стремиться, но без фанатизма конечно. Такие дела.
Но LAMP теперь тоже работает.