HolyWar...
Дилемма прикладного программирования...
Итак дано:
Крупный веб портал - крупный с множеством сервисов. Он разделён на множество кусков которые между собой связаны через кривое колено, хотя админятся из одного бэкофиса.
Так вот - стоит задача доработки/развития отдельных кусков портала в целом и всего портала в частности. Но тут возникает проблема разобщенности кода. Тоесть кусочек логики из одного куска вдруг требуется в другом куске - выглядит это физическим переносом (читай копипастом) контролов, страниц и пр. Как результат нарастает избыточность кода а при обновлении логики - приходится выискивать и апгрейдить туеву хучу кусков по совершенно разнообразным проектам.
С другой стороны такой "бардак" позволяет довольно эффективно реализовать масштабируемость и устойчивость проекта в целом. Разные куски (читай сервисы) находятся на физически разных серверах и соответственно до некоторой степени ресурсонезависимы и отказоустойчивы.
Есть мысль о том чтобы произвести консолидацию системы в целом - тоесть собрать все куски в одно место, дабы не потерять в производительности, на одном для всех серверов дисковом пространстве. Таким образом удастся сохранить масштабируемость (разные сервисы по прежнему будут крутится на разных физических серверах), но работа с кодом и обновления станут сильно проще. Недостатком такой системы является большая чувствительность к отказам (отказ внешнего хранилища влечет за собой полный отказ системы - это самое тонкое место).
Второй момент он почти такой же как первый.
Он исходит из особенностей ASP.NET в целом.
Итак есть два пути первый - когда на каждой страничке (.aspx) находится весь исчерпывающий HTML код + к ней подключаются внешние контролы - если это необходимо. Также к каждой страничке прилагается файл с кодом (.aspx.cs) в котором хранятся все "скрипты. Это достаточно удобно - можно вносить изменения "на лету". При обращении к странице вебсервер собирает все необходимые ресурсы (код, контролы, скрипты) компилирует их в законченную форму, засовывает её в рабочий AppPool (Пул), обрабатывает её и выдаёт результат. Вебсервер хранит эту форму какоето время таким образом наиболее часто запрашиваемые страницы обрабатываются быстро. Однако скомпилированная форма хранится в пуле не вечно, более того не так уж и долго, таким образом нечасто требуемые страницы обрабатываются заметно дольше.
Есть и второй путь - когда все скрипты вся логика и вся остальная требуха скомпилирована заранее, в несколько завершенных библиотек (.dll). Вебсервер не компилирует уже ничего, он засовывает в свою уже законченную форму в пул и там хранит почти вечно как базовую систему обработки. Таким образом общая скорость обработки отдельно взятого запроса возрастает, однако поскольку вебсерверу приходится переваривать значительно более большой откомпилированный кусок части которого весьма вероятно используются довольно редко - возрастают требования к аппаратной части (в частности к мощности процессора и размеру оперативной памяти). Такая система предъявляет большие требования к написанию кода дабы сводить к минимуму малоиспользуемые или вообще ненужные части. А также добавляет отдельные трудности при размещении системы более чем на одном физическом сервере (усложняется масштабируемость). Поскольку ядро системы едино то его нельзя править на лету в отдельных кусках, только замена целиком, сие однако не налагает сколь нибудь существенных проблем с доработкой и/или правкой ядра.
так вот собственно весь холивар в чём? - что выбрать консолидацию в единое ядро (моно полярность) или наоборот дробную структуру (мульти полярность) ????
Итак дано:
Крупный веб портал - крупный с множеством сервисов. Он разделён на множество кусков которые между собой связаны через кривое колено, хотя админятся из одного бэкофиса.
Так вот - стоит задача доработки/развития отдельных кусков портала в целом и всего портала в частности. Но тут возникает проблема разобщенности кода. Тоесть кусочек логики из одного куска вдруг требуется в другом куске - выглядит это физическим переносом (читай копипастом) контролов, страниц и пр. Как результат нарастает избыточность кода а при обновлении логики - приходится выискивать и апгрейдить туеву хучу кусков по совершенно разнообразным проектам.
С другой стороны такой "бардак" позволяет довольно эффективно реализовать масштабируемость и устойчивость проекта в целом. Разные куски (читай сервисы) находятся на физически разных серверах и соответственно до некоторой степени ресурсонезависимы и отказоустойчивы.
Есть мысль о том чтобы произвести консолидацию системы в целом - тоесть собрать все куски в одно место, дабы не потерять в производительности, на одном для всех серверов дисковом пространстве. Таким образом удастся сохранить масштабируемость (разные сервисы по прежнему будут крутится на разных физических серверах), но работа с кодом и обновления станут сильно проще. Недостатком такой системы является большая чувствительность к отказам (отказ внешнего хранилища влечет за собой полный отказ системы - это самое тонкое место).
Второй момент он почти такой же как первый.
Он исходит из особенностей ASP.NET в целом.
Итак есть два пути первый - когда на каждой страничке (.aspx) находится весь исчерпывающий HTML код + к ней подключаются внешние контролы - если это необходимо. Также к каждой страничке прилагается файл с кодом (.aspx.cs) в котором хранятся все "скрипты. Это достаточно удобно - можно вносить изменения "на лету". При обращении к странице вебсервер собирает все необходимые ресурсы (код, контролы, скрипты) компилирует их в законченную форму, засовывает её в рабочий AppPool (Пул), обрабатывает её и выдаёт результат. Вебсервер хранит эту форму какоето время таким образом наиболее часто запрашиваемые страницы обрабатываются быстро. Однако скомпилированная форма хранится в пуле не вечно, более того не так уж и долго, таким образом нечасто требуемые страницы обрабатываются заметно дольше.
Есть и второй путь - когда все скрипты вся логика и вся остальная требуха скомпилирована заранее, в несколько завершенных библиотек (.dll). Вебсервер не компилирует уже ничего, он засовывает в свою уже законченную форму в пул и там хранит почти вечно как базовую систему обработки. Таким образом общая скорость обработки отдельно взятого запроса возрастает, однако поскольку вебсерверу приходится переваривать значительно более большой откомпилированный кусок части которого весьма вероятно используются довольно редко - возрастают требования к аппаратной части (в частности к мощности процессора и размеру оперативной памяти). Такая система предъявляет большие требования к написанию кода дабы сводить к минимуму малоиспользуемые или вообще ненужные части. А также добавляет отдельные трудности при размещении системы более чем на одном физическом сервере (усложняется масштабируемость). Поскольку ядро системы едино то его нельзя править на лету в отдельных кусках, только замена целиком, сие однако не налагает сколь нибудь существенных проблем с доработкой и/или правкой ядра.
так вот собственно весь холивар в чём? - что выбрать консолидацию в единое ядро (моно полярность) или наоборот дробную структуру (мульти полярность) ????