Марк Шевченко - Микросервисы на C#

[@grafbcn]

Спасибо за доклад. Особенно за тонкости асинхронности на C#

[@samnihao6943]

32:05 про микросервисы

[@ivantut9210]

Кучу время потратил на поиск качественного объяснения и только спустя год видео появилось в рекомендациях.

[@samnihao6943]

Спасибо. Было бы здорово, если бы ссылки были в описании под видео.

[@VasilenkoYaroslav]

Спасибо за доклад. Как по мне про С# лучше было не расказывать, все не расказать за такое краткое время. Для одного потока выделяеться стек в 1 мб а не 10.

[@markshevchenko]

Спасибо за отзыв. Учту. Хотелось охватить всё, но не успел. Полная версия доклада на полтора часа. Про стек -- ошибся, спасибо, что поправили.

[@konstantinkav.9975]

Спасибо, отличное видео!

[@vborovikov]

что-то похожее по теме начинается с 38:00 минуты!

[@АристархЗловредович]

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

[@AntonSkworc]

Очень хороший доклад! С шарпом работаю уже довольно давно, но всё равно послушать было очень интересно. На мой взгляд, про микросервисы автор рассказал достаточно доступным языком, и в то же время интересно. А по поводу LINQ: его в основном используют благодаря методам расширения. В результате такой код выглядит достаточно красиво. Интересно было узнать, что именно в C# впервые применили концепцию написания запросов подобного рода в самом коде (в других языках аналогов не было). Автору спасибо за хороший и интересный доклад!

[@crazy_fedor]

Интересно, но очень мало про микросервисы :(

[@shaqull]

Простите, не удержался от критики :) Agile это про то, что мы сразу признаем - мы допустим ошибки, мы НЕ знаем как сделать, мы НЕ будет заниматься исследованием и длительным планированием, а сразу начнем делать, но мы будет это делать гибко держа руку на пульсе. Микросервисы это тоже про гибкость, но только для бизнес логики - если надо что-то внедрить, то бизнес не хочет быть зависимым от независящих факторов, которые не связаны с его новой логикой, но которые появляются в монолите, т.к. риск спутанности новых фич велик и надо ждать стабильную версию всей системы А у вас через слово: "вам надо сесть и договорится; надо сразу сделать правильно" Эти согласования взаимодействий будут сильно тормозить внедрение любой бизнес логики. При этом необходимость микросервисов обосновывается возможность обрабатывать 1 млрд запросов, а что мешает монолиту их обрабатывать, их же можно 5-10 штук запустить?

[@MyPomoshnik]

Так и есть. Но то что Вы описываете дороже в разы и называется экстремальным прототипирование - пилим сразу бизнес-логику, а потом переписываем полностью инфраструктуру.

[@SugarDiDi]

C# Рулит!

[@ЕвгенийМ-г1я]

Отличный доклад

[@nikiv2688]

Полезно

[@MisterGenix]

Спасибо, было интересно послушать. Про базу вот только не понял - говорите, что у каждого микросервиса должна быть своя база, но вместе с тем вы собирали данные в монго на одном микросервисе, а потом другими лазили в нее и что-то выбирали.. Или это про то, что обращения к этой базе должны проходить только через этот микросервис? И второй вопрос - если все-таки у нас в огромном приложении используется один единственный сервер, то стоит ли в пределах одного сервера выделять какие-то микросервисы на Kestrel или их суть только в том, чтобы можно было отсоединить физически на другой сервер?

[@markshevchenko]

Спасибо за вопросы. Сначала отвечу про базы и микросервисы. В идеале -- у каждого микросервиса своя база. Проектировать и делать надо так. Но диспциплина у нас инженерная, иногда приходится срезать углы. Бывает, что не хватает производительности в конкретном месте, или нужна согласованность данных, то есть нужна транзакция для двух-трёх операций. Мы можем решить, что в данном случае можно нарушить изоляцию сервисов и залезть в базу к соседу. Мы в таких случаях всё равно себя ограничивали: доступ в чужую базу делали только по чтению.

[@markshevchenko]

Вопрос про приложения и сервер. Микросервисы облегчают масштабирование. Если производительности сервера не хватает, вы ставите рядом второй. Вопрос: можно ли будет без труда разбить приложение на две части и разнести на два сервера. Нет. Это не происходит просто так. Чтобы можно было масштабировать приложение, его надо разбить на слабо связанные части. Тогда можно будет без труда запускать их на одном сервере или на нескольких. Тут есть хитрость. Если у вас большое приложение, его всё равно лучше разбивать на части, которые в DDD называют ограниченными контекстами (bounded contexts). Поставьте ограничение: контексты видят друг у друга только интерфейсы, события и DTO. Под интерфейсами я понимаю конкретно интерфейсы C#, ключевое слово interface. DTO -- простые объекты без поведения, чисто открытые данные. Для начала ваши контексты могут быть просто сборками, которые запускаются в рамках одного домена .NET, но в случае необходимости вы без труда (за условные две недели) сможете превратить их в микросервисы, не переписывая весь остальной код. Просто поменяете реализацию интерфейсов. События сделаете через очереди сообщений (message queue). Если делать так, вы можете разнести большое приложение на независимо масштабируемые микросервисы в случае необходимости.

[@MisterGenix]

@@markshevchenko спасибо за ответы, в принципе, эта идея и прослеживалась в видео - микросервисов даже если в проекте нет, они должны быть "в уме" в виде bounded context'ов )

[@alexgrinberg1888]

Был удивлён , что интро на с# представлены сразу с LINQ. Для новичка это очень сложно понять. Вообще этот курс я бы построил для бэкенд програмеров.

[@hysapod]

Так ведь это и есть для бекэндеров)

[@milovidov42]

Дерево выражений это конечно очень мощная технология но рассказывать людям эту технологию как введение в C# это конечно жесть.

[@superspy2008]

удивился, почему он про Emit не рассказал. Самое оно для спящих студентиков в зале

[@ЮрийМаксименко-ц1р]

Скажем так, если бы мне сразу освятили и сказали "братанчик, почитай что такое LINQ и лямбды" (как оно и было) - я бы .... я бы ничего не понял как и не понял до этого. Ладно. Ты прав, я передумал ахахахах

[@Евгений-ц3щ3к]

Докладчик молодец. Вопросы - пиздос не в тему. Кроме последнего. Последний хороший. Разбивать систему - не всегда лучшее решение. А вот независимая, устойчивая система - вот к чему нужно стремится. Атомарность, как можно меньше связности.

[@schmakov-alexander]

37; 45:40; 50:15

[@timur2887]

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

[@TinTaBraSS777]

опять часы пустого безсмысленного свистежа )

[@maksimsergeevich5939]

Странно что не упомянут Java, как наилучший инструмент для написания бекенда.

[@AlekseiChel]

Потому что C# лучше?

[@samnihao6943]

Прям наилучший?)

[@maksimsergeevich5939]

@@samnihao6943 ну вообще хз, я так пизданул просто) я вообще на php / JavaScript пишу))

[@samnihao6943]

@@maksimsergeevich5939 да и я вообще-то искал котиков, не знаю, как на это видео попал)

[@maksimsergeevich5939]

@@samnihao6943xD