Полностью согласен.
Скорость разработки для монолита сильно зависит от того как он написан, какая степень связанности компонентов в нем.
Более того в случаях если изменения придется "протащить" через все микро-сервисы, то в монолите это сделать в разы быстрее. Плюс не нужно будет продумывать порядок деплоя микросервисов.
В случае е
Плюс появляются риски сломать своими изменениями чужой продукт, так как ты не имеешь представления покрыт ли этот модуль тестами.
А в случаях ручного тестирования, ты дополнительно увеличиваешь скоуп регрессионного тестирования, следовательно сдвигаются сроки.
И как тогда переходить к деплою по мере готовности.
Насколько я понял, в вашем случае, приложение реконсилляции подключается в двум разным базам, проводит аналитику, и показывает разницу по-экземплярно?
В 3 из 4 случаев реконсилируются приложения WebApi vs WebApi, в оставшемся WebApi vs SQL, поскольку интерфейс не поддерживает бачевые методы, либо структура данных избыточна — большой оверхед на транспорт и сериализацию.
Если перед вами стоит задача реконсилировать SQL vs SQL и базы находятся на одном сервер, то проще и эффективнее написать SQL jobs. Но при таком подходе придется следить за изменениями в структуре БД, в этом плане использовать API с версиями намного проще.
Сериализация и вычисление хеша действительно быстрее прямолинейого множественного сравнения строк и чисел через AND?
Здесь больший фокус на универсальности, получается идентичная структура таблицы, одинаковый запрос на сравнение и константная стоимость хранения.
По факту большая часть ресурсов тратится на получение данных по HTTPS и десериализация объектов. Оверхед на функцию GetHashCode() минимальный (взгляните на ее код).
Реконсиляции — инструмент мониторинга целостности данных, а не способ устранения причины, почему данные разошлись. При этом ряд конфликтов (расхождений) действительно можно разрешить автоматически, но этим мы лечим следствие, а не причину.
То что вы описываете в комменте — способ устранение причины. Но конкретном случае мы не можем внести изменения в Dynamic CRM (Navision) и свести все к одному источнику данных.
1. монолитный Dynamic CRM, отвечающий за учет стока на складах и построение отчетов- 2. микросервисный Stock Service, отвечающий за общее число товаров на сайтах, кол-во доступных товаров для данного сайта и резервацию товаров пользователями.
С первой системой работает исключительно внутренний персонал, со второй покупатели через веб-сайты или мобильные приложения, следовательно изменения данных возможны с любой стороны.
Естественно обе системы связаны сервисом интеграции через Messages Queue, поскольку производительность приложений разная.
Что произойдет если кол-ва начнут расходиться 1. вы можете продать больше товаров, чем у вас есть на самом деле и как следствие потерять клиента 2. не распродать весь сток и тем самым нанести компании убытки
Для мониторинга подобных проблем как раз и пишется сервис реконсиляции, запускающийся каждый час.
Приложения написанные на .NET Core занимают значительно меньше оперативной памяти, в сравнении с .NET Framework и скорее всего такого выигрыша по памяти и CPU просто не будет (нет большого смысла оптимизировать память, когда сервис занимает 60 мб).
Как раз в Вашем случае эффект будет максимальный, так как переиспользуются одни и те же сборки.
Вы можете менять конфигурацию последовательно, оценивая вклад оптимизации на каждом шаге.
загрузка подписанных сборок в GAC
объединение сайтов в applicationPools
создание нативных образов для загруженных в GAC сборок
Поэтому хочется, чтобы bin папка была одна по сути, а субдомены цепляли свой персональный web.config
Касательно деплоя приложений: если содержимое папок bin ничем не отличается и вы не хотите каждый раз руками копировать недостающие сборки в папку bin, то самое простое это сделать symbol link через команду mklink.
Процесс деплоя менять не нужно. Идея состоит в том, чтобы придерживаться одного и того же номера версий сборок в своих сервисах, например:
AutoMapper 6.1.0
…
Microsoft.AspNet.WebApi.Client 5.2.3
Newtonsoft.Json 9.0.1
За счет этого и будет достигнут sharing между пулами и процессами. Однако если конкретному сервису потребуется специфичная версия, она будет загружена в специфичный домен и просто не будет шаринга.
Периодически нужно анализировать используемые сборки и помещать их в GAC
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Полностью согласен.
Скорость разработки для монолита сильно зависит от того как он написан, какая степень связанности компонентов в нем.
Более того в случаях если изменения придется "протащить" через все микро-сервисы, то в монолите это сделать в разы быстрее. Плюс не нужно будет продумывать порядок деплоя микросервисов.
В случае е
Плюс появляются риски сломать своими изменениями чужой продукт, так как ты не имеешь представления покрыт ли этот модуль тестами.
А в случаях ручного тестирования, ты дополнительно увеличиваешь скоуп регрессионного тестирования, следовательно сдвигаются сроки.
И как тогда переходить к деплою по мере готовности.
В 3 из 4 случаев реконсилируются приложения WebApi vs WebApi, в оставшемся WebApi vs SQL, поскольку интерфейс не поддерживает бачевые методы, либо структура данных избыточна — большой оверхед на транспорт и сериализацию.
Если перед вами стоит задача реконсилировать SQL vs SQL и базы находятся на одном сервер, то проще и эффективнее написать SQL jobs. Но при таком подходе придется следить за изменениями в структуре БД, в этом плане использовать API с версиями намного проще.
Здесь больший фокус на универсальности, получается идентичная структура таблицы, одинаковый запрос на сравнение и константная стоимость хранения.
По факту большая часть ресурсов тратится на получение данных по HTTPS и десериализация объектов. Оверхед на функцию GetHashCode() минимальный (взгляните на ее код).
Реконсиляции — инструмент мониторинга целостности данных, а не способ устранения причины, почему данные разошлись. При этом ряд конфликтов (расхождений) действительно можно разрешить автоматически, но этим мы лечим следствие, а не причину.
То что вы описываете в комменте — способ устранение причины. Но конкретном случае мы не можем внести изменения в Dynamic CRM (Navision) и свести все к одному источнику данных.
Допустим у Вас есть 2 системы:
1. монолитный Dynamic CRM, отвечающий за учет стока на складах и построение отчетов-
2. микросервисный Stock Service, отвечающий за общее число товаров на сайтах, кол-во доступных товаров для данного сайта и резервацию товаров пользователями.
С первой системой работает исключительно внутренний персонал, со второй покупатели через веб-сайты или мобильные приложения, следовательно изменения данных возможны с любой стороны.
Естественно обе системы связаны сервисом интеграции через Messages Queue, поскольку производительность приложений разная.
Что произойдет если кол-ва начнут расходиться
1. вы можете продать больше товаров, чем у вас есть на самом деле и как следствие потерять клиента
2. не распродать весь сток и тем самым нанести компании убытки
Для мониторинга подобных проблем как раз и пишется сервис реконсиляции, запускающийся каждый час.
Приложения написанные на .NET Core занимают значительно меньше оперативной памяти, в сравнении с .NET Framework и скорее всего такого выигрыша по памяти и CPU просто не будет (нет большого смысла оптимизировать память, когда сервис занимает 60 мб).
На stackoverflow есть интересный ответ на эту тему
Как раз в Вашем случае эффект будет максимальный, так как переиспользуются одни и те же сборки.
Вы можете менять конфигурацию последовательно, оценивая вклад оптимизации на каждом шаге.
загрузка подписанных сборок в GAC
объединение сайтов в applicationPools
создание нативных образов для загруженных в GAC сборок
Касательно деплоя приложений: если содержимое папок bin ничем не отличается и вы не хотите каждый раз руками копировать недостающие сборки в папку bin, то самое простое это сделать symbol link через команду mklink.
Процесс деплоя менять не нужно. Идея состоит в том, чтобы придерживаться одного и того же номера версий сборок в своих сервисах, например:
…
За счет этого и будет достигнут sharing между пулами и процессами. Однако если конкретному сервису потребуется специфичная версия, она будет загружена в специфичный домен и просто не будет шаринга.
Периодически нужно анализировать используемые сборки и помещать их в GAC