Экономия на дороге не валяется. Мы переведем только нагруженные сервисы с активной разработкой, в них будет четко виден эффект. И их же потом на .NET 8 переведем, сразу же как он выйдет.
Хотелось бы, но с нашим монолитом так не получится, as is код оттуда не вынести - слишком большая связность. Каждый вынос домена из монолита это творческое переосмысление этого домена и по сути написание кода с нуля, мало что получается переиспользовать. Но были и сервисы которые практически неизменными вышли.
В общем, могу себе представить такое для какого-то сферического идеального модульного монолита в вакууме, в котором код писали сразу же с учетом такого будущего выделения сервисов.
У нас "модульный" монолит, в нём 200 проектов, 16 запускаемых.
Раньше весь веб и все бэкграунд джобы были в одном сайте (IIS application pool). Затем году в 2016 этот огромный сайт разделили на раздельные запускаемые проекты-сайтики и джобы, всего их около 30 получилось. До разделения оно структурировалось при помощи aspnet areas. Например, подсистема доставки работала по условному урлу backoffice.dodopizza.ru/delivery, а после разделения стала обслуживаться отдельным app pool на урле delivery.dodopizza.ru
До 2022 дожили 16 запускаемых проектов(бинарей), которые собираются из одной монолитной кодовой базы и ходят в одну базу данных.
Вставили либу, начали логи собирать. Затем по логам пописали KQL запросы, сагрегировали топ блокирующих методов и пошли их чинить.
Пока нет. Это легко реализовать в наших условиях (наш бэкенд всегда знает, когда пицца клиента готова), но пока у нас нет мобильного приложения, а мобильные браузеры ещё не умеют в browser push.
ну, я бы в такую армию не пошел бы. вообще, мне кажется, такой метод управления подчиненными работает только в маргинальной среде, где люди не понимают(и не хотят понимать) человеческие слова. напоминает дрессировку.
У нас во всех сервисах кроме монолита MS DI. Фичи autofac нам не нужны, да и медленнее он(https://github.com/danielpalme/IocPerformance). В общем, у нас он лишний.
https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/
Экономия на дороге не валяется. Мы переведем только нагруженные сервисы с активной разработкой, в них будет четко виден эффект. И их же потом на .NET 8 переведем, сразу же как он выйдет.
Хотелось бы, но с нашим монолитом так не получится, as is код оттуда не вынести - слишком большая связность. Каждый вынос домена из монолита это творческое переосмысление этого домена и по сути написание кода с нуля, мало что получается переиспользовать. Но были и сервисы которые практически неизменными вышли.
В общем, могу себе представить такое для какого-то сферического идеального модульного монолита в вакууме, в котором код писали сразу же с учетом такого будущего выделения сервисов.
У нас "модульный" монолит, в нём 200 проектов, 16 запускаемых.
Раньше весь веб и все бэкграунд джобы были в одном сайте (IIS application pool). Затем году в 2016 этот огромный сайт разделили на раздельные запускаемые проекты-сайтики и джобы, всего их около 30 получилось. До разделения оно структурировалось при помощи aspnet areas. Например, подсистема доставки работала по условному урлу backoffice.dodopizza.ru/delivery, а после разделения стала обслуживаться отдельным app pool на урле delivery.dodopizza.ru
До 2022 дожили 16 запускаемых проектов(бинарей), которые собираются из одной монолитной кодовой базы и ходят в одну базу данных.
Вставили либу, начали логи собирать. Затем по логам пописали KQL запросы, сагрегировали топ блокирующих методов и пошли их чинить.
Извлекли, конечно. В целом, мы сейчас гораздо серьезнее относимся к техдолгу.
На .NET 7 переедем, да. Инвестиции на переезд 6.0 -> 7.0 будут копеечные.
Точно, спасибо, сейчас добавлю