Pull to refresh

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 раз в год, чем два списка раз в два года.

т.е. вы предлагаете с каждым выходом новой мажорной версии переписывать все имеющиеся проекты на использование новых фич? ябнестал....

Нет, не предлогаю. Я предлогаю давать возможность использавть новые фичи в новом коде старых проектов. Делайвыводыправильно.

Привет, у меня есть два вопроса:

  1. Не совсем понятно одно место. У вас был монолит, а потом… бах, и сразу переход к 16 сервисам?
  2. Были ли какие проблемы с Ben.BlockingDetector, или просто вставили либу, и начали логи собирать?

Ben.BlockingDetector

+1 Тоже хотел бы побольше относительно этого вопроса узнать.

  1. У нас "модульный" монолит, в нём 200 проектов, 16 запускаемых.

    Раньше весь веб и все бэкграунд джобы были в одном сайте (IIS application pool). Затем году в 2016 этот огромный сайт разделили на раздельные запускаемые проекты-сайтики и джобы, всего их около 30 получилось. До разделения оно структурировалось при помощи aspnet areas. Например, подсистема доставки работала по условному урлу backoffice.dodopizza.ru/delivery, а после разделения стала обслуживаться отдельным app pool на урле delivery.dodopizza.ru

    До 2022 дожили 16 запускаемых проектов(бинарей), которые собираются из одной монолитной кодовой базы и ходят в одну базу данных.

  2. Вставили либу, начали логи собирать. Затем по логам пописали KQL запросы, сагрегировали топ блокирующих методов и пошли их чинить.

UFO just landed and posted this here

Хотелось бы, но с нашим монолитом так не получится, as is код оттуда не вынести - слишком большая связность. Каждый вынос домена из монолита это творческое переосмысление этого домена и по сути написание кода с нуля, мало что получается переиспользовать. Но были и сервисы которые практически неизменными вышли.

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

UFO just landed and posted this here

Поясните, пожалуйста, момент c

По возможности отказываемся от Autofac в пользу Microsoft.Extensions.DependencyInjection

почему к этому пришли? AF работает в Core, возможностей предоставляет больше чем MS DI.
Плюс их же можно подружить друг с другом.

Сейчас как раз думаем над моментом использования Autofac в Core.

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

Sign up to leave a comment.