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

Марк Шевченко на Tver.io Backend Meetup 21 ноября.
Посмотрим на C# с точки зрения практики. Интересные для нас возможности языка - это деревья-выражений и async/await. Богатая библиотека позволит за считанные секунды подготовить каркас веб-приложения или создать миграцию базы.
Сравним микро-сервисный подход с другими распространёнными решениями: трёхзвенной и гексагональной архитектурами, чистой архитектурой Роберта Мартина и DDD. Узнаем, живёт ли C# в Linux и Docker. Подсказка: да, прекрасно живёт, и давно.
Немного поговорим о ползучей практике: что, как и в каком порядке. Придём к выводу, что C# для микро-сервисов - прекрасный выбор.

[@grafbcn]

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

[@konstantinkav.9975]

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

[@samnihao6943]

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

[@samnihao6943]

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

[@ivantut9210]

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

[@nikiv2688]

Полезно

[@AntonSkworc]

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

[@user-bd3ij4op5k]

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

[@MisterGenix]

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

[@markshevchenko]

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

[@markshevchenko]

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

[@MisterGenix]

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

[@crazy_fedor]

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

[@vborovikov]

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

[@VasilenkoYaroslav]

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

[@markshevchenko]

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

[@SugarDiDi]

C# Рулит!

[@shaqull]

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

[@MyPomoshnik]

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

[@user-bw9kk2se7q]

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

[@alexgrinberg1888]

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

[@hysapod]

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

[@milovidov42]

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

[@superspy2008]

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

[@user-hc9qs6fj7m]

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

[@user-wu5id5cx8v]

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

[@timur2887]

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

[@TinTaBraSS777]

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

[@maksimsergeevich5939]

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

[@AlekseiChel]

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

[@samnihao6943]

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

[@maksimsergeevich5939]

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

[@samnihao6943]

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

[@maksimsergeevich5939]

@@samnihao6943xD