Высоконагруженные системы, каковы принципы разработки?

Question

[SolidMinus]

Всем привет, каковы принципы разработки высоконагруженных систем?

А то вот в некоторых книгах приводят использование cgi-скриптов на python, использование python из скриптов на php и т.д. Безопасно ли это вообще в плане стресс-ситуаций, когда пользователей очень много?

Как разрабатывать сетевые сервисы на сокетах в случаях высокой нагрузки? Как?

Какие языки лучше использовать для этого? Какие не использовать?

Спасибо

Comments

[un1t]

cgi? может быть все-таки fast-cgi?

Answer 1

[Сергей Протько]

давайте так, есть два вида задач:

- CPU bound - различные алгоритмы, математика, кодирование/декодирование/шифрование... словом все что нагружает процессор.
- I/O bound - собственно когда у нас идет множество операций с вводом/выводом, где-то 90% задач связанных с WEB и серверной разработкой.

Для CPU bound стоит использовать языки вроде Си, Rust, Dlang, Go и т.д. Словом языки которые компилируются в эффективный машинный код.

Для I/O bound - Go, NodeJS, Erlang, Java.... да в принципе не важно какой язык, главное что бы использовались неблокируемые вызовы и отсутствовали блокировки.

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

Какие языки лучше использовать для этого? Какие не использовать?

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

Еще не стоит забывать о алгоритмах. Они тоже должны быть оптимальны. Например взять простую задачу - кластеризация меток на карте. Представьте что у вас в базе миллион объектов, которые мы должны выводить на карте. Поскольку делать подобное на клиенте будет проблематично - мы должны делать это на сервере и возвращать на клиент ровно столько данных сколько ему нужно.

И на таких объемах даже если бы мы взял Си, если наш алгоритм имеет сложность O(N^2) то как бы ничего тут особо не поделать. И так и так медленно будет. А вот если мы возьмем какие-либо алгоритмы имеющие сложность O(NLogN) то уже возможно что алгоритм этот можно хоть на php/python/ruby имплементить. Так например у меня этот алгоритм реализован на Java и не самым эффективным образом. Справляется.

Еще влияет скорость разработки (всякие ruby/python/node в этом плане хороши), стоимость поддержки (Си поддерживать сильно дороже чем Go например, хотя всегда можно написать все настолько плохо что проще выкинуть чем поддерживать), стоимость разработчиков.... Скажем найти дешевых сильных разработчиков на Go или Rust будет весьма проблематично.

Так же не стоит забывать что сервера нынче стоят не так дорого. Иногда бизнесу проще доплатить за еще десяток серверов нежели писать все на плюсах.

Собственно главное правило высоконагруженных систем - нагрузочное тестирование а потом уже оптимизации

Answer 2

[Тимур Шемсединов]

Про cgi, python, php, apache нужно сразу забыть. Лучше забыть и про http и вебсокеты. А смотреть на C/C++, node.js, Go, in-memory базы данных, TCP сокеты.

Comments

[SolidMinus]

Спасибо, in-memory базы данных это что-то вроде SQLite? Я где-то слышал, что СУБД наоборот лучше

И TCP-сокеты использовать многопоточность или асинхронные сокеты?

[Тимур Шемсединов]

Архитектура важнее алгоритмов и языков, о чем уже сказали, но еще важнее - построить хорошие структуры данных и выбрать хорошие протоколы. От структур данных зависят алгоритмы, которыми они будут обрабатываться, с плохими структурами нельзя написать хороший алгоритм. А от протоколов зависит производительность сервера и скорость обмена данными между компонентами системы (например, между СУБД и сервером, сервером и клиентом, двумя разными серверами или сервисами). Вот HTTP и прочие технологии ветхого веба ни как не подходят для высоконагруженных задач. Часто имеет смысл выбирать язык и платформу, которая имеет хороший менеджер памяти и способную держат в памяти и эффективно обрабатывать большие структуры данных, есть языки построения запросов к in-memory данным, смысл в том, чтобы СУБД не дергать, диск не дергать и вообще не делать I/O, кроме работы клиентом по сети.

[Сергей Протько]

Тимур Шемсединов: а что вы скажите о HTTP2?

[Тимур Шемсединов]

Сергей Протько, скажу, что это очень сложное решение простой проблемы, берем TCP + JSON и получаем в тысячу раз более гибкое решение, двунаправленный с установлением соединения и гарантированной доставкой транспорт, к которому за час дописывается переподключение при разрывах, вызов удаленных процедур и транслация событий.

[Сергей Протько]

Тимур Шемсединов: tcp + messagepack вы хотели сказать?) зачем тратить время на десериализацию данных.

[Сергей Протько]

Тимур Шемсединов: в целом я вижу смысл переходить на вещи вроде zeromq (не голые же сокеты использовать, да?) только тогда когда http узкое место, как минимум потому что дебажить и поддерживать проще. Сколько уже команд обожглось от этих преждевременных оптимизаций.

[Тимур Шемсединов]

Сергей Протько, я использовал ZMQ года два, но в результате и от него избавился и сейчас на голом TCP гоняю даже не JSON, а JavaScript. А парсить его заставляю V8. HTTP всегда узкое место, он настолько плохо спроектирован, что уход на сокты подымает производительность даже не в разы, а на несколько порядков. Обслуживать HTTP гораздо накладнее, чем написать свой протокол на более чем 10 языках, что мы и сделали.

[Сергей Протько]

Тимур Шемсединов:

> даже не JSON, а JavaScript

что-что простите? Тип нэйтив экстеншенами структурки гоняете в сыром виде? Ну так это же на корню убивает возможность заимплементить другую часть системы на чем-то другом нежели js. И я не думаю что способ этот эффективнее messagepack или thrift.

[Тимур Шемсединов]

Не нативные структуры, а синтаксис js. Сергей Протько, более 10 реализаций: несколько на js и node, несколько на c/c++, несколько на java, objective-c, swift, c#, python, haskell, php, go. Ну и с возможностью как гонять объекты/хеши, так и гонять массивы, к которым на удаленной стороне через заранее заготовленный прототип цепляются геттеры и сеттеры для обращения к полям по именам.

[Сергей Протько]

Тимур Шемсединов: еще раз, что значит "синтаксис JS" в контексте структур данных? Данные гоняются в бинарном или текстовом виде? Если первое - то чем это отличается от messagepack/thrift? Если второе - то это же json, нет?

[Тимур Шемсединов]

Да, Сергей Протько, в виде синтаксиса JS, текстового. JSON это не JS, на JS можно описать много всего, чего в JSON нельзя или не удобно. Например, в JSON [null,null,null,100], а в JS это же [,,100] и можно писать выражения, функции, конструкторы, что угодно и совершенно безопасно парсить их в v8 sandboxes:

{
  name: ['Marcus', 'Aurelius'].join(' '),
  passport: 'AE' + '127095',
  birth: {
    date: new Date('1990-02-15'),
    place: 'Rome'
  },
  age: function() {
    var difference = new Date() - birth.date;
    return Math.floor(difference / 31536000000);
  }
}

Конечно, обычно все это не применяется, а вместо этого позиционная передача, т.е. массивы, которые присвоением прототипа превращаются в объекты ['Ukraine','Kiev','03056','Pobedy','37',1,158]

[SolidMinus]

Тимур Шемсединов: как-то меня смущает элемент 'Ukraine' и элемент 'Pobedy', неужели укрособытия добрались и до вопроса с высоконагруженными системами...

[Тимур Шемсединов]

SolidMinus: Это адрес Национального Технического Ордена Ленина Университета Украины имени 50-летия Великой Октябрьской Социалистической Революции Киевского Политехнического Института Императора Александра II

[SolidMinus]

Тимур Шемсединов: а, эм, хм. Ну и название.

[Сергей Протько]

Тимур Шемсединов: короче недо-json. Понятно. Не понятно только зачем. Попахивает плохими архитектурными решениями и кастылями.

[Тимур Шемсединов]

Сергей Протько, это JSON недо-JavaScript, а парсеры JavaScript есть везде, в любой системе, и можно использовать сам V8, как парсер, мы так делаем и это работает быстро, со всеми оптимизациями, на порядок быстре JSON.

[Сергей Протько]

Тимур Шемсединов: вы имеете в виду использовать биндинг v8 как парсер? Попробуйте messagepack, я думаю он будет проще и быстрее.

[Тимур Шемсединов]

Сергей Протько, да, если в систему уже встроен v8, то зачем еще что-то, он делает скрытые классы для того, что парсит, да и JS хорошо поддерживается везде, ничего особо писать не нужно и в Qt и в iOS и в Android и в Java и в C#, только обертку сделать, да и парсить его не сложно, у нас есть сравнение двух десятков способов парсинга разными методами и на разных платформах. Бинарная сериализация не даст выигрыша, если это не нативный формат данных в памяти v8 или другого движка. Но к движку привязываться не хорошо.

[Сергей Протько]

Тимур Шемсединов:

> Бинарная сериализация не даст выигрыша, если это не нативный формат данных в памяти v8 или другого движка.

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

[Тимур Шемсединов]

Сергей Протько, а я потестирую messagepack, вдруг он окажется быстрее zmq и протобуфа.
Когда SDK будет не в бете, то выложу статью на Хабр.

Answer 3

[xmoonlight]

Добавлю, что для повышения производительности можно использовать микросервисы, написанные на C/C++ и контролируемых менеджером. А обращаться к менеджеру уже посредством сокета или через БД, давая задачи на выполнение.
А всё формирование страниц - отдать PHP (к примеру). В итоге получится синхронная система с полу-автоматической разделяемой нагрузкой на CPU, которую можно довести до автоматической путём создания сбалансированных правил распределения нагрузки на CPU разными модулями в различных ситуациях.

Answer 4

[Владимир Владимирович]

https://leha2148.000webhostapp.com/develop.html