Посоветуйте технологии для back end

Всем привет.

Подскажите пожалуйста на чем на данный момент лучше писать серверную часть приложения?
Планируется несколько сотен тысяч клиентов (несколько десятков тысяч онлайн).
Сервер — AWS.
Технология обмена данными — сокеты.
задачи — мультипоточно обрабатывать запросы с базой и клиентом.
Если можно пожалуйста развернутый ответ — какие плюсы минусы и риски.
Спасибо.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Запасаюсь попкорном.... Сейчас начнется.... :-)

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

ЗЫ Сережа молодец©

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

То что вам 100% понадобиться:
1) Load balancer — чтобы распределять нагрузку между нодами, если уже на амазоне — рекомендую Elastic Load Balancer. Хотя, NGINX и HAProxy тоже хороши.
2) Мониторинг, в самом амазоне уже есть CloudWatch и он вам понадобиться чтобы мониторить нагрузку на CPU, RAM, HDD и делать auto scaling EC2 нод. Впрочем мониторинг это отдельная большая тема, но следить за утилизацией ресурсов и health системы это в современном мире must have.
3) Аггрегация логов, нужна чтобы траблшутить ошибки которые возникают на проде и не делать SSH на каждую ноду, тут стандартом является ELK стек (elastic, logstash, kibana)
4) Инструменты для provisioning, т.е. средства деплоя всей системы, при чем желательно как-то минимизировать даун тайм. Это еще одна большая тема, но советую посмортеть или на Docker или на Ansible это совершенно два разных инструмента, но они могут решать одну и ту же задачу деплоймента.
5) CI/CD Pipeline — тоже автоматизация сборки, тестирования, поддержка деплоймента без даунтаймов.

А язык... это уже не так важно, главное чтобы не .NET

scala + akka для смелых
java + netty для консервативных
php и node.js если надо по бырому
go если хочется быть модными

а да — наймите хорошего специалиста по инфраструктуре и dba а то охренеете

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

я бы присмотрелся к .net Core в паре с какимто постгре

или монгой. или редиской. или православным mysql. или всего понемногу :-)
Есть момент, SignalR обещают зарелизить только через пол-года. Еще есть вот такая штука github.com/Code-Sharp/WampSharp

+1 к редиске с постгре. Главное прямые руки.

сотен тысяч клиентов
Сервер — AWS.
Это дорого...

шо прямо сразу пару тысяч онлайн, с первого же дня?

Опять телегу ставят впереди лошади.

Технологии это инструменты, которые реализуют процессы. Определитесь сначала с процессами расширения функционала, тестирования, девелопмента и масштабирования. А потом уже выбирайте технологии исходя из имеющихся у вас ограничений по специалистам, бюджету и прочее.

COBOL Stack — провереный инструмент для решения многих задач.

OOP нет. Smalltalk only! ;)

JSF — лучшее, что можно было придумать в Java-мире, решает все проблемы одним взглядом.

Вот сейчас как будто обидно было.

1) Если сами не знаете как, то находите программиста, который похожее делал — не важно на чём: PHP/Python, Java/Scala, .NET, ... По возможности не используете старые проверенные языки, а не NodeJS/Ruby/Go/Rust/.., кроме случаев, когда найдёте гения в этой технологии и будете уверены, что сможете собрать команду на ней.
Пример вакансии от компании со схожими потребностями: slack.com/...3556/backend-web-engineer

2) Просите сделать прототип тех модулей, где вероятнее всего будет завтык. Проводите нагрузочное тестирование.

3) Нанимаете ему помощников с опытом в этой же технологии.

4) Сами работаете PM-ом, даёте проектировать и программировать специалистам.

Ruby постарше Java, если что.

Говорим Руби, подразумеваем рельсы.

несколько десятков тысяч онлайн
Какого размера меседжи? Какого плана логика будет отрабатывать? Сколько меседжей планируете получать в минуту? Какой СЛА по процессингу меседжа? Что за БД планируете использовать? Потому что из вашего описания не понятно где там хайлоад.

Як говориться, кожен кулик хвалить своє болото... мабуть і я похвалю своє, як для бекенда: TypeScript + Node.js + nginx (Слава Казахстану!).

Хоча у вас є така вимога як «багатопоточність», а сама Node.js є однопоточною, можна ж ставити її на багатоядерний процесор, і на декілька VPS. При указаних параметрах в темі, можна інтуїтивно припустити, що це буде точно менше десятка VPS із двома ядрами, та двома гігами оперативи. (Давати Node.js більше гіга на ядро — немає сенсу! По крайній мірі, поки що це так є).

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

З однопоточними системами головне не забувати що «усі чекають один процес, якщо він не прикритий промісом»...

Коли і в мене був аналогічний вибір (скоро на ДОУ зацінете бету «українського хабра» ;), я перечитав дуже багато інфи, в тому числі і за PHP7, і за Go, і за Java, і т.д.

Кажуть PHP7 приблизно в двічі стала швидшою й економнішою, в порівнянні із PHP 5.6. Але таки все ще залишилась система «при кожному запиті ініціалізувати заново усю конфігурацію, усю систему... щоб в кінці все це прибити...» — для чого цим користуватись, якщо можна взяти Node.js, яка початково вже має механізм, завдяки якому ініціалізація відбувається лише раз при старті процесу?

Читаючи за Node.js, не можна було не помітити негативних відгуків за хіпстерність нодівців, що занадто вони вже поспішають, і часто видають неякісний продукт. Мені теж так інколи здається, але думаю це через:
1. злегка ілюзорну простоту JavaScript
2. через відсутність у ній рідної статичної типізації
3. ну і власне, через її мега, чи навіть гіга! популярність (як не як, а JavaScript — це мова програмування, яка знаходиться в топ 1 по-порулярності).

На мою думку, TypeScript просто кардинально покращує якість JavaScript-продукту, додаючи ясність коду, статичну типізацію, можливість використовувати вже сьогодні фічі ES2016. Усно важко описати всі ті переваги, які дає TypeScript, це треба просто спробувати.

За Go читав також, читав що це не менш сира мова, ніж JavaScript на Node.js, хоча й продуктивність може показати на порядок кращу. Читав що самі елементарні речі дуже часто у gopher’ів викликають питання, бо і документація дуже абстрактна, і є відхід від звичного правила програмістів «не повторюй код», і занадто низький (системний) рівень треба програмувати.

За Java читав що її краще вибирати для інших цілей, не для веба... ну і взагалі щось вона почала серйозно здавати позиції, коли тепер і JavaScript має свою віртуальну машину, а тому може працювати і на бекенді, й навіть для desktop application. Ще десь там був (чи й залишається) шумок про затримку нових релізів Java, щось там Oracle підзабив на неї...

За Java читав що її краще вибирати для інших цілей, не для веба... ну і взагалі щось вона почала серйозно здавати позиції, коли тепер і JavaScript має свою віртуальну машину, а тому може працювати і на бекенді, й навіть для desktop application.
topsape.ru/files/116335.png

Що саме в цій цитаті не так, у вас є для цього аргументи?

А где вы читали, что Java не для веба?

А где вы читали, что Java не для веба?
А де ви читали що Java не для веба?
Синхронный перевод? :)
ну і взагалі щось вона почала серйозно здавати позиції
пруфи, де саме джава здає?
коли тепер і JavaScript має свою віртуальну машину, а тому може працювати і на бекенді, й навіть для desktop application
а то ж я думаю, чого останнім часом тільки й зустрічаються статті від продуктових компаній про те, як вдало і вчасно звалили з nodejs
Ще десь там був (чи й залишається) шумок про затримку нових релізів Java, щось там Oracle підзабив на неї...
не Java, a саме Java EE 8. тут якщо шановний пан не в курсі, то краще промовчати:
adtmag.com/...6/09/19/java-roadmap.aspx
blogs.oracle.com/...java/javaee8-javaone-2016
java.net/...archive/2016-08/message/4
тут якщо шановний пан не в курсі, то краще промовчати

Ви десь на цьому форумі спостерігаєте експертні дискусії? По-моєму, тут можна говорити «десь там я щось чув» і очікувати підтвердження цих слухів від таких експертів як ви, наприклад...

По-моєму, тут можна говорити «десь там я щось чув» і очікувати підтвердження цих слухів від таких експертів як ви, наприклад...
в коментарі вище наведені посилання на джерела, які повністю дискредитують ваші висловлювання щодо
Ще десь там був (чи й залишається) шумок про затримку нових релізів Java, щось там Oracle підзабив на неї...

якщо у вас є контаргументи — прошу, цікаво буде почитати, а якщо ж ні — тоді на вихід

Чувак, які «дискредитують», ти що у Верховній Раді, чи хоча б на вчительських зборах?

Де ти побачив, щоб я себе позиціонував як експерта по новинам про Java, щоб потім мене можна було «виводити на чисту воду»?

Де ти побачив, щоб я себе позиціонував як експерта по новинам про Java, щоб потім мене можна було «виводити на чисту воду»?

ніхто і не намагається сказати, що ти експерт

по новинам про Java,

просто якщо ти вже сказав, що джава здає позиції і оракл на її забив — тоді пруфи або ти сам знаєш

Ти ото як скажеш щось, то я і не знаю — сміятися чи плакати...

Ну я хоч якось аргументую своє бачення... Що не так конкретно із цим моїм коментарем, є аргументи?

А как там с матиматикой в JavaScript? Вечные проблемы в ней именно с матиматикой. Особенно люблю:
0.1 + 0.7 = 0.7999999999999999
0.1 + 0.2 — 0.2 = 0.10000000000000003

та вообще-то это везде :)

вернее — не от ЯП зависит.

даже в «Java puzzle» есть шютка-задачка на эту тему :)

Oops, таки да, пардон)
Просто в основном тролят JS этим)

Но в любом случае в JS проблем хватает. Для HL вообще как по мне лучше не использовать такие языки.
Как бы я не любил Java, но для HL лучшее пока что нету

Как бы я не любил Java, но для HL лучшее пока что нету
я бы не так сказал:

Java для HL — самый проверенный выбор. как готовить HL на Java — стопицот апробированных в реальных проектах рецептов.

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

«Но самое главное, главное с нами веселый детский смех»

то есть — команда и ее скилы.

но, не обязательно лучший в 2016ом году, для конкретного проекта.
Я не говорю что лучший в 2016ом году. Он и вправду самый проверенный выбор.
Вообще, если будет правильная архитектура то любой ЯП подойдет. Так что да, я согласен что все же команда и скилы важный аспект.
Oops, таки да, пардон)
Просто в основном тролят JS этим)
пример того что те кто тролят — вообще ничего о программировании не знают

а вы проверьте:


echo "0.1 + 0.2 = ". ( 0.1 + 0.2 ) ."\n";
$true = 0.1 + 0.2 == 0.3 ? "Equal" : "Not equal";
echo "0.1 + 0.2 = 0.3 => $true\n";

Ага, дійсно фігня. Краще б тоді вже показували усі цифри як у прикладі для JavaScript. Я хоча й знав за те, що існує особливість роботи із точністю float, але не звертав раніше уваги, що у PHP неточність може бути навіть для чисел далеких від дробно-безкінечних значень.

Не сильно удачный пример, действительно. А вот можно было бы упомянуть, что в JavaScript нет такого понятия как целое (Integer) число.
o_O :)

Google Sheets же якось зробили на JavaScript, думаю вони б не брались за такий проект, без адекватної підтримки «математики».

Хоча у вас є така вимога як «багатопоточність», а сама Node.js є однопоточною, можна ж ставити її на багатоядерний процесор, і на декілька VPS.
прочитайте, будь-ласка: stackoverflow.com/...io-model-works-in-node-js

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

Ви хочете сказати що Node.js насправді багатопоточний чи що?

Я хочу сказати, що нода асинхронна і для заявлених потреб одного інстансу вистачить. Багатопоточність була більш заявлена як неблокуючий режим. І якщо ми будемо

ставити її на багатоядерний процесор
то нам потрібно буде насамперед сконфігурувати кілька процесів,а не потоків.
P.S. AWS надає сервіси з масштабуванням.
і для заявлених потреб одного інстансу вистачить

«один інстанс» звучить не однозначно. Я використовую VPS DigitalOcean, там самим вигідним варіантом для Node.js application, по-моєму, саме $20/mo (2 Гіга оперативи, 2 ядра).

Якщо прицінюватись до «декількох десятків тисяч онлайн через websockets», то ось є вже готовий NGINX WebSocket Performance, де можна побачити що VPS’а, з указаними мною параметрами, точно не вистачить щоб тримати 50 тис. активних конектів.

На скільки я зрозумів, коли прочитав це «по діагоналі», то на 50 тис. конектів, в натяжку вистачить три таких VPS (один для nginx, і два для websockets applications). А якщо ми говоримо про нормальну роботу, а не про роботу «в натяжку», то якраз до цих трьох мабуть краще додати ще хоча б до 3-5 таких же VPS.

І якщо ми будемо ставити її на багатоядерний процесор то нам потрібно буде насамперед сконфігурувати кілька процесів, а не потоків

Я в цьому не сильно розбираюсь, можливо ви праві. Для мене один процес === один потік.

Планируется несколько сотен тысяч клиентов (несколько десятков тысяч онлайн).
Сервер — AWS.
Технология обмена данными — сокеты.
задачи — мультипоточно обрабатывать запросы с базой и клиентом.
ИМХО, Erlang.

«+»:
1. предназначенный для создания распределённых вычислительных систем (AWS вроде для такого и предназначается)
2. большое кол-во клиентов онлайн просто обязан держать (помню когда-то натыкался на инфу, что эрланг может держать в несколько раз больше одновременных соединений, чем node.js)
3. если не ошибаюсь, во фреймворке N2O как раз и используются сокеты. (N2O — наверное наиболее популярный веб-фреймворк для эрлагнга на данный момент, хотя могу и ошибаться).
4. на эрланге написан сервер Cowboy (вроде один из самых быстрых веб-серверов).
5. Может работать годами не «падая»)
6. Довольно легкий в освоении (за пару недель можно освоить основные вещи и писать для продакшена под руководством более опытного эрлангера)
7. как говорит википедия, одна из баз данных для сервисов амазона написана на эрланге — en.wikipedia.org/wiki/Amazon_SimpleDB
«-»:
1. специфический прологовский синтаксис (к которому надо еще привыкнуть)
2. есть всяки еспецифические особенности языка (из-за чего он не является языком общего назначения)
3. спецов по эрлангу думаю явно меньше, чем по мейнстримовым технологиями типа пхп, ноды или джавы

Как вариант: Elixir (который поверх эрланг машини (т.е. доступны преимущества эрланга), который имеет Ruby-подобный синтаксис и набирает популярность (во многом благодаря веб-фреймворку Phoenix и «рибиновому» синтаксису).
З.Ы. Хотя возсможно еще подойдет что-то типа Go.

. большое кол-во клиентов онлайн просто обязан держать (помню когда-то натыкался на инфу, что эрланг может держать в несколько раз больше одновременных соединений, чем node.js)
спасибо, повеселило :)

habrahabr.ru/post/145796

для сферичних у вакуумі

ну дык 10к и нода держит и эрланг. Где там про «в несколько раз больше»?

я бы посмотрел как 1 инстанс ноды держит 10к не хеллоу ворлд трафика, эрланг может таким похвастаться

Go на одном сервере держит 1.5М одновременных подключений и 150К qps не хеллоу ворлд трафика или 6М qps хелло ворлд трафика (гуглите techempower benchmarks round 12). Эрланг таким может похвастаться?

На Эрланге это можно было сделать еще в 80-х годах

странно что имея такое впечатляющее преимущество, эрланг за 40 лет не завоевал мир.

Many companies are using Erlang in their production systems:

• Amazon uses Erlang to implement SimpleDB, providing database services as a part of the Amazon Elastic Compute Cloud (EC2).

• Yahoo! uses it in its social bookmarking service, Delicious, which has more than 5 million users and 150 million bookmarked URLs.

• Facebook uses Erlang to power the backend of its chat service, handling more than 100 million active users.

• WhatsApp uses Erlang to run messaging servers, achieving up to 2 million connected users per server.

• T-Mobile uses Erlang in its SMS and authentication systems.

• Motorola is using Erlang in call processing products in the public-safety industry.

• Ericsson uses Erlang in its support nodes, used in GPRS and 3G mobile networks worldwide.

The most popular open source Erlang applications include the following:

• The 3D subdivision modeler Wings 3D, used to model and texture polygon meshes.

• The Ejabberd system, which provides an Extensible Messaging and Presence Protocol (XMPP) based instant messaging (IM) application server.

• The CouchDB “schema-less” document-oriented database, providing scalability across multicore and multiserver clusters.

• The MochiWeb library that provides support for building lightweight HTTP servers. It is used to power services such as MochiBot and MochiAds, which serve dynamically generated content to millions of viewers daily.

• RabbitMQ, an AMQP messaging protocol implementation. AMQP is an emerging standard for high-performance enterprise messaging.

я просто упомяну тут java, C# - 40 лет назад их и в проекте не было, но тем не менее сейчас это мейнстрим, а эрланг — экзотика.

Угу, в нишы формошлеперства и клепания говносайтиков эрланг за 40 лет пробиться так и не смог.

вопросов больше не имею :)

ну так синтаксис эрланга не си-шный, и даже не алголо-подобный — не удивительно, что он является экзотикой)

Просто не всем нужны распределенные stateful приложения.

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

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

Ну вот получается что весь мир вокруг, плачет, колется, жрет кактус, и в упор не замечает замечательно стоящего рядом эрланга, в котором все эти проблемы были решены еще в 80е.
В версию о том что все вокруг дебилы я не верю, остается то что в ерланге не все так шоколадно, как рассказывают.

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

Ну вот давай называть вещи своими именами: эрланг — это довльно старый(со всем сопуствущим легаси) нишевый язык программирования, со всеми плюсами и минусами присущими старому, нишевому языку программирования.

В версию о том что все вокруг дебилы я не верю
а вот это очень зря.

Я очень уважаю теорвер вообще и нормальное распределение(как ну оочень распространенное) в частности. :)

правда в том что если бы не было большинство людей дебилами, то жили бы мы все в намного более лучшем мире, а не там где мы есть

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

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

Дженерики появятся в гоу после того, как в других языках появятся интерфейсы, как в Go.

Це все нікому не потрібні казки.
Колись був делфі (він і зараз є, але хто про нього чує), з інтерфейсами і TObject-ом. І адепти криком кричали, що дженеріків нема і не потрібно — завжди можна реалізувати наслідника від TObject і засунути його в TObjectList. (Або імплементувати IUknown, зробити наслідника від TList та отримати garbage collector даром :) ).
Чим закінчилось? В делфі реалізували дженеріки.
Розумієш, дженеріки — надто зручний інструмент, для того, щоб його ігнорувати. Навіть така «тюрма» як Ада і то має доволі елегантний механізм дженеріків, який можна майже без змін здерти в го.

«От пожалуйста»! А у TypeScript (читай — у Node.js) є і дженеріки, і інтерфейси, і як після цього можна дивитись в бік Go?

Очень внушительно. Я посмотрел ваш проект, и бенчмарки, отличная работа. Но все же, я увидел серьезный отрыв fasthttp от остальных только на plaintext-бенчмарке. Во всех остальных бенчмарках, разница внутри первой двадцатки в рамках одного порядка. Так ли важен raw performance HTTP-сервера если затык по все равно в 95% случаях в бизнес-логике?

Сейчас любого языка с мало-мальски достойным асинхронным IO обычно хватает для highload нужд.

можно краткое резюме, что самое важное в этом маркетинговом видео?

с мало-мальски достойным асинхронным IO
+1

Проблема С10К не на ровно месте возникла и бурно обсуждается, равно как и стандартные способы ее решения. Соотвественно, все веб сервера, которые следуют бест практикам, в общем случае на среднем железе показывают производительность около этой цифры — а дальше вопрос тюнинга, специфики тестов, железа и все такое.
Поэтому разницы «в разы» неоткуда взяться, если канечна писать код правильно.

Я говорю не о боттлнеке в веб-сервере, а о скорости работы бизнес логики, на том-же хабре всплывали статьи в которых ребята получали прирост производительности просто от того что переписывали все на джаву.

habrahabr.ru/...ny/wargaming/blog/233343

Скорость «работы бизнес логики» это очень скользкий момент, который зависит от огромного количества факторов, как правило специфичных для конкретно взятого продукта, и язык программирования — далеко не самый решающий.
Вот в примере с нодой — подключение сишных библиотек там с рождения. В теории можно вынести бизнес логику в эту либу, а там реализовать ассемблерными вставками и получить перфоманс «бизнес логики», близкий сферическому к коню в вакууме — при условии наличия в команде гуру ассемблера :)
Но показателен ли пример — да ни разу.
В 9 случаях из 10 «перфоманс бизнес логики» никому не нужен, а среднее время обработки запроса упирается в базу данных, сетевые соединения, простои в очередях-на локах, производительность диска и все такое.

Имелись в виду определенные вычисления, а не когда просто экспозится база данных крудом. А очереди на локах это в принципе не о ноде.

«определенные вычисления» — это как сферические кони в вакууме.
Не, я безусловно верю, что есть числодробительные задачи, но причем тут «бизнес логика»?

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

martinfowler.com/articles/lmax.html
вот пример реализации описанных реквариментов на жаве. Статья написана 5 лет назад, соответственно реализации — лет 8-10. Отмечу, что за прошедшее время прогресс на месте не стоит. И эта модель вполне себе востребована бизнесом(не смотря на то что в другой ветке ты говоришь обратное), и вполне себе нормально реализуется на мейнстриме, и узкие места — персистентность и очередь сообщений(и то и то порешали в данном примере).

Причем то что вы мне написали, к обсуждению того что является реальным показателем перфоманса? Если вы хотели тыкнуть мне в лицо Фаулером то увы, я этот артикл читал.

Решается все если у тебя key-value сторадж и горизонтальное масштабирование, вопрос в том сколько инстансов серверов нужно поднять одновременно чтобы разгребать нагрузку.

А насчет востребованности бизнесом, увы но в основном если что и заходит в Украину так это или адовое легаси или запилите мне стартап за месяц.

Причем то что вы мне написали, к обсуждению того что является реальным показателем перфоманса?
именна — с цифрами и так далее. Цена серваков ет канечна интересна, но я привел статью с цифрами, могу еще про stackoverflow вспомнить.
Решается все если у тебя key-value сторадж и горизонтальное масштабирование, вопрос в том сколько инстансов серверов
«все» — не решается :)
если что и заходит в Украину так это или адовое легаси или запилите мне стартап за месяц.
бред
если что и заходит в Украину так это или адовое легаси или запилите мне стартап за месяц
Меняй галеру, твоя тонет.

і ось іще якщо не вірите в силу ерланга:

www.youtube.com/watch?v=c12cYAUTXXs

scala + akka для смелых
java + netty для консервативных
php и node.js если надо по бырому
go если хочется быть модными

а да — наймите хорошего специалиста по инфраструктуре и dba а то охренеете

WordPress для смелых
HTML для консервативных
Joomla! если надо по бырому
Drupal если хочется быть модными

а да — наймите хорошего психолога а то охренеете )

Drupal
для смелых
WordPress для
если по бырому))
scala + akka для смелых

scala + fs2, для упоротых
go если хочется быть модными
Тут дело не в моде, а в прагматичности. Go для тех, кто хочет быстрый, простой в сопровождении и расширении код.

Для модников, любителей смузи, callback и dependency hell’a есть nodejs.

Для хайлоада нужны спецы по инфраструктуре и те инструменты которыми хорошо владеет текущая команда
язык вообще не принципиален, на пхп можно удивительные вещи делать если руки ровные

callback и dependency hell’a есть nodejs

Саша, вам треба оновити пластинку, бо колбек хел вже в минулому, а про депенденсі хел... щось я такого не чув по відношенню до node.js, можливо мається на увазі peer dependencies (різними плагінами одночасно запрошуються різні версії одної й тої самої залежності), так воно вирішується просто — розробник сам вирішує «яку саме версію він ставитиме».

в go зависимостями менеджется так как их менеджили в JS 15 лет назад, ну и ничего, никто же не жалуется.

В JS до сих пор весь код принято помещать в один файл-помойку. Размер которого составляет 10Мб из-за бесполезных и не используемых в 95% случаев «зависимостей» — реального кода там максимум пару Кб. Причем для создания этого файла существует 100500 не совместимых между собой инструментов и способов.

Код зависимостей в Go достаточно просто скопировать в папку vendor.

Какой из эти способов проще и эффективнее?

В js тоже так делали 15 лет назад, складывали все в папку и подключали референсами, сейчас так мало кто делает. Вот в go делают потому что ничего лучше нету. + Бандлинг никакого отношения не имеет к менеджменту зависимостей и так же не панацея при сборке проекта во времена http2, во всем есть альтернатива в отличии от go где все предрешено за вас.

Размер которого составляет 10Мб из-за бесполезных и не используемых в 95% случаев «зависимостей» — реального кода там максимум пару Кб.
Да, проблема `dead code elimination` существует.
Ее решают. В основном за счет tree-shaking в бандлерах.

Rollup
Webpack2

Код зависимостей в Go достаточно просто скопировать в папку vendor.
В ДжС при желание тоже так же сделать можно. Но зачем?

Якщо б Go вмів все те, що виконують сервіси, про які йдеться у статті за вашим лінком, то тоді можна було казати «нащо те все, коли Go все це вміє і працює на порядок швидше», а так ви явно порівнюєте м’яке із теплим.

В статье предлагают решение hello-world-like задачи с помощью 100500 *JS инструментов и фреймворков, модных в этом году, как это принято в среде js-разработчиков. Всем пофиг, что на изучение этих инструментов нужно полгода, что половина из них устареет уже в этом году, а для решения задач такого типа не нужно никаких зависимостей — достаточно 100 строчек кода на plain old html + js и часа работы.

Якщо для виведення hello world, треба 100500 JS-інструментів, то мабуть вам не буде складно показати хоча б єдиний такий інструмент чи фреймворк, який потребує ще й піврічного вивчення, щоб можна було на ньому написати елементарне.

Plain HTML + js DOM API

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

на чем на данный момент лучше писать

Наверное на 6й версии надо, шестая фаза сегодня.

С такой постановкой вопроса, на какой технологии не пиши — фейл обеспечен :)

а серьезней, вам тут правильно советуют — найдите специалистов. Они правда за идею не работают, но без инвестиций проекты таких масштабов не взлетают.

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

Ага, консультанта за % который впарит Oracle, Weblogic и 1000 Java developer-ов

Вы правы :)
Я и забыл про мир откатов, подковёрных войн и интриг.

Не стоит, титаник тоже забыл про 90% айсберга под водой. ))

Неплохо бы еще бюджет написать и сроки. То что на Rails/Grails можно делать 12 человеко-месяцев, на Java можно делать 12 человек-лет.

з цим можна поспорити. та тому же spring boot можна дуже швидко написати проект.

Причем на реилс потом прийдеться выкинуть и всеравно переписать на джава в итоге суммарно 13 лет уйдет.

Ну это если сотни-миллионов клиентов в секунду будет. По факту с вероятностью 95%, enterprise — это говносайт кривых правил бизнес-логики для 50-500-2000 задумчивых внутренних юзеров, где Rails/Grails летает на ура. Где Java, JVM, масштабируемость, big data, кластеры просто нафиг не нужны.

50-500-2000 задумчивых внутренних юзеров

Ну если уметь, на джаве сделать чтобы это тормозило- тоже не проблема.
вероятностью 95%, enterprise
Ентерпрайз мир куда более суров чем просто формочки...
Помню мы когдато такой «ентерпрайз» с 20 формочками для какого банка писали, и нам указом сверху «нужно юзать джбосс», мы спрашиваем, накой париться с джбосом, если мы тут ща за 2 дня на легковесном томкате со спрингом все напилим. А нам отвечают что «джбосс подлежит сертификации, а томкат нет»

нашел на что жаловаться
у нашего одного клиента целевой платформой был специально для них выпиленная IBM версия websphere.
не уверен что могу распространяться — но это было незабываемо

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

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

То что вам 100% понадобиться:
1) Load balancer — чтобы распределять нагрузку между нодами, если уже на амазоне — рекомендую Elastic Load Balancer. Хотя, NGINX и HAProxy тоже хороши.
2) Мониторинг, в самом амазоне уже есть CloudWatch и он вам понадобиться чтобы мониторить нагрузку на CPU, RAM, HDD и делать auto scaling EC2 нод. Впрочем мониторинг это отдельная большая тема, но следить за утилизацией ресурсов и health системы это в современном мире must have.
3) Аггрегация логов, нужна чтобы траблшутить ошибки которые возникают на проде и не делать SSH на каждую ноду, тут стандартом является ELK стек (elastic, logstash, kibana)
4) Инструменты для provisioning, т.е. средства деплоя всей системы, при чем желательно как-то минимизировать даун тайм. Это еще одна большая тема, но советую посмортеть или на Docker или на Ansible это совершенно два разных инструмента, но они могут решать одну и ту же задачу деплоймента.
5) CI/CD Pipeline — тоже автоматизация сборки, тестирования, поддержка деплоймента без даунтаймов.

А язык... это уже не так важно, главное чтобы не .NET

Вы знаете много highload систем на AWS реализованных на .Net?

Вот прям готовы поручиться за весь enterprise? Если вы их не знаете — это не значит что их нет.

Так ведь я и спросил, знает ли автор такие системы?

Я если честно тру хайлоад не видел, от слова совсем

Здесь уже встаёт вопрос о том, что же такое highload. Крайне «сферическое» понятие.
Что при прямых руках и хорошем сервере не хайлоад, то для кривых рук и плохого сервера уже он

stackoverflow.com. Не AWS конечно, но я впринципе не знаю хайлад систем на AWS :) все как-то в свои датацентры переезжают со временем.

еще пример — сам Azure Portal (старый\новый) с .Net-ом на backend-е тоже вполне себе крупный highload

Ну у SO всего то 25-35 серверов. Им свой ДЦ по сути и не нужен.

но я впринципе не знаю хайлад систем на AWS :)
netflix, atlassian, heroku, dropbox их можно считать hl? Последний, кажется, начал частичную миграцию в свой ДЦ.

Естественно у таких проектов как netflix их и не может не быть. Но на самом деле aws использует много крупных и соотв hl проектов. При этом, конечно, не у всех проектов вся инфраструктура целиком на AWS, у того же Airbnb на aws вроде только БД, но вы представляю какие там нагрузки

Если не привязываться к амазону, то jet.com — жужжит на ажуре.

Какой смысл стыковать AWS и .нет? Правильно, никакого. Для .нет есть ажура со всякими проприетарными свистоперделками заточенымы в первую очередь под конкретную платформу. А так на .нет хватает проектов которые могут скейлится и держать нагрузку.

В начальном коменте за АВС ни слова

то вы пропустили

Планируется несколько сотен тысяч клиентов (несколько десятков тысяч онлайн).
Сервер — AWS.
Технология обмена данными — сокеты.

я ну туда смотрел... посыпаю голову пеплом

Не было бы АВС, можно было бы насоветовать всякого разного, но увы.

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

Попробуйте стандарт:
Для MVP — Php и компания — дёшево, не долго и специалистов найти легче.
Если сервис прострелит и появится необходимость — перепишите на Java и комания.

О рисках говорить сложно — вы не описали, какие задачи будет решать ваше приложение.

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

Исчерпывающе описание.
Java точно подходит для решения таких задач.
А сейчас ещё остались однопоточные приложения? )

Вопрос риторический.

К тому, что серьёзное веб-приложение и должно быть многопоточным.

Расскажите это ноде. BTW, самым эффективным в утилизации cpu приложением всегда будет однопоточное.

Самым эффективным всегда будет написанное ровными руками :)

BTW, самым эффективным в утилизации cpu приложением всегда будет однопоточное.
ЛОЛ. А остальные ядра?

А на сервере всегда ранится только один сервис?

Вы можете это контроллировать, с помощью cgroups, например в докере можно распределить ресурсы CPU между контейнерами.

На чем угодно, лишь бы хватило денег на AWS когда сотни тысяч клиентов придут )))

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

ЗЫ Сережа молодец©

я кажется понял, вы с нуля что то решили выучить ? )))
если нет- то на том на чем у вас хватает экспертизы либо у тех кто будет писать.
рельсы с сокетами дружить сложно было, плюс нагрузка большая, те не рельсы)

Ми пропонуємо зробити на Ruby, і для нас гроші не головне.....

Якщо ви «стартап», і будете перевіряти ідею, то я би радив PHP. Побудова прототипу вийде дешево.

Якщо у вас вже є гроші, ви точно знаєте що ідея робоча, юзери точно будуть, то можна брати java чи go .
Але PHP або конкуренти (RoR, node.js) також справляться при правильній реалізаації.

Якщо у вас немає солідного бюджету, то можна брати технологію яку буде знати профі, який погодиться з вами працювати

тобто php + nodejs залишаються лидерами. дякую)

в похапэ сделали поддержку tcp sockets?

там есть плюсик
небольшой такой если вы не заметили

Вам нагадують за ваші ж побажання до проекта:

Технология обмена данными — сокеты.

Але і це вміє PHP, хоча дана технологія і не є рідною для PHP.

хендлить top сокеты на node.js? Мсье знает толк в извращениях :)

можна використати ReactPHP

Чет слишком много гемороя. Не верю.

а какие технологии знаете?

ответ в стиле — какие технологии знаете такие и используйте?)

если не знаете которую решает ваши проблему выбирайте близлижайшую

Хм, удивительно, что еще никто не предложил в топике писать бек енд на js и ноде, ведь мы же живем в 2016 году, как никак xD

Потому и не предлагают, не 2014 не дворе

Запасаюсь попкорном.... Сейчас начнется.... :-)

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

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

но тема да, «пятничная»

технологии не имеют значения. они сейчас все вполне зрелые.
хоть 80% на php и 20% на ноде написать — все будет пучком, если — см мой выше.

Пучком ли оно будет, вопрос зрелости/уровня команды.

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