Вибір інструментарію для написання middlware-сервера. М-м-м-м?

Обговорюється створення деякого проєкту, в числі складових частин якого передбачається такий собі middlware-сервер (application server? чи як би то краще означити...) в якості проміжного шару між SQL-сервером і HTTP-сервером. На цьому рівні буде оброблятись «бізнес-логіка».

Проєкт має бути високонагружений, але коли виникне ця висока нагрузка — хтозна... ймовірно, далеко не одразу. Натомість швидкість запуску ядра системи та можливість уточнення і відладки клієнтських інтерфейсів — видається ключовим параметром на першому етапі розробки.

Відтак, зробив коротесенький огляд можливостей для потенційного замовника. Може, ще кому було би цікаво. Тема, звісно, вкрай дискусійна. Я — представляю точку зору perl-розробника.

Можливі варіянти бачу наступні.

Perl + C/C++

Цей варіянт мені найближчий, звісно ж. Швидкодію завжли можна буде забезпечити переписуванням критичних фраґментів коду на C, инші відомі недоліки перла — проблеми з графічним інтерфейсом і зі створенням автономного бінарного коду — несуттєві для нашої задачі. Чув я і про «протікання thread’ів» у перлі — ну, тут можна обійтись і fork’ами (а коли притисне — перескакувати на C, знову ж таки). Попри те, що останнім часом perl дещо втрачає популярність — маю колеґ саме в perl-середовищі — так що буде з ким знайомим-перевіреним почати роботу. Ще один плюс перла — багатющий наявний набір бібліотек.

Всі инші компоненти системи, звісно ж, також пишуться на цій зв’язці інструментів.

PHP (+ C/C++ ?)

Я не шанувальник цієї системи — мені PHP видається чимось типу VisualBasic’a для серверів — все в ньому є, але якось трохи попсово... І популярність PHP — радше підтверджує цю точку зору. Так що я би не хотів робити сервер (навіть Web-сервер) на основі PHP — є, вважаю, кращі варіянти.

Java, Python, C#, Ruby...

Хороші і поважні системи з одним, як для мене, суттєвим недоліком — порівняно велика складність їх освоєння, по відчуттю, не окупляється якимись принциповими перевагами над відомими мені Perl/C/PHP/JS.

node.JS + C/C++

node.JS — це автономний runtime-движок для мови з JS-синтаксисом, розрахований, на відміну від бібліотек типу AJAX чи jQuery, для роботи будь-де — зокрема, на серверах. Для довідки — бо це зовсім нова система:

nodejs.ru
nodejs.org
habrahabr.ru/blogs/nodejs/118310

Node.JS, як знаю, стрімко набирає популярність. Очевидні плюси — легкість освоєння, оскільки сама по собі мова цієї системи — це загальновідомий JS, і, відповідно, можливість пошуку нових розробників на підтримку такої системи — серед будь-яких веб-програмістів, скажімо так, Ну й, звісно, уніфікація коду клієнтської та серверної частин.

Недолік node.JS — новизна, ризик несподіваних проблем і того, що нові версії node.JS-движка можуть вимагати змін в існуючому прикладному коді.

***

Отже, резюме видається очевидним :-) Почати розробку з Perl’а, а далі визначитись з варіянтами розширення, в якості яких варто розглядати C/С++ і/або node.JS.

А що б инше Ви хотіли почути від perl-розробника? :-)

P.S. Чи я все переплутав?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Якщо ж все таки вирішите на Perl
То декілька напрямків
на рахунок middleware:
PSGI + Plack(Starman/twiggy)
замість threads:
AnyEvent/Coro/etc
ну і різні фреймворки для «легкого входження»:

Mojolicious/Dancer/cgiapp/etc

є з чого вибрати ;)

Ну, «легко входити» в perl не маю потреби, бо я вже в нього увійшов, дужже навіть давно. А пропоновані стандартні рішення — гляну, спасибі.

еще варианты — ringo.js — (нод в профиль )
twisted ( предок нода на python )
akka — суровая вещ с агентами и прочими наворочеными вещами. Scala или Java.

mina.apache.org — на Java

очень рекомендую смотреть на уже готовые евент серверы — есть шансы крепко сократить время разработки и не изобретать сложный велосипед.

p.s. ruby eventmachine забыл я еще

Перші Ваші варіянти виглядають надто екзотично, як на мій смак. А от на рахунок евент-серверів — спасибі, подивлюсь.

постарался просто максимально охватить варианты.
расскажете потом о сделаном выборе и мотивах?

Неодмінно розкажу — було би про що...

event-серверы подойдут идеально, если нет или мало блокирующих операций, вроде обращения к БД (с асинхронными клиентскими библиотеками БД все не очень хорошо). У меня везде куча twisted серверов (это как раз не экзотика, а очень распространенная и стабильная штуковина, которую, правда, часто несправедливо критикуют за сложность программирования). Насколько я знаю, в перле с этим тоже все хорошо.

Упс... Йдеться про middlware між HTTP та SQL (писав про це одразу ж) — так що звертань до БД там буде багато, причому звертання будуть транзакційними. М-м-м-м?

тогда смотреть в сторону вещей типа akka или mina. на java\scala все хорошо с пулингом запросов в бд и подобными вещами

Поки що, все ж, я схильний спершу відновити свій С’шний досвід. Бо маючи перлову базу — шукаю, перш за все, не спрощень-зручностей (в перлі мені все й так дуже просто і зручно), але — ефективности. А далі — буде видно.

Еще раз, а кто сказал, что на перле будет неэффективно. Чтобы такое сказать, надо сначала ПОМЕРЯТЬ!

Так! Організація розробки, наскільки розумію, дозволяє спершу зробити простеньке perl’ове ядро — а потім вже визначитись з його розширенням і/або заміною.

java решения очень быстрые — так предубеждения о эфективности тут не должны стеснять.

вообще конечто — прототип покажет .

Тогда скорее джава. Нормальные треды, GC. Квалифицированно про перл сказать не могу. Мне кажется, не стоит торопиться от него отказываться.

Я й не спішу відмовлятись від перла, що характерно. До речи, про GC — питання від людини, яка з С не мала справ уже років 15 — перепрошую за банальність. Яку взяти бібліотеку на C (можна, в принципі, й на C++, але я б волів зупинитись саме на С) — щоб не паритись з malloc’ами при вводі-виводі? Бо розмір рядків наперед невідомий :-) Може, підкажете?

можно взять apr (apache portable runtime), там все в pool’ах

А вообще C, C++ наихудший вариант. С тредами секс будет, с памятью, асинхронное программирование ок, есть libevent, но опять же библиотеки бд синхронные, т.е. опять треды.

Ясно, спасибі. Хоч знатиму, на що дивитись при знайомстві з C’шними бібліотеками. А проблеми — вони самі проявляться, і навіть скоро, сподіваюсь.

python, c# или джава. Лично мне в этом списке больше импонирует джава. С питоном можно будет отгрести проблем с производительностью к примеру в зависимости от логики.
перл — теряет популярность, выпадает из мэйнстрима и может оказаться тупиковым направлением

node.js — недостаточно matured платформа имхо намного ближе к экзотике чем к реальным вещам.

на сегодня уже существуют достаточно крупные системы построены на node.js, он работает намного быстрее других вариантов и удобнее

Очень интересно было бы увидеть бенчмарки, ссылки на внедрения, и аргументацию про удобство.

Якщо Java — то чому не сам по собі C/C++? Чи можете арґументувати?

Кросплатформність в цій задачі не має значення, особистого інтересу до джави в замовника чи розробника — також нема ніякого.

Потому что более удачный компромис между производителностью и продуктивностью + намного-намного более развитая инфраструктура для веб дева.

Вдалий чи невдалий компроміс — оцінка доволі суб’єктивна. Мене продуктивність розробки і ефективність коду на C, наскільки можу судити, цілком влаштовує.

Що ж до інфраструктури для веб-розробника — вона в цій задачі не має значення. оскільки йдеться не про веб-сервер, а про бізнес-логіку (а для веб-частини проєкту є перл з прекрасною відповідною інфраструктурою).

Ну если тебя устраивает продуктивность си, мне больше сказать нечего.

Обычно middleware I/O bound, а не CPU-bound, поэтому скорость выполнения собственно кода не так важна. Сам использую twisted, но на вашем месте брал перл с каким-нибудь POE или Event, или что там у вас есть, и не боялся бы проблем с наличием перловиков. Их может и меньше сейчас, зато те, кто есть — матерые дядьки.


Java, Python, C#, Ruby...

Хороші і поважні системи з одним, як для мене, суттєвим недоліком — порівняно велика складність їх освоєнн

Як на мене, Python та Ruby мають найменьший поріг входу

Якщо стартувати з нуля — цілком можливо. Але моя база — perl + C.

І швидкість у цих систем, здається, не найвища... Чув добре про ruby, але, якщо предметно — не бачу арґументів, щоб міґрувати саме в ці системи.

nodejs. «новым» он был весной прошлого года. с node Вы забудете про кошмар тредов.

а перл в 2011 можно навсегда безопасно забыть. ничего интересного там давно не происходит. это legacy, увы.

Що node.JS поступово стабілізується — я розумію і маю на увазі цю систему. Але чим пізніше за неї взятись — тим стабільнішою вона буде, таки ж.

А що в перлі не діється нічого цікавого — так мені нічого цікавого і не треба, досить щоб програми працювали, як слід :-)

у node 2 ветки. если сидеть на stable и читать gmane.comp.lang.javascript.nodejs, то ничего плохого *внезапно* не случится.

насчет интересности: в 37 сигналов, по поводу выбора технологий клевещут, что «интересная» привлекает интересных девелоперов. а "стабильность"—это vba 6, там точно ничего уже не поменяется и девелоперы соответствующие.

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

Ну, знаю по багаторічному досвіду роботи, що перлові пакети підтримують всі необхідні технології і знаю цілком порядних perl-девелоперів, скажімо так. Тому єдина серйозна заувага до перла — продуктивність коду, яка, як я й писав, лікується або C’шними вставками, або, дійсно, повним переходом на C/C++ (наскільки можу судити про node.JS — це теж варіянт). Словом, прийде час — розберусь з переходом. Але ще не вже.

по-моему, если есть возможность взять что-то (для себя) новое, то этим лучше воспользоваться.

кроме того, когда перловый код придется отдавать поддерживать, это значит что придется искать готового перл читать, что в наше время непросто. (тут я всегда вспоминаю Randal Schwartz (тот что ведет floss weekly), который еле-еле нашел себе место, где кому-то все еще был нужен перловый хакер. Не самый последний чувак к комьюнити.)

Щодо проблем з кандидатами і вакансіями на perl-розробку — я в курсі :-( Це дійсно серйозний арґумент, згода.

btw, в последней технометрии обсуждается (правда, довольно поверхностно) как переписывали Utah Education Network из coldfusion на перл, но, в итоге, выкинули перловый код и остановились на nodejs:

itc.conversationsnetwork.org/...detail4911.html

Повчальна історія, спасибі. Тільки балакає той хлоп він якось по-бусурманськи... А викидати код посеред проєкту — я й сам вмію :-)

Підписатись на коментарі