Comments 13
Потому что буквально после двух простых рест сервисов возникнут следующие вопросы
1) Service discovery.
client side? server side? Как у Go с готовыми библиотеками под это дело? А такими которые уже опробованы в продакешене? А такими, которые опробованы в продакшене крупными компаниями аля нетфликс?
Понятное дело что можно использовать клиентов для Consul или Eureka.
2) Circuit breaker
Вот тот вот сервис подтупливает и отвечает по 1000 секунд вместо 5. Из-за этого все сервисы, которые на него завязаны тоже начинают тупить. Есть ли готовый продакшен фреймворк для go в этом случае? (Hystrix с страницей отчета)
3) Нужно сделать CRUD over REST, с пагинацией, с базовыми селектами.
Есть ли удобные и проверенные временем фреймворки для Go под это дело?
4) OAuth и сотоварищи. Насколько просто повесить на Go endpoint-ы авторизацию и аутентификацию?
5) Tracebility. Есть ли возможность *просто* отследить все сервисы через которые прошел запрос? Так, чтобы без руками пробрасывать UUID correlationID в заголовках или теле запроса?
6) Логирование. Stdout, конечно круто, а что насчет простой интеграции с ELK?
В Java мире эти вопросы закрыты более менее нормально.
Проблема не в создании микросервисов, а в оркестровке и отладке зоопарка из 20 хотя бы сервисов, каждый из которых имеет по 3-4 инстанса.
И понятное дело что в ИТ все вопросы решаемы. Но количество приседаний, которые необходимо для этого сделать очень отличатся.
И раз мы уже пытаемся минимизировать размер docker образа, почему бы не воспользоваться
Erlang docker 17MB?
В котором есть let it fail, supervision trees, и отличный веб-серве cowboy.
>> Поставьте эти словечки себе в профиль – и вас сразу начнут осаждать рекрутеры
Поставьте эти словечки себе в профиль – и вас сразу начнут осаждать рекрутеры
C глупыми и бесполезными предложениями.
DevOps/Микросервисы — это удел запада, а наши потуги внедрять всё это — довольно посредственны.
Пока не решится вопрос с контролем качества и общей организацией работ, а в 80% случаев их нет, до тех пор и думать про какой-либо DevOps и Микросервисы не то что бесполезно, а просто вредно, и для проектов, и для их руководства.
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 это кривой оверхед для меня. С другой стороны я не побоюсь использовать няшный Си и ассембрер, если в этом возникнет крайняя необходимость.
Ну и фраза про «go потребляет в 10 раз меньше памяти чем Java» шикарна, конечно.
Если речь идёт о разнизе в размере, то разница никак не в 10 раз…
> Чтобы протестировать сервис на ноутбуке разработчика, контейнер не нужен, всяческая связанная с ним магия – тоже.
Docker даёт возможность унифицировать дев- и прод- окружения, запуская сервис в «одинаковом» (простите) окружении. Хотя, конечно, смотря что понимать под «протестировать».
Язык Go, микросервисы и DevOps – хорошая компания?