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

Подписаться 1,4 тыс.

Просмотров 29 тыс.

50% 1

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

Опубликовано:

4 дек 2019

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 35

@ivantut9210 2 года назад

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

@grafbcn 2 года назад

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

@konstantinkav.9975 3 года назад

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

@samnihao6943 3 года назад

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

@samnihao6943 3 года назад

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

@nikiv2688 3 года назад

Полезно

@AntonSkworc 3 года назад

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

@user-bd3ij4op5k 3 года назад

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

@VasilenkoYaroslav 4 года назад

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

@markshevchenko 4 года назад

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

@crazy_fedor Год назад

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

@MisterGenix 4 года назад

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

@markshevchenko 4 года назад

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

@markshevchenko 4 года назад

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

@MisterGenix 4 года назад

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

@vborovikov Год назад

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

@SugarDiDi Год назад

C# Рулит!

@shaqull Год назад

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

@MyPomoshnik Год назад

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

@user-bw9kk2se7q 4 года назад

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

@alexgrinberg1888 3 года назад

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

@hysapod 3 года назад

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

@milovidov42 4 года назад

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

@superspy2008 3 года назад

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

@user-hc9qs6fj7m 2 года назад

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

@user-wu5id5cx8v Год назад

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