как?
Необходимо прикрутить оркестрацию в виде zebee/camunda, пока даже в голову не приходит, как все это делать.
Можно. Суть микросервисной архитектуры в том и заключается, помимо всего прочего, что ты можешь иметь пачку микросервисов написанных на чем угодно. При таком вопросе - ну например с помощью rest api
Я вот саму суть микросервисов не совсем понял, честн говоря. То есть получается, что микросервисы - это отдельные самостоятельные программы, которые обращаются друг к другу по http запросам?
не обязательно http. Но в целом да.
А оркестрация - это вид слежения за всем этим? Логгирование и т д?
скорее даже управления. Но это уже к девопсам.
ящик черный наружу торчит api, изменения в одном ящике не влияю на другой.
Если до этого работал с джангой и понял ее декомпозицию на приложения (app), то в микросервисной архитектуре каждый такой апп разделили бы на отдельный сервис.
как бы мягче сказать - ограничусь словом нет
исчерпывающий комментарий, спасибо.
это зависит от того как привык делать апы в джанге, я например всегда делаю их с мыслью, что этот ап может отделиться в отдельный сервис
Да, я тоже.
https://www.youtube.com/watch?v=7SM8GLArTDY
аппы это часто сильносвязанные компоненты, таже админка зависит от бд, если распихаешь ее в отдельный сервис, то падает бд - падает админка я уж не говорю про импорты в разных аппах пример микросервиса - например есть загрузка файла, вполне может жить основной когда загрузка лежит сама загрузка по OAUTH те ты радостно можешь его юзать для других сервисов или oauth сервер тоже как микросервис гут - у тя есть регистрация обычная и регистрация через оаут оайт лег, но в целом можешь работать через обычную авторизацию
Ты всё в кучу смешал. Микросервис тоже может упасть, если упадет БД которой он пользуется. И вообще это разные логические слои приложения.
По крайней мере в первом абзаце.
я уже написал это черный ящик - он живет своей жизнью, аппы это может быть просто логическое разделение если у тебя общая точка у всех сервисов - типа бд - это шмурдяк
Мне лень спорить. Просто скажу что все что ты пишешь по поводу микросервисов можно отнести и к "монолитным" приложениям. Например "черным ящиком" может выступать отдельная либа или приложение. Основное же преимущество микросервисной архитектуры лежит в легкости мастштабирования когда самые тяжелые куски можно захостить на пачке серваков.
потому что херню проще писать абстрактную пример хотя бы одного аппа есть из джанго когда оно жило в приложении, потом из него сервис сделали не мифическую мантру, а именно реального? потому что аппы в джанго а именно мы про это говорили - ну очень херово натягиваются на микросервисы, если ты специально не делаешь его под микросервисную архитектуру
Обсуждают сегодня