Tag Archives: nodejs

Server-side JavaScript – Node.js

Какво е Node.js?

nodejs

Node.js е платформа, разработена на open-source еджина за JavaScript на Google – V8. С помощта на Node.js можем да създаваме бързи и мащабни мрежови приложения. Node.js използва събития, неблокиращ I/O модел, който позволява лекота и ефективност. Перфектен е за приложения, които имат голям интензитет на прехвърляне на данни в реално време. В момента има много енергия и идеи около Node. За да разберете Node.js, ще е много полезно да осмислите някои от ключовите избори при дизайна му.

Събития и асинхронност

Node е базиран на събития и е асинхронен. Събития, като например HTTP заявка, ще изстреля JavaScript функция, която ще свърши малко работа и ще пусне други асинхронни задачи като връзка с базата или теглене на съдържание от друг сървър. Щом тези задачи бъдат пуснат, същата функция за изстрелване при събитие ще спре и Node ще заспи. В момента, в който нещо друго се случи – като установена връзка към базата или сървърът отговаря със съдържание, се изстрелва callback функция и още JavaScript код бива изпълнен, който може да пуска още асинхронни задачи. По този начин, Node.js ще разпредели много дейности за много паралелни работни потоци. Ето защо Node се справя толкова добре, когато трябва да управлява хиляди конекции едновременно.

Защо просто не използваме един процес на конекция, както всички други?

В Node новата конекция отнема много малко хийп памет. Но пускането на нов процес отнема внушително повече количество памет, мегабайт на някои платформи. Истинското натоварване обаче идва от context-switching-а (запазването на състоянието на процес, когато му свърши единицата време за изпълнение и връщането му в същото това състояние, когато му дойде отново реда за изпълнение). Когато имаме 10^6 нишки, ядрото трябва да свърши много работа, за да разбере коя ще бъде следващата пусната. Доста работа се свърши за да се разработи O(1) scheduler (планировчик), но в края на краищата е много по-ефективно да имаме един процес, който се управлява от събития от 10^6 процеса, състезаващи се за процесорно време. Също така, под голямо натоварване, мулти-процесорният модел се държи много посредствено и отнема много управляващи сървиси, особено SSHD. Това означава, че дори не можете да се логнете, за да разберете колко зле са нещата.

Как го прави Node.js?

nodejs

Node.js е едно-нишков и не заключва ресурси. Node има една нишка на процес. Заради това, е невъзможно няколко нишки да пипат по едни и същи данни едновременно. Следователно, не са нужни заключвания. Нишките са много трудни и предизвикват много трудни за проследяване бъгове. Елиминирането на някои от класовете, които отговарят за справянето на тези бъгове печели много време. Това е едно от най-големите предимства на Node.js.

Може ли Node.js наистина да се ползва за сървър?

Node е възможна опция за обслужване, но е далеч от това, което се обещава в документацията му. С Node v 0.6.x, в платформата се интегрира клъстер, осигуряващ доста важни блокове, но production.js скрипта, който трябва да се напише е пак около 150 реда код с логика, описваща създаване на лог директории, рециклиране и др. За сериозно обслужване, вие ще трябва да се подготвите поемете всички идващи конекции и да направите всичко, което Apache прави за PHP. Rails има същия този проблем. Той е разрешен чрез два допълнителни механизма:

  1. Rails/Node да се сложи зад самостоятелен уеб сървър (написан на C и тестван сериозно) като Nginx (или Apache/Lighttd). Уеб сървърът ще може успешно да се занимава със статичното съдържание, системата за достъп, редактирането на URL-та, да налага ограничения в правата и да управлява под-услуги. За заявки, които са предназначени за node service, уеб сървърът му дава пълномощно
  2. Използване на framework като Unicorn, който да управлява процесите, да ги зачиства периодично и така нататък. Все още няма читав подобен framework.

Четейки frameworks като Express карат човек да повярва, че стандартната практика е просто човек да прекара всичко през Node service… “app.use(express.static(__dirname + ‘/public’))”. За услуги, които са леки, това може да бъде прекрасно. Но в момента, в който опитате да натоварите вашата услуга и да я пуснете да е активна 24/7, ще осъзнаете защо големите сайтове използват сериозен код на C отзад като Nginx, който да се занимава с всички заявки за статично съдържание.