Посоветуйте видеоурок какой, не хочется читать просто, хотя можно и книгу, но лучше статью. Хотелось бы что-то не слишком большое или с возможностью набирать код, тогда можно подольше видос. Про архитектуру и практически как реализовать на примере. Куча примеров на торрентах, но там на английском, что я на слух иногда плохо воспринимаю и так много всего что не знаю что лучше. Спасибо!
Здравствуйте, dsalodki, Вы писали:
D>Посоветуйте видеоурок какой
Чего там учить. Ты же знаешь, что такое монолит. Вот микросервисы — это те же монолиты, только они маленькие, их много, и они копошаться (читай — взаимодействуют), как пчёлы в улье, ну или как глисты в копре. Всё, урок окончен. Иди делай.
G>Чего там учить. Ты же знаешь, что такое монолит. Вот микросервисы — это те же монолиты, только они маленькие, их много, и они копошаться (читай — взаимодействуют), как пчёлы в улье, ну или как глисты в копре. Всё, урок окончен. Иди делай.
Там вроде шина нужна, типа RabitMQ вот это я не знаю, паттерны какие-то есть
Здравствуйте, dsalodki, Вы писали:
D>Посоветуйте видеоурок какой, не хочется читать просто, хотя можно и книгу, но лучше статью. Хотелось бы что-то не слишком большое или с возможностью набирать код, тогда можно подольше видос. Про архитектуру и практически как реализовать на примере. Куча примеров на торрентах, но там на английском, что я на слух иногда плохо воспринимаю и так много всего что не знаю что лучше. Спасибо!
На ютбуе вбейте .net микросервисы + есть субтитры, т.е. автопереводчик английских каналов.
На степике есть курсы, но там вроде не .net (хотя и на .net может есть).
Здравствуйте, dsalodki, Вы писали:
G>>Чего там учить. Ты же знаешь, что такое монолит. Вот микросервисы — это те же монолиты, только они маленькие, их много, и они копошаться (читай — взаимодействуют), как пчёлы в улье, ну или как глисты в копре. Всё, урок окончен. Иди делай.
D>Там вроде шина нужна, типа RabitMQ вот это я не знаю, паттерны какие-то есть
Кому нужна? Обычно всё по http работает, REST'ы там всякие, или gRPC ещё
Здравствуйте, dsalodki, Вы писали:
G>>Чего там учить. Ты же знаешь, что такое монолит. Вот микросервисы — это те же монолиты, только они маленькие, их много, и они копошаться (читай — взаимодействуют), как пчёлы в улье, ну или как глисты в копре. Всё, урок окончен. Иди делай.
D>Там вроде шина нужна, типа RabitMQ вот это я не знаю, паттерны какие-то есть
Шина — это были сервисно-ориентированная архитектура, 20 лет назад. Сейчас же микросервисная, она распределённая, поэтому никаких серверных сессий, авторизация по токену, остальные паттерны сам додумай, в том же стиле. Т.е. если твоё решение не является распределённым, то оно не является микросервисным.
Хотя, сейчас уже есть и наносервисы, учи лучше сразу их. Хотя, пока выучишь, там уже придет квантовый компьютинг и ИИ со своими парадигмами, которые мы, стариков, уже не осилим своими слабенькими мозгами, нас вытеснят те, кто умеет прогать кубиты. Так что лучше сразу учи кубиты. Хотя там много матеши, пока всё освоить, уже приидет технологическая сингулярность и всех нас засосет в единый планетарный разум, тогда тебе вообще не нужно будет ничего учить, ты будешь знать всё, т.к. будешь частью улья. Но как часть улья, тебе не позволят расслабляться, бухать, гамать, путешествовать. Поэтому лучше займись этими вещами, пока есть такая возможность.
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, dsalodki, Вы писали:
D>>Посоветуйте видеоурок какой
G>Чего там учить. Ты же знаешь, что такое монолит. Вот микросервисы — это те же монолиты, только они маленькие, их много, и они копошаться (читай — взаимодействуют), как пчёлы в улье, ну или как глисты в копре. Всё, урок окончен. Иди делай.
не в монолите можно все изменения с базой в одной транзакции делать, а в микросервисах придется с этим жить.
Здравствуйте, m2user, Вы писали:
S>>.Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед
M>Как это применимо к микросервисы, которые, как правило, stateless?
M>Также в статье написано, что в отличие от .NET Remoting не нужно наследование от MarshalByRefObject. Как в этом случае реализована lifetime policy?
Ну подправь свой протокол через TCP/IP с портами отличных от 80. Передавай свои токены, шифрованные данные итд. Это делается не на уровне объекта, а транспорта.
Кроме того сам сервис может запускаться в песочнице. Это уже мелочи
и солнце б утром не вставало, когда бы не было меня
Это интересный академический пример.
Вот только для понимания принципов микросервисной архитектуры он будет полезен чуть более чем никак.
В том смысле, что в подавляющем большинстве случаев транспортом для взаимодействия между микросервисами будет что-то простое и стандартное (а, значит, поддерживаемое не только в .NET):
REST, WebSockets, JSON-RPC, GRPC, Thrift и т.п. — для синхронного request-response общения.
Либо JSON/Protobuf/Thrift/Avro и т.п. — для асинхронного общения через шину (RabbitMQ, ActiveMQ, Kafka и т.п.).
Это как раз тот самый микросервисный принцип dumb pipes, smart endpoints.
Никто по доброй воле не выберет для этого самописный stafefull протокол, заточенный под конкретную платформу.
Здравствуйте, RushDevion, Вы писали:
RD>Никто по доброй воле не выберет для этого самописный stafefull протокол, заточенный под конкретную платформу.
А почему ты решил, что под конкретную платформу?
Там под .Net Core. Что касается REST, WebSockets, JSON-RPC, GRPC, Thrift и т.п. — для синхронного request-response общения.
То это протоколы поверх TCp/Ip. Их также можешь применять, вместо Tcp/IP
Просто представлен универсальный маршалинг между двумя процессами. Только и всего. Суть микросервисов как раз в работе в разных процессах и обменом сообщений.
Только в моем случае это сделано более прозрачно, без всякого лишнего слоя. Только и всего.
То есть можно отладить реальный код в одном процессе и натравить этот же код на обмен между процессами.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Просто представлен универсальный маршалинг между двумя процессами. Только и всего. Суть микросервисов как раз в работе в разных процессах и обменом сообщений. S>Только в моем случае это сделано более прозрачно, без всякого лишнего слоя. Только и всего. S> То есть можно отладить реальный код в одном процессе и натравить этот же код на обмен между процессами.
Здравствуйте, Marty, Вы писали:
S>> Просто представлен универсальный маршалинг между двумя процессами. Только и всего. Суть микросервисов как раз в работе в разных процессах и обменом сообщений. S>>Только в моем случае это сделано более прозрачно, без всякого лишнего слоя. Только и всего. S>> То есть можно отладить реальный код в одном процессе и натравить этот же код на обмен между процессами.
M>Ну, это не микросервисы. Это DCOM скорее
Ну суть то по сути одна. Разделяем приложение на несколько процессов. Причем процессы могут быть на разных компах.
DCOM это просто протокол обмена и маршализация данных.
Тот же gRPC мало чем отличается от DCOM
и солнце б утром не вставало, когда бы не было меня
S>А почему ты решил, что под конкретную платформу?
Ну вот у меня есть сервис на NodeJS, еще один на Rust и третий на Go.
И все они хотят общаться с твоим сервисом на .NET (Core) в который воткнули этот самописный маршалинг.
Как их подружить? Имхо, либо никак, либо нужно рожать поддержку такого же самописного маршалинга под каждую платформу.
Поэтому "под конкретную платформу".
S>Там под .Net Core. Что касается REST, WebSockets, JSON-RPC, GRPC, Thrift и т.п. — для синхронного request-response общения. S>То это протоколы поверх TCp/Ip. Их также можешь применять, вместо Tcp/IP
Тут не понял. "Проколы поверх TCP/IP, применять вместо TCP/IP". Как это?
Но в любом случае мой посыл был в том, что это стандартные протоколы.
И если я, например, говорю, что мой микросервис предоставляет REST API поверх HTTP.
То таким API без проблем смогут воспользоваться и Rust, и NodeJS, и Go-разработчики в своих микросервисах.
S>Суть микросервисов как раз в работе в разных процессах и обменом сообщений.
Нет. Это подразумевается из соображений отказоустойчивости и масшатабируемости.
Но суть — в единоличном владении данными/процессами некоторой предметной области и предоставлении доступа к этому только через декларированное публичное API.
А углубляться в детали конкретных протоколов и тем паче, делать свою кастомную имплементацию протокола...
Ну это как если бы человек попросил рассказать в общих чертах про ООП, а ты ему начал объяснять, как работает ассемблер.
Здравствуйте, RushDevion, Вы писали:
S>>А почему ты решил, что под конкретную платформу? RD>Ну вот у меня есть сервис на NodeJS, еще один на Rust и третий на Go. RD>И все они хотят общаться с твоим сервисом на .NET (Core) в который воткнули этот самописный маршалинг. RD>Как их подружить? Имхо, либо никак, либо нужно рожать поддержку такого же самописного маршалинга под каждую платформу. RD>Поэтому "под конкретную платформу".
Да это для .Net. Но никто тебе не запрещает использовать зоопарк под разные платформы используя стандартное API.
А вот при использовании .Net как раз удобнее мой подход, так как проще отлаживать сначала библиотеки, а затем использую тот же код уже маршалинг.
S>>Там под .Net Core. Что касается REST, WebSockets, JSON-RPC, GRPC, Thrift и т.п. — для синхронного request-response общения. S>>То это протоколы поверх TCp/Ip. Их также можешь применять, вместо Tcp/IP RD>Тут не понял. "Проколы поверх TCP/IP, применять вместо TCP/IP". Как это? RD>Но в любом случае мой посыл был в том, что это стандартные протоколы. RD>И если я, например, говорю, что мой микросервис предоставляет REST API поверх HTTP. RD>То таким API без проблем смогут воспользоваться и Rust, и NodeJS, и Go-разработчики в своих микросервисах.
Проблемы будут всегда, особенно при использовании зоопарков.
S>>Суть микросервисов как раз в работе в разных процессах и обменом сообщений. RD>Нет. Это подразумевается из соображений отказоустойчивости и масшатабируемости. RD>Но суть — в единоличном владении данными/процессами некоторой предметной области и предоставлении доступа к этому только через декларированное публичное API.
Это уже твое видение. Возьми мой RPC и сделай его публичным. Я кстати его использую в своих приложениях. Поэтому и советую.
RD>А углубляться в детали конкретных протоколов и тем паче, делать свою кастомную имплементацию протокола... RD>Ну это как если бы человек попросил рассказать в общих чертах про ООП, а ты ему начал объяснять, как работает ассемблер.
На самом деле это чертовски интересно для познавания. Как это работает.
Как раз эта статья и показывает механизм работы стандартных API
и солнце б утром не вставало, когда бы не было меня
RD>>Поэтому "под конкретную платформу". S>Да это для .Net. Но никто тебе не запрещает использовать зоопарк под разные платформы используя стандартное API.
Вот так легко и непринужденно мы только что отказались от одной из главных фишек микросервисного подхода — возможности разработки на разных ЯП
S>А вот при использовании .Net как раз удобнее мой подход, так как проще отлаживать сначала библиотеки, а затем использую тот же код уже маршалинг.
И даже на .NET большинству моих знакомых все же удобнее использовать проверенные вещи: .NET Remoting, WCF/WCF Core, REST + Swagger, GRPC с автогенерацией как клиентской, так и серверной частей. А не заниматься "отладкой маршалинга" в самописной имплементации.
RD>>То таким API без проблем смогут воспользоваться и Rust, и NodeJS, и Go-разработчики в своих микросервисах. S> Проблемы будут всегда, особенно при использовании зоопарков.
Да, но со стандартными протоколами и отлаженными имплементациями под конкретную платформу проблем будет в разы меньше, чем с самописной либой.
S>>>Суть микросервисов как раз в работе в разных процессах и обменом сообщений. RD>>Нет. Это подразумевается из соображений отказоустойчивости и масшатабируемости. RD>>Но суть — в единоличном владении данными/процессами некоторой предметной области и предоставлении доступа к этому только через декларированное публичное API. S> А это уже твое видение. Возьми мой RPC и сделай его публичным. Я кстати его использую в своих приложениях. Поэтому и советую.
Это не мое видение. Это то, как микросервисный подход возник в Амазоне. Погугли историю перехода Амазона на микросервисы.
Мне твой RPC, при всем уважении, не нужен совершенно
У меня на одном проекте 12-летней давности свой похожий был. Только им за пределами того проекта никто пользоваться не захотел.
RD>>А углубляться в детали конкретных протоколов и тем паче, делать свою кастомную имплементацию протокола... RD>>Ну это как если бы человек попросил рассказать в общих чертах про ООП, а ты ему начал объяснять, как работает ассемблер. S> На самом деле это чертовски интересно для познавания. Как это работает. S>Как раз эта статья и показывает механизм работы стандартных API
Безусловно, это интересно. Но бесполезно (а скорее, даже вредно) для человека, который только-только начал разбираться с микросервисами.
RD>У меня на одном проекте 12-летней давности свой похожий был. Только им за пределами того проекта никто пользоваться не захотел.
Это понятно. Лучше пользоваться монструозными библиотеками на все случаи жизни.
S>>Как раз эта статья и показывает механизм работы стандартных API
RD>Безусловно, это интересно. Но бесполезно (а скорее, даже вредно) для человека, который только-только начал разбираться с микросервисами.
Еще раз микросервисы это отдельные процессы. Нужны они были прежде всего для разделения процессов программирования по командам.
Есть как много плюсов, так и минусов.
Но по жизни нужно обмениваться не только с микросервисами. Та же отладка использует Tcp/ip итд.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
M>>Ну, это не микросервисы. Это DCOM скорее S> Ну суть то по сути одна. Разделяем приложение на несколько процессов. Причем процессы могут быть на разных компах. S>DCOM это просто протокол обмена и маршализация данных. S>Тот же gRPC мало чем отличается от DCOM
Нет. Микросервисы — они стейтлес, ну, или стейт им передаётся каждый раз в параметрах. DCOM/COM+ объекты живут долго в чужом процессе, как и у тебя
