Comments 19
Спасибо!
Какие-то уроки после этого веселья извлекли?
На net 7.0 переезжать будете, или "оно и так работает"?
Извлекли, конечно. В целом, мы сейчас гораздо серьезнее относимся к техдолгу.
На .NET 7 переедем, да. Инвестиции на переезд 6.0 -> 7.0 будут копеечные.
А есть ли смысл переезжать на каждый новый релиз? NET6 так-то LTS, и переходить с него надо на следующий LTS имхо.
https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/
Экономия на дороге не валяется. Мы переведем только нагруженные сервисы с активной разработкой, в них будет четко виден эффект. И их же потом на .NET 8 переведем, сразу же как он выйдет.
IMHO, переходить надо на все major версии сразу. Во-первых, улучшения производительности происходят в каждой версии. Во-вторых, новые фичи всегда сладки, работа с новешими технологиями помогает удержать разработчиков. В-третьих, гораздо проще изучить список breaking changes раз в год, чем два списка раз в два года.
- Не совсем понятно одно место. У вас был монолит, а потом… бах, и сразу переход к 16 сервисам?
- Были ли какие проблемы с Ben.BlockingDetector, или просто вставили либу, и начали логи собирать?
Ben.BlockingDetector
+1 Тоже хотел бы побольше относительно этого вопроса узнать.
У нас "модульный" монолит, в нём 200 проектов, 16 запускаемых.
Раньше весь веб и все бэкграунд джобы были в одном сайте (IIS application pool). Затем году в 2016 этот огромный сайт разделили на раздельные запускаемые проекты-сайтики и джобы, всего их около 30 получилось. До разделения оно структурировалось при помощи aspnet areas. Например, подсистема доставки работала по условному урлу backoffice.dodopizza.ru/delivery, а после разделения стала обслуживаться отдельным app pool на урле delivery.dodopizza.ru
До 2022 дожили 16 запускаемых проектов(бинарей), которые собираются из одной монолитной кодовой базы и ходят в одну базу данных.
Вставили либу, начали логи собирать. Затем по логам пописали KQL запросы, сагрегировали топ блокирующих методов и пошли их чинить.
Хотелось бы, но с нашим монолитом так не получится, as is код оттуда не вынести - слишком большая связность. Каждый вынос домена из монолита это творческое переосмысление этого домена и по сути написание кода с нуля, мало что получается переиспользовать. Но были и сервисы которые практически неизменными вышли.
В общем, могу себе представить такое для какого-то сферического идеального модульного монолита в вакууме, в котором код писали сразу же с учетом такого будущего выделения сервисов.
Поясните, пожалуйста, момент c
По возможности отказываемся от Autofac в пользу Microsoft.Extensions.DependencyInjection
почему к этому пришли? AF работает в Core, возможностей предоставляет больше чем MS DI.
Плюс их же можно подружить друг с другом.
Сейчас как раз думаем над моментом использования Autofac в Core.
У нас во всех сервисах кроме монолита MS DI. Фичи autofac нам не нужны, да и медленнее он(https://github.com/danielpalme/IocPerformance). В общем, у нас он лишний.
Обилие фич аутофака позволяет усложнять код по самое "не могу". Для огромных монолитов это со временем может вырасти в "ещё одну проблему при рефакторинге". Пользуясь стандартным функционалом неткора прям начинаешь думать, а как бы сделать проще.
deleted
История о том, как мы монолит с .NET Framework на .NET 6 и Kubernetes переводили