"Зачем все это?" — спрашиваю я.
"Производительность, вестимо, — отвечает архитектор, глядя на меня со слабо скрываемым превосходством. — Мы можем запустить каждый компонент на обработку в своем собственном блоке. Если мощности блока не хватит, мы запросто добавим еще парочку, чтобы сбалансировать нагрузку". Теперь он уже и не пытается утаить самолюбования вперемешку с удивлением по поводу того, что я вообще посмел открыть рот.
Между тем передо мной возникает любопытная дилемма: заявить парню все сразу и выставить за дверь либо не торопясь показать ему дорогу к светлому будущему. Последнее во всех смыслах выгоднее, но гораздо хлопотнее, поскольку архитектор обычнослишком пленен собственными иллюзиями и вряд ли легко с ними расстанется.
Безусловно, все это просто замечательно, но... Хотя многие стороны жизни распределенных объектов действительно приобретают искомую прозрачность, это явно не относится к аспектам производительности. Наш герой-архитектор осуществил распределение объектов, как ему казалось, исходя из соображений производительности, но на самом деле выбор подобной структуры наверняка снизит эффективность системы и существенно усложнит процессы ее разработки и практического внедрения.
(C) Фаулер
Posts
6 comments:
Эту штуку ещё вычитал пару лет назад. И я её практически наизусть повторял, когда сейчас читал.
Благо у меня хороший учитель был в то время. Замечательные слова, которых и сейчас придерживаюсь:
* Написать систему может каждый, а написать её просто может только проффесионал.
С дядькой Фаулером полностью согласен.
Там как раз проблема в производительности и будет. и ни одним добавлением сервака проблему не решишь, если за одну обработку страницы у тебя вызывается 5 сервисов по сети причём неявно.
Нельзя взять горстку объектов и разбросать их по сети. Лучше на одной машине скомпоновать в одном домене, и добавлять машины, если буду проблемы с производительностью. Это дальше фаулер описывает. Я по памяти.
хорошая память!
А можно для нечитавших Фаулера и для тех, кто не является мегааццким архитектором, разложить по полочкам (желательно на примере), в чем именно заключался подход "архитектора" из книги и в чем его ошибка.. м?
Ты помнишь, 99 веб сервис проектов в студии от индусов? У них на любое действие был отдельный сервис. Работа с продуктами - вот вам, логирование - вот вам, аутентикация - ещё, управление категориями - вот вам. И если с каким-то сервисом проблемы в плане нагрузки - его выносят на отдельный сервак.
Конечная проблема: производительность системы. на вызов локально метода система тратит к примеру n единиц. На межпроцессорный вызов уже 100*n. Если по сети 1000*n. Цифры я с неба взял. Но они суть показывают. и если тебе для обработки страницы нужно сделать скажем 5 межсерверных вызовов - уже можно хоронить аппликацию.
Мне это наши проекты все очень напоминает )
Post a Comment