[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Total Knowledge вопросы для оценки
By the way, one thing in terms of clustering that would
be fairly easy to implement in CPPServ is balancing inside
of web server front end.
If web server module tracks sessions and makes sure to
direct requests that belong to same session to same CPPServ
instance, there is no need to implement session migration,
and at the same time it gives sufficient distribution of load
when service usage is so high that such distribution is really
needed.
This does require single webserver to be point of entry into
cluster, but if web serving is the only thing it does, it should
not be a problem - it will either serve static pages, or will
simply forward data between client and CPPServ.
Ilya A. Volynets-Evenbakh wrote:
Konstantin,
As I already mentioned I plan on having CSP (C++ Server Pages)
implemented. I don't see however why it would require on-the-fly
compilation. I rather think CSPs will be pre-compiled, and deployed
on server as pure code (I generally don't buy the argument that it
slows down development).
As for TagLibs and STRUTS analogs that would need to be built on
top of CPPServ, I was thinking myself about something like that and
was talking to various people about it, but it never went far. If as a
result of working on UU project we come up with generic web
development library, I'm all for it. We'll ship it as semi-separate
product
along-side with CPPServ.
Addressing clustering issues is a challenge, and not an easy one.
There are few possibilities that I see here.
1. We do nothing inside CPPServ. Instead we go "easy" route -
we let DNS round-robin between servers, and hope same user
will be connecting to same server during session this way.
2. We can modify CPPServ to support things like session migration,
and whatever else you feel is nessesary to get the thing done
Right Way (TM). Then we can use "real" load balancer in front of
cluster.
I am open to more suggestions as to what and how needs to be
done to achieve this.
To summarise: View CPPServ development as integral part of UU
project while making your time estimates.
Konstantin Kosinsky wrote:
Добрый день!
При базовой оценке проекта, мы рассмотрели предлагаемую архитектуру
системы, так как архитектурные решения всегда очень сильно влияют на
трудоемкость реализации проекта. В связи с этим мы оценили идейную
архитектуру и качество кода предлагаемого сервера приложений CppServ.
Как и во время обсуждения, основную проблему составляют
инфраструктурные моменты сервера приложений, т.к. ServletContainer –
это не только реализация базового класса для создания сервлетов, и
если рассматривать его в таком ключе, то мы повторим все ошибки и
проблемы решение которых в свое время привело к появлению огромного
числа сопутствующих технологий.
Первой из них является формирование HTML-кода возвращаемого
пользователю, т.к. формирование HTML посредством вывода в поток
вывода (aka out.println(“….”) в Java) приведет в сложности разработки
и развития качественного пользовательского UI. По этому использование
шаблонных технологий является просто необходимым. Тут возможно
несколько вариантов:
1. Реализация аналога JSP
2. Использование XML/XSLT
3. Использование собственного движка шаблонов.
При этом стоит учесть, что написание простого движка для вариантов 1
или 3, не пройдет, т.к. постепенно нужно будет добавлять все более и
более мощные средства, что выльется в собственный немаленький проект
либо мы упремся в возможность этих средств. Что касается возможностей
для реализации нужно либо будет реализовывать сложные парсеры/языки
шаблонов/аналогов JSP (с добавлением неких аналогов TagLibs/Struts и
т.д.), либо для вариант с JSP реализовывать генерацию Cpp класса на
лету и его компиляцию, а как известно компиляция C\C++ кода является
одной из самых долгих. В результате основное время формирования
страницы будет посвящено разбора шаблонов и генерации представления,
а не выполнению бизнес-логики, что минимизирует полезность
использования компилируемого кода, и в тоже время потребует
достаточно много времени на разработку платформы.
Вторая проблема заключается в низкой «поддерживаемости» и
«развиваемости» текущей реализации CppServ (при этом мы может
отметить неплохое качество кода как такового). Что приведет к
необходимости достаточно большого количества как архитектурного, так
и на уровне реализации рефакторинга и дописывания данной системы,
иначе обеспечить удобство разработки системы будет очень тяжело
обеспечить.
Третья проблема заключается в том, что при декларированных пожеланиях
о масштабировании на несколько хостов в текущую архитектуру CppServ
это не заложено даже в зачаточном виде. А это может привести
практически к невозможности его реализации на поздних стадиях.
По этому мы видим три варианта дальнейшего обсуждения:
1. Мы проводим серьезное архитектурное перепроектирование и
рефакторинг, а в последствии реализацию CppServ ядра. Что потребует
существенных затрат времени и ресурсов.
2. Мы выбираем более приспособленную к Web-разработке, но в тоже
время функционально достаточную технологию, например PHP/Perl/Python
и т.д. Здесь следуют отметить, что если будет необходимо дописать
некоторые узкие с точки зрения производительности моменты на C++.
Описанные веще технологии уже имеют достаточно развитую ООП-парадигму
(которая конечно несколько уступает C++) и поэтому позволят
качественно отделить логику и представление. Разговор о использовании
Java (некоторых кусков J2EE) здесь не идет, т.к. она слишком
тяжеловесна для данной задачи.
Этот вариант потребует существенно меньше трудозатрат при обеспечении
того же уровня QoS.
3. Опираться на существующую инфраструктуру и «давить кодом»
реализуя нужную функциональность, что приведет к большому кол-ву
тяжело поддерживаемого кода, и при кажущейся простоте разработке, к
сложности разработки на более поздних стадиях.
Кроме того, мы не согласны на это вариант, так как он не
соответствует нашим представлениям о разработке ПО. По этому,
стоимость такого варианта мы даже не будет обсуждать.
Выбор одного из этих вариантов необходим для выполнения даже
приблизительной оценки.